• Advertisement
Sign in to follow this  

What does ps1.1ps1.3 lives for ?!

This topic is 4488 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

I worte a 3D render engine based on VC6+DX9c and recently I do my job with optimize it and make it compatible with any hardware include fixed-pipeline video card, but some problem made me crazy, I wrote renderer with SM3.0 originally and it works fine with SM2.0, these days I find these shaders I wrote for SM2.0 and above hard to migrate to ps1.1~ps1.3(thank god that all vs works fine), and ps1.4 has a few problem. Even the simplest effect like per-pixel phong shading, HDR, normal mapping that ps1.1~1.3 can't made, always report errors no matter how I modify the shaders. I wonder if ps1.1~1.3 can't do these job, what do them live for? Any one can help~~~~~~~~~???

Share this post


Link to post
Share on other sites
Advertisement
Hi,

The first versions of the shader models had only a few instructions available compared to SM 3.0.
Here is a list of all the HLSL function available in DirectX 9.0c : HLSL Intrinsic Functions

When you click on a function, the minimum version of VS / PS is given. You can check what functions you're using that are not compatible with the target shader model.

Share this post


Link to post
Share on other sites
The simple answer is that they were the FIRST shader models - as featured in Direct3D 8.0 - right back when shaders were a new toy to most people [grin]

Things have most definitely progressed since then.

Maybe, if you're using a lot of advanced effects, you can "draw the line" at SM2.0 compatable hardware, stating it as a minimum requirement. This could be a good idea also based on the performance - you might get some funky effects going with multipass SM1x stuff, but the hardware simply might not have the power to handle it at an acceptable speed. I see quite a lot of games starting to come out that (and future ones) that will require SM2.0 or above.

Alternatively, if you have to support the older shader models - I often hear a lot of the more seasoned graphics programmers saying they have to drop back to assembly level coding to fit into the SM1x limits. Are you doing this, or are you hoping the HLSL compiler will do it for you?

hth
Jack

Share this post


Link to post
Share on other sites
OH~~~ Kill me ---- drop back to assembly level coding, I thought the HLSL compiler could be smarter than me. :(

Share this post


Link to post
Share on other sites
A compiler will NEVER be smarter than a programmer who knows what he or she is doing. Due to the simplicity of those early shader models, I personally find it much simpler to use ASM. They have so few instructions.

Share this post


Link to post
Share on other sites
One more question, can I embed assembly code into my HLSL like C++, how?.
If not, how can I get datas from C++ which passed in HLSL with name id other than assembly program with register id?

Share this post


Link to post
Share on other sites
Quote:
I thought the HLSL compiler could be smarter than me.

I think it's more a case that for the ridiculously small number of instructions (and even then, there are restrictions on what ordering is allowed) it just becomes extremely difficult to compile to.

On the other hand, a human might well be able to think at a "higher" algorithmic level and spot some ways to cut corners or re-use values/registers etc..

Quote:
One more question, can I embed assembly code into my HLSL like C++

Not that I'm aware of. Alternatively, you can use the /Fc"filename.html" /Cc compile-time switch to get it to generate an assembly listing in the specified file.

With the assembly listing you may well be able to start refining it.

Quote:
If not, how can I get datas from C++ which passed in HLSL with name id other than assembly program with register id?

The ID3DXConstantTable (and effect framework) basically just mask the constant buffers for you, so when dealing with "pure" ASM you'll just have to do that part yourself. If you wrote the assembly shader then you know which constant (e.g. c1) different parameters belong in.

There are 6 functions (3 for VS and 3 for PS) like this: IDirect3DDevice9::SetVertexShaderConstantF() ('F' for float, 'B' for bool, 'I' for int).

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
One more question, can I embed assembly code into my HLSL like C++, how?.


Yes, using the asm statement. It's used a little differently; in your technique/pass desc, where normally you'd put something like "pixelshader = compile ps_1_1 PS();", you put instead

pixelshader = asm
{
ASM instructions in here
};

Share this post


Link to post
Share on other sites
Quote:
Original post by Drakex
Quote:
One more question, can I embed assembly code into my HLSL like C++, how?.


Yes, using the asm statement. It's used a little differently; in your technique/pass desc, where normally you'd put something like "pixelshader = compile ps_1_1 PS();", you put instead

pixelshader = asm
{
ASM instructions in here
};

aah, I'd forgotten about that one [smile]

Although, just to make sure I'm clear - you can't just imbed blocks of ASM inside HLSL, right?

float4 ps( in float2 t : TEXCOORD ) : COLOR
{
float4 c = tex2D( ... );
asm
{
add ..
dp4 ..
};
}


Jack

Share this post


Link to post
Share on other sites
Thank you guys, now I use FXComposer to generate asm code and refine it manually.
And now I understand why there was few games use programmable pipeline in the period of dx8.

Share this post


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

  • Advertisement