5 ms·
KGPU - Augmenting Linux with the CUDA GPU
- adamgravitis 14y agoWhere is this useful? The bus speed across to the GPU is so slow, I thought it was only meaningful for near-autonomous operations.
- jws 14y agoREADME suggests RAID processing, file system encryption, and AES.
- GIFtheory 14y agoAgreed. I'm also struggling to see what kind of massively parallel operations need to be done in kernel space in the first place.
- jws 14y agoMaybe it doesn't have to saturate the GPU to be a win. If you can just banish some cache busting, streaming work, like raid processing, to a tiny sliver of the GPU it could be a win.
- Tuna-Fish 14y agoRight 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 summarized as "GPU and CPU share same memory, and can communicate by passing pointers". I can see this kind of work being really useful in the near future.
- patrickgzill 14y agoI had thought in the past that storing the index of a database (not the data, just index) on the card and using that to handle complex queries, might be interesting. Not sure if that has a practical, real-world use though.
- dfc 14y agoMore and more CPUs have AES instructions and my old lenovo ideapad has a crypto coprocessor. Do you think the GPU offload will be worth it when the sytem has hw accelerated crypto?
- tjoff 14y agoThe question should be whether dedicated hardware for accelerated crypto will be worth it when GPU offload is suitable for it. Although in that particular context (security) you might enjoy the isolation of dedicated hardware as opposed to sharing it with others. The GPU solution though of course has the advantage of being able to adapt to new ciphers etc.
- dfc 14y agoAdapting/implementing the newest and hottest cipher on the block is not something that the crypto community advocates. Do you really think crypto accelerated hardware is going to fall behind and not support the ciphers that the crypto community (academia/industry) endorses?
- Hoff 14y agoThat depends on which team you're playing for, no?
- dfc 14y agoI am not trying to be difficult but i have no idea what you are talking about. I looked through your past comments and you seem to be a competent commenter, can you clarify that you meant?
- Hoff 14y agoWhether you are attacking the encryption, or whether you're a user of encryption; a defender. If you're attacking, having flexibility is advantageous.
- 14y ago
- caf 14y agoNot 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.
- dkhenry 14y agoOne 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/ http://shader.kaist.edu/packetshader/
- rincebrain 14y agoI 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.
- deleted 14y ago[deleted]
- odranoelson 14y agoI wonder whether this won't conflict with other user applications using the GPU.
- mtgx 14y agoWould this be possible with OpenCL, too?
- gnu8 14y agoWhy is this cuda and not OpenCL? There's no reason to legitimize nvidia's proprietary nonsense, it just enables their bad behavior.
- iso-8859-1 14y agoCUDA is older and more popular: http://www.google.com/trends/explore#cat=0-5&q=opencl%2C%20cuda&cmpt=q http://www.google.com/trends/explore#cat=0-5&q=opencl%2C...
- snogglethorpe 14y agoNonetheless, 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...
- DannyBee 14y agoLike what, you mean instantly? What if OpenCL sucked? Should CUDA still die?
- fool 14y agoThe 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 see a generic OpenCL vectorization kernel module. Strong suspicion that this work was directly or indirectly underwritten by Nvidia so I guess someone (Intel?) needs to step up and fund similar academic projects.
- fool 14y agoSuspicion 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/ http://code.google.com/p/kgpu/
- wavesum 14y agoI don't understand :) Could someone explain what this kind of technology means in practice? Does this mean I can GPU accelerate my old code?
- greggman 14y agoYou 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.