[Mesa-dev] Samping GL_R32UI?

[Roland Scheidegger]

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...
> 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...

Roland


> Roland
> 
>> Even with KHR_debug enabled and set to use
>> DEBUG_SEVERITY_NOTIFICATION, I don't seem to get any error or warning
>> messages about this.
>> It seems like incomplete textures would be a very handy thing to know
>> about when debugging.
>>
>> Thanks again,
>>
>> Andrew
>>
>> On Wed, Feb 1, 2017 at 5:31 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 01.02.2017 um 05:32 schrieb Andrew A.:
>>>> Are there any known issues with using usampler2D on a GL_R32UI texture
>>>> in llvmpipe from within a VS/FS? I'm getting expected results on
>>>> Nvidia drivers (proprietary), but not with mesa llvmpipe (always get
>>>> zero).
>>>
>>> Not that I know of. There should be plenty of tests testing this.
>>> My best guess is your texture is incomplete - nvidia is known to ignore
>>> this for some cases but mesa would not.
>>> This would affect all mesa drivers presumably, not just llvmpipe.
>>> (This silent "non-error condition" is quite nasty and non-obvious in
>>> some cases - for instance if you use texelFetch which ignores all
>>> ordinary texture parameters such as wrap modes or filtering, however
>>> according to OpenGL rules the texture would still be incomplete
>>> depending on min/mag filter - and I know nvidia would ignore this
>>> particular case.)
>>>
>>> Roland
>>>
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>