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.
-Brian
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
