Slashdot Mirror
Future of 3d Graphics
zymano writes "Extremetech
has this nice article on the future of 3d graphics. The article also mentions that graphic card gpus can be used for non-traditional powerful processing like physics. A quote from the article, "GPU can be from 10 to 100 times faster than a Pentium 4 and Scientific computations such as linear algebra, Fast Fourier Transforms, and partial differential equations can benefit". My question - If these cards are getting so powerful at computations then why do we need a Intel/AMD processor at all? Just make a graphics card with more transistors and drop the traditional processor..."
...This is what the future releases of DirectX is supposed to address: The use of 3D renderers to render non-graphical elements and other work.
:-)
Good for the end user, but going to be a pain in the ass for software developers to take advantage of, is my guess.
alias uptime="echo '5:33pm up 22342352324 days, 6:28, 2124315623 users, load average: 2432.40, 12312.31, 123123.19'"
Because GPUs are specialized processors. They are only good at a couple of things: moving data in a particular format around quickly, and linear algebra. It is possible to do general-purpose calculations on a GPU, but that's not what it is good at, so you'd be wasting your time.
This is akin to asking why you shouldn't go see a veterinarian when you get sick. Because veterinarians specialize in animals. Sure, they might be able to treat you, but since their training is with animals you might find their treatments don't help as much as going to see a regular doctor.
In my opinion that's just a matter of definition. If it manages the core tasks of running the machine it's a CPU - i.e. a central PU - and not just a GPU since it handles more than the graphics.
That is as soon as there is no CPU and the GPU handles its tasks it becomes a CPU by definition!
You mean like: this?
Now, that press release was about two years old, and you can bet that ATI has advanced beyond that point (though I can't provide details).
Also, while not integrating a serious 3D graphics GPU, there's no reason that this can't be done -- except one -- and the same reason that a powerful CPU isn't integrated: heat dissipation.
But, for a "media processor", it sure is sweet.
You could've hired me.
Not true. Newer cards appear to be IEEE 'extended' (there isn't a definition of the bitsize of extended from the spec, so even Intel's 80-bit format is considered 'extended') at 128 bits wide per color channel. This is pretty much the last word in accuracy as far as I'm concerned. Perhaps numerical analysts can come up with scenarios where 128 bits aren't sufficient, but I don't want to hear about them.
For some of the stuff that we do, we would kill for a slightly faster card. Right now, for simulation of IR imagery, we have to prefly a scenario where the sensor-carrying vehicle (use your imagination) flys a trajectory and we render the imagery along this path. This rendering consists of doing convolutions of background scenes with target information to generate a final image. At the end we have a 'movie'. This can take a few hours to run.
Afterwards, we run the simulation in realtime and play frames from this movie (adjusted in rotation and scaling, etc. because real-time interactions can result in flight paths subtly different from the movie) and show it to a *real* sensor and see what happens.
The point: if we could do real time convolution inside a graphics card and then get the data back out some way (we usually need to go through some custom interface to present the data to the sensor), then a lot of pain would be saved. First, we could move the video-generating infrastructure into the real time simulation, which would be simpler, we wouldn't have to worry about rotating and scaling the result since we'd be generating exactly correct results in the fly, we wouldn't have to worry about allocating huge amounts of memory (Gigabytes) to hold the video and all the concerns about memory latency and bandwidth and problems with NUMA architectures, and finally (maybe) we could change scenarios on the fly without having to worry about whether we already had a video ready to use.
I think the computational horsepower is almost there, but right now there's no good way to get the data back out of the card. On something like an SGI you get stuff after it's gone through the DACs, which mean you now have at most 12-bits per channel (less than we want, although you can use tricks for some stuff to get up to maybe 16-bits for pure luminosity data). What would be sweet in the extreme is to get a 128-bit floating point value of each pixel in the X*Y pixel scene. So if the scene were 640x480 then we'd get about 4.5Meg of data per frame at say 60Hz then we'd get about 281Meg a second to convert and send out.
Life would be sweet. Sadly, this is a pretty special purpose application, so I'm not too hopeful. What's weird is that only NVidia (and perhaps ATI) are coming up with this horsepower because of all the world's gamers, and vendors like SGI are left with hardware that is many, many generations old (although it does have the benefit of assloads of texture memory).
In short: need 1GB of RAM on the card and a way to get stuff back out after we've done the swoopty math.
> The GPU allows you to do massively parallel computations, but penalizes you heavilly for things such as loops of variable length or reading memory back from the card outside of the once-per-cycle frame update, and the price of interrupting computation is prohibitive. Clearing the graphics pipeline can take a long, long time.
> Furthermore, while there have been a few papers published claiming the orders of magnitude increase in speed in these sorts of computations, none actually demonstrate this sort of speed-up. Everyone's speculating, but when it comes to it, results are lacking.
I looked in to using the GPU for vector * matrix multiplications over my Christmas vacation (yep, a Geek), and everywhere I turned I found people saying that whatever you gained in the number crunching you lost in the latency of sending your numbers to the GPU and reading them back when done. In the end I didn't even bother running an experiment on it.
But maybe conventional wisdom was wrong; elsewhere in the talkbacks I see links to a couple of
Sheesh, evil *and* a jerk. -- Jade