AMD: R8xx Speculation

[Voxilla]

So that means that tesselation is not a DX 11 specific feature?

Well, http://users.belgacom.net/xvox, uses some smart techniques to do GPU tessellation. In fact the technique already worked with DX8 hardware.

I've even extended it to do tessellation of spline objects. It works pretty well calculating tessellated spline vertices and normals...

Maybe I'll brush up the code and post it.

 

[Dave Baumann]

I see rumor-ometer has just gone haywire today...!

 

[Kaotik]

So that means that tesselation is not a DX 11 specific feature?

DX11 is the first DirectX to have tesselation in it's featureset, however tesselation to some extent has been done on GPUs on Radeon HD8500 already (n-patches aka truform), heck even GF3/4 had something similar to that but apparently without dedicated hardware, it was shortly removed from the drivers due abysmal performance. And then of course all ATI GPUs since R600 have had dedicated tesselator in them, similar to that in Xenos, which was used as the grounds for DX11 tesselator specifications / requirements

 

[no-X]

ATi says RV870 has 6th gen. of tesselator. I can keep count only 4 previous generations: 1. Xenos, 2. R600, 3. R670, 4. R770. What's the 5th gen?

 

[AlNom]

Maybe they're counting R200.

 

[smw]

ATi says RV870 has 6th gen. of tesselator. I can keep count only 4 previous generations: 1. Xenos, 2. R600, 3. R670, 4. R770. What's the 5th gen?

TruForm?

 

[Silent_Buddha]

I would guess they are including TruForm in that. I believe there was 2 versions of TruForm, but my memory might be wrong on that count.

Regards,
SB

 

[Humus]

It's a little more work to really calculate perspective correct differentials for texture coordinates per pixel instead of the difference between pixels, but it's by no means impossible.

How would you do that for the general case? I can see that working if you're talking about sampling directly from the interpolator coordinates, but that's not a sufficient solution since probably half of the texture reads if not more these days come from computations within the shader. How are you going to tackle dependent texture reads for instance? I don't see any analytical solution to that. The only per pixel solution I can come up with would be to triple the math in the shader to compute two neighbor samples and compute the gradients from that, but that's going to be slower for no particular benefit.

 

[2senile]

I would guess they are including TruForm in that. I believe there was 2 versions of TruForm, but my memory might be wrong on that count.

Regards,
SB

8500 hardware, 9700 software. My memory might be wrong as well but there was definitely a difference between the two implementations.

 

[Voxilla]

DX11 is the first DirectX to have tesselation in it's featureset, however tesselation to some extent has been done on GPUs on Radeon HD8500 already (n-patches aka truform), heck even GF3/4 had something similar to that but apparently without dedicated hardware, it was shortly removed from the drivers due abysmal performance. And then of course all ATI GPUs since R600 have had dedicated tesselator in them, similar to that in Xenos, which was used as the grounds for DX11 tesselator specifications / requirements

Don't forget about the Matrox Parhalia, it did displacement mapping and depth adaptive tessellation, way more advanced than anything NV or ATI had at the time.

 

[no-X]

Yes, R200 (R8500/R9100) was the only GPU supporting TruForm in hardware. RV250 (R9000) and later supported TruForm via software.

 

[Demirug]

Don't forget about the Matrox Parhalia, it did displacement mapping and depth adaptive tessellation, way more advanced than anything NV or ATI had at the time.

But unfortunately they never managed to provide proper driver support for it.

 

[neliz]

man...still 32 hours to go

 

[MfA]

How would you do that for the general case? I can see that working if you're talking about sampling directly from the interpolator coordinates, but that's not a sufficient solution since probably half of the texture reads if not more these days come from computations within the shader. How are you going to tackle dependent texture reads for instance? I don't see any analytical solution to that. The only per pixel solution I can come up with would be to triple the math in the shader to compute two neighbor samples and compute the gradients from that, but that's going to be slower for no particular benefit.

Let the developer worry about it, if he uses the difference instructions they run like quads ... if the performance degradation for small tris is too much for him he can solve it.

 

[nAo]

How would you do that for the general case?.

That's easy, you shade before computing visibility. I know..it's a bit drastic

 

[ferro]

Games will run 5 to 25% faster on Windows 7 than on Windows Vista?

Does this seem plausible?

 

[compres]

Nice, I got w7 in my non Linux partition. Good to know I get better performance than vista.

 

[flopper]

Games will run 5 to 25% faster on Windows 7 than on Windows Vista?

Does this seem plausible?

yes it does.

 

[Alexko]

Wow! A 25% performance boost over Vista in certain games, that's huge!

 

[Novum]

I'm sorry?

AF lacking samples?
If you're talking about AA, you are grossly mistaken and will be pleasantly surprised.

No I'm not talking about AA. I'm talking about AF which causes texture flickering in movement.

ATI is doing underfiltering here since the HD 2000 series. 16xAF is actually talking less samples in parts of the picture than 8xAF. It's even worse when you activate A.I..

And yes I know exactly what I'm talking about, I'm the author of this nice little tool:
http://www.3dcenter.org/3dtools/filter-tester-en