X600/300 can support SM2.0B and R3x0 cant?

[tb]

ATi Catalyst 4.8 beta leaked
http://www.station-drivers.com/telechargement/ati/ati 4.8.exe

Whoever has a X600/X300 can confirm that they support SM2.0B?

D3DXGetPixelShaderProfile did't even report "2_b" on the X800 and the more complex (>2.0) ShaderMark v2.1 shaders aren't working on the X800 yet, even with the 4.8 beta drivers...
How can it take ATi longer to get working 2_b drivers out than NVIDIA getting working 3_0 drivers out ...

The X800 has supported PS 2.x since its launch. Please check the D3D caps and be certain your shaders aren't being rejected for using a feature that is not supported. The Ashliviewer samples work fine.

I'am using the dx9.0c debug runtime and tried it with the official 4.7 drivers ande the 4.8 beta's - both gives me a bluescreen when I change the shader profile from 2_0 (which can't be compiled, because my shader needs for instructions) in the "Effects Edit" application provided with the SDK Update 2004, so it seems like a driver issue with the 2_b shader or dx9.0c or both.... GPU Recovers can't help here

I'll file a bug report to ATi's devrel with my HLSL shader code....

Thomas

 

[engall]

*eats humble pie*

I checked with ATI again and they have confirmed that X6 and X3 do not support 2.0b after all. They apologise and i apologise for the incorrect info.

*continues eating*

But What about this?

http://www.firingsquad.com/hardware/far_cry_ps2.0b/page5.asp

The app is using the PS 2.0b profile (AFAIK) however it's not exceeding the instruction limits of PS 2.0.

If so ,is it necessary to use PS2.0b and create PS2.0B profile?

Not sure what you mean. It may have been that the app was not originally written to do lighting in less than one pass per light, if that's what you meant.

I mean if PS2.0 can do it ,why bother PS2.0b and PS3.0 in Farcry 1.2?

 

[OpenGL guy]

*eats humble pie*

I checked with ATI again and they have confirmed that X6 and X3 do not support 2.0b after all. They apologise and i apologise for the incorrect info.

*continues eating*

But What about this?

http://www.firingsquad.com/hardware/far_cry_ps2.0b/page5.asp

The app is using the PS 2.0b profile (AFAIK) however it's not exceeding the instruction limits of PS 2.0.

If so ,is it necessary to use PS2.0b and create PS2.0B profile?

Not sure what you mean. It may have been that the app was not originally written to do lighting in less than one pass per light, if that's what you meant.

I mean if PS2.0 can do it ,why bother PS2.0b and PS3.0 in Farcry 1.2?

I believe that PS 2.0 is not enough to collapse all lights into a single pass in Far Cry. However, you're right that some of the collapsing that is being done now could have been done earlier.

 

[OpenGL guy]

*eats humble pie*

I checked with ATI again and they have confirmed that X6 and X3 do not support 2.0b after all. They apologise and i apologise for the incorrect info.

*continues eating*

But What about this?

http://www.firingsquad.com/hardware/far_cry_ps2.0b/page5.asp

The app is using the PS 2.0b profile (AFAIK) however it's not exceeding the instruction limits of PS 2.0.

If so ,is it necessary to use PS2.0b and create PS2.0B profile?

Not sure what you mean. It may have been that the app was not originally written to do lighting in less than one pass per light, if that's what you meant.

I mean if PS2.0 can do it ,why bother PS2.0b and PS3.0 in Farcry 1.2?

I believe that PS 2.0 is not enough to collapse all lights into a single pass in Far Cry. However, you're right that some of the collapsing that is being done now could have been done earlier.

I just found that many of the PS 2.0b shaders are over 70 instructions, which means they won't work on X300/600 (at least, the API won't allow you to create such long shaders). I guess the gains people are reporting are coming elsewhere.

 

[Demirug]

I just found that many of the PS 2.0b shaders are over 70 instructions, which means they won't work on X300/600 (at least, the API won't allow you to create such long shaders). I guess the gains people are reporting are coming elsewhere.

What happens if the shader is below 70 instructions but use more than 12 temporary registers? I find more than one shader with this properties.
Anyway until now I was able to split each of the shader in the 2.B path in two 2.0 shaders that can run on a R3XX.

 

[OpenGL guy]

I just found that many of the PS 2.0b shaders are over 70 instructions, which means they won't work on X300/600 (at least, the API won't allow you to create such long shaders). I guess the gains people are reporting are coming elsewhere.

What happens if the shader is below 70 instructions but use more than 12 temporary registers? I find more than one shader with this properties.

The runtime shouldn't allow such a shader to be created. This is a primary difference between how shaders are handled in D3D vs. OpenGL. In OpenGL, you can create whatever shader you want, give it to the driver and let it attempt to compile it. If it fails, you can try a different shader. In D3D, there are strict limitations on what sort of shader can be created for a particular HW. This means that a 65 instruction shader that can be optimized to 64 or fewer instructions is not valid for PS 2.0 HW

 

[digitalwanderer]

Thanks for taking the time/trouble to explain it all OpenGL guy, at least I get it now. 8)

 

[Demirug]

I just found that many of the PS 2.0b shaders are over 70 instructions, which means they won't work on X300/600 (at least, the API won't allow you to create such long shaders). I guess the gains people are reporting are coming elsewhere.

What happens if the shader is below 70 instructions but use more than 12 temporary registers? I find more than one shader with this properties.

The runtime shouldn't allow such a shader to be created. This is a primary difference between how shaders are handled in D3D vs. OpenGL. In OpenGL, you can create whatever shader you want, give it to the driver and let it attempt to compile it. If it fails, you can try a different shader. In D3D, there are strict limitations on what sort of shader can be created for a particular HW. This means that a 65 instruction shader that can be optimized to 64 or fewer instructions is not valid for PS 2.0 HW

Thank you for this information. The offical documentations only tells you that there is a validation in the runtime but it did not tell you which parts of the shader are checked.

 

[Blito]

RV360 supporting SM 2.0b???

Acording to Asus specifications, it's A9600xt supports it. It even makes it clear in a FAQ:

http://www.asus.com/support/faq/qanda.aspx?KB_ID=87625

On ASUS website, it says A9600XT can support SMARTSHADER 2.1 which expands advanced abilities of vertex shader 2.0 and pixel shader 2.0. But on ATI website, it says it can support SMARTSHADER? 2.0 only. Why?

In the past, ATI9600XT chipset supports SMARTSHADER 2.0 and now ASUS A9600XT can support SMARTSHADER version 2.1.

Not that it mathers. Asus driver's make my monitor loose sync
But what's up with that???

EDIT: it has the same clamis for it's 9800xt. So R3x00 do support it, it just need to be enabled in the driver.

 

[ET]

Re: RV360 supporting SM 2.0b???

On ASUS website, it says A9600XT can support SMARTSHADER 2.1 which expands advanced abilities of vertex shader 2.0 and pixel shader 2.0. But on ATI website, it says it can support SMARTSHADER? 2.0 only. Why?

In the past, ATI9600XT chipset supports SMARTSHADER 2.0 and now ASUS A9600XT can support SMARTSHADER version 2.1.

EDIT: it has the same clamis for it's 9800xt. So R3x00 do support it, it just need to be enabled in the driver.

That's interesting. Smartshader 2.1 was introduced in the 9800, which added the F-buffer. 9700 was 2.0. X800 has Smartshader HD, which is different. F-buffer on the 9600? If that's true, I wonder why.