Bug 76919

Summary:	Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)
Product:	Mesa	Reporter:	Darren Salt <bugspam>
Component:	Drivers/Gallium/r600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	eero.t.tamminen, lemody
Version:	10.1
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Example image (with mipmaps), the height of which triggers the problem

Description Darren Salt 2014-04-01 20:07:47 UTC

Created attachment 96745 [details]
Example image (with mipmaps), the height of which triggers the problem

There seems to be a problem with some compressed textures. When the height of the image (more specifically, of the mipmap level used) is not a multiple of 4, it appears that the bottom part of the image – as rendered – contains random junk, apparently set at image load time.

The example image will show the problem at its original size. I've also played with its height (initially 570px): increasing it to a multiple of 4 would remove the problem if it's rendered using the full-size version, but since when reduced by one level the height is again not a multiple of 4, the problem re-appears. Setting the full-size height to 576px moves the problem down further.

(We're using http://crunch.googlecode.com/svn/trunk/ for image (de)compression.)

Comment 1 Tapani Pälli 2014-04-02 10:02:40 UTC

I don't know details of the problem here but I got interested and went to read the spec ..

EXT_texture_compression_s3tc specification states in "Implementation Note":

"If the width or height is not a multiple of four, there will be 4x4 blocks at the edge of the image that contain "extra" texels that are not part of the image."

I'm not sure though what should happen if one samples/reads such texel.

Comment 2 Darren Salt 2014-04-06 01:34:16 UTC

I'm not sure either, but I'd (naïvely) expect the image height not being a multiple of 4 not to matter.

Comment 3 Darren Salt 2014-05-09 02:04:47 UTC

Turns out that the bug also affects the right edges of textures.

(Evergreen, in case there's something hardware-specific about this.)

Comment 4 Tapani Pälli 2014-05-19 12:09:45 UTC

Are you able to reproduce this bug with simple program using a standard dds file? If this is possible, please attach such example.

Comment 5 Eero Tamminen 2014-12-31 09:04:50 UTC

Bug 86747 (on Intel GPU) could also be due to DXT texture mipmap levels not being multiple of 4.

Comment 6 Tapani Pälli 2015-03-16 12:32:29 UTC

please attach a test case

Comment 7 GitLab Migration User 2019-09-18 19:15:48 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/503.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.