Whats the next big thing in realtime graphics?

SA said:
I see these changes being driven by the problems that still remain to be solved in realtime 3d. In particular, real-time 3d graphics is about much more that just the graphics (i.e. physical simulation of the optical properties). It's about 3d physical simulation in general. This includes the collision detection, rigid body physics, fluid dynamics, soft body dynamics, statics, character behavior, etc.

This is what I meant.

The eventuality that GPUs would become a "vector" purpose, generalized computaiton unit akin to our high speed scalar CPUs is an understanding that I thought most people had, at least those who are interested in this area. I don't see anything in SA that strays from this.

I think people are carry the G in GPU too far into their thinking, it's falling away.
 
Brimstone said:
SA said:
In either case, the compiler should detect the floating point capabilities and hide the hardware specifics. The compiler should also automatically optimize the floating point code for vector hardware without the developer being involved (much like Intel's current compiler). The same code would then work on current CPUs/GPUs but would take advantage of any new CPU/GPU floating point vector capabilites. Admittedly compiler optimization for vector processing is in its early stages, but it is one of those hurdles that must be overcome to move to the next phase.

Increasing frequency has had a good run for the last few decades. This approach to increasing performance, however, is quickly running out. New hardware architectures will need to focus on parallism and transistor efficiency, while keeping the job of programming for it roughly the same.

How are vector processing compilers in their early stages? They've been used for a long time in supercomputing?

New hardware architectures will focus on parallism, but expecting to keep programming the same is a false dream. A departure from C and C++ will have to happen. A general purpose processor designed with parallism will require a different programming model. The memory system will be organized differently.

While auto-vectorising compilers have existed for a long time, it has also been true that they have not been optimal by a very long shot. It's interesting to see the efforts IBM is making at present to get such capabilities into gcc4 in a useable form, so I guess eventually it will be completely mainstream, five decades or so after the CDC Cybers.

Personally, I'd tend to agree with Brimstone that the programming models need to change if the benefits of large scale parallellism are to widely realized. On the other hand the depressing number of "C++ forever" programmers shouldn't be underestimated. Additionally, it could be argued that we will see a forking in the development of processors, and that the change in processing capabilities tha SA describes will never make it out of the niche. Will users everywhere be prepared to pay the price of processors that increasingly only bring benefit to gamers and the relatively few number crunchers? I'm sure AMD, Intel and IBM all hope so in order to keep ASPs up, but I really don't think it's sustainable forever. (Everything I do that isn't connected to either number crunching and gaming could just as well be done with the processor in my PDA, and in a couple of years, the processor in my phone.) In a way, this is an argument in favour of the capabilities being provided via what we today call the GPU, but I can't really see Intel/IBM/AMD giving up that niche so easily. It will be interesting to if/how the Cell processor and the ideas behind it influences the next decade of general purpose computing.
 
I agree that the processing will move to general purpose. If you want to handle complex things like physics and lighting on the GPU, which I think is inevitable, because things like a boat moving through water require rules as well as morphing/creating geometry, you need things like procedures, libraries and dynamic branching. And at the same time, it would require an interface to upload those programs and download (some of the) results, so the game logic can keep track of events. Which is essentially the same as a MIMD stream processor, or a set of parallel DSPs, with additional general purpose logic for integer calculations (loops, booleans), resource management and branches.

While I agree that the CPU (or Intel, AMD etc.) will want to keep contributing to be able to sell more chips, I think the only way to do that would be like IBM (and ARM) do: by splitting the CPU up into separate units. Ahritmic cores, general purpose cores and interfacing (what chipsets do nowadays). To build a system, you would buy the parts you need and interconnect them in a carrier, or use them as chip macros and order them on a single substrate. Because if they don't, the GPU will become a console and only use the IO subsystems of the host PC.

Which brings us to yields versus packaging and heat dissipation, so we need a high-speed switched bus as well for that. So a supercomputer sounds right on target.


Edit: and all that would supply us with a new API and programming model for free, one way or the other.
 
I still say that graphics cards have enough to do (at least in their primary market: games), and it's more likely that CPU manufacturers will start adding in more vector processing than GPU's will actually find wide use for these applications.
 
Chalnoth said:
I still say that graphics cards have enough to do (at least in their primary market: games), and it's more likely that CPU manufacturers will start adding in more vector processing than GPU's will actually find wide use for these applications.

That sounds like the commercial thing to do, so you might be right. But it would only postpone the inevitable.

Edit: On the other hand, as soon as you use the high speed switched busses, you really want to move it all onto the motherboard. That would allow them (and force the enthousiasts) to upgrade that regulary. Lock the bus to a narrow range of CPU/GPU speeds, and you have a commercial winner that makes us all spend lots and lots of money.
 
Sage said:
just add a second motherboard socket for GPU's already!

I think my envisioned roadmap would be a bummer in that respect, except if Alienware and the CGI hardware manufacturers would step into that niche. The market share is too small.

Even with ePCI, the bandwith would be shared in all mainstream applications. And if we look at it from an economic perspective, we see that about three quarters or more of all GPUs are embedded or GF 2/4 MX...

Even as enthousiasts, we have to keep perspective.
 
SA -
How are long vectors so different from streaming architectures? Increasing the vector length significantly beyond 4 (SSE) makes the task of efficiently using computational resources difficult as well. I don't really know what (dis)advantages the vector model of computation has over a streaming model as embodied by the Merrimac or Imagine designs for example, but it appears to me that both approaches try to scale logic density and width of memory access without scaling control density (number of threads with different PCs, number of load/stores to distinct addresses) and probably take a performance nose-dive in similar situations.

In GPUs the execution time and path of a program operating on a data element (vertex, pixel quad, in future triangle) can differ by quite a lot. I don't see that a long vector/stream engine is a great answer to these problems.

It seems that the GPU is evolving towards something resembling multiple independent SSE pipelines... is this what you were proposing to add to the CPU?

My question with this type of design is: how is memory bandwidth and instruction bandwidth scaled? Or rather, how does one avoid adding multiple copies of large cache structures as seen in multi-core MPUs?

Regards,
Serge
 
Finally another very interesting and highly civilized debate. :)

You may excuse the interruption.
 
So, now we wait until the game designers and the chipset designers step in? Would they? Nah...

We'll see in about five years from now ;)
 
I'd imagine as this computing power became more available, wouldn't more general shaders take the place of more specialized shaders? I think this class of programs along with others would head down this path.
 
Next big thing in computer graphics, who knows? Probably some obscure geey crap most people wouldn't have a clue about. Would like to see some effort towards stereoscopic stuff, goggles suck, but without the support nothing better will come along..
 
Back
Top