BrookGPU: General Purpose Programming on GPUs
An anonymous reader writes "
BrookGPU is a compiler and runtime system that provides an easy, C-like programming environment (read: No GPU programming experience needed) for today's GPUs. A shader program running on the NVIDIA GeForce FX 5900 Ultra achieves over 20 GFLOPS, roughly equivalent to a 10 GHz Pentium 4. Combine this with the increased memory bandwidth, 25.3 GB/sec peak compared to the Pentium 4's 5.96 GB/sec peak, and you've got a seriously fast compute engine but programming them has been a real pain. BrookGPU adds simple data parallel language additions to C which allow programmers to specify certain parts of their code to run on the GPU. The compiler and runtime takes care of the rest. Here is the Project Page and Sourceforge page."
"graphics-realted" things include things like floating point mathmatics, linear algebra, and vector operations. If you are doing anything computationally intensive, this might be usefull. You don't have to actually use the hardware to do anything graphical if you are just interested in turning numbers.
"Brook is an extension of standard ANSI C and is designed to incorporate the ideas of data parallel computing and arithmetic intensity into a familiar, efficient language" I'll qualify that this is the first I've heard of Brook, however, the words: "efficient language", ring loud in my ears. If Operating systems were programmed as such, imagine how fast bootup and operation of a computer would be. Instead we have bloated software on all sides of the board, that can barely show us the differences of MHz to GHz machines. What century are we in again?
After taking a quick peek at the language part of the project it seems right now that most of it's functions are all about sets of data and how to move them around.
Makes sence of course as that is what a GPU is all about. (Yes I'm vastly over-simplyifying here.) So I would gather that it might be used for types of data that are streamed alot? Maybe used for video editing, real time video, etc where your trying to deal with a lot of data at once that your trying to move around and not just store or have to perform some more complicated types of functions upon.
However, I'm no 3d programmer and I should would love a more detailed analysis of the potentals for this.
Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
Definately possible - general purpose CPUs have to do everything where graphics cards can specialize and do what little they can, faster.
Also, good point about comparing GHz to GHz - AMD CPUs do more per cycle than Intel, but are also clocked much lower. You could look at a subset of instructions (ie: FLoating-point OPerations (FLOPS)) but this only gives you a piece of the overall performance picture.
Without having read the article, my guess is they extrapolated (educated, math-based guess) how fast a 10GHz P4 would perform and compared the results that way.
I'd LOVE to see this tech built into a SETI or Folding@Home client (steroids version). (Imagine the kids - "Mom, I need the Radeon 9800XT to find a cure for Grandma's cancer!")
Beyond3D had a shader contest and some genius wrote frogger in a pixel shader. That's some great stuff.
If GPUs are to become general purpose, will the AGP bus problems have to be fixed (fast at delivering data, slow at getting it back from the GPU). Does PCI-X fix this?
This looks like a straightforward and clean extension that experienced C/C++ programmers won't find difficult to learn, but it isn't entirely clear to me whether just using this language, without any knowledge of GPU architecture, will lead to big improvements in performance. Granted, you don't need to know the details, but you've got to have an idea of what it is that you're trying to do and in a general way how the special constructs of the language allow you to do that. As with other such language extensions, you can nominally write in the language but not really use the extensions (how many "C++" programs have you seen that were really C programs with // comments and a few couts?) or use them in unintended ways that prevent the intended optimization. It seems to me that if the project really is aiming at programmers who are not familiar with GPUs, they need at least to provide a brief introduction to the special properties of GPU architecture and some guidelines as to how to use the features of the language to take advantage of them. At present I don't find this either on the web sites or in the distribution.
I've always wondered why certain research programs (like Folding@home or SETI@home) don't use this type of code. My GPU sees more free time than my CPU plus it would probably get the work done faster. Also, imagine the speed increase of utilizing both the GPU and the CPU to their fullest potential. Now thats some fast folding!
SIGFAULT
WARNING: Lots of conjecture involved.
:)
That said, if you can fit your data sets and your program on to the video memory (128MB isn't uncommon on high-end), and you're doing lengthy calculations on these sets while being only interested in the results (again, not uncommon in HPC), then the relative slowness of reading these results back becomes a nonissue.
Does that help?
Why not? Printers have been doing this for years... There's no reason you couldn't make a graphics card to display postscript in hardware.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
In 12 months, AGP will be obsolete.
It will be replaced by PCI-Express, which as a general purpose bus supposely won't have these issues.
Even though general purpose CPUs approach the flop rate of GPUs, you cant feed the memory for many data intensive computations fast enough. A GPU may give you 12 or so bytes of data per cycle, where very few commodity CPU buses can do that.
as far as i know, GPU's do a lot of rounding off
It depends. If you have a gaming card, it will sacrifice precision for speed to hit its price. If you're rendering 100 fps in a game and in a couple of noncontiguous frames the walls don't quite line up, no big deal. But a professional CAD card, speed is sacrificed for precision - the risk of an engineer making a mistake or failing to spot one in an assembly alignment because of rendering artefact is too high.
In practice, a CAD card is just as fast as a gaming card, it just costs 5x as much (or more). Still, if your computation was well suited to matrix multiply and add (even a modest GPU will spank a good CPU at this) it might still be worth it.
You're missing the point completely. Main memory -> AGP is blazing fast, for the reasons you just stated. AGP -> main memory is painfully slow, because there's almost no requirement for much data to flow this direction. The result of %99.9999 of the output that the video card computes is displayed on the screen and then discarded with the next refresh.
Of course NN can be used for "graphics-related things", such as image recognition, but not only image, for example voice recognition. And not only recognition, for example forecasting on huge sequences with explicit and implicit (hidden) side-factors.
Stock market trader on GPU, anyone?
Less is more !