GPGPU Programming and Marketing

>> Wednesday, May 25, 2011

It's been a big week for GPU computing. Cray recently announced their first supercomputer with GPUs: the XK6. Mathworks announced that their new Parallel Computing Toolbox will support GPU-based applications. And the University of Michigan has developed a GPU-based version of R, the popular language for statistics.

This is major progress for GPGPU programming, but all three of these projects are exclusively based on CUDA, which only runs on Nvidia hardware. OpenCL runs on many more types of devices, but if anyone's doing anything exciting with it, they're doing a great job keeping it under their hat.

My hopes for OpenCL rest on AMD's Fusion processor, which should be released in the next month or so. I think this will spur interest in OpenCL, but Nvidia has already worked hard to position itself as the GPU vendor for high-performance computing. It will be hard for the Khronos Group to convince people otherwise.

The Fusion embodies a revolution in computing, but AMD isn't getting the word out. I always wonder what might have happened if Intel had developed the Fusion instead. We'd be bombarded with commercials and advertisements and sales pitches. We'd see engineers dancing in their pastel bunny suits as they made chips, and what would they be dancing to? Fusion, of course.

My favorite piece of Intel marketing came around in 1996. After making minor improvements to the Pentium P5, they released an updated device that supported additional instructions for vector computing. No existing software could execute these instructions, but that didn't bother Intel. They called the new device Pentium with MMX, and it was a huge success. I mean, who wants a vanilla Pentium when you can have a Pentium with MMX? The acronym (as I understood it) stood for MultiMedia eXtension, but it didn't matter. It was so catchy that people upgraded from Pentiums to Pentiums/MMX just because of the name.

Read more...

Right Here in River City

>> Sunday, May 15, 2011

I live in California at the border of Walnut Creek and Pleasant Hill. I love this area. The weather is gorgeous, the running paths are gorgeous, and the people are as pleasant and as laid-back as could be wished.

In Pleasant Hill, there's a small shop called My Divine Skin. I always assumed it was a beautician's office, but it's actually a massage parlor. And by night, it's a police-run brothel.

And that's just the tip of the iceberg. According to the article, the local police have been involved in bribery, distribution of stolen drugs, and setting up phony DUI arrests.

My beloved city is a hotbed of vice and corruption! I'm shocked beyond my ability to express myself.

What fascinates me is that I was at the Contra Costa courthouse recently as a potential juror. The judge turned us all away because his cases had settled, but this would have been an incredible case to sit in on.

The more I read about this, the more certain I am that there's a novel in here somewhere. There has to be...

Read more...

Rats

>> Sunday, May 1, 2011

I submitted my mutex-based barrier code to the OpenCL forum, and they weren't impressed. It wasn't that my code didn't work, they said, but that it didn't scale. And this is important - if your OpenCL code doesn't scale, it may as well not work.

They were absolutely right. My barrier works only as long as the number of work-groups doesn't exceed the number of compute units on the device. But, as I learned the hard way, if the number of work-groups is greater than the number of compute units, the kernel hangs. More precisely, the GPU hangs, which means I have to restart the computer.

I don't know exactly how compute units execute work-groups, but not all work-groups execute at once. Once the first set of work-groups finish their execution, then the next set can start. So here's the problem--if the first set of work-groups is waiting for all the work-groups to synchronize, they'll never stop executing and the next set of work-groups will never start. So that's why my barrier never completes.

Rats.

Read more...

  © Blogger template Werd by Ourblogtemplates.com 2009

Back to TOP