Slashdot Mirror
Using GPUs For General-Purpose Computing
Paul Tinsley writes "After seeing the press releases from both Nvidia and ATI announcing their next generation video card offerings, it got me to thinking about what else could be done with that raw processing power. These new cards weigh in with transistor counts of 220 and 160 million (respectively) with the P4 EE core at a count of 29 million. What could my video card be doing for me while I am not playing the latest 3d games? A quick search brought me to some preliminary work done at the University of Washington with a GeForce4 TI 4600 pitted against a 1.5GHz P4. My Favorite excerpt from the paper:
'For a 1500x1500 matrix, the GPU outperforms the CPU by a factor of 3.2.' A PDF of the paper is available here."
http://developers.slashdot.org/article.pl?sid=03/1 2/21/169200&mode=thread&tid=152&tid=18 5
Here's a HTML version of the PDF, thanks to Google.
General-purpose computation using graphics hardware has been a significant topic of study for the last few years. Pointers to a lot of papers and discussion on the subject are available at: www.gpgpu.org
Yes, it's true that it has that many transistors BUT, only 29 million of them are part of the core, the rest is memory. The transistor count on the video cards does not count the ram.
Here is a link at Adobe where you can turn any PDF into HTML.
Is a course being offered at caltech since last summer on using gpus for numerical work. Course page is here.
:wq
Before you get excited just remember how asymmetric the APG bus is. Those GPUs will be at much better use when we get them as 64bit pci cards.
If you have a matrix solver, there is no telling what you can do. And i remember, these papers show that the speed is faster than the matrix calculations of the same stuff using the CPU.
# Linear Algebra Operators for GPU Implementation of Numerical Algorithms
Jens Krüger, Rüdiger Westermann
# Sparse Matrix Solvers on the GPU: Conjugate Gradients and Multigrid
Jeff Bolz, Ian Farmer, Eitan Grinspun, Peter Schröder
# Nonlinear Optimization Framework for Image-Based Modeling on Programmable Graphics Hardware
Karl E. Hillesland, Sergey Molinov, Radek Grzeszczuk
some one else posted this...
www.gpgpu.org
Website on this topic (Score:0)
by Anonymous Coward on Sunday May 09, @01:57AM (#9098550)
General-purpose computation using graphics hardware has been a significant topic of study for the last few years. Pointers to a lot of papers and discussion on the subject are available at: www.gpgpu.org [gpgpu.org]
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
BrookGPU
from the BrookGPU website...
As the programmability and performance of modern GPUs continues to increase, many researchers are looking to graphics hardware to solve problems previously performed on general purpose CPUs. In many cases, performing general purpose computation on graphics hardware can provide a significant advantage over implementations on traditional CPUs. However, if GPUs are to become a powerful processing resource, it is important to establish the correct abstraction of the hardware; this will encourage efficient application design as well as an optimizable interface for hardware designers.
From what I understand this project it aimed at making an abstraction layer for GUP hardware so writing code to run on it is easier and standardsied.
I thought this looked familiar:
1 /169200.shtml?tid=152&tid=185
http://developers.slashdot.org/developers/03/12/2
At least, I would imagine most of the comments would be the same or similar....
I would guess the difference would be comparable. Altivec is no more impressive than the SSE/SSE2/etc. types of instructions of the modern x86.
Hmm. My Newton has a "160Mhz StrongARM SA-110 RISC Processor". Doesn't sound like a GPU to me.
Well they already make DSP cards for audio processing. Simply do a google(TM) search for "DSP card" and you will get several vendors.
I can't imagine it would take a whole lot to hack them for just their processing power outside of audio applications.
"The graphics card has a lot of unused computing power, nearly equal to the main processor chip in the computer if not more, that is not being used when there is no game or video being played, right?"
Longhorn is suppossed to offload a lot of the GUI stuff to the card. So yeah, it'd take advantage of untapped power of the card. However, as for other general purpose stuff, it wouldn't be so interesting. It's kinda like comparing a Ferrari to a school bus. The Ferrari will run circles around the bus, but can only ferry 2 people. The bus can move a LOT of cargo, but not as fast as the Ferrari. We're talking about specialization here. The trick is to find ways to take what the GPU is good at and making them useful.
"Derp de derp."
I've been thinking about using the GPU for audio DSP work for some time, even got to a point where I could transform some signal by "rendering" it into a texture (in a simple way, I could mix two sounds using the alpha as factor).
The problem is that these cards are made to be "write only" and that basicaly fetching back anything from them is *very* slow, which makes them totaly useless for the purpose, since you *kmow* the results are there, but you can't fetch them in an usefull/fast maneer.
I wonder if it's deliberate, to sell the "pro" cards they use for the rendering farms
Look at gpgpu.org I believe they have papers on doing FFT on GPUs. They also have a collection on papers regarding GPU as CPUs.
Well, it's really more that the pipelines are very long. On the order of 600 pipelinestages, and that's pretty damned long. (P4 which is a CPU with a deep pipeline has 21 stages IIRC.)
They do of course store data between those stages, and there are caches on the chip. Otherwise performance would be shot all to hell.
I doubt that the original statement that GPU designs don't count the on chip memory is correct. That just seems like an odd way to do it.
Video cards are already able to run many things in parallel- they are beyond dual-core.
QE is cool, but it doesn't do anything similar at all to what they're talking about here. FFTs on an NV30 are only incidentally related to texture mapping window contents. Check out gpgpu.org or BrookGPU. In a sense, the idea is to treat modern graphics hardware as the next step beyond SIMD instruction sets. Incidentally, e17 exploited (hardware) GL rendering of 2D graphics via evas a bit before Apple put that into OS X.
Seems worth checking out: GPGPU.ORG - "General-Purpose Computation Using Graphics Hardware"
...
> AGP does a lot better taking data in, but it's still pretty
> costly sending data back to the CPU.
I've heard that mentioned a few times, is it true?
From the AGP 3.0 spec:
The AGP3.0 interface is designed to support several platform generations based upon 0.25m (and
smaller) component silicon technology, spanning several technology generations. As with AGP2.0, the
physical interface is designed to operate at a common clock frequency of 66 MHz. Its source
synchronous data strobe operation, however, is octal-clocked and transfers eight double words
(Dwords) of data within the span of time consumed by a single common clock cycle. The AGP3.0 data
bus provides a peak theoretical bandwidth of 2.1 GB/s (32 bits per transfer at 533 MT/s). Both the
common clock and source synchronous data strobe operation and protocols are similar to those
employed by AGP2.0.11
Later on Page 96:
Traditional AGP devices can demand up to the maximum bandwidth available over the AGP ports.
However, the AGP system does not guarantee to deliver the requested bandwidth, nor does it guarantee
transfers will take place within some clearly specified request/transfer latency time.
This is done by the system guaranteeing to process a specified number (N) of read or write transactions of a specified size (Y) during each isochronous time period (T). An AGP3.0 device can divide this bandwidth between read and write traffic as appropriate. Further, the system transfers isochronous data over the AGP3.0 Port within a specified latency (L).
(emphasis mine)
I'm no expert, just asking if the "low upsream bandwidth" assumption is true. If it is, there could still some applications (eg: simple data compression) that could use it. Also, maybe output from VGA/DVI ports could be tapped.
It would be really neat if I could do some of the more complicated audio analysis (FFT etc) that requires lots of vector math using the video cards gpu.
There's a company that actually does this. The Universal Audio UAD-1 audio DSP had a previous life as a video card and a DVD hardware accelerator. Check out this thread on the UAD forums for more technical information.
(For those unaware of how FORTRAN does strings, they're stored in fixed length arrays that are padded to the end with spaces. When you want to compare two strings you have to make them the same length with a "substr" type operation (eg "STRING1(1:37) .EQ. STRING2(1:37)") - it's easy to use, just too crude to be usable.)
Saying FORTRAN isn't user friendly on the basis of its string handling is like saying Commodore BASIC 2 wasn't user friendly because of its procedures, erm, I mean subroutines. What could be hard about GOSUB and RETURN? Nothing. It's just they're not very useful.
You are not alone. This is not normal. None of this is normal.
I can tell upto about 80'ish FPS, but I run the refresh rate at 85 or 100 for no flicker. So yes there is a point for higher FPS. But you didnt say you played video games. And if you turn vsync off you get tearing.
I remember awhile back someone did quake2 benchmarks on accuracy vs FPS, and how 79FPS (i think) was the sweet spot, faster and lower refresh rate had a negative effect on accuracy.
But I wont argue 20FPS over 80, but 100 seems to be target. imho
Having done a similar work for my final year project this year, I have some experience attempting general purpose computation on a GPU. The results that I recieved when comparing the CPU with the GPU were very different with many of the applications coming in at 7-15 times slower on the GPU. Further, I discovered some problems which I mention below:
! Matrix results
As in mentioned earlier in the report, the graphics pipeline does not support a branch instruction. So with a limitied number of assembly instructions that can be executed in each stage of the pipeline (either 128 or 256 in current cards), how is it possible for them to perform a calculation on a 1500x1500 matrix multiplication. To calculate a single result 1500 multiplications would need to take place and if they are really clever about how they encode the data into texture s to optimise access, they would need two texture accesses for even 4 multiplications. By my calculations that is 1875 instructions, where you can only do 128 or 256.
My tests found that using the Cg compiler provided by NVidia, that a matrix of size 26x26 could be multiplied before the unrolling of the for loop exceed the 256 limitation.
One aspect that my evaluation did not get to examine was the possiblity of reading partial results back from the framebuffer to the texture memory along with loading a slightly modified program to generate the next partial result. They don't mention if they used this strategy so I assume that they don't.
! Inclusion of a branch instruction
Even if a branch instruction were to be included into the vertex and fragment stages of the pipeline, it would cause serious timing issues. As student of Computer Science, I have been taught that the pipeline operates at the speed of the slowest stage and from designing simple pipelined ALUs, I see the logic behind it. However, if a branch instruction is included then the fragment processing stage could become the slowest as the pipeline stalls waiting for the fragment processor to output its information into the framebuffer. I believe it for this reason that the GPU designers specifically did not include a branch instruction.
! Accuracy
My work also found a serious accuracy issue with attempting compuation on the GPU. Firstly, the GPU hardware represents all number in the pipeline as floating point values. As many of you can probably guess, this brings up the ever present problem of 'floating point error'. The interface between GPU and CPU are traditionally 8-bit values. Once they are imported into the 32-bit floating point pipeline the representation has them falling between 0 and 1, meaning that these numbers must be scaled up to their intended representations (integers between 0 and 255 for example) before computation can begin. Combine these two necessary operations and what I saw was a serious accuracy issue where five of my nine results(in the 3x3 matrix) were one integer value out.
While I don't claim to be an expert on these matters, I do think there is the possiblity of using commodity graphics cards for general purpose computation. However, using hardware that is not designed for this purpose holds some serious constraints in my opinion. Anyone who cares to look at my work can find it here
Yes, it's true that it has that many transistors BUT, only 29 million of them are part of the core, the rest is memory. The transistor count on the video cards does not count the ram.
Sure it does, it's just that the ram isn't cache, it's mostly huge register files.
I don't recall exactly: maybe Horizon, definitely scandinavian. I remember because I decompiled it! What happened was that I started the demo, and unusually the disk drive kept spinning: so I turned if off which caused the demo to fail. Tested loading, then trying to start the demo and it didn't work, so curiosity, an Action Reply and an irq investigation revealed what was going on. I think it was a single part demo: the most memorable C64 demo for me because of that trick.
This concept was being used back in 1988. The Commodore 64 (1mhz 6510, a 6502 like micro processor) had a peripheral 5.25 disk drive called the 1541, which itself had a 1mhz 6510 cpu in it, connected via. a serial link.
Actually, the processor in the 1541 was an ordinary 6502. The 6510 added some memory mapping stuff that the drive didn't need.
GPUs pass input and output from GPU memory at 4-12 bytes per flop. This is much faster than CPUs which are limited by bus speeds that are likely to deliver a number every sever several operations. So CPU benchmarks are bogus, using algorithms that use internal memory over and over again.
Its not always easy to reformulate algorithms to fit streaming memory and other limitations of GPUs. This issue has come up in earlier generations of custom computers. So, there are things like cyclic matrices tha map multi-dimensional matrix operations into 1-D streams, and so on.
The 2003 SIGGRAPH had a session on this topic showing you could implement a wide variety of algorithms outside of graphics.
Actually, the GeForce 6800 includes the hardware to do just that. I'm surprised no one else has mentioned it by now, as I thought it was one of the cooler features of the new NV40 chipset.
ATI has had this for even longer. The all-in-wonder series uses the video card to do accelerated encoding and decoding.
Also, I believe that mplayer, the best video player/encoder I have seen also uses openGL (and thus the video card on a properly configured system) to do playback.
Personally, I don't think there is anything really new in this article.
64-bit floating point texture filtering and blending and support for the D3D vertex and pixel shader 3.0 standard,
That's 64-bits for a four element vector (RGBA) or (XYZW), which is thus 16-bits per float. This is referred to as the 'half' floating point data type, as opposed to 'float' or 'double'. This is compatible with Renderman.
1. Is anyone except Apple trying to leverage the GPU for non-3D tasks? Apple has been doing Quartz Extreme for a while but I have not heard if anyone else is doing it.
Microsoft, for Longhorn, and freedesktop.org, for X11. Both go quite a bit beyond Quartz Extreme by using D3D/OpenGL for all drawing, not just compositing.
3. How come GPU makers are not trying to make a CPU by themselves?
GPUs are very different from CPUs. Graphics is almost infinitely parallizable, so you are really just limited by how many execution units you can stick on the CPU. Assuming enough memory bandwidth, you get nearly a linear increase with increasing numbers of execution units. CPUs, on the other hand, deal with general-purpose code that has an inherent parallelism of about 3-way to 4-way at most. So CPU manufacturers have to do clever things like SMT to take advantage of increased execution resources, but mainly must concentrate on ramping up clock speed and memory bandwidth.
Interestingly enough, GPU makers wouldn't be very good at making CPUs. GPUs are designed using high-level software, like VHDL. This has a big impact on their maximum clock speed, but that doesn't really matter, because they can always double the number of pipelines and get a nearly 2x increase in performance. Meanwhile, CPUs are designed by hand, and tweeked to get every last MHz, because throwing twice as many execution units on the CPU wouldn't help performance much at all.
A deep unwavering belief is a sure sign you're missing something...
Boy, you really have no idea what the heck you are talking about, do you? Of course the basic UNIX stuff is there, /bin, /sbin, /usr/local, all that stuff.
Those directories have very little files in them, you will also notice a lack of init.d startup scripts. Most of the system is contained in /System.
For example, rather than /etc/init.d, it has startup services in /System/Library/StartupItems. For example there is an apache folder, in that are the scripts necessary to start Apache along with a file which describes Apache's dependencies. Also, these startup items are multi lingual. You can boot into any language you want. All of this in one folder. That's f*cking elegance, yet it is only a very small example.
Check it out, you will see.
Pinnacle has a video editing product called Liquid Edition that uses the GPU for processing video effects & such.
As for organizations beating slashdot to the punch on this one, that's true... but it's good to see this getting even more exposure. :)
GPGPU (General-Purpose computation on GPUs) was a hot topic at various conferences in 2003; a number of papers were published on the subject. At SIGGRAPH 2004 there will be a full-day course on GPGPU given by eight of the experts in the field (including myself).
Mark Harris of NVIDIA maintains a website dedicated to GPGPU topics, including discussion forums and news postings. Well worth a browse if you're interested in GPGPU topics.
I look forward to seeing some of you at SIGGRAPH! :)
--Cliff