Bug 76919 - Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)
Summary: Random junk at the bottom of non-multiple-of-4 compressed textures (original ...
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: 10.1
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-01 20:07 UTC by Darren Salt
Modified: 2019-09-18 19:15 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Example image (with mipmaps), the height of which triggers the problem (190.73 KB, application/octet-stream)
2014-04-01 20:07 UTC, Darren Salt
Details

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.