Shader maximum vertex constants

How many GLSL vertex shader constants are there on a gf 6800, 256x1 floats or 256x4 floats? The spec seems to indicate the former, but my card is capable of the latter. What’s up?

The spec only defines the minimum, that every hardware must support, when it claims to be GLSL compatible.

Of course newer hardware can do better. Be happy about it.


No, you misunderstood. How can one determine the number of floating point components on their card?


This number is simply 256 on my 6800, which seems to suggest only 64 vec4 are available. My point is that this card has 256 vec4 registers. Why the disparity?

Thanks for the reply.

To me it seems that the spec says that it should be ( MAX_VERTEX_UNIFORM_COMPONENTS_ARB * 4 ). Some drivers may get this wrong or have some additional limitations.

Additionaly according to the spec this value should be at least 512 so there is likely some problem with your driver.


Thanks for the reply.

Here’s the relevant section from the spec:

The amount of storage available for uniform variables accessed by
a vertex shader is specified by the implementation dependent constant
MAX_VERTEX_UNIFORM_COMPONENTS. This value represents the number of individual
floating-point, integer, or boolean values that can be held in uniform variable
storage for a vertex shader.

This does seem to suggest it’s individual floats, not vec4, but it’s late. I couldn’t find anything in the spec about a minimum of 512. I’m looking at the 2.0 spec. Do you have a page number for me?

Latest official FW 84.21 driver.

Much thanks! :slight_smile:

OGL state tables. Table 6.35 in the spec 2.0, page 296

Yep, 512 floats is the minimum, according to that table. Driver bug, or so it would seem.

Could someone with a 6800 verify that this number is reported as 512? I’ll even code it for you:

GLint n;

I still don’t understand the disparity in register counts. That’s still only 128 vec4s. An implementaiton issue with GLSL, I’ll wager.

Thanks for you help, Komat. I really appreciate it.

Well, after a visit with

I was able to verify that this number is reported as 256 across various flavors of - and drivers for - the 6800 (awesome website, by the way). Perhaps you were right, Komat, in speculating that this number is just being misreported as vec4 registers rather than individual floats. I guess I’ll just have to take the nestea plunge to find out. If anyone can say with any certainty, one way or the other, I sure would appreciate it.

Thanks again for your help, Jan and Komat.

Yes, sorry, i misunderstood your question. Unfortunataly i am not able to be of more help with this issue, i have an ATI card.


Thank you, Jan.

I was just sniffing around at the glinfo registry again, and I noticed that some of the more recent ATI cards have some rather large figures for uniform counts, like 4096 for the X300-800 series. I’m guessing that the 6800 is roughly the equivalent of the X800 and other “SM 3.0” capable cards.

If you have a X300 or better, then you’re swimming in uniform constants!

I’m now darn near convinced that Nvidia is incorrectly reporting the uniform count as vec4 registers, as this large a discrepancy in similar technologies is hard to imagine. So instead of 256, perhaps it should be reporting 1024.

Thanks again,


I got my new and shiny laptop a week ago and, yes, it does have 4096 uniforms (ATI X1600).
The maximum of varying floats is 44.

I would also guess, that the Gf 6 has about 1000 uniforms or even more. You could write a shader that simply tries to access more than 1024 uniforms and check, what the compiler says about it.


I’m actually in the process of coding up a test for just that. I’m sure you’re right, it’s got to be 1024.

I’ve noticed a few other inconsistencies with Nvidia implementations and the GLSL spec, but they’re generally harmless and easy to work around. I just want to be sure that’s all it is.

Congrats on your new box. :slight_smile:



[Update] I’ve confirmed that the query in question returns the number of vec4 registers, not float components.

[Update] I’m pleased to add that this bug has been reported. :slight_smile: