| Bug ID | 101224 |
|---|---|
| Summary | texelFetch(usampler) returns black color |
| Product | Mesa |
| Version | 17.1 |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | pmjobin@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created at=
tachment 131561 [details]
texint.c test case + reference images
I isolated the issue in the provided texint.c test case which attempts to d=
raw
two identical bars by sampling a ramp pattern stored inside the red channel=
of
a texture. The top bar is drawn using sampler1D ('tex' in the code). The bo=
ttom
one is drawn using usampler1D and an integer texture ('texint' in the code).
Running the test under Mesa 17.1.1 (Fedora 26) yields a solid black bar for=
the
usampler1D case (bottom) rather than the expected ramp pattern (ref: bad.pn=
g).
Running the same code on the same hardware in Windows 10 + Radeon Crimson
ReLive Edition 17.5.2 yields two identical red ramps (ref: good.png).
Relevant lines from glxinfo:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.10.0 /
4.11.3-300.fc26.x86_64, LLVM 4.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.1
Thanks for the report. I can reproduce this, and I'll investig= ate.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTOURBUG |
Your texture is incomplete, because you left Min/Mag filters a= t GL_LINEAR / GL_LINEAR_MIPMAP_NEAREST, which is an incorrect setting for integer texture= s. You need to switch both to GL_NEAREST instead. It's a bug in the Windows driver that this condition isn't flagged.
Nicolai, First and foremost, I wish to thank you for your time and support. I applied the fix you recommended and now, the testcase behaves as expected. You mention the incompatible filtering parameter "condition being flag= ged" but prior to filling a bug report, I did run the testcase against a debug conte= xt (as well as under apitrace) and obtained no diagnostic information whatsoev= er about the texture lack of completeness. I understand that integer textures are incompatible with filtering settings other than GL_NEAREST but I did expect glTextureStorage to take care of tha= t as it receives the internal format argument. It does take care of mipmap setti= ngs afaik. As a suggestion, would it be possible for the driver to at least generate a ARB_debug_output message when linear filtering is applied to an integer texture? (especially since this is a default setting) I wouldn't have suspe= cted a driver bug if I had been made aware of my mistake in some shape or form. Thank you again, PM
Hi Pierre-Marc! Conceptually, glTextureStorage can't take care= of the sampler settings unfortuantely because of the possibility of having separate sampler objects. I agree with you though that having a debug message on incomplete textures would be useful.
FWIW, in Mesa debug builds, you can set the environment variab= le MESA_DEBUG=3Dincomplete_tex, and it will print out information about incomp= lete textures. Might be a nice project for somebody to hook that up with ARB_debug_output.
This is certainly not the first time it came up fwiw, especial= ly since there's binary drivers which will just ignore the incomplete texture since obviously that sampler state isn't needed at all for texture fetch (yes technically t= hey are wrong). It is also very easy to miss since it's really not obvious you = have to worry about it for texel fetches (it is logical given how the incomplete texture is defined, but still sort of surprising, especially when you might have experience with d3d10 which doesn't have sampler state at all for just fetches (loads)). So I think everybody agrees hooking that detection up with ARB_debug_output would be a good idea.