Advertisement Jump to content
Sign in to follow this  

Excerpt from Offset dev blog, clarifying sampler usage[SOLVED]

This topic is 3841 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From this entry (paragraphs 3 & 4): What does he mean by "as far as the driver (and HLSL compiler) is concerned, I want to use all 16 possible textures." ? Did he mean that even if you don't have a texture bound to a sampler, it is still counted as a used sampler when the shader is compiled? Thanks for any help you can provide. [Edited by - n00body on July 17, 2008 11:30:39 AM]

Share this post

Link to post
Share on other sites
No what he's saying is that even though no individual pixel accesses more than samplers, he still needs to have more than that bound at the time he issues the draw call. Take something like this for instance:

sampler2D sampler1 : register( s0 );
sampler2D sampler2 : register( s1 );

float4 PS(float2 texCoord : TEXCOORD0) : COLOR0
if(texCoord.x > 0.5)
return tex2D(sampler1, texCoord);
return tex2D(sampler2, texCoord);

Now for each run of this simple shader it will never sample more than one texture, however you need both textures bound at draw time since each pixel could access either of them. This is the problem he's talking about, just multiplied.

Share this post

Link to post
Share on other sites
Yes and no.

Branching says to you and me (as developers) that I optionally choose to use a given resource. However the runtime (and hence compiler) don't know which ones we're going to choose therefore it has to provide us with all of them.

The key comes in that HLSL and GPU programming is very resource constrained - 16 unique samplers being the crucial constraint here.

In essence it says "you can have dynamic branching, but you must choose from a small subset that you tell me about in advance". As described in that blog, for what they're doing it is hard (if not impossible) to fit the entire set of possible options into such a constrained pool.

Similar happens in the CPU world, but the levels of RAM L1->L2->L3->SYSRAM->VRAM and the wonders of caching/paging tend to hide this from us entirely.

In real-terms for lighting, a multi-pass approach will usually allow you to skip this problem. Heading down the direction that blog suggests ended up with the "uber shader" facination we had for a while [smile]


Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!