   Hidden texture derivatives in pixel shaders?
  On SM2 and lower systems, the tex2D HLSL function doesn't allow for any derivatives to be used to filter the texture, e.g. for trilin/aniso filtering. However, it seems that they're still in effect when doing tex2d lookups. I was wondering if anyone knew where the 'invisible' derivatives in this case were coming from, and how they're modified.Edit: Promit told me that he didn't understand what I was asking. Allow me to elaborate.The derivatives I'm referring to are, AFAIK, used to determine on the hardware how the texture is filtered for trilinear or anisotropic filtering. In SM2, there are no instructions (ASM or HLSL) that do texture lookups in conjunction with those derivatives (SM2.x and higher support them: texldd for ASM and tex2Dlod for HLSL), but yet texture filtering still behaves normally. Clearly, the required derivatives are being supplied SOMEHOW, and I was wondering if anyone knew where  those derivatives are coming from, and if they can be modified directly or indirectly (e.g. if the register used for the texld instruction was previously div'd by 2, are the 'hidden' derivatives div'd accordingly?).[Edited by - Cypher19 on May 14, 2006 10:55:25 PM]
  I dont think you'll be able to modify the derivatives unless the API specifically allows it. Despite pixel shaders being "low level" they are still fairly enclosed/seperate from the actual hardware implementation. Specifically, the assembly that the runtime feeds the driver will be converted to GPU-specific microcode. I doubt the D3D runtime specifically knows how it happens [smile]My take is that this microcode is shader model (and API) independent - so it's quite possible that the texture lookups for ps_2_0 will be implemented using the same microcode as ps_3_0's. The difference being that in ps_3_0 you can "see" and manipulate the derivatives...Are you specifically wanting to "interfere" with the filtering computations then? [smile]Cheers,Jack   ;  Modern graphics hardware processes pixels in 'quads': 2x2 pixels in parallel. This allows them to look at neighboring pixels to determine texture gradients. So mipmap levels are in fact computed per-quad. This technique is fast but as you noted it also has the advantage that if you perform operations on the texture coordinates the gradients are still computed correctly for mipmapping.   ;  By the way, even if the hardware processes pixels in quads, the gradient instructions dsx/dsy/texldd are only available if the D3DPS20CAPS_GRADIENTINSTRUCTIONS flag is set in the PS20Caps.Caps device caps. Somewhat older hardware has these calculations hard-wired so it can't be accessed in the shader.   