Since when do the R500 support SM3.0?

[DOGMA1138]

http://www.theinquirer.net/?article=20146

Microsoft's current kit is powered with older Radeon 9800 cards and things will get much faster this time round. Developers have to code on Shader Model 3.0 hardware.

AFAIK the R500 have only SM2.0+ support. and giving that this data comes from the inq, i dont know if its reliable.

 

[tEd]

..then your knowing doesn't go very far does it

 

[DOGMA1138]

i never said it dose
i thoght that the R500 had SM2.0+ and unifide shaders, and that the R520 will have SM3.0.

 

[tEd]

well then r500 is supposed to have at least SM3.0 functionality. Never heard otherwise

 

[DeanoC]

Considering by defination a unified shader core has to have texture support, branches and FP32, how hard would it be to make it SM3.0?

 

[Inane_Dork]

Considering by defination a unified shader core has to have texture support, branches and FP32, how hard would it be to make it SM3.0?

I would think you'd have to specially design it to make it less than SM3.0, which would be funny (from my POV) and sad/stupid (from your POV).

 

[KimB]

I was under the impression that the R500 was to become the Xbox Next part, and the R520 the desktop part.

 

[KimB]

Considering by defination a unified shader core has to have texture support, branches and FP32, how hard would it be to make it SM3.0?

Branching wouldn't be required in a unified shader core.

 

[MuFu]

I was under the impression that the R500 was to become the Xbox Next part, and the R520 the desktop part.

That does seem to be the case, yes.

They might not even mention a "shader model" with respect to R500, although I imagine it'd be approximate to an SM3.0-SM4.0 intermediary. Walla (tee-hee).

 

[Acert93]

My guess would be since MS requested the chip, and is setting the SM 4.0 and WGF/DX Next standard (which it is working with IHV's like ATI on) I would think they would try to make the R500 as close to a SM 4.0 part as possible. I get the impression part of Longhorn is this new impressive graphic interface, so having your console support a strandard pretty similar would be a good move for cross platforming... and is that not what a big part of XNA is about? I would not expect SM 4.0, but SM 3.0+ would be a good bet imo. And the leak discussions I have seen mention this, but I have not seen anything in stone in the "leaked" specs (if they are real). I guess we only have a few more weeks to wait to know for sure!

 

[Megadrive1988]

http://www.theinquirer.net/?article=20146

Microsoft's current kit is powered with older Radeon 9800 cards and things will get much faster this time round. Developers have to code on Shader Model 3.0 hardware.

AFAIK the R500 have only SM2.0+ support. and giving that this data comes from the inq, i dont know if its reliable.

that's incorrect. whether Inquirer said it or not. R500 should have SM3.0++


the R500 for Xbox2 is a step beyond the upcoming SM3.0 or 3.0+ capable R520 (dispite the numbering scheme). R500 should have SM 3.0++ ....basicly something inbetween SM3.0 and SM4.0. perhaps closer to SM4.0.

the R600 for PCs will be based on R500 but should have full SM4.0 support.

R300 / 350 / 360 / 420 / 480 all support SM 2.0+ so it would be silly to think that R500 isnt going to be a significant advance over SM2.0+ which has been in ATI graphics processors since late summer/ fall 2002.

so let me throw the question back to you. since when did you think R500 was only going to support SM2.0+ ?

 

[Hyp-X]

Ok, once more:

R520 - R420 core hacked to be SM3.0 compliant
R500 - complete redesign with features above SM3.0 specification

Altough I don't know the details but it sounds like R500 might do better than R520 even in features supported by both (like dynamic branching).

 

[DeanoC]

Considering by defination a unified shader core has to have texture support, branches and FP32, how hard would it be to make it SM3.0?

Branching wouldn't be required in a unified shader core.

VS2_0 requires static branching, so any unified core must have that (assuming it has even R300 capabilities).

In theory a unified core could not do dynamic branching, and therefore not be SM3.0 but its one of the few features you have to add.

 

[Ailuros]

the R500 for Xbox2 is a step beyond the upcoming SM3.0 or 3.0+ capable R520 (dispite the numbering scheme). R500 should have SM 3.0++ ....basicly something inbetween SM3.0 and SM4.0. perhaps closer to SM4.0.

If Xenon doesn't incorporate a Geometry Shader, I'd be rather call it SM3.0. There's more to the unification of shaders in the shader model of WGF2.0 than "just" pixel and vertex shaders and from my understanding it must be a requirement in WGF2.0 (unless I've missed the boat and there are different versions of WGF2.0 "compliance" already).

Bottomline: if there's any merit to the above, having unified units doesn't give you much more than SM3.0. Ok they're unified, so what?

 

[Dave Baumann]

AFAIK the Geometry Shader doesn't necessarily have the same functonality / instructions as the VS/PS; I believe the only elements that are confirmed as unified (in their instruction set / capability requirements) are the VS and PS.

 

[Zeross]

AFAIK the Geometry Shader doesn't necessarily have the same functonality / instructions as the VS/PS; I believe the only elements that are confirmed as unified (in their instruction set / capability requirements) are the VS and PS.

In the leaked "Save the nanosecond" pdf we could read :

If the geometry shader is “done rightâ€￾ it’s part of the vector processor pool – and therefore can have a vertex shader before it – and after it! Which is useful...

So I guess it's unified with VS, PS or at least in an ideal world it should be. I don't really see how since it must have specific functions for creating or deleting vertices which shouldn't be available in PS because that would have no sense...

 

[Dave Baumann]

Richard recently gave me cause to believe that it won't necessarily be unified with that pool (but that doesn't preclude utilising the results before and after).

 

[KimB]

VS2_0 requires static branching, so any unified core must have that (assuming it has even R300 capabilities).

Static branching doesn't require hardware support. The hardware that makes use of it typically just resolves the branches in the driver at shader load time.

 

[DeanoC]

VS2_0 requires static branching, so any unified core must have that (assuming it has even R300 capabilities).

Static branching doesn't require hardware support. The hardware that makes use of it typically just resolves the branches in the driver at shader load time.

Doesn't require it, but then neither does dynamic branches. The question is how fast you want it to be...

Its true that in some cases will the driver resolve branchs at render time (static branches are on constant changes) but unless this is an very cheap operation they 'drop' back to instruction level branching.

Think about it, a potential worse case could be reloading the program into GPU instruction ram (IRAM) at every draw call (if each draw call changes a constant the shader is branching on). Changing shader on chip is generally the most expensive state change, usually you have to flush the front side geometry and then reload the instructions.

However if you have lots of instruction RAM (to hold all possible paths at the same time) or double buffered IRAM then you prehaps don't need specific instructions.

Anyway there exists hardware virtually free static branch hardware and I suspect either that or real dynamic branching is supported in all SM2.0 or higher hardware. The way the hardware actually make static branching virtually free is itself fairly clever and really demostrates how unlike a CPU, a GPU can be.

 

[KimB]

Bottomline: if there's any merit to the above, having unified units doesn't give you much more than SM3.0. Ok they're unified, so what?

As far as I can tell, the only reason to go unified is performance. For example, imagine a scene that has some nearby objects with large triangles, and other objects far away with very small triangles.

With a traditional renderer, those far away objects would tend to be primarily vertex-limited, while the nearby objects would be pixel-limited. So pretty much the entire time the scene is being drawn part of the core will remain largely unused.

With a unified renderer, however, you could get near-perfect utilization all the time, such that you'd have just as many pipelines operating as vertex pipelines as are necessary at that time.

Naiively, then, this would seem to be clearly better than a traditional renderer. The questions remain as to how many extra transistors it would cost to do this, and whether or not there would be any additional performance concerns in attempting to make the same pipeline do two separate jobs at basically the same time.

nVidia's claim is that the choice will then become between very efficient but separate pixel and vertex pipelines, or a unified system that isn't as efficient when doing just one or the other, but is more efficient in keeping more pipelines active. Which will come out ahead? Well, we'll have to see.