12 ms·

Rust-GPU

• kvark 6y ago
  We've been trying to design a safe and portable language in WebGPU (called WGSL), but it turns out to be really hard. For example, subgroup ops discussion [1] so far concluded that even the most limited form still has portability concerns. Even things like texture sampling (that depend on control flow uniformity) could be tricky with regards to how the uniformity is defined. And at least in WGSL we can be conservative, but Rust-GPU does probably not have this luxury. Thus, I'm curious to see how Rust will tackle it. Will it try to enforce the portability and safety guarantees with a type system, or will it specifically lower the guarantees compared to native code (thus keeping the syntax of Rust but not the philosophy). Anyhow, amazing work by Embark, and a stellar example how to collaborate in open source! [1] https://github.com/gpuweb/gpuweb/pull/954 https://github.com/gpuweb/gpuweb/pull/954
  • deleted 6y ago
    [deleted]
  • Jasper_ 6y ago
    > it turns out to be really hard Everyone was yelling this at you since the beginning. Ever since Apple proposed "safe HLSL", and then it morphed into WHLSL and then WLSL and then the competing Tint proposal which is now WGSL, everyone (Adobe, Valve, Epic, Unity, NVIDIA) was saying "none of this will do what you think it does, we've all been here before and it's very very hard, at the very least, get some IHVs or at least a team that does port work / emulation tech on board". The committee chose not to listen, instead forcing WebGPU down this hell that nobody really wants or appreciates. The whole WebGPU is three years late and still has no users, despite being one of the most complicated specs to land in years. And yeah, I'm still a bit bitter about it. I am also skeptical of rust-gpu's approach, because I don't think it's possible to take a CPU-inspired language design and blindly adapt it to GPUs without some difficult questions to answer (they still don't have flow control, but I'm told that's coming). But at the very least, I think repi and Embark know what they're doing and know about the tough problems, rather than feigning being blindsighted.
    • auggierose 6y ago
      So what are you saying here? WebGPU should have been just Apple Metal?
      • masklinn 6y ago
        > we've all been here before and it's very very hard, at the very least, get some IHVs or at least a team that does port work / emulation tech on board
      • kevingadd 6y ago
        There were working SPIR-V+WebGPU prototypes quite a while ago, and plenty of people would've been happy with SPIR-V+WebGPU. But a particular big company's petty fights with Khronos derailed that.
        • cogman10 6y ago
          Why not call them out? It was Apple that decided that standards weren't for them. Sure, it might be more of an Apple legal team problem vs programmer problem. None-the-less they are the ones that decided to derail the standard.
          • om2 6y ago
            SPIR-V by itself does not have the needed safety or interoperability properties for the web, or the advantages of text formats that the web has benefitted from. These are the more important factors, not IPR considerations. Fortunately, we landed on a good compromise with a textual language that maps closely onto SPIR-V semantics. A lot of the hard work remaining is to achieve the level of safety and interoperability required for the web. Even in an approach of using SPIR-V as the syntax, a similar level of effort would have been required on safety and interop aspects.
            • Jasper_ 6y ago
              > SPIR-V by itself does not have the needed safety or interoperability properties for the web Safety, maybe not 100%, but this could be fixed with extensions, and transformations. The same transformations that WGSL compilers will apply. I'm unsure of what you mean by "interoperability". > or the advantages of text formats that the web has benefitted from. ??? Nobody has ever enumerated these to me. Or told me why if these advantages are so great, why Apple has not advocated for a text-based formats for <audio> and <video>. Binary formats are widely becoming more standard on the web for all sorts of reasons (images, fonts, video, audio, even code in the form of WebAssembly, and Bloomberg/Facebook's JS AST proposal improved performance by removing parsing cost. MapBox ships its vectors in binary format. glTF is a binary format.), and even in the graphics space, the release of the new SPIR-V format over having to ingest GLSL is seen as one of the greatest advantages of Vulkan over OpenGL. If you want a text format, take the text serialization of SPIR-V. It's there, it's standard, it exists. But you won't bother answering me, because every time you bring this up, we ask the same questions, repeat the same evidence, and you ignore us, preferring just to reply "text is more webby". Not to mention that you're currently pressuring the WG to add new APIs to avoid the heavy front-end cost of Apple's own MSL shader compiler. https://github.com/gpuweb/gpuweb/issues/1064 https://github.com/gpuweb/gpuweb/issues/1064
• nyxtom 6y ago
  Having the crate ecosystem for shaders written in Rust will be very useful to have. Excited to see this project progress!
• amelius 6y ago
  Will this only target graphics operations, or will it also be suitable for general purpose computations (matrices, tensors, etc)?
  • Impossible 6y ago
    From the readme Focus on Vulkan graphics shaders first, then after Vulkan compute shaders So no compute support yet. Also, Rust-GPU's focus is writing shaders in Rust, in order to support a game engine, so the focus will be real-time graphics and simulation. It seems like it will never evolve into a CUDA like heterogeneous environment that's more common in scientific computing and ML.
    • pcwalton 6y ago
      > It seems like it will never evolve into a CUDA like heterogeneous environment that's more common in scientific computing and ML. I don't think anyone would be opposed to evolving the project into a strong alternative for scientific computing and machine learning!
• 2bitencryption 6y ago
  imagining a simple x86/64 machine that also has a simple GPU... what does the amd64 assembly look like for "telling the GPU to do something"? Is there an amd64 instruction that says "Tell the GPU to start executing here?" Or is it at the OS layer instead of the assembly layer, with an OS syscall that defers to the GPU?
  • cylon13 6y ago
    CPU code calls in to drivers which talk to the GPU over the PCIe bus. So assembly code that does stuff with the GPU just looks like loading a shared library, passing in some shader code, and then passing in some drawing commands. This project looks like it aims to compile rust to a shader intermediate format so you can use it instead of more common shading languages like GLSL or HLSL. Basically your HLSL/GLSL/(now Rust) code ends up as an intermediate format, which the CPU passes in to a graphics driver before asking that driver to draw things.
  • MayeulC 6y ago
    CPU peripherals are memory, so it just looks like copying a GPU "kernel" (program) from a memory area (from disk) to another (GPU, via PCIe). I don't know enough about PCIe to be an authoritative source, but I'll just go along and describe the way most microcontrollers and peripherals work. I doubt x86 has instructions dedicated to PCIe. There will likely be a PCIe controller memory-mapped to some hardware address, that the OS will write to as if it was regular memory (that address is physically wired to the controller, be it on the CPU die or on the motherboard). The address is generally specified by the BIOS/UEFI (devicetrees on most embedded platforms). Of course, what you will write will depend on the controller itself, but the OS will have a driver that contains that information. You have a back-and-forth to list peripherals on the bus, identify the one you want to communicate to, set-up access mode (direct memory access where you map an area of your memory to the peripheral, or just sequential access trough the controller). Once you can communicate with the GPU, you start the same dance to give it a program you compiled ahead of time, have it run, and fetch the result. I don't have low-level experience with that specific part of the system, but that kind of stuff is generic enough that you find the same patterns everywhere, at least for turing machines, which x86 CPUs are.
• shmerl 6y ago
  Oh, I was waiting for something like this to appear. So this allows using Rust to generate SPIR-V for Vulkan instead of GLSL or HLSL? Can Rust be used also for compute? It would be a great way to dislodge CUDA lock-in, since something in Rust could be a lot better option than either CUDA or OpenCL.
  • m12k 6y ago
    From the link: "Focus on Vulkan graphics shaders first, then after Vulkan compute shaders"
    • shmerl 6y ago
      How does using shader in language X in Vulkan compare to approaches of OpenCL and CUDA? I.e. is it ergonomic to use for compute?
      • Impossible 6y ago
        I don't think anyone on HN that regularly uses CUDA would call graphics compute ergonomic, and I often see complaints about it. I also see graphics programmers using CUDA complain about graphics interop (although Opti-X seems pretty good), so it might be the result of different use cases, rather than anything better or worse about either model.
        • shmerl 6y ago
          So you think there is no need to make something different for Rust than using it as a shading language for Vulkan, or GPU programming can be improved with different approaches? Basically, I'd like there to be something that's ergonomic, using Rust and can eventually help get rid of CUDA lock-in.
          • Impossible 6y ago
            I think there is a need for it. I'm not sure if this will become that, although it might be a piece of it. There seem to be multiple projects to build CUDA like environments (or CUDA itself to Rust.
• MayeulC 6y ago
  That's quite interesting, but I wonder what Rust brings to the table here. From my understanding of GLSL, it seemed like the hardware was in control of scheduling, and the driver that compiled the shaders was the one inserting locks, fences, etc. GPUs seem like a bad fit for run-time exceptions and return value checking (? operator?) since they are so poor at branching, being SIMD. The more you can check ahead of time, the better, and Rust isn't such a bad fit there. But given that Rust's main advantages seem to be the ability to safely control multiple execution threads, and its handling of edge cases, I wonder if the first is going to be used at all, and if the second isn't going to lead to extra instructions?
  • adamnemecek 6y ago
    I'm going to guess that it's a subset of Rust.
  • ironmagma 6y ago
    Rust has hygienic macros and a package manager, at least. It'd also be nice to have a common language that you could run on the CPU for debugging purposes. I see this more as a moonshot type project though, where if you could accomplish it, it would mostly just speed up Rust's time to utility for other similar use cases like embedded development.
  • Impossible 6y ago
    Another advantage (for Embark) is their main engine codebase is also in Rust. This allows for sharing of some code on GPU and CPU. This isn't uncommon in the game industry, for example header files that compile in both C++ and HLSL in order to share struct definitions for CPU code and GPU code, and CPU math libraries that use HLSL types and semantics. Rust is different enough from GLSL and HLSL (most game engines use HLSL as "native" and cross compile to GLSL, MSL or use header defines to build PSSL) that introducing a new shading language compatible with Rust is probably worth the effort for them.
  • flohofwoe 6y ago
    The main benefit is that the GPU-side code can better integrate with the CPU-side code, and that you don't need separate tools and a complex build process integration. For instance it's possible to share data structure between the CPU and GPU side directly from the same source code, or you can run the same code on the CPU or GPU for whatever reason (debugging, unit testing etc...). The Metal API uses C++ (with some extensions) as shader language, which IMHO is complete overkill too, but one nice side effect is that you can put shared data structures into headers, and then include the same shared headers on the CPU and GPU side. Ideally it should be possible to mix GPU and CPU code in the same source file, and only (for instance) annotate GPU functions with an attribute which causes it to be compiled as shader code.
• Const-me 6y ago
  > developers could use open-source crates that provide the graphical effects needed to create beautiful experiences That HLSL/GLSL code is tightly coupled to format and bindings of the input and output data (textures, samplers, constant/uniform buffers, render targets, etc.) These are defined by the combination of non-shader assets, and the CPU-running code which implements the rest of the graphics engine. I’m not sure how different shader language is going to help?
• RcouF1uZ4gsC 6y ago
  Microsoft did something very similar for C++ back in 2012 calling it Accelerated Massive Parallelism (AMP) https://en.wikipedia.org/wiki/C%2B%2B_AMP https://en.wikipedia.org/wiki/C%2B%2B_AMP It generated a lot of buzz in the Windows world around that time, but as far as I can tell never went anywhere.
• bogwog 6y ago
  > If we do this project right, developers could use open-source crates that provide the graphical effects needed to create beautiful experiences. Instead of sharing snippets of code on forum posts, they could simply add the right crates. That’s not a very compelling value proposition. You don’t need to switch languages to use a package manager. Plus, not all engines have the same data layout, so an “effect crate” would either require your engine to work a very specific way, or would require integration work that would probably defeat the purpose of using a package manager in the first place. And what does Rust itself add that GLSL/HLSL don’t offer? It can’t be worth the headaches, especially when you consider how a TON of devices still only support OpenGL, which not only requires runtime compilation of shaders (so only GLSL unless your app ships a cross compiler), but different drivers behave differently, requiring ugly hacks for the sack of performance in some cases.
  • chungus_khan 6y ago
    The project actually says it compiles to SPIR-V (Vulkan's standard intermediate representation), so driver/GPU support really shouldn't be too much of an issue so long as the target is one that supports Vulkan.
    • flohofwoe 6y ago
      SPIRV can also be used as intermediate format and converted to various target shader languages: https://github.com/KhronosGroup/SPIRV-Cross https://github.com/KhronosGroup/SPIRV-Cross
  • pcwalton 6y ago
    > Plus, not all engines have the same data layout, so an “effect crate” would either require your engine to work a very specific way, or would require integration work that would probably defeat the purpose of using a package manager in the first place. You could say the same thing about nodes in shader graph systems, but in practice they work quite well. > It can’t be worth the headaches, especially when you consider how a TON of devices still only support OpenGL, which not only requires runtime compilation of shaders (so only GLSL unless your app ships a cross compiler) You can AOT compile SPIR-V to GLSL with SPIRV-Cross.