[Mesa-dev] Samping GL_R32UI?
sroland at vmware.com
Thu Feb 2 16:37:34 UTC 2017
Am 02.02.2017 um 16:40 schrieb Brian Paul:
> 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.
Wow that's really crazy...
> But yes, with GLSL, sampling an incomplete texture returns black.
> FWIW, GL 1.0 had textures, but not texture objects.
Ahh right my bad, even with nice internal format support of 1,2,3,4 :-).
I somehow thought it was a 1.1 feature. So that incomplete behavior was
indeed there since day 1 (I think the all-white behavior was due to
pretending like texture mapping was disabled in this case?).
>>> 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