Instancing regression between between 361.28 and 361.42

Hello,

We have an application running on many systems with different NVIDIA cards, ranging from the 460 series up to modern cards.

This application has started failing after drivers have been updated from the 340-series to the 367-series, drawing pretty much garbage for everything that is rendered using instancing.

I have pinpointed the breakage to 361.42 and newer, with 361.28 being the newest working driver. I tested the latest drivers in the following series: 346, 352, 355, 358. All of them work fine. The problem still exists in the latest 370.28 driver.

We are using glDrawElementsInstancedBaseInstance, together with vertex buffers for which glVertexAttribDivisor has been set to 1 (for per-instance stepping of the vertex attribute). The shaders appear to get garbage for all per-instance vertex attributes, while the per-vertex attributes are working fine. This issue happens even for simple single float attributes.

Now, it’s fully possible that we are unknowingly doing something non-conforming to cause these issues, but I don’t know what that would be. We have the possibility of updating our code, in case there is something that needs to be done differently.

The changelog for the first version with this problem (361.42) doesn’t give me any hint.

The changelog for 346.35 mentions a fix for corruption when using glDrawElementsInstancedBaseInstance, but our application works throughout the 346-series, before and after this change.

Does anybody have any idea what could be causing our problems?

What changed in 361.42 that could break our instancing?
nvidia-bug-report.log.gz (151 KB)

Hello,
the driver behavior did change between 361.28 and 361.42, in order to fix a bug (incorrect behavior) that your application may be relying on.
It’s highly likely that your application is at fault.

From this document:
http://http.download.nvidia.com/developer/GLSL/GLSL%20Release%20Notes%20for%20Release%2060.pdf

“NVIDIA’s GLSL implementation therefore does not allow built-in vertex attributes to collide with a generic vertex attributes that is assigned to a particular vertex attribute index with glBindAttribLocationARB. For example, you should not use gl_Normal (a built-in vertex attribute) and also use glBindAttribLocationARB to bind a generic vertex attribute named “whatever” to vertex attribute index 2 because gl_Normal aliases to index 2.”

If your application is calling glVertexAttribDivisor to set the divisor for these aliased named vertex attribute indices, and the program uses “gl_Vertex”, “gl_Normal”, “gl_TexCoord”, etc… it will no longer work, because there was no guarantee by the spec for those to ever work in the first place.

I hope this helps.

Thanks for your answer!

I also expected the issue to be in our application, but I was still hoping that knowing what has changed in the driver might give a hint towards where to look.

After some digging deep inside the third party rendering library we are using, I managed to find that the library doesn’t bind the attributes with glVertexAttribPointer. It uses glTexCoordPointer instead, which admittedly seems very wrong. Changing this makes everything work nicely again.

For some reason older drivers seem to have been allowing this misuse.

Is there any reason why such compatibility changes aren’t listed in the ChangeLog? It would have been very helpful to know that the API usage has become stricter.

Thanks

This change definitely should have been covered in our changelog. It is largely a manual process, so there can be important changes that we forget.