Hack the Catalyst and find a SM3 chip

[Pete]

Uneducated Q: ATi seems to have better success with vertex shaders (vis a vis nV), while nV appears to have better luck with pixel shaders (vis a vis ATi). Is it conceivable that ATi are approaching unified pipes from a position of relative advantage, their vertex shaders? Or am I (grossly) oversimplifying?

 

[KimB]

Uneducated Q: ATi seems to have better success with vertex shaders (vis a vis nV), while nV appears to have better luck with pixel shaders (vis a vis ATi). Is it conceivable that ATi are approaching unified pipes from a position of relative advantage, their vertex shaders? Or am I (grossly) oversimplifying?

How do you think ATI is having better luck with their vertex shaders? ATI just has more of them in their latest iterations of the R3xx architecture.

 

[Dave Baumann]

Obviously, R500 is likely to be able to do filtering with Vertex texturing as it is going to have access to the same capabilities as the PS, but with R520 die space will still be an issue and whilst you are still using separate PS and VS you'll probably want to keep the VS spec down to the minimum where its easy to do so.

Not according to the caps Demirug found. And it makes sense, really, as Xmas said. The usual input format for VS is FP32.

Chalnoth - you're missing out on whats actually being discussed here (both myself and Mintmaster). R500 != R520.

R500 is, as far as we know, from the unified platform (to be used in XBox2) R520 is not the unified platform but a continuation of the R300 line with separate VS and PS. Thats why there are differences between the VS and PS capabilities with R520, but likely not with R500. My suggestion is that the VS capabilities are likely drawn from the ALU's that are used in R500's unified ALU's, but they lack Filtering to save die space in this separated structure that R520 is in.

 

[KimB]

I doubt they'd have filtering anyway, as, as Xmas mentioned, you'd probably want FP32 filtering with vertex textures, something that would take up a ton of die space.

 

[Dave Baumann]

I doubt they'd have filtering anyway, as, as Xmas mentioned, you'd probably want FP32 filtering with vertex textures, something that would take up a ton of die space.

For R520, yes, this is exactly what I've said (3 times now). However, under a unified shader pipeline the VS and PS are going to have to have the same capabilities so it stands to reason VS operations are going to have access to filtering under such a hardware structure.

 

[Xmas]

R500 will have filtering in the VS, but probably not with FP32 textures.

 

[Pete]

How do you think ATI is having better luck with their vertex shaders? ATI just has more of them in their latest iterations of the R3xx architecture.

Yes, their lead in the latest gen appears simply due to greater numbers or clock speeds (and nV's are more capable ATM), but ATi was faster and AFAIK more capable (GI) until this latest gen (from the 9700P's release to the 6800U's). Whereas ATi was "merely" faster with the previous gens' pixel shaders, while nV seemed competitive on the features front.

I may well be wrong. In fact, I probably am, thus the preface in my previous post.

 

[KimB]

For R520, yes, this is exactly what I've said (3 times now). However, under a unified shader pipeline the VS and PS are going to have to have the same capabilities so it stands to reason VS operations are going to have access to filtering under such a hardware structure.

The only problem with this is that there isn't the same amount of data available in the vertex pipeline as there is in the pixel pipeline, such as gradient information. So you may get bilinear filtering (at most for FP16), but you won't get trilinear/anisotropic or MIP mapping (except maybe with user-defined LOD).

 

[radar1200gs]

Perhaps I'm missing something fundamental here, but why would you want vertex data to be filtered the same way as pixel data in the first place? It doesn't make much sense - about the only use I can see is it would help ensure there are no accidental holes in a vertex mesh anywhere.

 

[Ostsol]

What if the mesh is denser than the texture? Of course, there's no point to -just- doing that since there would be alot of wasted vertices resulting in no extra detail. Still, one could use a detail texture to further modify positions.

I think it'd be most useful if there was hardware bi-cubic filtering, though.

 

[Inane_Dork]

The only problem with this is that there isn't the same amount of data available in the vertex pipeline as there is in the pixel pipeline, such as gradient information. So you may get bilinear filtering (at most for FP16), but you won't get trilinear/anisotropic or MIP mapping (except maybe with user-defined LOD).

So... what's the problem with that? Isn't that how you'd expect it to work?

 

[radar1200gs]

What if the mesh is denser than the texture? Of course, there's no point to -just- doing that since there would be alot of wasted vertices resulting in no extra detail. Still, one could use a detail texture to further modify positions.

I think it'd be most useful if there was hardware bi-cubic filtering, though.

Then your in-game tesselator is probably broken.

 

[Ostsol]

Huh? Did you read beyond the first sentence?

Make a grid that's 1024x1024 vertices. You have a heightmap that's 1024x1024 pixels. That texture fits perfectly to the grid, right? Now have an LOD system that will tesselate further. Now, let's say you have a grid that has 4x the vertex density, maximum. Take a 256x256 detail heightmap (representing rocky areas, I suppose) and apply it on a 1:1 ratio. If you used point sampling, the result would be full of steep angles when it should just be interpolated.

Here's another example (that probably makes more sense):

If you just take a heighmap and simply use each pixel as the height for a vertex, you can get some very poor terrain. A cross-section for an area with a slope of 0.5 will look like this:



Ugly, eh?

The alternative is to use a grid that's one larger on each dimension than the heightmap. Thus, for a 1024x1024 heightmap you have a 1025x1025 vertex terrain (the dimensions of which work out to 1024x1024). To get it to look right, without the stairsteps, is to sample heights from the corners of each texel, rather than the centre. If you use point-sampline, you have to do the math manually in the vertex shader and sample up to four texels. With linear texture filtering, it's automatic. The result for the a 0.5 slope will be a smooth line.

EDIT: Of course, this is only the case for an 8-bit heightmap. A heightmap that is generated in floating-point precision and stored in float-point precision will not suffer the same way.

 

[KimB]

EDIT: Of course, this is only the case for an 8-bit heightmap. A heightmap that is generated in floating-point precision and stored in float-point precision will not suffer the same way.

Huh? How does higher precision save you here? It seemed to me that your entire argument revolved around the granularity of sampling, not the precision....

Anyway, this is all true, but the question is, given that the software is going to have to calculate a number of the variables that are calculated automatically in the pixel shader, does it make sense to hardware-accelerate filtering, or will it just not be that much slower if emulated in the shader?

 

[Rolf N]

Vertex texturing without filtering strikes me as a useless gimmick feature. There's hardly any practical difference between using that and just adding another vertex attribute stream.
The only "no go" situation for attribute streams vs vertex textures is if you sample the same texture multiple times per vertex ... which you do to get the filtering the hardware doesn't provide. Meh. It just doesn't make any sense.

Mipmapping is close to meaningless in the VS though. It may be useful for fancy geometry LOD techniques, but not much else AFAICS.

 

[DeanoC]

Point sampling vertex textures gives you random access read-only array access in a similar manner to a CPU.

Having this greatly enhanced what you can do in a vertex shader. Examples are function approximations for particle systems and topology operations.

Also you can prefilter using a pixel shader for some operations or filter in the shader program.

Vertex texturing with any kind of filtering is the key benefit of SM3.0. IMO much more important than loops or any of the other stuff.

 

[radar1200gs]

Yes, I can see where point sampling can help, but bilinear, trilinear and Anisotropic filtering seem to be worthless in the vertex shader to me.

 

[DeanoC]

Well bilinear is a couple of 'free' lerps (very handy for functional approximation) so worthless is a bit much.

But yes it (and the others) can be reconstructed manually with a few arithmetic operations.

One day there may be no fixed function filtering in vertex OR pixel shaders but that day is some way off.

 

[Rolf N]

Point sampling vertex textures gives you random access read-only array access in a similar manner to a CPU.

Having this greatly enhanced what you can do in a vertex shader. Examples are function approximations for particle systems and topology operations.

W/o filters? With pure point sampling, you can't smoothly scale (or otherwise transform) texture coords. You always end up with popping artifacts if you try. That means that VS constants as an influencing factor to the texcoords are out of the equation. It's only the vertex data itself. Because the texcoords for the fetch can only depend on the vertex's attributes, you can just as well precompute the fetch result per vertex and be done with it. Sure, you can bind a different vertex texture to get a different version of your mesh, but just as well you can swap out a single attribute stream.

Each and every interesting usage of vertex textures requires filtering. Usage models that don't benefit from filtered vertex textures don't benefit from vertex textures at all IMO.

Also you can prefilter using a pixel shader for some operations or filter in the shader program.

Yes. But if we've learned anything from SIMD, a proper hardware implementation can do it much more efficiently. There's no ordering requirement between the four texels in a bilinear fetch, but there's good cache coherency. This really should be done in hardware, and a macro should be provided right now to enable a smooth transition.

Vertex texturing with any kind of filtering is the key benefit of SM3.0. IMO much more important than loops or any of the other stuff.

Agreed

 

[Mark]

No one should have something like "Point sampling vertex textures gives you random access read-only array access in a similar manner to a CPU." thrown in their face on a Monday morning.