The ZMan

I saw this in the October SDK readme

October 2006 DirectX readme! wrote:

Preview Release of the new HLSL Shader Compiler for Direct3D 9 Targets

This release has a beta version of d3dx9d_31_beta.dll that 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 targets. This debug-only DLL allows developers to utilize the new Direct3D 10 HLSL compiler for their Direct3D 9 shaders, and will become the default compiler for all Direct3D shaders. Please try the new compiler by building your application with d3dx9d_31_beta.dll instead of d3dx9d_31.dll.

Does this mean in future SDKs SM 1.1 will not be supported any more, or is this limitation just becuase its a beta DLL.

We've seen a lot of people in the XNA forums not be able to run the XNA spaewar sample becuase it used SM2 so there's lots of older cards still activly being used of course.




Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

I wouldn't cry that much about it except that VS1.1 is also dropped. For PS1.x it's been always the case that I use assembly instead of HLSL. But HLSL for VS1.1 is still important and a big time saver...





Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Ralf Kornmann

You can still use the compiler from an older D3D DLL that supports 1.1 shaders.






Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

It's annoying to keep two different packages in your project. It's a transitional time indeed, but maybe it's somewhat a little bit too early...





Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Michael Oneppo

Support for VS 1_x is available in the new compiler both in this Beta release and in future releases. PS 1_x will continue to be available to developers through the following channels:

1. D3DX9_31.DLL

2. The December SDK version of D3DX9 (D3DX9_32.DLL) will offer a compilation flag called D3DXSHADER_USE_LEGACY_D3DX9_31_DLL that will, as the name implies, load the D3DX9_31 DLL and use it to compile. If the DLL cannot be found on the system, the compilation call will fail.

If you wish to use the old compiler codebase that has been available for DirectX 9, I suggest you use option 1. If you want to use the latest compiler available but still wish to compile pixel shaders for 1_x targets, I suggest you use option 2 for those targets.

It is important to note that the D3DXSHADER_USE_LEGACY_D3DX9_31_DLL will eventually be removed once 1_x targets have sufficiently split from the mainstream, but not in the next few SDK releases at the least.






Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

What can I say I never felt more convenient than before Great decision!!





Re: Game Technologies: General Future D3DX's not supporting SM1.x??

reltham

As a developer that has to continue to support 1.X shader cards for min spec, I find this really CRAPPY.

It sounds like I'm gonna have to have seperate FX files for my 1.x techniques, because I have to run them thru the old compiler. So now I have to maintain two sets of FX files with different syntax. That really sucks big time. I really can't believe that you would intentionally do something this craptacular.

It's bad enough that the only way to get SM4 features on XP is to go with OpenGL, but now this... I mean really, do you want developers to continue using your API or what






Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

reltham wrote:
As a developer that has to continue to support 1.X shader cards for min spec, I find this really CRAPPY. It sounds like I'm gonna have to have seperate FX files for my 1.x techniques, because I have to run them thru the old compiler. So now I have to maintain two sets of FX files with different syntax.

You don't have to split the files. You always have #defines and #ifdefs and techniques, and it's much more elegant and manageable to do it this way instead of splitting the files.




Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Laurent

I totally agree with Reltham. We have a very large customer base and most of our customers are still using old vidboards and integrated chipsets when playing on their laptops.

In the recent months, MS has been trying to push everyone to advanced shader models, making everything possible to complicate development for programmers willing to use so called 'legacy' features. The problem is what MS now calls legacy is still for many devs the best feature set they can use at this time: For example, our game must run on a GeForce 2 MX: 32MB Ram of Video Ram, VS 1.1 and no PS.




Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

What you're calling "MS push" is the natural evolution of the market. A GF2 is 6 generations behind already, so obviously all the new SDK developments will be made for next-gen graphics cards. If your target market is all GF2s then all the previous SDK releases can be used for it. No one's forcing you to move to the latest SDK release, and all the previous SDK releases had a good HLSL compiler for VS1.1 (not to that even the current SDK release still supports VS1.1).




Re: Game Technologies: General Future D3DX's not supporting SM1.x??

reltham

PS1.x is still a large enough part of the market that is should not be "pushed" out of first class support. It is unreasonable to expect me to stay on an older SDK version to retain PS1.x HLSL support in FX files. In fact, it is unreasonable to expect anyone to stay on old SDK releases ever.

I think it is absurd that MS plans to abandon PS1.x HLSL support now or in a few releases from now (that is only 6-8 months out). This should not even be an issue. It should be assumed that they MUST continue support for PS1.x HLSL in FX files. I am literally in shock that anyone at MS thinks otherwise.






Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

reltham wrote:
It is unreasonable to expect me to stay on an older SDK version to retain PS1.x HLSL support in FX files. In fact, it is unreasonable to expect anyone to stay on old SDK releases ever.

Why do you believe it is unreasonable (practically speaking)




Re: Game Technologies: General Future D3DX's not supporting SM1.x??

reltham

 Wessam Bahnassi wrote:
 reltham wrote:
It is unreasonable to expect me to stay on an older SDK version to retain PS1.x HLSL support in FX files. In fact, it is unreasonable to expect anyone to stay on old SDK releases ever.


Why do you believe it is unreasonable (practically speaking)

I don't know what you work on in game development, but out here in the real world of game development it is still pretty damn common to have minimum specs for titles in development that are FFP, let alone SM1.x.  Sure, you have some high profile games that can afford to have higher minimum specs, but it's just not that common for a game to require higher. So making it harder to support SM1.x in the FX system is just going to make it harder for many game developers right now.

D3D is an API that caters to all of us, not just the high end.  I really think it is absolutely stupid to try and take SM1.x out of first class support.  Seriously, why is this being done How hard can it be to support SM1.x HLSL in the new FX format They have the old compiler that worked just fine, make it automatically call out to the old compiler for SM1.x shaders within the new FX files.  Do not add some dumb flag, do not talk about removing the support in the near future.

Staying on older SDK versions is just silly. Too many good things are added with each update. I want to use the new compiler because then the FX formats will be the same between D3D9 and D3D10. I assume that is the whole reason for them doing it in the first place. With well written HLSL you will be able to share a lot of shader code between you D3D9 and D3D10 engines. Since they are making you write two engines if you want to support XP and also support the latest cards in D3D10, this seemed like something done to help make that a little less painful.

As I said before, it's already painful enough that we are not getting new card support on XP (no D3D10 there), and now they are attacking us from the other end.  Seriously, if feels like they want us all to switch to OpenGL where we get new card support on XP, and they are not removing stuff that is still in heavy use. I seriously hate that option, but if things keep going the way it sounds like they are, I may be forced down that path.

 






Re: Game Technologies: General Future D3DX's not supporting SM1.x??

Wessam Bahnassi

reltham wrote:
D3D is an API that caters to all of us, not just the high end. I really think it is absolutely stupid to try and take SM1.x out of first class support. Seriously, why is this being done How hard can it be to support SM1.x HLSL in the new FX format They have the old compiler that worked just fine, make it automatically call out to the old compiler for SM1.x shaders within the new FX files. Do not add some dumb flag, do not talk about removing the support in the near future.

No one said that D3D is a solution for high-end games only, neither I've implied that in my posts. Note that the drop is currently for PS1.x HLSL only (VS1.1 is still there). The main reason for all of this is that PS1.x is too restrictive with its instruction set. If you check the archives of how people used to deal with HLSL for PS1.x, you'll find it's all turning around: "what HLSL code do I have to write to generate this PS1.x instruction ". People writing PS1.x for a while know that it's far easier to write in PS1.x assembly directly rather than HLSL.
That being said, such a decision isn't something that happenned after the D3DX team has gathered in a dark room with red lights to say: "Hahaha what can we do to make their lives harder !! Drop PS1.x!!!".
It's simply driven by the requirement of investing time at the best place of development.
reltham wrote:
Staying on older SDK versions is just silly. Too many good things are added with each update. I want to use the new compiler because then the FX formats will be the same between D3D9 and D3D10. I assume that is the whole reason for them doing it in the first place. With well written HLSL you will be able to share a lot of shader code between you D3D9 and D3D10 engines. Since they are making you write two engines if you want to support XP and also support the latest cards in D3D10, this seemed like something done to help make that a little less painful.

Ok, I can imagine two situations here based on what you're saying:

One: you have pixel shader code that is shared between all shader profiles (at least PS1.x and something higher). This simply means you're not using the additional higher shader profiles functionality. Thus, you don't really care about the new functionality introduced by recent compiler updates (since they're almost centralized around new shader profiles).

Two: Your effects have a separate code path for PS1.x, which is naturally backed up by application code support. In this case, you already have a clear fork in your code which can handle the additional flag that's annoying you.




Re: Game Technologies: General Future D3DX's not supporting SM1.x??

reltham

Wessam Bahnassi wrote:

No one said that D3D is a solution for high-end games only, neither I've implied that in my posts. Note that the drop is currently for PS1.x HLSL only (VS1.1 is still there). The main reason for all of this is that PS1.x is too restrictive with its instruction set. If you check the archives of how people used to deal with HLSL for PS1.x, you'll find it's all turning around: "what HLSL code do I have to write to generate this PS1.x instruction ". People writing PS1.x for a while know that it's far easier to write in PS1.x assembly directly rather than HLSL.
That being said, such a decision isn't something that happenned after the D3DX team has gathered in a dark room with red lights to say: "Hahaha what can we do to make their lives harder !! Drop PS1.x!!!".
It's simply driven by the requirement of investing time at the best place of development.

I have been doing HLSL/FX shader coding for a few years now and target PS 1.1 and 1.4 just fine. In fact, I have done very little asm shader coding. I found I did not need it, because I could get what I needed from HLSL.

Wessam Bahnassi wrote:

Ok, I can imagine two situations here based on what you're saying:

One: you have pixel shader code that is shared between all shader profiles (at least PS1.x and something higher). This simply means you're not using the additional higher shader profiles functionality. Thus, you don't really care about the new functionality introduced by recent compiler updates (since they're almost centralized around new shader profiles).

Two: Your effects have a separate code path for PS1.x, which is naturally backed up by application code support. In this case, you already have a clear fork in your code which can handle the additional flag that's annoying you.

The issue is that the fx_4_0 profile is significantly different from the fx_2_0 one. I doubt you could have one FX file with new fx_4_0 syntax techniques and shaders along with fx_2_0 format stuff for PS 1.x. This means you have to have two seperate FX files for your effect if you want to do PS 1.x with HLSL, and these two FX files are in different syntax. I am sure you can see how that is undesirable. So, right now my solutions are to use ASM for PS 1.x stuff, maintain seperate and syntactically different FX files, or not use the new compiler and file format at all. I do not like any of those options. Especially when it would be easy for them to make it work as I said before. It is clear that they have made a choice to just drop PS 1.x HLSL support, but it is not clear why.

The beauty of the effect framework is that you can support all the various levels of cards within the fx files and your game engine code can be the same (and very simple). I do not have a seperate SM1.x code path from SM2.x or 3.0 path, it is all one simple code path. I just have different techniques in the fx files that validate based on the hardware it is running on.