Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to send quite a bit of data to the GPU, the data will never change (or will change very rarely) after it has been created. Is there a performance impact to using global shader variables or should I pack the data into a texture to perform look ups?

share|improve this question
Can you clarify what you mean by 'external arrays?' Constant buffers? – Josh Petrie Jul 11 '13 at 17:41
@JoshPetrie I haven't looked into constant buffers much, would they perhaps be better? Perhaps external variables is not the best word, but 'global' variables which can be set from outside the shader. – jacker Jul 11 '13 at 17:50
up vote 2 down vote accepted

Sometimes. Maybe. Maybe not. It depends.

Early shader models had a very limited count of constant registers (I'm assuming pixel shader registers here since you're comparing to texture lookups) - 8 in SM1.x, 32 in SM2.0, and scaling the giddy heights of 224 in SM3.0. What's worse, some hardware didn't even support any pixel shader constants natively, and needed to patch the raw shader binary in order to emulate them (some GPU manufacturers would even recompile shaders, with - IIRC - NVIDIA for example advising that values of 0.0, 0.5 and 1.0 would trigger a recompile).

Common tricks included using textures to encode trig functions, normalization, etc (which also helped with overcoming the pathetic instruction limits that these shader models had).

If you want to support this class of hardware you need to bear all of this in mind.

More recently, it's the case that ALU operations are vastly faster than texture lookups, so straightaway you have a bottleneck if you use textures for storing your data. See the accepted answer to this question for more info.

Nowadays a constant buffer would be the optimal solution, and GPUs and drivers can be expected to be optimized for that kind of usage, but since you mention "global shader variables" that indicates to me that you're using D3D9 (also looking at your "HLSL" tag here which rules out OpenGL).

If that's the case then it depends on your definition of "quite a bit of data". Note the register limits I gave above, note that you're going to want to keep some spare for other usage, and you could very quickly find yourself bumping into those limits. So a texture would be your only real option, and available register space would be a more important determining factor than performance.

share|improve this answer

For older shader models, "global" variables are just mapped to GPU registers. They may be faster at a micro-timing level than texture lookups, but you probably won't have enough of them to sufficiently represent the data you want. Updating each constant variable would also have some overhead, but since you said updates will be quite rare, that may not be a problem. Textures are probably want you want if you are using an old model.

On newer shader models (4 and up) "global" variables (shader constants) are stored in constant buffers or texture buffers. You'd want to use whichever is more appropriate for your data and update/access patterns.

share|improve this answer
On DX11 a structured buffer is also a possibility. They can be bigger than constant buffers, and have tighter packing (no need to pad things to 16-byte boundaries). – Nathan Reed Jul 11 '13 at 19:54
How many can I use? I remember using arrays of floats up to 2^16 in XNA. – jacker Jul 11 '13 at 20:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.