7 ms·

I absolutely love that AMD is making technology open and cross platform on the GPU end. They don't get enough credit for doing that.

DaiPlusPlus 5y ago
I'm sure Intel and NVIDIA would also like to make more of their platform and driver-stack open, but they are bound by confidentiality clauses in third-party technology that they've licensed. That's part of why huge chunks of Windows aren't open-source: because Microsoft doesn't "own" all of it, there's a lot of third-party licensed code compiled from source in Windows.
- snicker7 5y ago
  Not fully owning your own drivers/OS is something only a galaxy-brained MBA could think of.
  - rawoke083600 5y ago
    Underrated comment :)
  - znpy 5y ago
    Not necessarily. Bryan Cantrill talked extensively about how long it took for Sun Microsystems to open source Solaris, and a lot came from code that was often outsources because it was "boring" and basically non-core tech (the example was i18n/l10n)
    - snicker7 5y ago
      And they, you know, couldn't demand rights to the code of their own OS? Sounds like Sun had some galaxy-brainers of their own.
    - ric2b 5y ago
      You can outsource while retaining ownership so that you can opensource it later if you want. Just need to pay for it and add it to the contract.
  - deleted 5y ago
    [deleted]
- ChuckMcM 5y ago
  Presumably Intel or nVidia could buy out any confidentiality, after all it really is just about dollars at that level.
- yaomtc 5y ago
  Intel works on developing Mesa, together with AMD and VMWare. Intel graphics work quite well on the open source graphics stack.
  - IntelMiner 5y ago
    Intel aggressively pushes their chips into Mesa, likely since they use Linux as the testbed for unreleased chips in development AMD is something like 10% of the total Linux kernel size now which is ridiculous. But their commitment in recent years is admirable as hell NVIDIA need to pull their fucking head out and just start working on Nouveau
    - atq2119 5y ago
      Most of it is header files full of redundant register names. It's pretty ridiculous. The driver code itself also has lots of code duplication. It's just strange.
      - vbezhenar 5y ago
        What's strange is why Linus allows that kind of code in the kernel.
        ClumsyPilot 5y ago
        Because done is better than perfect. I've had enough issues with ideologues precenting any meaning full progress
        snuxoll 5y ago
        It’s also not the worst way of making sure new chips get supported relatively quickly. Those “giant” header files are mechanically generated from the RTL source for each GPU, it’s not like it’s some horrendously inefficient bloat form an outsource developer that doesn’t care about writing clean code or something.
        5y ago
- hobofan 5y ago
  Even with a proprietary driver they didn't have to kill OpenCL once they got the slightest edge on it with CUDA.
  - 01100011 5y ago
    Who killed OpenCL? OpenCL 3.0 is supported on Nvidia's latest GPUs.
    - hobofan 5y ago
      Yes, now, after letting the whole ecosystem die by not supporting OpenCL 2.x for ~10 years, which in turn caused the whole ML field to turn into a Nvidia/CUDA monoculture.
      - my123 5y ago
        OpenCL 2.x wasn’t well supported by others either, AMD’s implementation was pretty unusable and only had printf as a debug mechanism. There was no hardware at all on which you could rely on it, on top of it being much worse than CUDA.
      - 0-_-0 5y ago
        I believe OpenCL 2.0 had a mandatory feature that nvidia couldn't support (maybe something about sharing pointers between GPU and CPU?). OpenCL 3.0 solved this by making many features optional.
        hobofan 5y ago
        I tried to create a ML framework[0] that would work on both CUDA and OpenCL (and natively on the CPU) around 2015/2016, which included creating FFI wrappers for both CUDA and OpenCL. This is where my experience on the subject (and my contempt for NVIDIA) comes from. Me memory isn't perfect, but IIRC the situation was roughly the following: We were quite short on resources (both devtime and money), which meant that we had to choose our scope wisely. Optimally we would have implemented both CUDA and OpenCL 2.0, but we had to settle for OpenCL 1.2 (which offered reduced performance, but was "good enough" for inference). IIRC OpenCL 2.0 was very very similar in what capabilities it assumed and offered to the CUDA version at the time, and cards like the GTX Titan X had "compute capabilities" that supported features like shared virtual memory between CPU and GPU in CUDA at the time. In fact the advances around memory management (and async copying) that were present in CUDA and not in OpenCL 1.x were the main source for the performance differences between the two. From everything that I can tell at that point in time, if NVIDIA would have wanted to support OpenCL 2.0 they could have done so based on technical requirements. What the reason for not doing so is, is just pure speculation (lack of internal resources due to focusing on devtools?), but to me it always looked like they were using the edge they got via their proprietary libraries like cuDNN to get a foot into the field of ML and then purposefully neglected OpenCL to prevent any competitors from catching up. Classic Embrace, Extend, Extinguish. [0]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf
- schmorptron 5y ago
  Nah, nVidia massively profits from the marketability of stuff like HairWorks / GameWorks a couple of years back being proprietary, and now it's DLSS. It's super cool tech, but kinda sad that [Speculation] it'll be replaced with a slightly worse version that works on all cards down the line just because nVidia wants to market it's exclusivity while it lasts.
  - Hikikomori 5y ago
    Nvidia likes to use Gameworks etc as a weapon against AMD. Like when they turned up tessellation to ridiculous levels because AMDs cards didn't have the hardware for it at the time.
    - beebeepka 5y ago
      Crysis 2 simulating an entire ocean to render a puddle comes to mind. Also tessalating perfectly leveled floors IIRC.
      - andromeduck 5y ago
        That has been throughly debunked a million times over. The ocean only renders in wireframe mode because occlusion culling doesn't happen in wire frame mode.
    - bazooka_penguin 5y ago
      Nvidia never did that though.
- zucker42 5y ago
  NVIDIA doesn't give a crap about it's driver stack being open source. In fact, they actively want it to be not open. They refuse to even release signed firmware so the community can build an independent driver. Intel's stack is already pretty open on Linux.
moogly 5y ago
I'm not sure they have much choice, since they're not the ones driving the innovation.

DaiPlusPlus 5y ago

I'm sure Intel and NVIDIA would also like to make more of their platform and driver-stack open, but they are bound by confidentiality clauses in third-party technology that they've licensed. That's part of why huge chunks of Windows aren't open-source: because Microsoft doesn't "own" all of it, there's a lot of third-party licensed code compiled from source in Windows.

snicker7 5y ago
Not fully owning your own drivers/OS is something only a galaxy-brained MBA could think of.
- rawoke083600 5y ago
  Underrated comment :)
- znpy 5y ago
  Not necessarily. Bryan Cantrill talked extensively about how long it took for Sun Microsystems to open source Solaris, and a lot came from code that was often outsources because it was "boring" and basically non-core tech (the example was i18n/l10n)
  - snicker7 5y ago
    And they, you know, couldn't demand rights to the code of their own OS? Sounds like Sun had some galaxy-brainers of their own.
  - ric2b 5y ago
    You can outsource while retaining ownership so that you can opensource it later if you want. Just need to pay for it and add it to the contract.
- deleted 5y ago
  [deleted]
ChuckMcM 5y ago
Presumably Intel or nVidia could buy out any confidentiality, after all it really is just about dollars at that level.
yaomtc 5y ago
Intel works on developing Mesa, together with AMD and VMWare. Intel graphics work quite well on the open source graphics stack.
- IntelMiner 5y ago
  Intel aggressively pushes their chips into Mesa, likely since they use Linux as the testbed for unreleased chips in development AMD is something like 10% of the total Linux kernel size now which is ridiculous. But their commitment in recent years is admirable as hell NVIDIA need to pull their fucking head out and just start working on Nouveau
  - atq2119 5y ago
    Most of it is header files full of redundant register names. It's pretty ridiculous. The driver code itself also has lots of code duplication. It's just strange.
    - vbezhenar 5y ago
      What's strange is why Linus allows that kind of code in the kernel.
      - ClumsyPilot 5y ago
        Because done is better than perfect. I've had enough issues with ideologues precenting any meaning full progress
        snuxoll 5y ago
        It’s also not the worst way of making sure new chips get supported relatively quickly. Those “giant” header files are mechanically generated from the RTL source for each GPU, it’s not like it’s some horrendously inefficient bloat form an outsource developer that doesn’t care about writing clean code or something.
      - 5y ago
hobofan 5y ago
Even with a proprietary driver they didn't have to kill OpenCL once they got the slightest edge on it with CUDA.
- 01100011 5y ago
  Who killed OpenCL? OpenCL 3.0 is supported on Nvidia's latest GPUs.
  - hobofan 5y ago
    Yes, now, after letting the whole ecosystem die by not supporting OpenCL 2.x for ~10 years, which in turn caused the whole ML field to turn into a Nvidia/CUDA monoculture.
    - my123 5y ago
      OpenCL 2.x wasn’t well supported by others either, AMD’s implementation was pretty unusable and only had printf as a debug mechanism. There was no hardware at all on which you could rely on it, on top of it being much worse than CUDA.
    - 0-_-0 5y ago
      I believe OpenCL 2.0 had a mandatory feature that nvidia couldn't support (maybe something about sharing pointers between GPU and CPU?). OpenCL 3.0 solved this by making many features optional.
      - hobofan 5y ago
        I tried to create a ML framework[0] that would work on both CUDA and OpenCL (and natively on the CPU) around 2015/2016, which included creating FFI wrappers for both CUDA and OpenCL. This is where my experience on the subject (and my contempt for NVIDIA) comes from. Me memory isn't perfect, but IIRC the situation was roughly the following: We were quite short on resources (both devtime and money), which meant that we had to choose our scope wisely. Optimally we would have implemented both CUDA and OpenCL 2.0, but we had to settle for OpenCL 1.2 (which offered reduced performance, but was "good enough" for inference). IIRC OpenCL 2.0 was very very similar in what capabilities it assumed and offered to the CUDA version at the time, and cards like the GTX Titan X had "compute capabilities" that supported features like shared virtual memory between CPU and GPU in CUDA at the time. In fact the advances around memory management (and async copying) that were present in CUDA and not in OpenCL 1.x were the main source for the performance differences between the two. From everything that I can tell at that point in time, if NVIDIA would have wanted to support OpenCL 2.0 they could have done so based on technical requirements. What the reason for not doing so is, is just pure speculation (lack of internal resources due to focusing on devtools?), but to me it always looked like they were using the edge they got via their proprietary libraries like cuDNN to get a foot into the field of ML and then purposefully neglected OpenCL to prevent any competitors from catching up. Classic Embrace, Extend, Extinguish. [0]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf
schmorptron 5y ago
Nah, nVidia massively profits from the marketability of stuff like HairWorks / GameWorks a couple of years back being proprietary, and now it's DLSS. It's super cool tech, but kinda sad that [Speculation] it'll be replaced with a slightly worse version that works on all cards down the line just because nVidia wants to market it's exclusivity while it lasts.
- Hikikomori 5y ago
  Nvidia likes to use Gameworks etc as a weapon against AMD. Like when they turned up tessellation to ridiculous levels because AMDs cards didn't have the hardware for it at the time.
  - beebeepka 5y ago
    Crysis 2 simulating an entire ocean to render a puddle comes to mind. Also tessalating perfectly leveled floors IIRC.
    - andromeduck 5y ago
      That has been throughly debunked a million times over. The ocean only renders in wireframe mode because occlusion culling doesn't happen in wire frame mode.
  - bazooka_penguin 5y ago
    Nvidia never did that though.
zucker42 5y ago
NVIDIA doesn't give a crap about it's driver stack being open source. In fact, they actively want it to be not open. They refuse to even release signed firmware so the community can build an independent driver. Intel's stack is already pretty open on Linux.

moogly 5y ago

I'm not sure they have much choice, since they're not the ones driving the innovation.