[Mesa-dev] Samping GL_R32UI?

Brian Paul brianp at vmware.com
Thu Feb 2 15:40:30 UTC 2017

On 02/02/2017 08:13 AM, Roland Scheidegger wrote:
> Am 02.02.2017 um 16:00 schrieb Roland Scheidegger:
>> Am 02.02.2017 um 09:11 schrieb Andrew A.:
>>> Thank you for the help! It was indeed an incomplete texture issue.
>>> Setting the MIN/MAG filters to GL_NEAREST ended up resolving it.
>>> I did have one other question -- why is this considered a silent
>>> non-error condition?
>> I did put quotation marks around that :-).
>> Incomplete textures have been like that since day one in OpenGL (or
>> rather, since GL got support for textures). Not considered an error, you
>> just get all black, even though really everybody would consider that an
>> error in practice...

Actually, the original fixed-function pipeline expected to get white 
texture samples from incomplete textures and I remember a screen saver 
from many, many years ago that depended on that behavior.

But yes, with GLSL, sampling an incomplete texture returns black.

FWIW, GL 1.0 had textures, but not texture objects.

>> Maybe it's because this error is only detectable at draw command time,
>> and there weren't really any errors which got detected (and returned as
>> such) with draw commands then (just invalid parameters of draw itself).
>> Albeit this is no longer the case now. But really I have no idea... And
>> yes it is annoying and sometimes makes for interesting debugging
>> (especially since some vendors don't actually implement it as literal as
>> the spec says in cases the filters don't matter and don't even warn
>> about it...).
> I forgot to mention, mesa can warn about this -
> MESA_DEBUG=incomplete_tex should do it with a debug build. Maybe though
> this should always be logged through KHR_debug (especially since in
> contrast to incomplete fbos, there's just no way to query it from GL),
> I'm not familiar with that part...

That's a good idea.  I may look into it if I have spare time.


More information about the mesa-dev mailing list