Report says that X1000 series not fully SM3.0?

[Richard]

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.

While I generally agree what you're trying to say I don't agree that "[it] is not very necessary at all". With it HDR RT allows faster light blooms. And yes INT16 formats can do the job but not for all situations unless you slave way at the fragment program; with more and longer shaders I think the goal should be to get away from low-level optimisation. And the "16-bit is enough" argument can be risky as was proven in the past. We're not talking about a feature no IHV has and we wish they did. Is this a huge problem? No, but I think filtering is needed and in this gen.

Anyway, similarly, nVidia's vertex texture look-up also requires filtering on the vertex program (not really a big deal) however the need to roll your own LoD there is I think a significant hindrance as instructions begin to pile up; that and the inherent latency of course. Before making up my mind about R2VB what I'd really like to see is a test showing its performance penalty.

 

[OpenGL guy]

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.

Exactly, so what's your complaint? The only thing the control panel option does is allow you to disable GI if you don't want it.

 

[Demirug]

I wrote that several days ago and published it on wednesday

I don't want to argue who was first. I am sure we both will lose because I remeber that someone from nVidia say the same thing back in the days of NV30.

But they couldn't change DCT to check for point sampling?

I am sure DCT already check the vertex texture filter flags in the case the VS version is 3.0. And in the case of a X1800 the driver set this flags to point sampling. This check will be fine.

But to run a vertex fetch test it will need to create a texture. They spec say that it can only use a texture format that have the right flag. DCT need to check all formats but it will not be able to find one. As the spec don't say that you need to have at least on useable vertex fetch format a DCT test can not stop and call it a fault if it can't find a texture format. This is the open hole in the spec.

As I am writen before I am willing to live with that if Micorsoft or at least ATI and nVidia together find a common way to suport R2VB with a DX hack. I am still prefer a VT solution because it need less render passes. But make R2VB useable is at least a fallback that should better than let the CPU do all the calculations.

I know that Direct3D 10 will have suport for R2VB but it will not help me with Windows XP and pre D3D 10 hardware.

 

[Demirug]

Exactly, so what's your complaint? The only thing the control panel option does is allow you to disable GI if you don't want it.

I have no problem with the control panel option.

I even understand that the driver hack was the only way to get it in after DirectX 9.0c was done.

My complaint in the GI case was primary that there is still no offical document on ATIs developer site that tell everybody that the cards support GI and how it could activate.

On the other hand there is still the question why ATI don't request a Cap bit for this usefull feature. But this is not a direct complaint because I know only the statement from a microsoft employee.

 

[Dave Baumann]

Demirug, my point being is that I already know what you're saying (as I have published in the article), and we are kind of saying the same things, I just don't believe they went into it without checking it with MS first, it would be too risky a manouver - they are saying that MS are happy to expose R2VB this was, although they weren't under similar circumstances with GI. My understanding that DCT checks the the VT Caps bit, but doesn't mandate any texture format so just won't run any VT tests if its not there (but evidently passing even on 0 tests run!).

 

[DemoCoder]

I'd argue that in the long run, given R2VB being part of DirectX at some point and the move to a unified shader programming model (where you must support texturing from all shader programs regardless), that SM3.0-level vertex texturing might have a short shelf life in games titles.

Unified shading doesn't mean vertex programs go away. What unified shading means is that vertex programs execute more efficiently and reuse some of the same texturing logic as the fragment shaders.

I'd argue that unified shading hardware will be more likely to make R2VB go away. A unified HW will execute VS + VT very efficiently, more efficiently than R2VB, because you are not wasting time with the ROPs and wasting bandwidth.

 

[Geo]

Another episode in All Our ALUs:



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.

It's so standard that a full year later it is already in one game? No, that doesn't read like Brent either --that reads like cut 'n paste from the email he received from his <kaff> technical experts that he consulted on the matter with ATI's response to him. Not that that is entirely inappropriate, btw, since the technical experts I have in mind certainly are technical experts. But, y'know, the fella in the middle has to apply some "common sense filters" too.

 

[Hellbinder]

I'm pretty sure that even S3 is supporting this feature. Does Deltachrome alredy support it?

 

[Rolf N]

I'm pretty sure that even S3 is supporting this feature. Does Deltachrome alredy support it?

What? Vertex texture fetch? No.

 

[WaltC]

Another episode in All Our ALUs:



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.

Agreed. It was most certainly written by a nVidia marketeer--that would be my guess. Another sad chapter in the dismal story of the compromise and usurpation of some web sites by vested corporate interests (Heh... Did I really just say that?)

I can only wonder, since Brent isn't the "editor-in-chief" after all, if his remarks weren't give a bit of "editorial addition" by the "editor" just to make absolutely sure that we could all see through the charade without difficulty so that there would be no doubt that it wasn't written by Brent... (Pride goeth before the fall, etc.) If Brent claims to be the author then I'd like to pose a few questions to him.

As to this distinct topic, I feel it's A-OK for ATi, and for nVidia, to implement whatever features of the specs they choose, and I would hope that what is implemented gets implemented for a lot more justification than providing empty marketing bullets. Don't know about anyone else, but "feature" implementation which has the net practical effect of doing nothing for my 3d gaming is never something, IMHO, to jump up and down about.

 

[DemoCoder]

As to this distinct topic, I feel it's A-OK for ATi, and for nVidia, to implement whatever features of the specs they choose

It is not ok to implement a subset of a spec, and then claim full support. Regardless of the performance of features, specifications exist to ensure interoperability, not to ensure performance. It is a separate question as to whether Microsoft specifications should include minimal performance guarantees. I think they should, since performance guarantees are one reason why console programming has advantages. But that is a separate argument.

I don't like bifurication of specs, and I don't like weakly written specs that cause fragmentation of the market. Not having CAPs bits is one problem, but having a proliferation of CAPS bits is another. It is best to create a feature and performance profile, that IHVs must meet, and which consumers and developers can rely on.

 

[Humus]

Hopefully R2VB will be easy to use and exposed on all hardware.

It's supported on R300 and up and I believe it's already in public drivers.

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.

For moderate ranges it works fairly well. But one of the best things about the RGB10_A2 is that it can be used as a backbuffer format, which will improve quality, even for non-HDR cases.

 

[Humus]

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.

Why the heck would vertex texture fetch be required for raytracing? In the next ATI SDK there will be a raytracing sample I wrote, and it uses neither VTF or R2VB.

Edit: Just noticed the new SDK is up.

 

[OpenGL guy]

I'm pretty sure that even S3 is supporting this feature. Does Deltachrome alredy support it?

Deltachrome is a SM2.0 part. S3 never marketed Deltachrome as having SM3.0 features, so I don't know where you are getting this from.

 

[DemoCoder]

Humus, It isn't neccessary for anything, as all of those can be done via R2VB. I just don't think R2VB is very forward looking. It's a hack to get around the lack of lookups in VS, and the lack of some other features the VS model is missing (access to neighbors, which you get somewhat with gradient in PS. Ability to loop back data into another VS pass, etc.) But VS doesn't need many of the other raster operations provided by the pixel pipeline, hence I feel it is aesthetically ugly, and should be replace by unified shading and SM4.0 in the future.

I think the VS programming model is much cleaner than R2VB model, and the abstraction of operating on vertices at a high level should be preserved to the developer.

 

[Humus]

I'd argue that unified shading hardware will be more likely to make R2VB go away. A unified HW will execute VS + VT very efficiently, more efficiently than R2VB, because you are not wasting time with the ROPs and wasting bandwidth.

Uhm, in what way do you save any ROPs and bandwidth? With VTF you render to a texture, then access it through a sampler. With R2VB you render to a texture, then access it as a vertex buffer. There's no difference in bandwidth or ROPs needed. There's one difference, that VTF requires extra instructions and/or vertex data to compute texture coordinates, which is not the case with R2VB.

 

[OpenGL guy]

Uhm, in what way do you save any ROPs and bandwidth? With VTF you render to a texture, then access it through a sampler. With R2VB you render to a texture, then access it as a vertex buffer. There's no difference in bandwidth or ROPs needed. There's one difference, that VTF requires extra instructions and/or vertex data to compute texture coordinates, which is not the case with R2VB.

Plus with R2VB you get texture filtering, mipmaps, a variety of texture formats, etc.

 

[DemoCoder]

I disagree.

With VTF, you only render to texture only if you need to update the texture every frame (e.g. e.g. iterated physics) and when you do it, the possibility exists to do it only once, and reuse it with multiple vertex streams. With R2VB you update both the texture you are sampling (e.g. iterated physics) AND must render a new vertex buffer. Every new vertex stream requires a separate render. Theoretically, you could combine the storage of your physics state as well as your vertices in the same buffer, but that adds additional complications as well limit reusability of the calculations for other streams.

The VTF requires extra instructions to figure out texture addresses, but the R2VB requires extra texture samples to lookup the input vertices.

The assumption that vertex textures are created by the rasterizer I think is flawed. That may be the case in some instances, with the assumption of physics done on the GPU, but is also likely the case that these are done by the CPU, which is certainly more like the case on XB360/PS3, as the very system architecture was designed to allow CPU driven procedural synthesis.

It R2VB is such a huge win, why don't we just get rid of vertex shading on GPUs, get rid of unified shading, and just make pure PS rasterization cards? I think it is the wrong model, and that the current segmented model (vertex shader, pixel shader, and future geometry/tesselation shaders) is the correct one going forward.

 

[DemoCoder]

Plus with R2VB you get texture filtering, mipmaps, a variety of texture formats, etc.

Presumably on a unified shading card, you would automatically get these since you'd be sharing many of the same function units. This is not an argument for R2VB and against the VS model going forward in the future. It is an argument about what can be done today in HW. My message from the beginning has be about what is the right model for developers and for IHVs in the future. R2VB is a hack and using it to do VS is the wrong abstraction.

 

[cho]

Uhm, in what way do you save any ROPs and bandwidth? With VTF you render to a texture, then access it through a sampler. With R2VB you render to a texture, then access it as a vertex buffer. There's no difference in bandwidth or ROPs needed. There's one difference, that VTF requires extra instructions and/or vertex data to compute texture coordinates, which is not the case with R2VB.

Ther R2VB need to run Pixel Shader instructions ? is it transparent when developers use VTF (like the ATI driver can conversion the VTF as R2VB on X1000s) ?