Announcement

Collapse
No announcement yet.

ZLUDA v2 Released For Drop-In CUDA On Intel Graphics

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ZLUDA v2 Released For Drop-In CUDA On Intel Graphics

    Phoronix: ZLUDA v2 Released For Drop-In CUDA On Intel Graphics

    One of many interesting and original open-source projects to be started in 2020 was ZLUDA, an open-spurce drop-in CUDA implementation for Intel graphics. ZLUDA - developed independent of Intel and NVIDIA - is built atop Intel's oneAPI Level Zero interface (hence the name, ZLUDA) and allows for unmodified CUDA applications to run on Intel UHD/Xe Graphics hardware with near-native performance. Well, that's the goal at least but with the initial ZLUDA release were a number of support limitations...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I don't have a supported processor to test this out but I think it is cool.

    What would stop NVIDIA from extending CUDA regularly to ensure constant incompatibility?

    Comment


    • #3
      Probably it´s not allowed anyway at least for commerical purposes, otherwise i see no reason why "hipify" in ROCM exists, which basically replaces all calls to CUDA libs in your code with an equivalent "rocm_samename" function...
      They could have just implemented the same ABI on rocm libs, to load them in place of CUDA.

      Comment


      • #4
        Originally posted by creoflux View Post
        What would stop NVIDIA from extending CUDA regularly to ensure constant incompatibility?
        They would be shooting themselves in the foot. Companies will not be pleased if NVIDIA keeps making breaking changes to their API and will seek alternatives.

        The only risk is if NVIDIA keep adding "new" little features and then spreading the word that ZLUDA is "out of date". Luckily only students (and a few too many open-source developers) blindly use the latest and greatest gimmicks needlessly.

        Comment


        • #5
          creoflux
          Originally posted by kpedersen View Post

          They would be shooting themselves in the foot. Companies will not be pleased if NVIDIA keeps making breaking changes to their API and will seek alternatives.

          The only risk is if NVIDIA keep adding "new" little features and then spreading the word that ZLUDA is "out of date". Luckily only students (and a few too many open-source developers) blindly use the latest and greatest gimmicks needlessly.
          In addition to this, Nvidia will likely always have leverage in having the best overall performance/efficiency, and a lot of what you're paying for is their support. CUDA is "tailor made" for Nvidia's hardware. Nvidia doesn't need to artificially hamper competition, because it's inherently going to run worse and if/when something goes wrong, they can be like "too bad, we don't support non-Nvidia hardware".

          Comment


          • #6
            If I understand it correctly this is better in some ways than Nvidia's CUDA. Because of how it is licensed, CUDA is not in main repos for many distros. But this is under Apache license so it could be. So if you want seamless CUDA experience on Linux, you probably should consider Intel over Nvidia in the future!

            Comment


            • #7
              no offence ...but zluda sounds like the retarded brother of cuda .

              Comment


              • #8
                Originally posted by schmidtbag View Post
                creofluxCUDA is "tailor made" for Nvidia's hardware. Nvidia doesn't need to artificially hamper competition, because it's inherently going to run worse and if/when something goes wrong,
                Yeah, it's like how WINE never really cut into sales of MS Windows. If anything, this benefits Nvidia by acting as a sort of CUDA-lite, to let you start using CUDA apps on non-Nvidia hardware. Then, when you hit some bug or decide you want more performance, you're probably going to become a Nvidia customer.

                In that sense, it's actually bad for more open alternatives. Especially if it lets developers feel like they don't need to write/maintain OpenCL or Vulkan-compute based backends, because non-Nvidia users can just use this or some kind of HiP-equivalent.

                Comment


                • #9
                  Originally posted by JacekJagosz View Post
                  If I understand it correctly this is better in some ways than Nvidia's CUDA. Because of how it is licensed, CUDA is not in main repos for many distros. But this is under Apache license so it could be.
                  The risk of depending on it is that if it becomes too popular, Nvidia could follow Oracle's playbook and shut down this project on the basis of copyright enforcement (i.e. for copying their symbol names).

                  If you really want a libre solution, I'd avoid CUDA, entirely.

                  Comment


                  • #10
                    Originally posted by Spacefish View Post
                    Probably it´s not allowed anyway at least for commerical purposes, otherwise i see no reason why "hipify" in ROCM exists, which basically replaces all calls to CUDA libs in your code with an equivalent "rocm_samename" function...
                    They could have just implemented the same ABI on rocm libs, to load them in place of CUDA.
                    Yeah I'm curious about this too. It'd be nice to see equivalent support for AMD GPUs, but I assume for legal reasons AMD perhaps couldn't take this route?

                    As ZLUDA is third-party and not from Intel, perhaps AMD could officially add support for OneAPI and indirectly enable better (unofficial) CUDA support for AMD GPUs?

                    I'm only aware of MeshRoom trying to leverage the HIP approach to convert CUDA dependency, and that they were running into issues getting that ported.

                    Proprietary software where you can't utilize that approach is where there's more value, and is not uncommon in certain industries leading software, and there doesn't appear to be much interest from those developers to additionally support ROCm. If ZLUDA can solve that, that's cool

                    Comment

                    Working...
                    X