glIsEnabled( GL_UNIFORM_BUFFER_UNIFIED_NV ) --> GL_INVALID_ENUM

Gaming and Visualization Technologies APIs OpenGL
#1

This seems to be a bug in the NVIDIA Graphics Driver (tested on latest 472.47 Win10 drivers), and should be a trivial fix for one of the NVIDIA OpenGL driver developers.

PROBLEM: Calling glIsEnabled( GL_UNIFORM_BUFFER_UNIFIED_NV ) results in a GL_INVALID_ENUM error

According to:

this should be valid.

By contrast, the other 3 NV bindless enables can be queried successfully via glIsEnabled() without tripping a GL error. So it appears support for GL_UNIFORM_BUFFER_UNIFIED_NV was just never added.

#2

Hello @Dark_Photon!

Thank you for pointing this out. Did you try if this is only a problem of glIsEnabled() reporting GL_INVALID_ENUM or is it also not possible to use the extension?

I will also check with our internal experts.

#3

Thanks for the reply, @MarkusHoHo.

The core of the extension definitely works properly. We’ve been using that successfully here for > 1 year for accessing UBOs in shaders. i.e.:

  • gl{Enable,Disable}ClientState( GL_UNIFORM_BUFFER_UNIFIED_NV ) and
  • glBufferAddressRangeNV ( GL_UNIFORM_BUFFER_ADDRESS_NV, ... ) and

The problem seems to be limited to glIsEnabled() queries for GL_UNIFORM_BUFFER_UNIFIED_NV specifically. I found this problem by adding some debugging code that “distrusts” the engine’s GL state tracking and queries GL directly to verify the currently-active values in the context.

#4

Thank you for the additional details!
I was able to reproduce the behavior also on the newest driver. But I am pretty sure it is not a real bug but rather an oversight in the original specification text. I think glIsEnabled should not have been mentioned there in the first place. From a functionality standpoint it does not make sense, since it is not a feature that can be enabled/disabled and there is a difference to EnableState/DisableState. And querying for Extension availability is not done this way either, but rather by using glGetStringi().

Nevertheless I brought this to the attention of our engineering team to decide how this should best be handled.

#5

Ok, good. Thanks for testing it.

Actually, yes it is a feature that can be enabled/disabled. Just as the other 3 bindless enables can:

glEnableClientState( GL_VERTEX_ATTRIB_ARRAY_UNIFIED_NV );  // Vertex attribute buffer access
glEnableClientState( GL_ELEMENT_ARRAY_UNIFIED_NV );        // Index buffer access
glEnableClientState( GL_DRAW_INDIRECT_UNIFIED_NV );        // DRAW_INDIRECT buffer access
glEnableClientState( GL_UNIFORM_BUFFER_UNIFIED_NV );       // UBO buffer access     <--------------

as defined in these OpenGL extensions:

#6

What I meant was the distinction between the Server side glEnable() and the Client side glEnableClientState().

Since UBO handling is defined as a Client side state it seems unlikely that you should be able to query it as a server side capability.

#7

Hi @MarkusHoHo. I understand what you’re saying. However, this is in conflict with every OpenGL extension spec I’ve found that calls out how to query the current state of client state enables, including NVIDIA’s.

It is very clear that OpenGL supports querying client-side or server-side enable states glIsEnabled().

For example, search for EnableClientState in the following:

Also related to this, see Issue (9) in EXT_direct_state_access.

#8

Thank you for pointing this out!

Clearly my OpenGL is a bit rusty.

As I said, I already filed a bug and will try to get clarification.

#9

Great – thanks!