Affect of shader variables in aspect of shader models (used amount of registers)

Hello,

I’m currently in the process of rewriting my previous shader, but some of the details in how interpolators are handled seem (even if slightly) unclear to me.

I’m using this page for general reference; High-Level Shader Language - Wikipedia

When using a Texture2D, float, half, fixed, vertex, which registers does this actually affect withing the pixel/vertex shader comparisons?
I can’t seem to find any reference to use even as a general rule of thumb.

Judging from simply using #pragma target’s and messing around with texture2d tags i’m currently guessing the following:

texture2d mainly uses “Texture indirections”, but other then that i have no idea.

I assume that an executed instruction counts for every mathematical command (even an example tex.rgb=tex.rgb*0.8 )
I have no idea what a position register is

And i have no idea what the difference between the “Temp registers” and “Constant registers” is.

I want to ask this, because i’d love to know simply how these variables stack up,
i could in example in some cases pack 4 half’s into a single vector if it would give me the needed space elsewhere, but when i run into compilation issues i thus far generally know i only used too much of something, unless the error “Texture Interpolator” is returned, that one i’m already quite familiar with.

I had seen a topic a while ago which had talk about storing multiple fixed values in a fixed4, but even that topic i can’t seem to find at the moment for reference :frowning:

Also, i was wondering if it’s possible to create a fixed4, but also destroy the same fixed4 to free up space and assign another later within a surf pass. I’d prefer that instead of making a single fixed4 named temp and having to use that name as reference over and over (just for readability of the code).

I hope someone knows some more details about these things, or maybe knows where to find some more documentation on the matter.

As far as I’m aware, “texture indirections” arise when you try and sample a texture in the fragment shader using values that are swapped from or altered version of the vertex data (or simply made up as a result of other fragment shader operations). Essentially, you want to feed the direct vertex shader results directly in as the UV coordinates without swizzling, masking or other operations.

With surface shaders, this is unavoidable - the values get automatically packed in the vertex shader and reconstituted in the fragment shader (uv_MainTex becomes - vertex shader: float4 pack0; pack0.xy = TextureTilingOffsetThing(uv, MainTex_ST); - fragment shader: float2 uv_MainTex = pack0.xy; - and then you feed that in as texture coords and it’s an indirection because it’s been reconstituted from a packed value).

If there are no indirections, it’s able to pre-fetch the texture data used in the fragment shader.

Not every function equates to one command. There are several which become “free” if used right and some which, with a little fiddling of your maths, can be reduced from two operations to one - mostly the MAD command, which does a multiply then add all as one instruction.

Emil “Humus” Persson recently put up a great set of slides from his GDC talk going over ways to optimise shaders for the compiler - it’s well worth a read;
http://www.humus.name/index.php?page=Articles&ID=6

Wow, that is an awesome presentation! it would generally cover exactly the subject that matters to me, but looks like i’ll need to take a more in-depth dive at the basics of shader operation to gain a full understanding, however luckily i can start by using the examples, i had started “dumbing down” the math in a way to use as few mathematical actions as possible to achieve the result using simple math order.

I found the comparisons showing the (i guess) HLSL/GLSL code and the resulting hardware code very interesting.
Other then manually refactoring the code, is there a method to see the result of your HLSL/GLSL code as if it were ran on the GPU (disassembly?)? Like some shader emulator maybe? (I tried googling FXC which brought me to this page : Tools for DirectX graphics - Win32 apps | Microsoft Learn - I’m guessing it’s part of the windows SDK which i’m downloading and installing right now to check it out at least :slight_smile: )

I’ve downloaded the NVIDIA CG toolkit and the windows SDK, after having written my first simple diffuse and diffuse + normal CG shaders yesterday it’s time to take a full-on nosedive, i hope these toolkits will be able to aid me.

If anyone happens to know a toolkit that in their opinion works great for writing and rapidly testing Cg shaders, please let me know!