| Priority | medium |
|---|---|
| Bug ID | 76919 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Random junk at the bottom of non-multiple-of-4 compressed tex= tures (original or mipmapped) |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | bugspam@moreofthesa.me.uk |
| Hardware | Other |
| Status | NEW |
| Version | unspecified |
| Component | Drivers/Gallium/r600 |
| Product | Mesa |
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 o= f 4, it appears that the bottom part of the image =E2=80=93 as rendered =E2=80= =93 contains random junk, apparently set at image load time. The example image will show the problem at its original size. I've also pla= yed 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://cru= nch.googlecode.com/svn/trunk/ for image (de)compression.)
| What | Removed | Added |
|---|---|---|
| Hardware | Other | x86-64 (AMD64) |
| OS | All | Linux (All) |
| Version | unspecified | 10.1 |
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 N=
ote":
"If the width or height is not a multiple of four, there will be 4x4 b=
locks at
the edge of the image that contain "extra" texels that are not pa=
rt of the
image."
I'm not sure though what should happen if one samples/reads such texel.
| What | Removed | Added |
|---|---|---|
| Attachment #96745 mime type | text/plain | application/octet-stream |
I'm not sure either, but I'd (na=C3=AFvely) expect the image h= eight not being a multiple of 4 not to matter.
Turns out that the bug also affects the right edges of textures. (Evergreen, in case there's something hardware-specific about this.)
| What | Removed | Added |
|---|---|---|
| CC | lemody@gmail.com |
Are you able to reproduce this bug with simple program using a= standard dds file? If this is possible, please attach such example.
Bug 86747 (on Intel GPU) could also be due to DXT texture mipmap levels not being multiple of 4.
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
| What | Removed | Added |
|---|---|---|
| Status | NEEDINFO | RESOLVED |
| Resolution | --- | MOVED |
-- 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.