Report says that X1000 series not fully SM3.0?

Another episode in All Our ALUs:

Yesterday we wrote a short news piece on some realizations that have come to light about what features the X1000 series support in regards to Shader Model 3.0. We asked ATI specifically if texture lookups in the vertex shader were supported, this is their response:

"Vertex texture fetch (an optional feature in SM 3.0) is not supported directly; however, since the X1000 family does all pixel shader calculations with FP32 precision, just like the vertex shader, it is possible to get the same results using the render to vertex buffer capability. Basically, you do a quick pre-pass where you render to a special linear buffer in which each pixel represents a vertex. Textures can be used to modify each vertex through the pixel shader, and the result is then read back into the vertex shader. The result is fast vertex texturing with full filtering support, without requiring any special hardware in the vertex shader engine."

The claim here is that the feature “Vertex Texture Fetch†is actually an optional feature in Shader Model 3.0 and this specific feature is not supported directly with the Radeon X1000 family. They then go on to explain how there is a work around to enable the same result as doing a texture lookup from the vertex shader using pixel shaders. While the technique is very intriguing from a technical standpoint the fact is that ATI lacks a major Shader Model 3.0 feature in hardware.

Vertex Texture Lookups are necessary for some effects such as displacement mapping, hardware raytracing, advanced hardware skinning, hardware based collisions and soft body deformations, bone system generation, and many other areas of research developers are working on. To not include a very standardized feature means the progression of games utilizing these features will be dwarfed. In fact there is indeed already one game that supports the “Vertex Texture Fetch†feature and is using it to provide better image quality with water.

The way the workaround works with the Radeon X1000 family requires game content developers to specifically write in special code just for ATI X1000 family hardware if they want to gain the same result as doing a texture lookup from the vertex shader. This requires more time and effort on their part to specifically support these kinds of features within the X1000 family. With NVIDIA’s GeForce 6 and 7 series however this same result can easily by done officially through the supported Shader Model 3.0 feature in DirectX. This workaround that ATI has in place reminds us of their backdoor method of performing Geometry Instancing in R420 hardware which was not officially supported in DirectX. We all know how well that turned out, basically no developers used it in their games, instead opting for the Shader Model 3.0 implementation, and one example is FarCry. CryTek added in a patch the ability to do geometry instancing using the Shader Model 3.0 implementation and not ATI’s specific implementation that only works on their hardware and is not part of the DirectX standard.

This seems to us a case of ATI believing they are doing something better or “Right†but in reality they are lacking a very important specific feature of Shader Model 3.0. Therefore we hold our ground in saying that the slogan “Shader Model 3.0 Done Right†should really be called “Shader Model 3.0 Done the ATI Way.†Wasn’t this the mentality NVIDIA had when they created the high level language CG and the GeForce FX? We all know how that turned out.

Someone is being led straight down the primrose path. I'm sorry, but the bulk of that absolutely does not read like it was written by Brent.

Edit: Oh, and enabling vertex texture fetching in Pacific Fighters is great, if you like frame rates from 5-15 fps on high-end systems.
 
Last edited by a moderator:
They really appear to be off on one at the moment - Brents report talks about Geometry Instancing as something that didn't get used because of the way it is enabled, citing Far Cry as an example of adding it for SM3.0 but not realising that Far Cry was the very game that enabled it for ATI as well. Kyle has just put a stupidly puzzling post up about "paper launches" and the X800 GTO they they, apparently, have never seen, not realising that its a vendor only card. Weird.

Brent also appears to be suggesting that its not an optional feature, which isn't the case - caps shows as VS3.0 fully exposed.
 
Kaotik said:
Do the current HDR solutions (or forthcoming) requiring FP blending require also filtering, or are the X1x00 cards fine?

You can do it without blending an filtering but this is a real pain. If you have at least blending it can be done better because filtering can emulate most times with the pixelshader. It will only a problem if a game want to use real FP16 textures for normal game content.

But as ATI is one of the two big GPU manufactor you can be sure that HDR solutions in future games will work with X1x000 cards. And I am sure that we will see patches for current games with HDR solutions very soon if the game does not already contains the changed shadercode.

Maybe in some point in the future it is possible that a HDR solution can give you a better quality if the chip suports FP filtering but this is not very likely.

If HDR is your only point that stop you from select a X1x000 you can go ahead because it will work for sure.
 
Dave Baumann said:
They really appear to be off on one at the moment - Brents report talks about Geometry Instancing as something that didn't get used because of the way it is enabled, citing Far Cry as an example of adding it for SM3.0 but not realising that Far Cry was the very game that enabled it for ATI as well. Kyle has just put a stupidly puzzling post up about "paper launches" and the X800 GTO they they, apparently, have never seen, not realising that its a vendor only card. Weird.

In the case of the GI Issue ATI is guilty in more than one way.

- They miss to tell Microsoft that they can suport it with there VS 2.0 hardware and want a caps bit for it.
- They miss to write a public document about how you can check for it and activate it. Sure you can ask for this information but if you don't know about it why you should ask?

Dave Baumann said:
Brent also appears to be suggesting that its not an optional feature, which isn't the case - caps shows as VS3.0 fully exposed.

It's only an optional feature because the spec have a hole. You will find no single word in the whole DX documentation that it is possible that a Vertex Shader 3 hardware don't suport vertex fetch. On the other hand the spec says that you need to suport point filteror better for vertex fetch. Why should there be a demand for a filter if you don't need to suport it at all?
 
Demirug, the point I was maing about GI is the fact that its pretty silly using Far Cry as a way to implement SM3.0 GI when they did in fact enable it for ATI as well.

As For Vertex Fetch - do you seriously believe that ATI went into this without vertifying it with MS? ATI rely on DCT and WHQL and when they designed this they would have made sure that they were going to get it and MS don't "close" that loophole as they did with GI.
 
Dave Baumann said:
Demirug, the point I was maing about GI is the fact that its pretty silly using Far Cry as a way to implement SM3.0 GI when they did in fact enable it for ATI as well.

Yes, using Far Cry was silly. Anyway GI was a different case an it should better not used in the context of this new problem.

Dave Baumann said:
As For Vertex Fetch - do you seriously believe that ATI went into this without vertifying it with MS? ATI rely on DCT and WHQL and when they designed this they would have made sure that they were going to get it and MS don't "close" that loophole as they did with GI.

There never was a loophole in the case of GI. The person who build this hack in they driver was only to stupid to do it right. I am sorry for this hard words but it is easy to use FourCC codes to show additional features and still pass the WHQL test.

After the current DirectX 9.0c version microsoft say that we will not see any more spec changes and they will only release new runtimes if they need to fix bugs. Anyway even if microsoft change the spec in a way that say that you need to have at least one texture format that can be used for vertex fetch ATI still can add a driver solution that emulate this with the pixel shader an the R2VB technic. As Microsoft is not very fast in build a new DCT and make it compellingly time shoud not a problem if this ever happend.

My answer to your question is yes. I am seriously believe that ATI is take this little risk because Microsoft can do nothing about it without change the spec. They can't change they spec simply overnight and if they do it they have to speak with all IHVs.
 
Hellbinder said:
Why is it that every single time ATi leaves out a Feature that Nvidia is supporting or has supported for a while... The reason is "Its not required or its to slow"..
You want to give some examples?

There was PS 2a on he FX, and that was next to useless for end users. PS 3.0 without decent branching performance does very little over PS 2.0 from a practical gaming standpoint. Even purely synthetic tests (e.g. Shadermark shadowing) showed that.

The only thing I see fit your description is FP16 blending. The more intelligent among us did know this was a problem for ATI for HDR support in games - even I was frustrated that they didn't have Int16 blending at least, and declared I would never buy a R4xx/RV4xx product upon discovering this.

I was very excited about vertex texturing, but the huge latency is a big problem for NVidia. Most of the cool stuff you can do with vertex fetch, like doing cloth/water/particle simulation, are probably nearly as fast on the CPU because of this, and if you don't get a sizable speedup there's no point unless you're a developer. Displacement mapping is not very useful without high tesselation, at which point performance would slow down to a crawl. Even using it for a table lookup is heavily discouraged.

In fact, I would argue that your statement is true in the opposite sense - when NVidia lacked a feature that ATI had nobody cared. When the Radeon came out with EMBM, it as written off as a poor way to do bump mapping and DP3 was the correct way. EMBM is dependent texturing, far more useful than just for bumps, and I would say ALL of the "wow" effects of the DX8 era could have been done on the original Radeon, and oddly enough would have looked better sometimes. Parallax mapping has been blowing people away for a while now, but it could have been done (and was in a demo, actually) on PS 1.4 with ease. Instead, PS 1.4 was never really used. I better stop myself before I get on a rant.
 
  • Like
Reactions: Geo
There never was a loophole in the case of GI. The person who build this hack in they driver was only to stupid to do it right. I am sorry for this hard words but it is easy to use FourCC codes to show additional features and still pass the WHQL test.
What I'm talking about is that MS objectd to this method of GI and actively did change DCT in this case to check the texture capabilities of the FOURCC modes expose, which is why ATI had then go back an enable it as a control panel option.

After the current DirectX 9.0c version microsoft say that we will not see any more spec changes and they will only release new runtimes if they need to fix bugs. Anyway even if microsoft change the spec in a way that say that you need to have at least one texture format that can be used for vertex fetch ATI still can add a driver solution that emulate this with the pixel shader an the R2VB technic. As Microsoft is not very fast in build a new DCT and make it compellingly time shoud not a problem if this ever happend.

My answer to your question is yes. I am seriously believe that ATI is take this little risk because Microsoft can do nothing about it without change the spec. They can't change they spec simply overnight and if they do it they have to speak with all IHVs.
The design of R520 was started long before the current DX9.0c was implemented, and as my point above shows, MS have made changes to DCT even after DX9.0c was out.
 
Demirug said:
There never was a loophole in the case of GI. The person who build this hack in they driver was only to stupid to do it right. I am sorry for this hard words but it is easy to use FourCC codes to show additional features and still pass the WHQL test.
What are you going on about? GI support was added precisely the way it was for a reason. Since you aren't privvy to those reasons, maybe you should give people the benefit of the doubt?

There is no CAP for GI support. It's expected that all SM 3.0 cards support GI. However, cards that don't support SM 3.0 are not allowed to support GI, capiche? Think about that for a while.
 
Even if the loophole has been "closed", the fact remains, the spec has been written as if VT was a requirement. If MS patches the spec now, or "reinterprets" the spec to allow it to pass, it just means the lobbying succeeded. But what about the other IHVs who were trying to build SM3.0 prior to this (NV isn't the only one), who put in extra effort to meet all of, what was then assumed, *required* SM3.0 features? That seems a little unfair that the spirit of the original spec is being changed just to satify one IHV's marketing requirements to slap a "SM3" moniker.

Now the market is fragmented yet again. Devs need yet another code path, and the "SM3.0" moniker in fact, means nothing, since almost everything that SM3.0 was supposed to have required is now optional.

They may as well called SM3.0, SM2.d or something. I thought the whole point of major version number jumps in shader models was to set some minimum level of required features.

SM3.0 seems to be a minefield as far coding is concerned, and it seems developers may as well just stick with 2.0
 
Kaotik said:
Do the current HDR solutions (or forthcoming) requiring FP blending require also filtering, or are the X1x00 cards fine?
FP16 filtering, while nice, is not very necessary at all for HDR in games. There are great workarounds with Int16 (see Humus's site), and even better is that these workarounds save speed on all hardware, including NVidia's. Besides, ATI can do pixel shaded filtering if need be at a speed cost, even making it transparent to the developer.

Alpha blending is very different, though, as you need significant code changes to make do without it. If they did just this one thing last generation, NVidia's practical gaming advantage with features would be next to zero. I think ATI did this intentionally so that they could leverage the R3xx/NV3x user base and hope developers would see it their way. I don't think they anticipated the 6800 to be such a dream card for developers.
 
DemoCoder said:
Even if the loophole has been "closed", the fact remains, the spec has been written as if VT was a requirement. If MS patches the spec now, or "reinterprets" the spec to allow it to pass, it just means the lobbying succeeded.
:?: The spec hasn't been patched and it does pass.
 
OpenGL guy said:
There is no CAP for GI support. It's expected that all SM 3.0 cards support GI. However, cards that don't support SM 3.0 are not allowed to support GI, capiche? Think about that for a while.
Hubba-wa? What?

Y'mean my lowly X800 TT that's only SM 2.0 could support GI officially if those meanies at MS would let it? Why wouldn't they?!? :???:
 
Dave Baumann said:
What I'm talking about is that MS objectd to this method of GI and actively did change DCT in this case to check the texture capabilities of the FOURCC modes expose, which is why ATI had then go back an enable it as a control panel option.

Yes I know this but there was an other solution that did not need a control panel option. Simply use a valid textureformat if a texture from this "faked" format is created. This would make DCT happy.

Dave Baumann said:
The design of R520 was started long before the current DX9.0c was implemented, and as my point above shows, MS have made changes to DCT even after DX9.0c was out.

As I have writen before Vertex fetch can be emulate with R2VB. If Microsoft had force a spec change in the past ATI would be able to still get a SM3 chip. But as the spec is not changed they were able to save some work.

DCT is changed from time to time but all new tests are write against the spec. It is imposible to add an vertex fetch test that will fail on a X1x000 without changeing the spec.
 
Demirug said:
As I have writen before Vertex fetch can be emulate with R2VB.
I wrote that several days ago and published it on wednesday ;)

DCT is changed from time to time but all new tests are write against the spec. It is imposible to add an vertex fetch test that will fail on a X1x000 without changeing the spec.
But they couldn't change DCT to check for point sampling?
 
Demirug said:
Yes I know this but there was an other solution that did not need a control panel option. Simply use a valid textureformat if a texture from this "faked" format is created. This would make DCT happy.
Something like this was already done. I believe the control panel option is just to allow you to force GI support all the time, without requiring the app to use the back-door method to get it enabled.
 
OpenGL guy said:
What are you going on about? GI support was added precisely the way it was for a reason. Since you aren't privvy to those reasons, maybe you should give people the benefit of the doubt?

I am sorry if i had made you angry.

But I need to tell you that one person from microsoft was nice enough to give some information about the GI story. He say that before they build they DirectX 9.0c runtime there were no request to add an additional cap bit for GI. Because of this they don't change they spec. Maybe this was a lie but as long nobody say that there was a request for a GI Cap bit I see no reason why I should not believe him.

OpenGL guy said:
There is no CAP for GI support. It's expected that all SM 3.0 cards support GI. However, cards that don't support SM 3.0 are not allowed to support GI, capiche? Think about that for a while.

Yes, this are not allowed but this don't stop the ATI DirectX driver team to build an hack that make it possible to use GI on every VS 2.0 card from ATI.

To use it you will need to check for a special FourCC Format and then you need to write a special value to a renderstate that is normaly not used. But I am sure you know this better than me.
 
Back
Top