GDC Presentation Suggests No VS 3.0 Support for R420

[bloodbob]

If we are to assume that the R420 is to be released at GDC or earlier.

The GDC paper show how the new profiles fit in and the diagram Clearly points that "You are hear" is just before VS_3_0!!!!. ( same goes for PS_3_O ). This could also be a marketing ploy for the current generation cards being really really close to the next generation too I guess.

 

[AlphaWolf]

Well there are currently no cards on the market with either, so ya that is where we are. Is that where they say we are gonna be in 2 months?

 

[DemoCoder]

Yes, it also suggests that the R420's pixel shader feature set is even less than the NV3x, since PS_2_a still has every limitation that PS2.0 had except for the instructions are raised to 512 limit and there are a few more temp registers.

No arbitrary swizzle, no unlimited dependent textures, no gradient instructions, and no predication.

 

[jpaana]

You probably mean ps_2_b, as ps_2_a is the NV3x profile.

 

[ben6]

Who gave you the idea that R420 is being launched at GDC? Sorry that ain't the case.

 

[DemoCoder]

You probably mean ps_2_b, as ps_2_a is the NV3x profile.

Yes, I mean PS_2_b (e.g. PS_2_ATI) is a subset of PS_2_a. Now developers are back in the situation they were in with PS1.1,1.2,1.4,2.0. A profliferation of profiles.

Ben,
Why would ATI create a new DX9/HLSL profile (PS_2_b) if they were going to fully support PS_2_x(a) in the R420? PS_2_b offers nothing new except bigger instruction limit (already supported by 2_a) and a few temp registers. To me that clearly indicates that the R420 isn't going to support the queryable features of PS_2_x. The only possibility is that PS_2_b is intended for the R9800 + F-Buffer as a profile.

 

[DemoCoder]

NVidia's GDC presentations hint at NV40 features

http://download.nvidia.com/developer/presentations/GDC_2004/RenderingTechniquesNVIDIA.pdf

Render To Vertex Buffer + Texture Read in Vertex Shader
FP16 textures with floating point texture filtering and render target blending. Judging by the samples, VS3.0 looks like a huge improvement.
Also Centroid Sampling looks like it will make it, as well as "Geometry Instancing"

More is supposed to be available Wednesday.

 

[Mintmaster]

Thanks, DemoCoder, that was a very informative pdf. I'm definately looking forward to VS 3.0, so I hope ATI didn't skip it.

I'm not sure why they talked so much about that gaussian approximation of normals. Approximating a sum of gaussians as another gaussian won't do that much for quality. A 2D lookup in a 128x128 texture will certainly cause plenty of thrashing as well, gobbling up cache space, as N dot H changes with high frequency wrt to space. I guess 128x128 is probably a bit extreme in one axis at least, as N dot N shouldn't vary a whole lot.

I think PTM's (polynomial texture maps) solve this problem in a much better way. They should be faster, can approximate self-shadowing and interreflections, and have no mipmap problems. I guess this discussion should go in the coding forum.

I'm rather skeptical about NV40 having so many (16) full pixel pipelines. I mean they have fp texture filtering (with AF), fp blending, supposedly far better per-clock pixel shading, VS 3.0, PS 3.0, and NV35 took 130 million transistors for a 4x2 config. They're supposed to get all that with only 200 million transistors? I'd be mighty impressed. Seems like they'd have to start from scratch (which is possible if a parallel team has been working on this since GF3 or GF4), and get amazing design efficiency.

 

[jpaana]

The only possibility is that PS_2_b is intended for the R9800 + F-Buffer as a profile.

I thought of that as well, but currently ATI only exposes 12 temps on 9800, the ps_2_b profile has 32. I don't think F-buffer increases the number of available temps as such?

 

[Evildeus]

What do you recon of the AA presentation?

Mintmaster> Aren't most of the transistors memory cache? Or am i wrong? So i wouldn't say it's impossible to do it.

 

[991060]

Hi guys, do you have any detail about this ps_2_b thing? I saw it in the new HLSL compiler, but the document mentioned nothing about it.

 

[Evildeus]

Perhaps there's something on Ati developper's page?
http://www.ati.com/developer/techpapers.html
Edit:
http://www.ati.com/developer/gdc/D3DTutorial_ShaderModels.pps

 

[991060]

Great help,thanks a lot

 

[Evildeus]

Np

 

[nutball]

Re: NVidia's GDC presentations hint at NV40 features

FP16 textures with floating point texture filtering and render target blending.

FP render target blending?

If that supports FP32, I'm having NVIDIAs babies.

 

[bloodbob]

Re: NVidia's GDC presentations hint at NV40 features

FP16 textures with floating point texture filtering and render target blending.

FP render target blending?

If that supports FP32, I'm having NVIDIAs babies.

Even FP16 blending would be damn nice though you couldn't use it in all cases.

 

[Dave Baumann]

Why would ATI create a new DX9/HLSL profile (PS_2_b) if they were going to fully support PS_2_x(a) in the R420?

Because PS_2_a compiles to NV3x target, which may not necessarily be optimal for ATI.

 

[991060]

which platform is vs_2_a mapped to? I think it's NV3X.

 

[DemoCoder]

Yeah, but if that was the case Dave, they could have created a PS_2_b which supports *every feature of PS2_x* AND the compiler uses different optimization heuristics. Instead, PS_2_b isn't merely a flag to signal different optimization heuristics, it's a profile that does't offer any new PS_2_x features except more instructions slots and a few temp registers.

If the R420 HW really supports PS_2_x features, why didn't they add those as well?

First of all, the profileration of profiles as compiler hints stinks. But that's wouldn't be bad if they were just that. But since PS_2_b offers more slots and registers, it is in fact, a new class of shaders, which means developers will have to write PS_2_b specific shaders (a class of shaders with more instructions than PS2.0, but none of the advanced features of PS_2_a)

Are we going to add a new DX9 profile for every new HW that comes out, just so the DX compiler can optimize properly? This is insane. PS_2_a(b) shouldn't really exist. There should be PS2.0 and PS3.0. It was bad enough that 2_a got created, we don't need more.

 

[Evildeus]

which platform is vs_2_a mapped to? I think it's NV3X.

You think? I thought it was the R420.