[Mesa-dev] [Mesa-stable] [PATCH 1/2] mesa: default DEPTH_TEXTURE_MODE should be RED in the core profile

[Kenneth Graunke]

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 <kenneth at 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