Does Dave have ATI SM 3.0 Hardware?

[digitalwanderer]

Whether the SM2.0 speed can be made faster is irrelevant when you consider developers' preferences. It will always be preferable to write SM3.0 code than worrying about how to split SM2.0 code into multiple passes in order to make up for the lack of dynamic branching and other features that SM3.0 introduces. SM3.0 will also allow ATI's implementation of instancing to fit "properly" within the spec, though that's certainly a minor issue.

Gosh, it's nice to know that nVidia worries so much about making it easier on developers now...

So will it be easier than dealing with _pp?

 

[Ostsol]

Whether the SM2.0 speed can be made faster is irrelevant when you consider developers' preferences. It will always be preferable to write SM3.0 code than worrying about how to split SM2.0 code into multiple passes in order to make up for the lack of dynamic branching and other features that SM3.0 introduces. SM3.0 will also allow ATI's implementation of instancing to fit "properly" within the spec, though that's certainly a minor issue.

Gosh, it's nice to know that nVidia worries so much about making it easier on developers now...

So will it be easier than dealing with _pp?

They've reduced the need for extensive use of partial precision, haven't they? It still helps, but it isn't nearly so critical as it used to be.

 

[digitalwanderer]

They've reduced the need for extensive use of partial precision, haven't they? It still helps, but it isn't nearly so critical as it used to be.

Oh, I know that....I just haven't taken a gratuitous shot at nVidia in a while and wanted to make sure I was still in top form.

 

[Ostsol]

Oh, I know that....I just haven't taken a gratuitous shot at nVidia in a while and wanted to make sure I was still in top form.

Rotten troublemaker. . . *whacks the dig with a pixel shaded (3.0) trout*

 

[WaltC]

Whether the SM2.0 speed can be made faster is irrelevant when you consider developers' preferences. It will always be preferable to write SM3.0 code than worrying about how to split SM2.0 code into multiple passes in order to make up for the lack of dynamic branching and other features that SM3.0 introduces. SM3.0 will also allow ATI's implementation of instancing to fit "properly" within the spec, though that's certainly a minor issue.

What I think you're doing is assuming developers will prefer SM3.0 because of the additional assumptions you're making about a general desire among developers to "make up for the lack of dynamic branching and other features that SM3.0 introduces," and so on. The thing is, though, that of those developers who even know how to properly code for SM2.0 at this date I haven't heard much at all in the way of developer complaints or rants about "the limits of SM2.0."

Rather, what I've heard expressed is an appreciation of SM2.0 over SM1 that has come as developers *have learned* SM2.0--something that didn't by any means come overnight after the introduction of R300 SM2.0 back in '02. So I think the jury is out on whether SM3.0 is going to be hotly embraced by a majority of developers ASAP, at least before an IHV comes up with something *better* to offer them, that is...

Is SM3.0 as compelling a tool for developers as it has been for 3d-card IHV PR departments in recent months? We'll know by the end of this year going into next, I should think.

 

[DegustatoR]

Most of clever performance tricks ATI used in R300 core to make it as fast as we know it (FP24 being one of them) will be impossible in SM3 architecture. That's the main reason why many people aren't so sure that R520 will be as big a performance improvement over R420 as R420 was over R350.

R520 is definately a new generation architecture - the same way as NV40 is a new generation architecture compared to NV30.

 

[digitalwanderer]

Most of clever performance tricks ATI used in R300 core to make it as fast as we know it (FP24 being one of them)

Oh c'mon, now you're just baiting me.

FP24 wasn't a trick quite so much as it was a specification.

 

[Dave Baumann]

I'm wondering what other "tricks" won't be applicable to SM3.0 as well.

 

[Galduta]

I'm wondering what other "tricks" won't be applicable to SM3.0 as well.

in r520 ?

 

[digitalwanderer]

I'm wondering what other "tricks" won't be applicable to SM3.0 as well.

AND YOU'RE JUST CONTINUING TO TORTURE ME!!!!! :?

Dang it! Old man, weak heart....ring any bells?

 

[Xmas]

The thing is, though, that of those developers who even know how to properly code for SM2.0 at this date I haven't heard much at all in the way of developer complaints or rants about "the limits of SM2.0."

I've heard several developers claiming they already hit the limits of PS2.0 in a few occasions, mostly the instruction limit of ps_2_0 or the dependant read limit that still exists with ps_2_b. It's really not that hard to reach those limits with a flexible shader design tool.

Rather, what I've heard expressed is an appreciation of SM2.0 over SM1 that has come as developers *have learned* SM2.0--something that didn't by any means come overnight after the introduction of R300 SM2.0 back in '02. So I think the jury is out on whether SM3.0 is going to be hotly embraced by a majority of developers ASAP, at least before an IHV comes up with something *better* to offer them, that is...

Developers don't have to learn SM3.0. They write their HLSL code just as before, and enjoy less compiler errors because things that failed with ps_2_0 suddenly just work. This advantage is even bigger when you have artists create shaders by using some visual shader design tool

Is SM3.0 as compelling a tool for developers as it has been for 3d-card IHV PR departments in recent months? We'll know by the end of this year going into next, I should think.

Why not ask them now? I think I know the answer already.

FP24 wasn't a trick quite so much as it was a specification.

Let's say, it became a specification.

 

[digitalwanderer]

Let's say, it became a specification.

Uhm, no. You can say that if you like, but you'll be saying it in error.

It was the specification.

 

[CMAN]

Let's say, it became a specification.

Uhm, no. You can say that if you like, but you'll be saying it in error.

It was the specification.

Does this matter if it isn't the specification that will be part of the new chip?

 

[digitalwanderer]

Does this matter if it isn't the specification that will be part of the new chip?

It does since he was talking about the R300 and claiming that FP24 was a trick.

 

[Xmas]

Let's say, it became a specification.

Uhm, no. You can say that if you like, but you'll be saying it in error.

It was the specification.

I have to assume we're talking about different specifications or different chips then.

 

[CMAN]

Does this matter if it isn't the specification that will be part of the new chip?

It does since he was talking about the R300 and claiming that FP24 was a trick.

From a certain point of view it could be considered one, and from another it wouldn't. I believe it was a valid path to obtain certain frame rates.

 

[digitalwanderer]

Does this matter if it isn't the specification that will be part of the new chip?

It does since he was talking about the R300 and claiming that FP24 was a trick.

From a certain point of view it could be considered one, and from another it wouldn't.

True. One point of view would be correct and one wouldn't.

Please quit trying to do revisions to history, FP24 was the standard and IS the standard.

 

[rwolf]

Most of clever performance tricks ATI used in R300 core to make it as fast as we know it (FP24 being one of them) will be impossible in SM3 architecture. That's the main reason why many people aren't so sure that R520 will be as big a performance improvement over R420 as R420 was over R350.

R520 is definately a new generation architecture - the same way as NV40 is a new generation architecture compared to NV30.

FP24 was just to save transistors. FP32 can run just as fast or faster than FP24, it all depends on implementation.

I don't know what you mean by "Most of clever performance tricks". If anything it will be faster because they will have new and better or more clever performance tricks.

 

[CMAN]

Please quit trying to do revisions to history, FP24 was the standard and IS the standard.

Not arguing that! 8)

 

[ANova]

The fact that it will most likely be running FP32 and only FP32 is what is going to limit it's performance.

But they have the process shrink to allow more transistors. The only way FP32 limits performance when the entire processor is built for it is that you must allocate transistors for it that could otherwise have been used for other performance boosting circuitry. The NV40 has no problem running FP32 and I doubt R520 will have any problems. Was this thinking inspired by the Geforce FX where FP32 suffered because it was FP16 design doing double duty? (like a 32-bit CPU having to calculate 64-bit integers by looping)

What if, for instance, the R520 was not an SM3 part and thus continued to run FP24. You then would have those extra transitors from the die shink to help increase performance further rather then allocating them to other functions. An SM3 R520 at 600 MHz running FP32 vs an SM2b R520 at 600 MHz running FP24. Which do you think will run faster?

I'm not saying the R520 will have problems running FP32, on the contrary there are rumours that it will be more efficient then the NV40. What I am saying is that having to run FP32 will definitely hurt it's performance delta.

Regarding SM3 and it's future, I don't think it has one. Sure it can come in handy and yes it does make it easier for developers, but by the time games start to make use of instruction heavy shaders to the point where SM2 will no longer be a viable option WGF 2.0 will be available and far superior, at least imo.