Shader Model 4.0 -- what do we know about it?

[Reverend]

Well, the NDA'ed won't be able to offer much useful thoughts... can anyone summarize what it would offer based on "information"? Thanks.

 

[suryad]

4.0?!?! Already? Man do I feel behind the times with my ATI supporting 2.0b at the highest!! Err have programmers already harnessed the power of SM 3.0?!

 

[mustrum]

I don't expect any games that make good usage of SM3.0 before end 2006 (GOOD usage, not just implementing some basic SM3 stuff).
Talking about SM4 allready is insane!
Just look how long the game developer took to make good usuage of SM2.0!

 

[Bob]

I don't expect any games that make good usage of SM3.0 before end 2006 (GOOD usage, not just implementing some basic SM3 stuff).
Talking about SM4 allready is insane!
Just look how long the game developer took to make good usuage of SM2.0!

One could just use a high-level shading language instead. You'd then just code up whatever algorithm you fell like, and let the compiler work out how to map it to the hardware.

Of course, the compiler will have a much easier time on an SM4.0 target than on SM3.0.

 

[Megadrive1988]

less limitations than Shader Model 3.0's Vertex Shader 3.0 and Pixel Shader 3.0 more programmability, more features, etc ? I know, I don't know either

 

[aths]

I prefer to call it WGF2 instead of SM4. As far as I know will WGF2 just use "Shaders".

- The same instruction set for pixel- and vertexshaders, since there are just shaders.

- IEEE compliance. Well, mostly.

- Virtualized memory.

- A minimum performance to fulfill WGF2 compliance.

 

[Reverend]

I'll admit I haven't given much thought to SM4 ... until Deano, unexpectedly (by me), chosed to mention it in his recent article.

Treating SM4 as WGF2 would not be correct IMO -- WGF encompasses both a 3D desktop as well as 3D apps. WGF (1.0 or 2.0) is a big step up for the IHVs, for the CPU guys as well as the 3D guys.

I was speaking in terms of strictly what SM4.0 can afford in 3D apps. As we know, it's still in the formulation stages but with the vast pool of knowledge this forum has, I was hoping for some thoughts from certain individuals here that may provide something to think about for the lurkers (Tim Sweeney, for example) here that help shape DX/WGF and SM4.

 

[991060]

http://download.microsoft.com/downl...41f2-893d-a6f2295b40c8/TW04079_WINHEC2004.ppt
http://download.microsoft.com/downl...41f2-893d-a6f2295b40c8/DW04018_WINHEC2004.ppt

These might be a little out-dated, but they'll give you a general idea anyway. There will probably be update after WinHec2005.

 

[Dave Baumann]

http://www.beyond3d.com/articles/directxnext/

Treating SM4 as WGF2 would not be correct IMO -- WGF encompasses both a 3D desktop as well as 3D apps. WGF (1.0 or 2.0) is a big step up for the IHVs, for the CPU guys as well as the 3D guys.

If WGF2.0 is removing fixed functionality to rely solely on shaders then it probably is the case that we should actually remove the concept of "Shader Model x.x" entirely as they effectely are the API. For instance - part of the the "Shader" capabilities will be to be able to process unlimted length shaders, but thats intrinsically linked to the other capabilities required by WGF2.0.

 

[DemoCoder]

From what I've seen, DX-Next is more of an ambitious "wish list" than a set of requirements for WGF2.0. I don't believe everything people have seen publically will make it in to WGF2.0/SM4.0.

 

[Demirug]

From what I've seen, DX-Next is more of an ambitious "wish list" than a set of requirements for WGF2.0. I don't believe everything people have seen publically will make it in to WGF2.0/SM4.0.

Yes, the DX-Next papers from the last WinHEC are not longer Up to Date. Microsoft have removed the whole tesselation stuff from the pipeline. I am even not sure how unlimted the shader resources are at the moment because I have see something that tells me that as example the number of useable textures per pass are still limited.

 

[Demirug]

http://www.beyond3d.com/articles/directxnext/

Treating SM4 as WGF2 would not be correct IMO -- WGF encompasses both a 3D desktop as well as 3D apps. WGF (1.0 or 2.0) is a big step up for the IHVs, for the CPU guys as well as the 3D guys.

If WGF2.0 is removing fixed functionality to rely solely on shaders then it probably is the case that we should actually remove the concept of "Shader Model x.x" entirely as they effectely are the API. For instance - part of the the "Shader" capabilities will be to be able to process unlimted length shaders, but thats intrinsically linked to the other capabilities required by WGF2.0.

I am very sure we will not see any fixed functionality for pipeline stages that can control with a shader program. Even for WGF 1.0 microsoft removed fixed functionaliity on the driver interface for SM3 hardware.

 

[nAo]

Microsoft have removed the whole tesselation stuff from the pipeline

Bahh..tesselation is meant to be removed every time from whatever specification

 

[trinibwoy]

I am very sure we will not see any fixed functionality for pipeline stages that can control with a shader program. Even for WGF 1.0 microsoft removed fixed functionaliity on the driver interface for SM3 hardware.

Will the shader hardware be able to execute these functions as fast as the dedicated logic we have now?

 

[Megadrive1988]

So I guess that whatever has been axed from SM4.0 and WGF2.0 that was in DirectX Next / DX10, will then perhaps go into
SM 5.0 ? and a WGF3.0, basicly DX11, which we will not see for maybe 3-5 years.

 

[Ailuros]

Microsoft have removed the whole tesselation stuff from the pipeline

Bahh..tesselation is meant to be removed every time from whatever specification

Sad but oh so true. I guess IHVs set other priorities and they just run out of space.

 

[suryad]

I read that ATI was teaming up with M$ to come up with the WGF 2.0 spec with the "unified" pipeline idea...interesting...so then the R600 theoretically could be WGF .2.0 compliant.

 

[Ailuros]

I read that ATI was teaming up with M$ to come up with the WGF 2.0 spec with the "unified" pipeline idea...interesting...so then the R600 theoretically could be WGF .2.0 compliant.

I doubt that having unified units in WGF2.0 ended up being a requirement. Rather optional or if you prefer "you can if you want to"....

I've no idea what some of the small vendors have planned for the WGF2.0 era, yet there are more members than just ATI that have a vote in the according board I figure.

 

[_xxx_]

I've no idea what some of the small vendors have planned for the WGF2.0 era, yet there are more members than just ATI that have a vote in the according board I figure.

Oh, sort of like US and the UN Security council?

 

[KimB]

One (potentially) highly significant optimization will be optimized cubemap rendering. Currently, cube maps are rendered such that each face is rendered separately. The optimization in WGF2 will allow all six cubemaps to be rendered at the same time. This requires about the same pixel fillrate, but should significantly decrease vertex processing required for cube maps. Since shadow maps are particularly vertex-limited, this should help performance with the rendering of shadow maps significantly (for point lights).

Note: like all other features of WGF2, keep in mind that the official spec has not been released, and thus all current knowledge is subject to change.