glGenBuffers has corruption issues on several cards of RTX Ada family

[Fabrice_Mollo]

Hi,
I found two big issues with Opengl API, occuring “only” with graphics cards RTX Ada, all latest drivers:

• NVIDIA RTX A2000 12GB/PCIe/SSE2 - 4.6.0 NVIDIA 572.16
• RTX3000 Ada edition notebook, with the latest studio driver (Jan 2025)
• Nvidia RTX 2000 Ada Generation 16Gb

First, our professional 3D engine is working well since several years, on different graphics card families (Quadro, GeForce, Intel, etc…), but since RTX Ada, some customers had crashes and complained.

I managed to reproduce issues on a RTX A2000 (572.16).
There was strange crashes in Nv threads, buffer mapping losts, memcpy crashes, etc… (mainly)
After two weeks of hard debug, looking everywhere, I found that one call to glGenBuffers was used without opengl context in some part of my code, and that was corrupting id mapping : next valid calls to glGenBuffers were returning already valid Ids, used in different data (vbos mainly).

So please fix your glGenBuffers API to avoid to do anything in such cases !

A second issue (still with crashes) has been found too: calling glGetUniformLocation after using the shader, binded, is crashing the related Nv thread.
I have not found the issue source, but I have found a workaround: I need to get all uniform locations during the shader initialization and keep them all in a map.
Still, this issue occurs only with “Nvidia RTX *** Ada” but not with GeForce RTX for instance.
(Maybe we are calling some glGet*** without any context… and then corrupting opengl data ?)

So please fix your APIs, for the best of Opengl community users.

EDIT:
another graphics card of customer with same issues:
NVIDIA RTX 3500 Ada Generation Laptop GPU/PCIe/SSE2, 4.6.0 NVIDIA 572.83

[ceniza666]

Some of our users are also experiencing problems with recent drivers on the following cards: T400, Quadro T1000, RTX 2000. We recently purchased a T400 to further investigate the issue, and we also found that it only fails with more recent drivers (tested with 573.24).

There are some strange drawing issues here and there, but the crash occurs when calling glGetUniformLocation. I also managed to get an OpenGL error when using setUniformLocation with another shader after glGetUniformLocation succeeded (it was either INVALID_VALUE or INVALID_OPERATION, I don’t recall which of the two).

Calling glGetUniformLocation right after linking the shader program works perfectly fine. There are no issues reported when compiling or linking.

Disabling “Threaded optimization”, as suggested by the linked thread, does “solve” the issue.

I’m really glad I found this thread, otherwise I may have wasted too many hours hunting down what seems to be a driver issue.

[Fabrice_Mollo]

Glad to hear.
For our professional customers experimenting crash issues, we suggest also to disable this “Threaded optimization” Nvidia option, and it works.
The problem is that some customers are never complaining. They bought expensive cards > 3000k but our application is just crashing, making them very angry.
hope Nvidia will release better OpenGL driver in the future. OpenGL is not yet dead. Lot of CAD softwares will still using it for the next ~5 years.