Announcement

Collapse
No announcement yet.

NVIDIA Announces Open-Source CUDA Compiler

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

  • NVIDIA Announces Open-Source CUDA Compiler

    Phoronix: NVIDIA Announces Open-Source CUDA Compiler

    NVIDIA CUDA developer relations just fired off an email entitled NVIDIA Contributes CUDA Compiler to Open Source Community...

    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
    WARNING: THIS IS A CHEAP TRICK!!!!
    Nvidia is trying to exclude their competitors by introducing their own "standards". They must not be allowed to do this. The only way it can be prevented is by NOT ACCEPTING.

    Anticipate it to be about as open as "VDPAU", which is an abomination, only useful with nvidia hardware.

    Comment


    • #3
      Indeed.

      What's the point of an open source compiler when the resulting code can only be run reasonably on a closed driver?

      Comment


      • #4
        Originally posted by droidhacker View Post
        WARNING: THIS IS A CHEAP TRICK!!!!
        Nvidia is trying to exclude their competitors by introducing their own "standards". They must not be allowed to do this. The only way it can be prevented is by NOT ACCEPTING.

        Anticipate it to be about as open as "VDPAU", which is an abomination, only useful with nvidia hardware.
        Without trying to fire another conspiracy theory, this is obviously a strong strategic decision.
        We all know how open-source friendly NVidia usually is.

        Comment


        • #5
          Originally posted by droidhacker View Post
          Anticipate it to be about as open as "VDPAU", which is an abomination, only useful with nvidia hardware.
          It's only useful with nvidia hardware, because only they have a full implementation. VDPAU itself is fully open, there's a state tracker using it, for example. Though for now it only decodes mpeg2. But it's there.
          Intel could provide hardware decoding via VDPAU, there's nothing technical preventing them from doing it, it's just that they're already using VAAPI.

          Saying VDPAU is not open, just because one implementation is closed, is silly. That would mean xvmc is not open either, seeing as how nvidia has a closed implementation in their driver. Which is, of course, equally silly.

          Comment


          • #6
            I want KMS

            That's all good and stuff, but not important to me.
            I want KMS (kernel mode setting) and open source device driver.

            Comment


            • #7
              No, thanks. I prefer an open standard that runs across devices and vendors: OpenCL. Period.

              Comment


              • #8
                Nouveau. There.

                I don't mind being less closed source. It's LLVM, not GCC, where this doesn't affect the rest of the compiler if it's implemented.

                Also people can start using it, but OpenCL is more like it.

                Sound a bit like 3Dfx to me; open sourcing a GPU lib in the light of a more general open source one.

                But OpenCL isn't the end-to-end-all either, since the code is still pretty much hardware bound. For example if you want to squeeze parallel performance, you have to implement a very GPU architecture specific dataset. So OpenCL isn't as generic as OpenGL (yet).

                Comment


                • #9
                  Originally posted by d.a.a. View Post
                  No, thanks. I prefer an open standard that runs across devices and vendors: OpenCL. Period.
                  OpenCL sucks compared to CUDA. I'd much much rather have an Open Source CUDA that put up with the shit Khronos peddles.

                  Unfortunately, this isn't an actual open source compiler, since the backend only outputs PTX, which requires a proprietary library to consume and compile to native code.

                  It's a frontend, which is useful, but not an actual Open GPU solution.

                  AMD, on the other hand, has actually released direct-to-hardware LLVM code for compiling against GPU programs on their actually Open hardware.

                  Comment


                  • #10
                    Having worked with both OpenCL and CUDA in recent months, I don't see what the fuss is all about.

                    CUDA comes with a more mature set of pre-made libraries, CuFFT and CuBLAS are both high-quality libraries.

                    Other than that, I don't see the incredible difference. It's the same shit at the end of the day. Only one of them is open, the other one will make you a slave to one brand for all eternity.

                    Comment

                    Working...
                    X