Results 1 to 7 of 7

Thread: Gdev: A Competitive Open-Source CUDA Implementation

  1. #1
    Join Date
    Jan 2007
    Posts
    14,335

    Default Gdev: A Competitive Open-Source CUDA Implementation

    Phoronix: Gdev: A Competitive Open-Source CUDA Implementation

    Shinpei Kato, the developer that last year at XDC2011 Chicago presented TimeGraph as an open-source GPU Linux command scheduler and PathScale's GPGPU run-time, has something new to share. Shinpei's latest project is Gdev, which comes down to being an open-source CUDA implementation that's competitive to NVIDIA's proprietary stack...

    http://www.phoronix.com/vr.php?view=MTA3OTI

  2. #2
    Join Date
    Sep 2008
    Posts
    989

    Default

    Sounds awesome, but I'm sure Linus will get a few laughs from the proposal to run CUDA kernels... in the Linux kernel. It'll go something like "hahahahahahahahahahahaha NO". If we can't even do floating point or C++, how can we do something this "heavy" in the kernel?

    Also: don't confuse this project with "gudev" -- I almost did at first

  3. #3
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    500

    Default

    Bear in mind, that CUDA run atop GPU, not atop CPU.

  4. #4
    Join Date
    Sep 2010
    Posts
    453

    Default

    Someone tell this guy about OpenCL.

    Kidding. I don't think going with vendor dependent things in the situation CUDA is in, is a very good idea.
    (And in this case, I have some technical grounded reservations.)

  5. #5
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    862

    Default

    Quote Originally Posted by plonoma View Post
    Someone tell this guy about OpenCL.

    Kidding. I don't think going with vendor dependent things in the situation CUDA is in, is a very good idea.
    (And in this case, I have some technical grounded reservations.)
    I'm not a huge fan of CUDA, but if I remember correctly, the nvcc that Nvidia open-sourced a while back was LLVM-based. If that's the case, a CUDA state tracker that can output LLVM IR might be feasible without too much effort. And once we've got LLVM IR, we might also be able to run CUDA programs on CPU/R600/Nouveau/other (assuming the user is willing to recompile their programs targetting that architecture). OpenCL is still better for us in the long run, but it would be useful to be able to execute CUDA code via the OSS drivers, even if just to ease porting to OSS CL implementations.

  6. #6
    Join Date
    Mar 2012
    Posts
    9

    Default

    Quote Originally Posted by Veerappan View Post
    I'm not a huge fan of CUDA, but if I remember correctly, the nvcc that Nvidia open-sourced a while back was LLVM-based. If that's the case, a CUDA state tracker that can output LLVM IR might be feasible without too much effort. And once we've got LLVM IR, we might also be able to run CUDA programs on CPU/R600/Nouveau/other (assuming the user is willing to recompile their programs targetting that architecture). OpenCL is still better for us in the long run, but it would be useful to be able to execute CUDA code via the OSS drivers, even if just to ease porting to OSS CL implementations.
    By doing so you are encouraging the spread of a proprietary specification; a specification controlled by a unique vendor and shaped according to their needs. Given we already have the open standard OpenCL, which roughly speaking is a superset of CUDA, I don't think we should promote closed alternatives.

  7. #7
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Don't forget that this is OS RESEARCH! Architecture is the first step ("Embrace..."). Next up -> Gallium when it's ready, so it'll 'run' on non-nVidia hardware ("... extend..."). After that it's killing CUDA ("knife the baby") and "... Extinguish!".

    This is the tried and proven Microsoft way to operating system succes. Who's gonna disprove me on that? ;D

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •