5 ms·

Who is we here? I'm curious to hear more about your ambitions here, since surly pulling in wgpu or something similar seems out-of-scope for the traditionally le

Who is we here? I'm curious to hear more about your ambitions here, since surly pulling in wgpu or something similar seems out-of-scope for the traditionally lean Rust stdlib.

LegNeato 1y ago
Many of us working on Rust + GPUs in various projects have discussed starting a GPU working group to explore some of these questions: https://gist.github.com/LegNeato/a1fb3e3a9795af05f22920709d92e456 https://gist.github.com/LegNeato/a1fb3e3a9795af05f22920709d9... Agreed, I don't think we'd ever pull in things like wgpu, but we might create APIs or traits wgpu could use to improve perf/safety/ergonomics/interoperability.
- Voultapher 1y ago
  Cool, looking forward to that. It's certainly a good fit for the Rust story overall, given the increasingly heterogenous nature of systems.
- junon 1y ago
  I'm surprised there isn't already a Rust GPU WG. That'd be incredible.
- jpc0 1y ago
  Hears an idea, Get Nvidia, AMD, Intel and whoever else you can get into a room. Get LLVMs boys into the same room. Compile LLVMIR directly into hardware instructions fed into the GPU, get them to open up. Having to target an API is part of the problem, get them to allow you to write Rust that directly compiles into the code that will run on the GPU, not something that becomes something else, that becomes spirv that controls a driver that will eventually run on the GPU.
  - Ygg2 1y ago
    Hell will freeze over, then go into negative Kelvin temperatures before you see nVidia agreeing in earnest to do so. They make too much money on NOT GETTING COMMODITIZED. nVidia even changed CUDA to make API not compatible with interpreters. It's the same reason Safari is in such a sorry state. Why make web browser better, when it could cannibalize your app store?
    - jpc0 1y ago
      Somehow I want to believe if you get everyone else in the room, and it becomes enough of a market force that nvidia stops selling GPUs because of it, they will change. Cough linux gpu drivers
    - shmerl 1y ago
      Yeah, Nvidia can get lost with their CUDA moat. But AMD should be interested.
    - ashdksnndck 1y ago
      Hmm. Maybe the opportunity would be more like AMD, Intel, and the various AI labs and big tech get together, and by their powers combined figure out a way to stop giving NVIDIA their margin?
      - __s 1y ago
        They tried. OpenCL, OpenMP
    - pjmlp 1y ago
      By making Web browser "better" do you mean more ChromeOS like? CUDA is great for Python as well. Maybe Intel and AMD should actually produce something worthwhile using.
      - pawelmurias 1y ago
        Better for running web apps.
        pjmlp 1y ago
        As long as they are using Web standards, and not Chrome APIs, I do agree.
      - Ygg2 1y ago
        > By making Web browser "better" do you mean more ChromeOS like? Whichever part makes Safari completely fail at properly rendering Jira. A task even Firefox can do.
  - bobajeff 1y ago
    Sounds sort of like the idea behind MLIR and it's GPU dialects. * https://mlir.llvm.org/docs/Dialects/NVGPU/ https://mlir.llvm.org/docs/Dialects/NVGPU/ * https://mlir.llvm.org/docs/Dialects/AMDGPU/ https://mlir.llvm.org/docs/Dialects/AMDGPU/ * https://mlir.llvm.org/docs/Dialects/XeGPU/ https://mlir.llvm.org/docs/Dialects/XeGPU/
    - jpc0 1y ago
      Very likely something along those lines. Effectively standardise passing operations off to a coprocessor. C++ is moving into that direction with stdexec and the linear algebra library and SIMD. I don’t see why Rust wouldn’t also do that. Effectively why must I write a GPU kernel to have an algorithm execute on the GPU, we’re talking about memory wrangling and linear algebra almost all of the time when dealing with GPU in any way whatsoever. I don’t see why we need a different interface and API layer for that. OpenGL et al abstract some of the linear algebra away from you which is nice until you need to give a damn about the assumptions they made that are no longer valid. I would rather that code be in a library in the language of your choice that you can inspect and understand than hidden somewhere in a driver behind 3 layers of abstraction.
      - bobajeff 1y ago
        >I would rather that code be in a library in the language of your choice that you can inspect and understand than hidden somewhere in a driver behind 3 layers of abstraction. I agree that, that would be ideal. Hopefully, that can happen one day with c++, rust and other languages. So far Mojo seems to be the only language close to that vision.
      - pjmlp 1y ago
        Guess which companies have been driving senders / receivers work.
    - trogdc 1y ago
      These are just wrappers around intrinsics that exist in LLVM already.
  - deleted 1y ago
    [deleted]
  - mertcikla 1y ago
    LLVM people have been at it for a while now, they got it working on Nvidia and AMD working on apple I believe: https://www.modular.com/ https://www.modular.com/ it baffles me that more people haven't heard about them. it's mighty impressive what they have achieved.

Who is we here? I'm curious to hear more about your ambitions here, since surly pulling in wgpu or something similar seems out-of-scope for the traditionally lean Rust stdlib.

LegNeato 1y ago

Many of us working on Rust + GPUs in various projects have discussed starting a GPU working group to explore some of these questions: https://gist.github.com/LegNeato/a1fb3e3a9795af05f22920709d92e456 https://gist.github.com/LegNeato/a1fb3e3a9795af05f22920709d9... Agreed, I don't think we'd ever pull in things like wgpu, but we might create APIs or traits wgpu could use to improve perf/safety/ergonomics/interoperability.

Voultapher 1y ago
Cool, looking forward to that. It's certainly a good fit for the Rust story overall, given the increasingly heterogenous nature of systems.
junon 1y ago
I'm surprised there isn't already a Rust GPU WG. That'd be incredible.
jpc0 1y ago
Hears an idea, Get Nvidia, AMD, Intel and whoever else you can get into a room. Get LLVMs boys into the same room. Compile LLVMIR directly into hardware instructions fed into the GPU, get them to open up. Having to target an API is part of the problem, get them to allow you to write Rust that directly compiles into the code that will run on the GPU, not something that becomes something else, that becomes spirv that controls a driver that will eventually run on the GPU.
- Ygg2 1y ago
  Hell will freeze over, then go into negative Kelvin temperatures before you see nVidia agreeing in earnest to do so. They make too much money on NOT GETTING COMMODITIZED. nVidia even changed CUDA to make API not compatible with interpreters. It's the same reason Safari is in such a sorry state. Why make web browser better, when it could cannibalize your app store?
  - jpc0 1y ago
    Somehow I want to believe if you get everyone else in the room, and it becomes enough of a market force that nvidia stops selling GPUs because of it, they will change. Cough linux gpu drivers
  - shmerl 1y ago
    Yeah, Nvidia can get lost with their CUDA moat. But AMD should be interested.
  - ashdksnndck 1y ago
    Hmm. Maybe the opportunity would be more like AMD, Intel, and the various AI labs and big tech get together, and by their powers combined figure out a way to stop giving NVIDIA their margin?
    - __s 1y ago
      They tried. OpenCL, OpenMP
  - pjmlp 1y ago
    By making Web browser "better" do you mean more ChromeOS like? CUDA is great for Python as well. Maybe Intel and AMD should actually produce something worthwhile using.
    - pawelmurias 1y ago
      Better for running web apps.
      - pjmlp 1y ago
        As long as they are using Web standards, and not Chrome APIs, I do agree.
    - Ygg2 1y ago
      > By making Web browser "better" do you mean more ChromeOS like? Whichever part makes Safari completely fail at properly rendering Jira. A task even Firefox can do.
- bobajeff 1y ago
  Sounds sort of like the idea behind MLIR and it's GPU dialects. * https://mlir.llvm.org/docs/Dialects/NVGPU/ https://mlir.llvm.org/docs/Dialects/NVGPU/ * https://mlir.llvm.org/docs/Dialects/AMDGPU/ https://mlir.llvm.org/docs/Dialects/AMDGPU/ * https://mlir.llvm.org/docs/Dialects/XeGPU/ https://mlir.llvm.org/docs/Dialects/XeGPU/
  - jpc0 1y ago
    Very likely something along those lines. Effectively standardise passing operations off to a coprocessor. C++ is moving into that direction with stdexec and the linear algebra library and SIMD. I don’t see why Rust wouldn’t also do that. Effectively why must I write a GPU kernel to have an algorithm execute on the GPU, we’re talking about memory wrangling and linear algebra almost all of the time when dealing with GPU in any way whatsoever. I don’t see why we need a different interface and API layer for that. OpenGL et al abstract some of the linear algebra away from you which is nice until you need to give a damn about the assumptions they made that are no longer valid. I would rather that code be in a library in the language of your choice that you can inspect and understand than hidden somewhere in a driver behind 3 layers of abstraction.
    - bobajeff 1y ago
      >I would rather that code be in a library in the language of your choice that you can inspect and understand than hidden somewhere in a driver behind 3 layers of abstraction. I agree that, that would be ideal. Hopefully, that can happen one day with c++, rust and other languages. So far Mojo seems to be the only language close to that vision.
    - pjmlp 1y ago
      Guess which companies have been driving senders / receivers work.
  - trogdc 1y ago
    These are just wrappers around intrinsics that exist in LLVM already.
- deleted 1y ago
  [deleted]
- mertcikla 1y ago
  LLVM people have been at it for a while now, they got it working on Nvidia and AMD working on apple I believe: https://www.modular.com/ https://www.modular.com/ it baffles me that more people haven't heard about them. it's mighty impressive what they have achieved.