hybrid vertex textures ?

[KimB]

There are reasons why using the CPU is not a likely scenario at all.

Well, yes, it'd kill performance for more reasons than one, but would be a solution if ATI wanted SM3 functionality for a checkbox feature, even if they didn't fully support one of the required instructions.

The other solution, using the pixel texture units from the vertex shader, would seem to be difficult to implement well, and would drop pixel performance whenver vertex textures are used, but would certainly be better than basically using software emulation.

 

[Dave Baumann]

Well, yes, it'd kill performance for more reasons than one, but would be a solution if ATI wanted SM3 functionality for a checkbox feature, even if they didn't fully support one of the required instructions.

Given the evidence that suggests ATI are concentrating on branching performance it doesn't suggest they are looking at these things in a "Checkbox only" fashion, does it?

But like I said, wait and see (I've already given a hint but I'm not going to make it too easy).

 

[KimB]

Well, typically branching performance is at odds to texturing performance, since for high-performance texturing you want to have long pipelines to hide latency, but for high-performance branching you want short pipelines. So I don't think that concentrating on branching performance would preclude the use of vertex textures as a "checkbox feature."

One side note, though:
There's no reason why shaders that use a vertex attribute directly as a texture coordinate need be slow with this hybrid CPU/GPU method. It's just shaders that do any sort of dependent texture read that would have poor performance.

 

[wishiknew]

sorry, I just read something about stochastic or pseudo-stochastic AA and felt I had to post.

I suppose the "stay tuned" bit is T-AA, but gah. underwhelming.

Sireric made a couple posts recently that has a "stay tuned"

http://www.rage3d.com/board/showthread.php?t=33796563

 

[3dcgi]

Well, typically branching performance is at odds to texturing performance, since for high-performance texturing you want to have long pipelines to hide latency, but for high-performance branching you want short pipelines.

I don't think this needs to be true. You can have short ALU pipelines surrounded by a memory to absorb the texture latency. Then when the texture data is available route the data back through the ALUs.

 

[KimB]

I don't think this needs to be true. You can have short ALU pipelines surrounded by a memory to absorb the texture latency. Then when the texture data is available route the data back through the ALUs.

Right, but then you have a situation where you may want to have different items in the pipeline run with different latencies. This is a problem that would need to be solved, I believe, in order to efficiently handle unified pipelines, but is a nontrivial one. I would be rather surprised, actually, if ATI was doing this sort of thing already without actually going fully-unified.

 

[Hyp-X]

I don't think this needs to be true. You can have short ALU pipelines surrounded by a memory to absorb the texture latency. Then when the texture data is available route the data back through the ALUs.

Right, but then you have a situation where you may want to have different items in the pipeline run with different latencies. This is a problem that would need to be solved, I believe, in order to efficiently handle unified pipelines, but is a nontrivial one. I would be rather surprised, actually, if ATI was doing this sort of thing already without actually going fully-unified.

Think about this as breaking down the shaders into runs of texture instructions than runs of ALU instructions.
Call these phases - and I suspect all ATI GPUs work that way.

You can say - hey you cannot do that if a texture fetch is in a conditional branch.
Well, IIRC, the need to support a texture fetch in a conditional branch in SM3.0 was removed in DX9.0c...

 

[Demirug]

I don't think this needs to be true. You can have short ALU pipelines surrounded by a memory to absorb the texture latency. Then when the texture data is available route the data back through the ALUs.

Right, but then you have a situation where you may want to have different items in the pipeline run with different latencies. This is a problem that would need to be solved, I believe, in order to efficiently handle unified pipelines, but is a nontrivial one. I would be rather surprised, actually, if ATI was doing this sort of thing already without actually going fully-unified.

Think about this as breaking down the shaders into runs of texture instructions than runs of ALU instructions.
Call these phases - and I suspect all ATI GPUs work that way.

You can say - hey you cannot do that if a texture fetch is in a conditional branch.
Well, IIRC, the need to support a texture fetch in a conditional branch in SM3.0 was removed in DX9.0c...

There are some restrictions however it is not completely forbidden.