On 07/22/2013 03:58 PM, Marek Olšák wrote:
There are a couple of reasons why this was missed:
So, I wrote nearly this exact patch in November:
http://lists.freedesktop.org/archives/mesa-dev/2012-November/030209.html
And it was rejected, which explains my skepticism.
1) The depth texture mode doesn't exist in the core profile, so the
core spec doesn't and cannot specify what the default should be, so
that's why nobody updated it.
Correct - DEPTH_TEXTURE_MODE doesn't exist. However, the spec can still
specify what gets returned when you sample from a depth texture.
Which I believed it did: in the OpenGL 3.0 through 4.1 specs, Appendix E
(lists of deprecated stuff) states:
"* Depth texture mode - DEPTH TEXTURE MODE. Section 3.8.14 is to b
changed so that r is returned to texture samplers directly, and the
OpenGL Shading Language 1.30 Specification is to be changed so that
(r, r, r, 1) is always returned from depth texture samplers in this
case."
However, in 4.2 this changed to:
"[...] the OpenGL Shading Language 1.30 Specification is to be changed
so that (r, 0, 0, 1) is always returned from depth texture samplers in
this case."
I interpreted this as the GL spec saying that it should be treated as
LUMINANCE in OpenGL 1.x -> 4.1, and RED in 4.2...regardless of
core/compatibility. Which is insane.
However the 4.1 core spec says:
"3.8.9 Depth Component Textures
Depth textures and the depth components of depth/stencil textures can
be treated as RED textures during texture filtering and application
(see section 3.8.16). The initial state for depth and depth/stencil
textures treats them as RED textures."
I hadn't seen across this text before. It also appears in the OpenGL
3.1 specification, and seems quite clear, and sensible. It also sounds
much more authoritative than the text I saw.
Apparently it works like this:
- Core: RED
- Forward Compatible: RED
- Compatibility or <= 3.0: LUMINANCE
- ES2 with OES_depth_texture: LUMINANCE
- ES3 for unsized formats: RED
- ES3 for sized formats: LUMINANCE
(The ES3 rules are crazy and cooked up by the Khronos ES workgroup after
we started filing bugs. The problem is that ES2 can be silently
promoted to ES3, yet OES_depth_texture is incompatible with the original
ES3 text.)
So, based on the new text you've found, I'm happy with this change.
It's the only sane solution anyway.
Patch 1 is:
Reviewed-by: Kenneth Graunke <kenn...@whitecape.org>
2) The default TBO format is LUMINANCE8 according to the ARB_tbo spec,
so apparently the default value was copied from there. However the GL
core spec is different again and says R8 is the default format. This
was also missed because the piglit test expects LUMINANCE8 and also
because proprietary drivers don't support 3.1 without
ARB_compatibility (I assume the piglit tests had been tested on
proprietary drivers first).
I guess we should stop exposing ARB_tbo, because it conflicts with the
GL core spec.
BTW I have also sent some fixes for piglit. We just lack a test for
the depth textures being treated as RED by default.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
