Created attachment 131561 [details] texint.c test case + reference images I isolated the issue in the provided texint.c test case which attempts to draw 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 bottom 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.png). 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 investigate.
Your texture is incomplete, because you left Min/Mag filters at GL_LINEAR / GL_LINEAR_MIPMAP_NEAREST, which is an incorrect setting for integer textures. 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 flagged" but prior to filling a bug report, I did run the testcase against a debug context (as well as under apitrace) and obtained no diagnostic information whatsoever 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 that as it receives the internal format argument. It does take care of mipmap settings 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 suspected 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 variable MESA_DEBUG=incomplete_tex, and it will print out information about incomplete 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, especially 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 they 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.
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.