rwolf said:
Well unless you go in the road of RT or GI, there's no much more you can offload to the GPU there, unless you wanted some kind of automatic-multipass-system, which might work in a Deferred Renderer but not too well in anything else. This would most definitively have at least some use, but I don't think the result would be mind-blowing.
I assume you mean per-object visibility determination. I imagine some very smart things could be done in a RT-like architecture when it comes to this, but the possibilities in a normal renderer are only so great.
If the batch overhead was smaller, however, I do imagine one possibility regaridng this, but I honestly doubt it's going to happen, at least not anytime soon: you could associate a render call with a very low tesselation model, basically a bounding box, and you'd transform that with a simple VS program. The resulting vertices would then be clipped, but not rasterized.
Then, if at least one vertex survived the clipping (no matter if it was modified or not), the full model would be rendered. Otherwise, it wouldn't be. What this does, basically, is highly accurate frustum culling on the GPU, at very low costs.This would most obviously required dedicated transistors for it, but besides for what's with them after the clipping, the vertices could be passed through the normal pipeline.
With a better bus or more dedicated logic, you could also do hierarchical visibility determination with such a scheme. You could also implement LOD with it, if you rasterized the box but didn't check it with the Z-Buffer, just to check hiw many pixels COULD be visible. I think doing a depth test would be counter-productive, because you could have only a very small part of a building visible, but very near you: that would require good geometric detail even though much of it would be occluded, or it risks looking like crap. A more complicated scheme might work better for that but would be, well, more complicated.
And before anyone even considers saying this is similar to Occlusion Queries, it honestly doesn't have much of anything in common, unless you used OQs in an imo really inefficient way, and even then it wouldn't do quite the same thing. I just thought of this idea now, so I didn't try to schematize exactly how to get the "fully culled" information, but it seem very possible to me. Using rasterization for that seems counterproductive however, because it might miss something considering there isn't an infinite number of subsamples and the real triangles won't have the same subpixel positions.
Well, Intel's new architecture seems better for physics than the current one, but still nothing astonishing, so dedicated logic for physics in special purpose processors has some potential in the x86 market, at least in the short-term.
A company like NVIDIA or ATI wouldn't be in a position to create its own physics API, so they would most likely have to depend on Novodex. This means to me that they would be reluctant on such a thing, especially so when graphics have no real "transistor limits" like CPUs; that is, with twice the number of transistors, you can dramatically improve per-clock performance without really reducing the clockrate.
What could happen is that either company might buy AGEIA if their PPU isn't a financial success; they could then either develop a discrete solution, integrate it into high-end motherboards, or include it in high-end GPUs. Or, if AGEIA's lineup is a success, they could license the API and do any of the above, although then a discrete solution seems very unlikely to me. Heck, in all cases, I doubt this is going to happen within the next 4 to 5 years.
Uttar
P.S.: If there's one technology I think we'll see within the next 2.5 years, it most definitively is dynamic allocation of MSAA samples ala 3DLabs; the actual financial savings of this technology are quite big, as it would result in a slowdown of the expansion of RAM costs. This is also key in making FP16+ HDR MSAA an extremely viable option.
