Report says that X1000 series not fully SM3.0?

[Redeemer]

Don't know if this has been posted, not quite sure I understand it either. What I want to know is, is it a big deal?


http://www.techreport.com/onearticle.x/8872



Quote:
Turns out that the vertex shaders in the Radeon X1000 series GPUs don't support a notable Shader Model 3.0 feature: vertex texture fetch. As it sounds, this capability allows the vertex shaders to read from texture memory, which is important because texture memory is sometimes treated as general storage in programmable GPUs. Vertex texture fetch is useful for techniques like displacement mapping, where the vertex and pixel shaders need to share data with one another.

 

[BRiT]

*ahem*

http://www.beyond3d.com/reviews/ati/r520/index.php?p=02

http://www.beyond3d.com/forum/showpost.php?p=588805&postcount=23

 

[Redeemer]

thanks

 

[Humus]

Vertex fetch is optional, so it's not needed to be SM3.0 compliant.

You basically have three options. Do like nVidia and implement it, but be slow and very limited. Or spend an assload of die space to put equal texturing capabilities in the vertex shaders, at the expense of general performance or other features you could use that space for. Or defer this feature until it makes more sense and use R2VB instead for today's needs as that's going to outperform vertex texture fetch and will work on previous generation hardware as well. Personally I think the last option is the right choice.

 

[Pete]

Question: vertex shader ALUs are vec4, and pixel shader ALUs are vec3+scalar. Will this be a problem WRT shunting vertex texturing to the pixel shaders, or will R2VB be used simply to access the PS' texturing units?

 

[Humus]

I'm not sure I get what you mean with that, I don't see why ALU configuration would cause any problems. Sure, R2VB can be used merely to access texturing capabilities, but it can be used to much more. Like effectively running vertex shaders in the pixel pipe, thus potentially achieving up to twice the performance.

 

[hkultala]

and you are totally confusing vertex and pixel shaders.

if there is a limitation in vertex shaders it has NOTHING to do with pixel shaders.

so the topic of this thread is completely wrong.

 

[AlphaWolf]

and you are totally confusing vertex and pixel shaders.

if there is a limitation in vertex shaders it has NOTHING to do with pixel shaders.

so the topic of this thread is completely wrong.

You should go around and post this comment in reply to the front page of about 20 news sites.

 

[mboeller]

Vertex fetch is optional, so it's not needed to be SM3.0 compliant.

You basically have three options. Do like nVidia and implement it, but be slow and very limited. Or spend an assload of die space to put equal texturing capabilities in the vertex shaders, at the expense of general performance or other features you could use that space for. Or defer this feature until it makes more sense and use R2VB instead for today's needs as that's going to outperform vertex fetch and will work on previous generation hardware as well. Personally I think the last option is the right choice.

Does that mean that the NV40/G70 would be faster with R2VB than when using vertex fetch too? Or in other words, would it make sense to use R2VB for every card, or would the developer has to use different paths for the different cards to get the best performance.


Manfred

 

[Humus]

Does that mean that the NV40/G70 would be faster with R2VB than when using vertex fetch too?

Most likely.

 

[Demirug]

Humus, you are right that the Vertex fetch Feature in VS 3.0 is optional. But it looks more like a forgotten backdoor than a planned behavior.

I am sure that anybody who try to read the DirectX Specs impartially will come to the same conclusion. But I will add my reasons why I believe that is only a backdoor.

1. The whole SDK documentation contains no words of warnings that it is possible that you can’t use vertex fetch with a VS 3.0 hardware. In the case of other optional features you can find such information’s.
2. If you look at the caps that a R520 reports you will see that it tell you it can use a point filter for vertex fetch. Nice. It don’t have a useable format but it supports filter. This looks unreasonably but there is a good reason why the driver do this. The DDK says that if your driver say that it support VS 3.0 it have to report at least point filter for vertex texture. IF it was ever planned to make vertex fetch an optional feature it makes no sense to add this demand to the DDK. It would be more easy to say: “If you don’t support vertex fetch report no filter for vertex texture.â€￾ In this case a developer can check the filter caps and don’t need to check every texture format to find that none of them supports vertex fetch.

Anyway I still have a little bit hope that ATI will add a driver solution. But it is only little. On the other Hand I hope that they will share some more information about the R2VB Hack. It would be nice if they work together with MS and nVidia at this point to make sure that it can be used not only for ATI hardware. But this is only a dream.

 

[Razor1]

Vetex texture fetching isn't that slow, there is a hit yes, but not that bad. Pacific Fighters uses it do all of its water rendering. Plus this game also uses dynamic branching for the water effects too. If used properly it can be used with no problems at all.

 

[Geo]

This is on the front page of [H] now, with some snotty comments on "Shader 3.0 done right".

How is it that some reviewers were aware of this and mentioned it in their pieces, while other high-profile ones are now claiming to be "shocked, shocked"?

 

[AlphaWolf]

This is on the front page of [H] now, with some snotty comments on "Shader 3.0 done right".

How is it that some reviewers were aware of this and mentioned it in their pieces, while other high-profile ones are now claiming to be "shocked, shocked"?

Media over dramatizing a story?!!? say it ain't so...

 

[Pete]

I'm slow, eh?

I'm not sure I get what you mean with that, I don't see why ALU configuration would cause any problems. Sure, R2VB can be used merely to access texturing capabilities,

I'm with you up to here, as I guessed using this back door for texturing would bypass the ALUs.

but it can be used to much more. Like effectively running vertex shaders in the pixel pipe, thus potentially achieving up to twice the performance.

This is where I'm having trouble. If one were to run vertex shaders with the pixel shaders, does the fact that vertex shaders can apparently process one more vec component per clock than pixel shaders (vec4 + scalar vs. vec3 + scalar) make any difference? Would it require an extra pass for the extra component?

 

[Rys]

How is it that some reviewers were aware of this and mentioned it in their pieces, while other high-profile ones are now claiming to be "shocked, shocked"?

Pretty simple: ATI didn't mention it in their presentations to press. You had to ask the right questions with sireric if you got a chance to chat to him.

They advertise the cap, but don't expose any surface formats to use with it, with devrel saying R2VB if an ISV asks how to texture from the VS.

 

[akira888]

If one were to run vertex shaders with the pixel shaders, does the fact that vertex shaders can apparently process one more vec component per clock than pixel shaders (vec4 + scalar vs. vec3 + scalar) make any difference? Would it require an extra pass for the extra component?

So long as the program is executing on the fragment-side HW it shouldn't matter whether pixels or vertices are the output type, the coissue rule is still vec3 + scalar. If you write a fragment shader that processes vertices into a vertex buffer, you will be still bound by the more restrictive coissue rule.

 

[Karma Police]

Is this dead yet? I used to really like the [H], but they posted this so fast before the facts are out & now they just look like the Inq.

 

[Dave Baumann]

I'm with you up to here, as I guessed using this back door for texturing would bypass the ALUs.This is where I'm having trouble. If one were to run vertex shaders with the pixel shaders, does the fact that vertex shaders can apparently process one more vec component per clock than pixel shaders (vec4 + scalar vs. vec3 + scalar) make any difference? Would it require an extra pass for the extra component?

Its not an extra pass - "co-issue" is just a performance opimisation thing, i.e. the shader compiler can issue two instructions on the VS at the same time from the same program simultaneously. All it would mean is that if the VS program was jam packed full ov Vec4 instructions and scalar instructions it would take twice as long to run on the PS than is would on the VS (well, not quite twice as long since many of the Scalar instructions would just be re-optimised to co-issue one on the Vec3 unit and another on the Scalar). In reality the instruction processing on the ALU's may be a little slower on the PS, but anything where textures are involved is almost certianly going to offset that in the PS.

 

[Mintmaster]

R600, where are you? :smile:

I've been waiting for fast vertex fetch ever since I heard of unified shaders in R400 back in 2001 while working at ATI. Four years later, and it's still not here except in Xenos, sadly.

I was sort of considering R520 when I saw it's featureset (FP blending + AA), but the lack of vertex texturing kills the deal for me. Of course, I'm approaching this from a semi-developer POV, not because I expect NVidia to have any advantage in games due to VTF. Even though Pacific Fighters uses it, it looks like most people are going the parallax occlusion mapping route.

Looks like one and a half more years with my good old 9700P. Hopefully R2VB will be easy to use and exposed on all hardware.

BTW, while we are talking about R520 features, does it have FP10 support or not? It's quite a stretch to call Int10 an HDR format, though I thought maybe that was a PR error.