   Texture Unit Redundancy...
  I''m currently implementing a CG shader based system, and I''m curious as to whether a redundant call to SetTexture such as this:   IDirect3DTexture9 *A, *B;...SetTexture( 0, A );    // moves texture into video memory...[...Render Stuff...]...SetTexture( 1, A );    // does this move another copy of the texture to video memory or merely uses the copy that''s already in memory?SetTexture( 0, B );    // moves another texture into video memory...incurs the same performance cost as uploading a completely different texture, i.e. you''re merely changing the texture stage, not the texture?   Chris PergrossiMy Realm | "Good Morning, Dave"    
  If you''re using a PURE device, then you''ll probably get the same performance as if you used a totaly different texture because redundant state changes are not checked; they''re merely passed on to the driver no matter what.If you use a NON-PURE device, the runtime should catch the redundant state change and not pass it on to the driver.neneboricua ;  It won''t cause an extra texture upload though, so your texture will only be stored once in video memory. Stay Casual,KenDrunken Hyena;  So, if I use a ''not''-pure device, and I ask that it change texture stage textures to different stages, what will Direct3D do?  You say it won''t pass it on to the driver?  But I need it to change texture stages Let me explain what I''m trying to do.  I''m going to sort my shaders and the like by shader first, then texture, etc etc.  Anyway, I need to change the texture stage for some of my shaders (one expect TextureA in stage 0, and another expects TextureA in stage 1 and TextureB in stage0) and I''m not sure if there is a way around this, or if it''s faster then just rendering all shaders with no sorting.  Any help would be appreciated.   Chris PergrossiMy Realm | "Good Morning, Dave" ;  If you know that two of your shaders will use TextureA, then you should make both of them expect to see that texture in the same stage.  Since you''re still in development, it shouldn''t be too much trouble to change your shaders so that they all expect TextureA to be in slot 0, TextureB in slot 1, etc...To answer your original question though:quote:So, if I use a ''not''-pure device, and I ask that it change texture stage textures to different stages, what will Direct3D do? You say it won''t pass it on to the driver? But I need it to change texture stagesIf you use a non-pure device, D3D will check whatever calls you make to see if they are redundant.  If they are, then D3D will ignore them.  If they are not redundant (they actually do make some kind of change to the texture stages, render states or whatever) then D3D will pass it on to the driver and the change will be made.neneboricua ;quote:Original post by neneboricua19  If you''re using a PURE device, then you''ll probably get the same performance as if you used a totaly different texture because redundant state changes are not checked; they''re merely passed on to the driver no matter what.If you use a NON-PURE device, the runtime should catch the redundant state change and not pass it on to the driver.neneboricua   - He wasn''t doing a redundant state set, he was setting the texture at unit 0, and then at unit 1- A very common misconception/misinformation is that PURE devices don''t filter state. I was under that impression too, until recently. It turned out they do filter any state supported by an underlying interface  , except pixel shaders.Here''s the relevant post from Chuck Noble (DX Team) on DIRECTXDEV, titled "Re: [DIRECTXDEV] D3DX Effects performance numbers"quote:Great, thanksOn pure device you shouldn''t have to worry about filtering texture and vertex shader changes. As a rule, d3d9 PURE device will filter any state changes supported by an underlying interface (idirect3dtexture9, idirect3dvertexshader9, etc) with the exception of SetPixelShader.  Setting a duplicate state that IS filtered by the runtime is exceptionally "cheap", IMO it''s best to simply allow the runtime to filter such states.  In that case, you could quite safely remove pure-device filtering of settexture and setvertexshader.On non-pure device, I''d recommend limiting filtering to only SetPixelShader for the same reasons. Muhammad Haggag;  It''s likely that the driver only uploads the texture IF it''s not already on the card.It''s also likely that a SetTexture() is not enough to force a texture load; actually queuing geometry with the texture bound is probably necessary to force the upload.But you can''t tell for sure; the implementation may vary. ;quote:Original post by Coder  - A very common misconception/misinformation is that PURE devices don''t filter state. I was under that impression too, until recently. It turned out they do filter any state supported by an underlying interface    , except pixel shaders.Here''s the relevant post from Chuck Noble (DX Team) on DIRECTXDEV, titled "Re: [DIRECTXDEV] D3DX Effects performance numbers"[snip...]Ok.  I see.  That''s really good to know.  Saves all kinds of needless optimization work.  Maybe it would be a good idea if they put that in the DX FAQ in the next SDK update (if it''s not already there).neneboricua ;  Well, my problem is that I''m thinking of allowing CG to manage my shaders, which means I set a texture by using a texture name expected by the shader.  Now if two shaders expect the same texture, give the same name to texture when declaring it, and the two of them directly follow each other, does CG ''understand'' that it''s the same texture, and modify accordingly?  Or do you have to explicitly re-state, TextureA is the same as before (by using another call to the CG SetTexture function)?  I''ve explained my end goal of trying to minimize texture changes, but I''m not sure how to go about this.neneboricua19:I don''t know what texture stages my shaders expect each texture, only that they expect the texture (CG handles the specifics) and it seems somewhat difficult (if not impossible) to go through all shaders and make sure there are no conflicting texture expectations for all materials and all objects in every map I have or ever will have!   Chris PergrossiMy Realm | "Good Morning, Dave" ;  A better place for Cg questions would be CgShaders.   Muhammad Haggag