Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KGPU - Augmenting Linux with the CUDA GPU

github.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: KGPU - Augmenting Linux with the CUDA GPU

#21

Post by fool »

fool wrote: post #20
gnu8 wrote: post #16

Why is this cuda and not OpenCL? There's no reason to legitimize nvidia's proprietary nonsense, it just enables their bad behavior.

The GPU code seems to be relatively isolated to memory operations in gpuops.cu. Not altogether sure but a quick review suggests such mapping is supported by OpenCL. So one could rewrite that module and the whole thing would work without CUDA. Of course, in terms of compilers it is going to be a while before users can move away from nvcc for nvidia graphics card support. However, as with the parent I'd really like to…

Suspicion confirmed:

"KGPU is a project of the Flux Research Group at the University of Utah. It is supported by NVIDIA through a graduate fellowship awarded to Weibin Sun."

http://code.google.com/p/kgpu/

Re: KGPU - Augmenting Linux with the CUDA GPU

#22

Post by dfc »

fool wrote: post #21
fool wrote: post #20

Earlier quoted context omitted.

The GPU code seems to be relatively isolated to memory operations in gpuops.cu. Not altogether sure but a quick review suggests such mapping is supported by OpenCL. So one could rewrite that module and the whole thing would work without CUDA. Of course, in terms of compilers it is going to be a while before users can move away from nvcc for nvidia graphics card support. However, as with the parent I'd really like to…

Suspicion confirmed: "KGPU is a project of the Flux Research Group at the University of Utah. It is supported by NVIDIA through a graduate fellowship awarded to Weibin Sun." http://code.google.com/p/kgpu/

It really makes you wonder why AMD does not do the same thing; the hw is essentially free and how much could a fellowship cost. Does anyone know if research grants like this are a tax write-off?

Re: KGPU - Augmenting Linux with the CUDA GPU

#24

Post by caf »

Tuna-Fish wrote: post #6
adamgravitis wrote: post #2

Where is this useful? The bus speed across to the GPU is so slow, I thought it was only meaningful for near-autonomous operations.

Right now, the bandwidth to modern GPUs is actually pretty decent (16GB/s bidirectional), but the latency is still horrid. This means that you need rather large operations for offloading to pay off. I think doing raid-5 or full disk encryption with large blocks might just barely be worth it. However, with AMD and Intel integrated GPUs, this is about to change. AMD is doing a lot of work on HSA, which can be summarize…

Not so much RAID5, which is just an XOR operation that is as good as free on a modern CPU, but RAID6 where a more computation-intensive Reed-Solomon code is used.

Re: KGPU - Augmenting Linux with the CUDA GPU

#25

Post by snogglethorpe »

iso-8859-1 wrote: post #19
gnu8 wrote: post #16

Why is this cuda and not OpenCL? There's no reason to legitimize nvidia's proprietary nonsense, it just enables their bad behavior.

CUDA is older and more popular: http://www.google.com/trends/explore#cat=0-5&q=opencl%2C...

Nonetheless, it's a bad idea to favor proprietary languages that lock you into a particular company's products.

CUDA should have died when OpenCL came about.

Of course since such lockin is to Nvidia's benefit, it's understandable why they keep promoting their proprietary solution...

Re: KGPU - Augmenting Linux with the CUDA GPU

#26

Post by DannyBee »

hyperbovine wrote: post #23
gnu8 wrote: post #16

Why is this cuda and not OpenCL? There's no reason to legitimize nvidia's proprietary nonsense, it just enables their bad behavior.

What sort of vitriol is this? How dare they invent a new technology and build an API to it.

Didn't you know all good API's are designed from scratch in open committees, instead of being standardized after multiple competing implementations?

Re: KGPU - Augmenting Linux with the CUDA GPU

#27

Post by DannyBee »

snogglethorpe wrote: post #25
iso-8859-1 wrote: post #19

Earlier quoted context omitted.

CUDA is older and more popular: http://www.google.com/trends/explore#cat=0-5&q=opencl%2C...

Nonetheless, it's a bad idea to favor proprietary languages that lock you into a particular company's products. CUDA should have died when OpenCL came about. Of course since such lockin is to Nvidia's benefit, it's understandable why they keep promoting their proprietary solution...

Like what, you mean instantly? What if OpenCL sucked? Should CUDA still die?

Re: KGPU - Augmenting Linux with the CUDA GPU

#29

Post by greggman »

You do NOT want to do this. Unlike the CPU which can be preempted current GPUs can not. If you give them 2-30 minutes of work to do they will not return until that work is done. Windows gets around this by resetting the GPU if it doesn't respond for more than a few seconds. Linux/osx no such luck, at least not yet.

But, once reset the state of the GPU is often unknown. Not a good thing if you are embedding GPU code into your kernel.

Re: KGPU - Augmenting Linux with the CUDA GPU

#30

Post by rincebrain »

dkhenry wrote: post #12
adamgravitis wrote: post #2

Where is this useful? The bus speed across to the GPU is so slow, I thought it was only meaningful for near-autonomous operations.

One situation where you might see immediate results is in High volume routing. I think this project [1]. They were using the GPU to saturate multiple 10GbE interfaces with a commodity processor. 1. http://shader.kaist.edu/packetshader/

I actually spoke to them about doing a similar thing, and they said they were using a GPU because they were pushing lots of sub-1500 MTU packets, and that commodity h/w could probably saturate multiple 10GbE interfaces that were just doing large packets for high-throughput.
Post reply on HN