Sign in to follow this  
Xrystal

December DirectX on Downloads

Recommended Posts

reltham    642
This is rediculous:

New HLSL Shader Compiler for Direct3D 9 Targets: No Support for 1.x Pixel Shader Targets

The December 2006 SDK includes D3DX9_32.DLL. This DLL includes the Direct3D 10 HLSL compiler enabled for Direct3D 9 targets (shader models 2.0 and later). The new compiler has no support for 1.x pixel shader targets. This new compiler is the default for Direct3D 9. As a result, all developers are encouraged to author their shaders in HLSL and use shader models 2.0 and higher. The legacy compiler is available using the /LD switch.

The new compiler exposed has the following issues:


* Using asm_fragment blocks is not supported by the DLL. Compilation of shaders or effects containing these statements will fail.
* Because only a subset of HLSL optimizations and new features are active in this release, generated shaders will not be fully optimized.



Why are you doing this to us? Why is this the default when it's not ready? Why are you breaking a bunch of existing code?

Share this post


Link to post
Share on other sites
jollyjeffers    1570
Good catch Xrystal - stickied [grin]

The other files (from here):

Quote:
Original post by reltham
Why are you doing this to us? Why is this the default when it's not ready? Why are you breaking a bunch of existing code?
I've yet to check the details, but I'm pretty sure there is a flag to force the older HLSL compiler instead of the new D3D10-generation one.

Also, whether you buy it as a reason or not, there is no requirement to install an updated SDK. In fact, if you're mid-project then its probably a bad idea full-stop. With that in mind, anyone bothered about the HLSL compiler (and SM1 targets) should stick with whatever SDK they've already got....

I'd imagine its because the SDK is not a compulsory upgrade that they're happy with putting new and not quite finished components in as defaults...

Quote:
I have the perfect summary of the december SDK: Mostly useless.
Well if you're doing D3D10 work (as I am) then the Vista RTM compatability is a pretty useful addition [smile]

Cheers,
jack

Share this post


Link to post
Share on other sites
reltham    642
For new titles, that still need to support SM1 (and FFP). I think it's unreasonable to expect us to stay on old SDK versions. Too much is enhanced and fixed. You are the second MVP type to say that, and it makes me wonder why you guys think it's ok to stay on old versions? I think it's terrible to stay on old versions.

You know most really big games still do run on those old cards. While I do love all the new SM3 and SM4 stuff, I still have to be practical about market share. I think it's too early to stop supporting SM1 as a first class target with HLSL compiling.

The new compiler (when finished) will be REALLY nice for SM2+ stuff, it should include SM1 in HLSL (not just ASM). And the flag to use the old compiler isn't very friendly since I'd have to maintain a seperate FX file with the SM1 techniques in the OLD fx format, while having SM2+ stuff being in the new format to gain the benefits of the new compiler and fx sharing between D3D9 and D3D10 (which should be possible and desirable since we already have to build 2 engines, sharing the fx files would make it a little less painful).

Maybe I'm alone in making a renderer that supports SM1 thru SM3 on D3D9 and SM4 on D3D10. I guess it's two renderers really, but anyway. I'll likely even support FFP if I can.

Not everyone is making a FPS that targets uber gamers only with high end gear.

Share this post


Link to post
Share on other sites
Demirug    884
Scaling from FFP to SM4 is a big aim and most of the bigger games you noticed stay away from the effect framework to reach it. They have implemented their own that work better with their own tool chain.

I know that would not help you. Maybe the D3D10 multistream example could ease your pain a little bit. It shows how the preprocessor could be use to use both FX file formats in one file.

But I agree that adding support for at least ASM PS 1.1-1.4 to the new format would be a good addition.

Share this post


Link to post
Share on other sites
Demirug    884
In the case someone is interested. A header comparison show some more changes than the “What’s new” includes:
http://gpu-fun.spaces.live.com/blog/cns!FB5EEACE075E1350!225.entry

Share this post


Link to post
Share on other sites
jollyjeffers    1570
Quote:
Original post by reltham
For new titles, that still need to support SM1 (and FFP). I think it's unreasonable to expect us to stay on old SDK versions. Too much is enhanced and fixed. You are the second MVP type to say that, and it makes me wonder why you guys think it's ok to stay on old versions? I think it's terrible to stay on old versions.
Yes, I can see how my thoughts wouldn't be universally agreed upon [smile]

My main thought is that upgrading "for the sake of upgrading" is not a sensible option. If you're just seeing announcements every 2 months to a new version and automatically and blindly ripping out your existing one and dropping in the new one just because then that doesn't seem sensible.

If you're mid project or if you have some stable technology based on a particular release of the SDK then changing your SDK is equally a risky idea. At the very least you'll need to re-test components to ensure they work as intended, at worst you could end up spending time upgrading any code that relies on API parts that have changed between SDK's (which is rare lately, but it has happened in the past).

With respect to the latter point (which I think is the case here) then there needs to be a very strong reason for changing your tools mid-project. Is there a show-stopping bug in your current SDK that is now fixed? Is there a brand new feature that you just cannot live without? I suppose you could say it's the "risk versus reward" argument - the risk that something they've changed might break my existing code versus the reward I might get from some bug-fix or cool new feature.

Anyway, that's how I look at it and that's why I have said on several occasions that changing the SDK is not always a good idea. It's fine by me if you see things differently [smile]

Quote:
Original post by reltham
You know most really big games still do run on those old cards. While I do love all the new SM3 and SM4 stuff, I still have to be practical about market share. I think it's too early to stop supporting SM1 as a first class target with HLSL compiling.
Baring in mind that the HLSL compiler was never amazing at the ps_1_x targets (it was okay with vs_1_x) I do fully appreciate that supporting the older generation of hardware is still important. Especially given that some SM2 hardware (*cough*GeForceFX*cough*) weren't so good at SM2 and in practice need to be run as high-end SM1 parts...


Registering your point of view is always a good thing, maybe the powers that be will listen and act on it. But as far as we currently know, if you want the nice shiny D3D10 generation compiler you lose SM1 support. With that fact in mind it seems to me that sticking with the older generation SDK is your only option - given that you need an RTM SDK for your D3D10 engine it may even mean you have to split your code across builds against two SDK's. Not nice. But as Demirug posted - scaling across the hardware as you're attempting is no easy thing to do!

Quote:
In the case someone is interested. A header comparison show some more changes than the “What’s new” includes:
http://gpu-fun.spaces.live.com/blog/cns!FB5EEACE075E1350!225.entry
Nice summary. Thanks [grin]

Jack

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Really noob question here, am I right in assuming if I use dx10 only in my engine that it will not run, or run very badly, on dx9 hw.

Share this post


Link to post
Share on other sites
Demirug    884
Quote:
Original post by Anonymous Poster
Really noob question here, am I right in assuming if I use dx10 only in my engine that it will not run, or run very badly, on dx9 hw.


It will not run at all (on user systems).
The Refrast is part of the SDK and normally your users would not have it installed. For development purpose you can use it. But it is slow like hell. Seconds per Frame and not frames per second.
At the moment a D3D10 engine will cut your user base to zero as there is still no D3D10 driver available. This will hopefully change soon but even then not many people will have the right hardware and the right operating system.

Share this post


Link to post
Share on other sites
jogshy    134
huh.... I'm trying to compile a supernoob ps1.1 like:



.... blah blah boring VS ...

float4 g_vBillboardColor;

texture g_BaseTex;
sampler BaseTexSampler =
sampler_state
{
Texture = <g_BaseTex>;

MinFilter = LINEAR;
MagFilter = LINEAR;
MipFilter = LINEAR;

AddressU = clamp;
AddressV = clamp;
};

float4 billboardPS( float2 inUV : TEXCOORD0 ) : COLOR
{
return tex2D ( BaseTexSampler, inUV ) * g_vBillboardColor;
}

technique Billboard
{
pass P0
{
ZEnable = true;
ZWriteEnable = true;

FillMode = Solid;

CullMode = None;

AlphaTestEnable = true;
AlphaFunc = GreaterEqual;
AlphaRef = 127;

AlphaBlendEnable = false;

VertexShader = compile vs_1_1 billboardVS();
PixelShader = compile ps_1_1 billboardPS();
}
}


and the new FXC10 shader compiler with /LD /T fx_2_0 commands gives me a nice undescribed error(somthing like "Can't compile shader in line(60)" in the "compile ps_1_1" line... but but I ***USE*** the /LD! whyyyyyyyyyyyyyyyyyyyyyy!


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this