Hack the Catalyst and find a SM3 chip

[Demirug]

If you use a disassembler with the "ati3duag.dll" you can find code that set the DX Caps for a SM3 chip.

VS: 3.0 with 1024 slots (NV40: 544) and only pointsampling (like NV40)
PS: 3.0 with 512 slots (NV40: 4096)

If you search a little more you can find a other part that change one property for the FP16 RGBA texture. It looks like that this flag allow the use of alphablending with this format. On the other hand the texturefilter option seems still deactivated.

 

[oeLangOetan]

Did you find that in the cat4.12 betas?

 

[tEd]

Did you find that in the cat4.12 betas?

yes

 

[Tim Murray]

does this necessarily mean anything at this point?

 

[Inane_Dork]

does this necessarily mean anything at this point?

Yes. It means that ATi has another graphics card coming out, which is pretty shocking.

 

[Moloch]

does this necessarily mean anything at this point?

Yes. It means that ATi has another graphics card coming out, which is pretty shocking.

R520?

 

[Inane_Dork]

does this necessarily mean anything at this point?

Yes. It means that ATi has another graphics card coming out, which is pretty shocking.

R520?

:?

 

[Tagrineth]

does this necessarily mean anything at this point?

Yes. It means that ATi has another graphics card coming out, which is pretty shocking.

But I thought ATi was dead! You mean they really plan to release another card?

 

[tEd]

how important is a more advanced texture filter in vs3.0? Is it even important? Point sampling is min. spec. but would it be useful to support bilinear or even aniso (yet)?

 

[Inane_Dork]

But I thought ATi was dead! You mean they really plan to release another card?

Well, it's all speculation at this point, but numerous developers leaks seem to confirm it. This thing about the driver is just more direct proof.

And... you never know... it might be... Cell based!

 

[Xmas]

how important is a more advanced texture filter in vs3.0? Is it even important? Point sampling is min. spec. but would it be useful to support bilinear or even aniso (yet)?

There are basically two ways to look at texture filtering. One is to use it to find the value of a continuous function at an infinitely small point, but since you only have discrete sample values, you have to interpolate between them. The other is integrating texture values over the area which irepresents a pixel projected into texture space. Point and bilinear sampling rather fit the first category, while trilinear and especially anisotropic filtering are based on the concept of area integration.

However, a vertex has no area, so you would need a concept of "distance to a neighbor" to make use of those filtering modes, and there is no such thing in VS3.0. The lack of bilinear filtering in the VS is disappointing, but understandable given that the usual input format for VS is FP32, and that bilinear filtering at that precision is very costly.

 

[frost_add]

And if absolutely neccessary one can always implement filtering inside vertex shader. One of NVIDIA's papers on vs3.0 even shows exact code to do bilinear and trilinear. vs3.0 (just like ps3.0) has no limit on texture dependency levels or number of used texture instructions.

 

[cho]

One of NVIDIA's papers on vs3.0 even shows exact code to do bilinear and trilinear. vs3.0 (just like ps3.0) has no limit on texture dependency levels or number of used texture instructions.

nv40's VS can use shader to do linear filter ?

 

[KimB]

One of NVIDIA's papers on vs3.0 even shows exact code to do bilinear and trilinear. vs3.0 (just like ps3.0) has no limit on texture dependency levels or number of used texture instructions.

nv40's VS can use shader to do linear filter ?

Hell, with arbitrary texture reads, you could in principle do bicubic filtering.

 

[KimB]

If you use a disassembler with the "ati3duag.dll" you can find code that set the DX Caps for a SM3 chip.

VS: 3.0 with 1024 slots (NV40: 544) and only pointsampling (like NV40)
PS: 3.0 with 512 slots (NV40: 4096)

Just fyi, the available instruction slots in the NV40 has been increasing since launch. There may not in fact be a hard limit with the NV40 (though the lack of a hard limit is more likely with pixel shaders than vertex shaders).

But, on a side note, this does seem rather interesting. It seems to indicate a rather different direction to 3D rendering (focusing more on vertex than pixel shading). One has to wonder why ATI is going in this direction?

 

[Geo]

Thanks, Demirug. Personally, I like to hear about these little milestones in the real world supporting what we think we know from the whisper/rumor mill. Maybe everyone has already put it in their pocket that R520 is coming in the spring, but not having access to inside sources myself, or any practical way to judge the reliability of the source of other anonymously-sourced reports that appear, I like to hear about things like this as a reality check.

 

[Mintmaster]

But, on a side note, this does seem rather interesting. It seems to indicate a rather different direction to 3D rendering (focusing more on vertex than pixel shading). One has to wonder why ATI is going in this direction?

My guess is it has to do with a unified shading pipeline in ATI's future architectures stemming from R500 (well, R400 originally). The biggest advantage you get is a massive increase in vertex shading power. Aside from academic examples, however, I don't think having super long vertex programs really buys you that much better graphics.

Vertex texturing should quite cheap as well since the latency could be entirely absorbed. IMO, this is where the next major advances will be as far as using the GPU to enhance gameplay.

 

[KimB]

My guess is it has to do with a unified shading pipeline in ATI's future architectures stemming from R500 (well, R400 originally). The biggest advantage you get is a massive increase in vertex shading power. Aside from academic examples, however, I don't think having super long vertex programs really buys you that much better graphics.

I don't see why vertex and pixel pipelines would allow a different number of instructions in this case.

 

[Dave Baumann]

R520 is a hack job, innit?

Its probably far easier to hack the capabilities of the VS than it is the PS - in fact, it wouldn't surprise me at all to find that the vertex shader ALU's are much more akin to the ALU's of R500 than the Pixel Shader ALU's are or will be, since they are probaly easier to replace at this juncture. 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.

 

[KimB]

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.