1
\$\begingroup\$

I'm in the process of migrating our object oriented OpenGL wrapper from 3.3 core to 4.5 core.

Some OpenGL implementations are notoriously permissive on what inputs they'll accept which can make tracking down bugs difficult. Wherever possible the inputs to our wrapper are validated with asserts to keep them in line with the spec.

While setting up the asserts for glTextureStorage3D I've noticed that according to this page on the Khronos website it only accepts the following sized depth types: GL_DEPTH_COMPONENT32F, GL_DEPTH_COMPONENT24, GL_DEPTH_COMPONENT16, GL_DEPTH32F_STENCIL8 or GL_DEPTH24_STENCIL8.

Non-floating point 32bit depth types seem to be missing from that list which leads me to believe they're no longer supported (or at least actively discouraged). There's also this answer to another question which states that:

GL_DEPTH_COMPONENT32 is probably overkill, and as of 4.5, isn't a required format for OpenGL implementations to support (though 16 and 24 bit ones are).

I have tried to find some reference to this in the 4.5 core spec but turned up nothing.

Is GL_DEPTH_COMPONENT32 a deprecated size type? If so, why?

\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

Typically, I've managed to find the answer almost immediately after asking the question.

§8.5.1 TEXTURE IMAGE SPECIFICATION, p201Sized Types Table

...

Implementations are required to support at least one allocation of internal component resolution for each type (unsigned int, float, etc.) for each base internal format.

This seems to say that yes the format is deprecated. It appears the format is not deprecated but is now optional and may not be available on all OpenGL 4.5 implementations. The reason is that only one type (int, float, etc) needs to be supported for each resolution (8, 16, 24, 32, etc).

\$\endgroup\$
3
  • 1
    \$\begingroup\$ "Not required to be implemented" is not the same as "deprecated"; the language of the spec indicates that an implementation can indeed advertise support for GL_DEPTH_COMPONENT32, that you can test for it, and you can use it if present, and you would still be conformant. I.e. it's not a deprecated format, it's an optional format. \$\endgroup\$
    – Maximus Minimus
    Commented Feb 21, 2019 at 9:56
  • \$\begingroup\$ @MaximusMinimus you are correct on the semantics. In this case they are functionally the same for me though because I won't be allowing anything that isn't guaranteed across all conformant implementations. \$\endgroup\$
    – Fibbs
    Commented Feb 21, 2019 at 21:57
  • \$\begingroup\$ That's a very reasonable thing to do. \$\endgroup\$
    – Maximus Minimus
    Commented Feb 21, 2019 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .