OpenGL ES: What extensions allows depth textures to be filterable?

[greggman]

The OpenGL ES 3.2 spec section seems to say that depth textures are not filterable 8.17 page 207

Using the preceding definitions, a texture is complete unless any of the following conditions hold true:

...

• The texture is not multisample; either the magnification filter is not NEAREST, or the minification filter is neither NEAREST nor NEAREST_- MIPMAP_NEAREST; and any of

  • The effective internal format specified for the texture arrays is a sized internal depth or depth and stencil format (see table 8.11), and the value of TEXTURE_COMPARE_MODE is NONE.

My understanding of that is that in OpenGL ES 3.2 depth textures are not filterable. Maybe I'm not finding it but I don't see any extension that would make them filterable. OES_texture_float_linear doesn't mention depth formats.

[null77]

I don't know of such an extension Gregg. Are you expecting there to an extension that allows non-nearest sampling on depth/stencil?

edit - it seems though filtering is maybe allowed when using a compare mode

[pdaniell-nv]

There is a little more detail on page 214 of the OpenGL ES 3.2 spec describing how filtering affects the depth comparison reference value fetched.

[greggman]

I'm expecting something to tell me if depth textures are filterable. The spec says "implementation defined" so they may or may not be filterable even when using TEXTURE_COMPARE_MODE is COMPARE_REF_TO_TEXTURE

Effectively it sounds like the only way to find out is to render and check if the result is filtered.

[kenrussell]

Could the WebGL working group please ask for a bit more detail and clarification from the OpenGL ES working group to help resolve https://github.com/KhronosGroup/WebGL/issues/3359 ?

Right now with TEXTURE_COMPARE_MODE=COMPARE_REF_TO_TEXTURE and a non-NEAREST TEXTURE_MIN_FILTER or TEXTURE_MAG_FILTER, OpenGL ES implementations can choose whether or not to sample more than one depth texture value.

Is there any way to determine what the implementation's behavior will be at the API level, other than doing a render?

We are trying to determine whether WebGL should define an extension ("WEBGL_depth_texture_linear"?), do a render itself at startup time to see whether the implementation would support it, and require it to be enabled in order to enable this implementation-dependent filtering behavior. If not supported and enabled, then WebGL implementations would force the TEXTURE_MIN_FILTER/TEXTURE_MAG_FILTER to NEAREST for these textures even if the application requested, for example, LINEAR.

Thanks for reconsidering this, and any general advice about portability issues between platforms and GPUs that the OpenGL ES working group has seen in this area.

[pdaniell-nv]

Thanks for reconsidering this, and any general advice about portability issues between platforms and GPUs that the OpenGL ES working group has seen in this area.

@kenrussell We discussed this in the joint OpenGL/ES working group meeting today. We're not aware of a way currently for the application to query the behavior of the implementation when the filtering is not NEAREST. A quick poll of the members present suggests there are at least three different behaviors.

It appears the OpenGL spec for this is the same as OpenGL ES. For Vulkan it doesn't appear this is specified: https://www.khronos.org/registry/vulkan/specs/1.3/html/vkspec.html#textures-depth-compare-operation.

Effectively it sounds like the only way to find out is to render and check if the result is filtered. At this time that sounds like the best way forward short-term. With that in place it would be interesting to see what the behavior is of all the implementations and whether we can practically categorize it for a future extension.

[pdaniell-nv]

I filed an internal Vulkan issue here: https://gitlab.khronos.org/vulkan/vulkan/-/issues/3058

[pdaniell-nv]

FYI this is actually mentioned in the Vulkan spec, it just in a different place that expected. It's in the 34.2. Format Properties section in the description for VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT:

If the format being queried is a depth/stencil format, this bit only specifies that the depth aspect (not the stencil aspect) of an image of this format supports linear filtering, and that linear filtering of the depth aspect is supported whether depth compare is enabled in the sampler or not. Where depth comparison is supported it may be linear filtered whether this bit is present or not, but where this bit is not present the filtered value may be computed in an implementation-dependent manner which differs from the normal rules of linear filtering. The resulting value must be in the range [0,1] and should be proportional to, or a weighted average of, the number of comparison passes or failures.

This is essentially the same as the OpenGL ES spec and also allows implementation-defined behavior.

[pdaniell-nv]

I think the next step for this is to propose an extension for OpenGL ES so implementations can advertise their implementation-defined behavior, or applications can do a quick test to measure what the implementation does. Do we need to keep this issue open?