Assigning/Linking textures and samplers to specific slots in technique declaration

Started by
2 comments, last by Namethatnobodyelsetook 17 years, 10 months ago
From my understanding, it's perfectly valid to assign texture and samplers to specific texture and sampler slots from within the technique declaration as such:

technique Foo
{
        pass P0
        {
            Texture[ 0 ] = (g_ShadowDepthBuffer0);
            Texture[ 1 ] = (g_ShadowDepthBuffer1);
            Texture[ 2 ] = (g_ShadowDepthBuffer2);
            Texture[ 3 ] = (g_ShadowDepthBuffer3);
            Texture[ 4 ] = (g_ShadowDepthBuffer4);
            Texture[ 5 ] = (g_ShadowDepthBuffer5);
            Sampler[ 0 ] = (ShadowDepthSampler0);
            Sampler[ 1 ] = (ShadowDepthSampler1);
            Sampler[ 2 ] = (ShadowDepthSampler2);
            Sampler[ 3 ] = (ShadowDepthSampler3);
            Sampler[ 4 ] = (ShadowDepthSampler4);
            Sampler[ 5 ] = (ShadowDepthSampler5);
            Texture[ 6 ] = (g_BaseMap);
            Sampler[ 6 ] = (BaseMapSampler);
...


This allows you to set these textures and render states for these textures and samplers via the traditional way:

pDevice->SetTexture( nSlotID, SomeRenderStateID, SomeRenderState );
pDevice->SetSamplerState( nSlotID, SomeRenderStateID, SomeRenderState);
etc.

Rather than pEffect->SetTexture( "TextureName", pTexture );


However, the HLSL compiler does not seem to be honoring my request to bind these samplers to the sampler register I've specified. For example, I specifically requested that the BaseMapSampler be bound to Sampler[ 6 ], yet the HLSL compiler decided it was going to bind it to sampler register s0 (see below). Is this acceptable output, is it a bug, or is there some intermediate linkage going on that I don't know about, that properly hooks up sampler and texture registers to the C/C++ side of the API?

asm {
//
// Generated by Microsoft (R) D3DX9 Shader Compiler 9.12.589.0000
//
// Parameters:
//
//   sampler2D BaseMapSampler;
//   sampler2D ShadowDepthSampler0;
//   sampler2D ShadowDepthSampler1;
//   sampler2D ShadowDepthSampler2;
//   sampler2D ShadowDepthSampler3;
//   sampler2D ShadowDepthSampler4;
//   sampler2D ShadowDepthSampler5;
//   float2 g_MaterialProperties;
//   float g_fShadowIntensity;
//
//
// Registers:
//
//   Name                 Reg   Size
//   -------------------- ----- ----
//   g_fShadowIntensity   c0       1
//   g_MaterialProperties c1       1
//   BaseMapSampler       s0       1
//   ShadowDepthSampler0  s1       1
//   ShadowDepthSampler1  s2       1
//   ShadowDepthSampler2  s3       1
//   ShadowDepthSampler3  s4       1
//   ShadowDepthSampler4  s5       1
//   ShadowDepthSampler5  s6       1
//

    ps_2_0
    def c2, 1, 0, 0, 0
    dcl_pp t0.xyz
    dcl_pp t1.xyz
    dcl_pp t2.xyz
    dcl_pp t3.xyz
    dcl_pp t4.xyz
    dcl_pp t5.xyz
    dcl_pp t6.xy
    dcl_2d s0
    dcl_2d s1
    dcl_2d s2
    dcl_2d s3
    dcl_2d s4
    dcl_2d s5
    dcl_2d s6 


[Edited by - Brian Lawson on June 8, 2006 2:37:03 PM]
Advertisement
Bueller?
The register semantic is what your after I beleive:
sampler Tex0: register(s0);
In addition to the correct semantic provided by griffin, I vaguely remember there being a bug with it. Using v0, v1, etc, which don't really make sense for samplers, works perfectly. The compiler likely ignores the 'v' or 's' part and just uses the indices, but using 's' was somehow broken. I think it was when when attempting to skip a sampler, or maybe declare them out of order. This might be fixed in newer SDKs.

I'd suggest trying with s first. If you run into trouble, then try v.

This topic is closed to new replies.

Advertisement