Mr Blue,
I've edited your quotes because a) It doesn't really matter if we're talking about a 9800 or something else, b) It doesn't matter if it's realtime for your uses. All that matters is "Is it faster than a CPU?"
Mr Blue said:
o [A Graphics Chip] can *not* implement n texture passes [....]
[...]"n" usually means large in the computer world. "N" also denotes no bounds.
A VPU can do 8->32 in a pass and do as many passes as you want. Tends to be faster than a CPU at it as well. If your shading tree takes more than 32 textures in a a single node I'd be surprised (but feel free to surprise me
)
o [A Graphics Chip] can *not* implement noise shaders [in realtime] (all instructions done in hardware with *no* lookups) due to it's limited instruction set and API.
It can be done. People tend not to because it's slow for realtime use, but it can be done. (Oh, if you're doing gradient noise, i.e. classic Perlin, then you'll need to do lookups into your gradient table, but you do that on a CPU anyway)
How about conditional branching and looping (which is required to implement of fully functional filtered noise? How about shader trees where several shaders can call other shaders? Can I compute a gradient noise vector by calling it 3 times shifting my x, y, and z values by a small delta?
o Conditional branching, no, but predicates, yes, so we can do the same thing in a different way.
o Looping, yes.
o Shaders calling other shaders. Two ways of doing that come to mind. Either running ShaderB inline when ShaderA calls it, or Run shaderB first, write the output to a p-buffer and then use that as a texture in ShaderA.
o Calling a function three times with varying parameters
Please.
o [A Graphics Chip] can *not* implement complex lighting models [in realtime] also due to it's design and API.
That is rapidly becoming false. OpenGL SL and HLSL have an almost identical feature set to RenderMan SL, sure they're still in their infantcy, but it's not going to be long before you're going to be able to specify an abitarily complex shader and have it execute. Maybe not in realtime, maybe not written in the same style that you're used to, but faster than doing the same thing on a CPU I'll wager.
o [A Graphics Chip] does *not* have enough memory or bandwidth to render the kinds of scenes that go on the screen.
Bandwidth tends to be higher on a VPU than a CPU, but capacity is the one that I think is a real problem. In particular, the quantity of memory required to hold the meshes/textures, but there are chips out there that have nice large virtual address ranges (think "greater than the 4GB address space you currently have on each of those 32-bit CPUs in your renderfarm").
I think the main division between the VFX community and the Hardware 3D community is that the VFX community tend to see what the hardware is capable of in realtime and think that that's it. Games companies don't right complex lighting models because they want it to run in realtime. That doesn't mean it can't be done, and done quickly (comparitavly) .
Think of what state of the art software based rendering is, and compare it to what VFX companies do non-realtime.
Then think of what state of the art Hardware based rendering is, and imagine what VFX companies could do non-realtime.
As a parting thought. Why do you think NVIDIA bought Exluna?
Edit: P.S. Why render to 2Kx768? Why would you want a 2.6:1 aspect ratio? Surley 768 is rather low for the vertical dimension of something that'll be projected N feet high (Where N is large and unbounded
)
