Slashdot Mirror
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."
Reminds me of the good old days when you used the processors in the C64 tapedrive to compute stuff. Wouldn't want to waste those precious cycles.
:)
I'm sure a lot of old farts will tell me how they used some serial controller to compute stuff back in the 60's and that I'm just a little kid.
2 words: X86 architecture. Everyone who hated it told you it sucks. Now you see why.
Multiply power by N.
You work for Nvidia, don't you?
Forget thrust, drag, lift and weight. Airplanes fly because of money.
*arrrg*!!
PowerPoint-like presentation... going dumb... noooooo...
So now I can port my slow as tar software rendering engine to this and finally make my DOOM killer 3D Game a reality!
Oh wait.. never mind
-Jason
Would that speed up my processing ? Will I be able to play Half Life 2 on my Pentium now ?
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
Someone ports a GPU Linux and some asshole loads 8 PCI cards into his machine and maked a beowulf cluster inside of one case?
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
We got our first boards from the developers of an antiaircraft RADAR signature decoder/sight. We wound up using DSP32Cs, 25MFLOPS as I recall, by late 1990. We had an EISA card (PCI was in the future) with an FPGA for linearly scalable pluggable DSPs. We had experimented with a transputer, but found we could use the DSPs to preprocess the video sensor data during calibration, and load custom logic and buses into the FPGAs for maximum efficency routing the data. When the company folded and reformed, the technology had evolved into a general-purpose FPGA imageprocessor, with scalable utility DSPs embedded in the hyperarray of FPGAs. The lead engineer went to Xilinx, which has consistently produced the most advanced FPGAs since then, including the Virtex-II line with embedded RISCs (PPCs).
One DSP SW engineer I worked with at Array had come from the academic computational music world. He had hooked each DSP32's six parallel ports to the other members of a cube topology, with buses around the surface of the cube. The buses were connected to actual I/O buffers. Some of those were connected to input controls, like sensors on big cans, or tuned monochords, or hard rubber blocks. Outputs from the cube were hooked to output actuators, like solenoids strapped to gongs, motorized clappers against barrels, and rows of mallets aimed at piano keys. Musicians would bang their parts out on the inputs, with computed rhythms and "pitches" spewed out of the actuators. Keyboard/monitor stations allowed musicians on the parallel network to sample parametrized rhythms, sequences, timbres and other values in realtime from other musicians.
The whole thing was totally insane, but then we were a Silicon Valley company in Oakland during the last recession that recruited exclusively musicians, philosophers, exhippie mathematicians, and yours truly (college dropout) as their mascot, for an imageprocessing startup. I've never been the same since, and the industry has yet to catch up with any of us.
--
make install -not war