34 pointsby eventhelix4 days ago6 comments
  • flumpcakes4 days ago
    Rust does not seem well suited for GPU programming. Current shader languages could be improved and are only C-like probably for ergonomics.

    What's the benefit here? The only one I can see is if you don't want to learn a shading language/compute platform and you are already writing in Rust and you want your codebase to be in a single language.

    It's cool that this exists, but it really is oversold and a bit off putting calling it "the future" of GPU programming.

    • dathinab4 days ago
      It's a bit of a question about what kind of GPU programming we speak about.

      Like you have complex GPGPU programs which have nothing anymore to do with graphics, programming of Graphics (shaders) and using programming for Graphics to do GPGPU (roughly).

      In the later two cases you might want a shader language but in the first case you might want something more "general purpose".

      And I mean tracking down wrong computations due to soundness issues or similar is still a gigantic pain in GPGPU.

      And the absence of code level abstraction mechanisms is a problem with many shader languages, too.

      But I still agree that I don't expect rust succeeding there, but it would be nice and it has the potential to at least get some niche success.

  • brianhorakh4 days ago
    Whoa, was checking the rust GPU examples out this morning, but didn't end up using it.

    Needed to find a way to bicubic resize images fast on an embed Nvidia gpu.

    Was looking at both llvm ptx & vulkan spir-v as a way to reduce dependency on Nvidia hardware. We ended up using npp with autogen c++ binding.

    The rust GPU foundation is a great idea. Lots of interesting possibilities for rust devs.

    Rust patterns, because it's advanced type checking (part of memory safety) makes a lot of functional tasks faster for embedded devs. It's also a dream to cross compile and deploy with (cargo(, several times faster and easier than c++.

    You need fewer tests and less (often neglected) runtime error handling code because of the contract with the compiler.

    I also love how I can write crates for python using pyo3 that data science team can use.

  • DrNosferatu4 days ago
    Great trailblazing! Now we just need Zig GPU ;)
  • krogue4 days ago
    From a PR standpoint, this page encourages the viewpoint that Rust fans are too often Rust fanatics.

    As for ultimate usefulness, I am not really convinced. The big selling point on Rust is no memory leaks, no use after free and so on. These issues do not exist in shaders; one cannot allocate memory in shaders really, so that point of Rush seems, well, pointless. I would also never put bounds checking into a shader either; that harms performance a great a deal. I guess if you like Rust's syntax this is a useful, though doing bits that are natural in typical Rust would likely be far from ideal on GPU code. This happens also with current shading languages too, but I strongly suspect this makes it worse.

    As a point against usefulness: it is somewhat useless on Apple platforms since one will need to translate into Metal (and yes, there are tools for that), but that drops so many capabilities of targeting Apple devices. Apple GPU's, because of their nature, can do things other GPU's cannot (and also the other way) and to make this useful to me (or any performance minded project that targets Apple GPUs), will require shoe-horning those features somehow into this.

    But I guess, it is nice for those who like the syntax of Rust (I confess I do not like Rust's syntax) and are targeting Vulkan as it gives one another shading language to write in; which I guess means a point for SPIR-V (and the interface language idea in general).

    • persnickety4 days ago
      There are other big selling points of Rust, compared to GPU-specific languages.

      One is an expressive type system with algebraic types and generics. It's a lot easier to produce versions of code optimized for a certain use case. Only CUDA comes close.

      This brings us to the ecosystem. Outside of CUDA, how many libraries exist that can easily be used from a shader context?

      Rustc has great error messages. I don't know others, but errors in OpenGL shaders make me want to flip tables.

      And being able to run the same code on the CPU is valuable as well, leading to simpler testing and debugging.

      So unless you like CUDA and its problems, then this is rather attractive.

    • laerus4 days ago
      > The big selling point on Rust is no memory leaks

      Memory leaks are not considered memory errors in Rust and they are allowed.

      • Yoric4 days ago
        They are allowed, but they're extremely uncommon nevertheless.
    • MindSpunk4 days ago
      A modern language with generics and quality IDE experience with the ability to write truly composable code is what interests me in the project. Modern shader codebases are truly enormous, but the languages up until recently lacked any tools for composition beyond the function. HLSL got templates in 2021 and GLSL is a dead end with no development.

      No Metal support is IMO no problem. I and most of the rest of the games industry couldn’t care less about MSL. Nobody uses it. I’ve seen numbers from Apple that say upwards of 80% of developers they asked target Metal via SPIR-V Cross and HLSL from DXC.

      I love what this project wants to do, use a “real” language to get the developer experience while writing shaders. However IMO slang will eat Rust-GPU’s lunch. You are right, borrow checking is not useful for shaders, and slang delivers most of the same language improvements (modules, generics) while being able to target many more platforms. And slang is production ready, unlike rust-gpu.

      I’d still love to see what rust-gpu could become though, especially with DX12 moving to spirv in the future. It’s be nice to share rust code between my engine code and shader code.

      • krogue3 days ago
        > No Metal support is IMO no problem. I and most of the rest of the games industry couldn’t care less about MSL. Nobody uses it. I’ve seen numbers from Apple that say upwards of 80% of developers they asked target Metal via SPIR-V Cross and HLSL from DXC.

        That is a real, real shame with respect to performance. A number of algorithms one can do with MSL (or really because of tile based rendering) so much faster (nearly no main memory bandwidth consumption). Atleast there is GL_EXT_shader_pixel_local_storage for GL. For Vulkan it appears that there is VK_EXT_shader_tile_image, but I do how widespread it is on Android.

        There are other nice features that are Metal-ish only as well (tile shaders are a big deal) but typically the memoryless textures tops my list.

    • 4 days ago
      undefined
  • 4 days ago
    undefined
  • WhereIsTheTruth4 days ago
    A language that is slow to compile can't be the future of anything

    Waiting for your code to compile in order to be able to see how this new color looks, or this new font or this new title or this new game player speed feels, just is BAD, very BAD

    You don't have to trust what i say

    You can however trust facts

    Here a real world example to verify that fact everyone can test at home

    Clone this popular open source game written in Rust:

    https://github.com/veloren/veloren

    Compile it, `cargo build` easy

    Insert "... an hour later .." meme

    Nice, you got it to compile

    Now change any value, just like a gamedev would do when he iterates on its game

    Here for example, the strength of the lighting effect:

    https://github.com/veloren/veloren/blob/master/server/src/cm...

    Again, `cargo build`

    Let us know, how long it took to compile on your machine

    It took 17 seconds for me, 17!!! seconds!!!, just because i wanted to change the look of the lighting effect

    Is this how you view the future of GPU/gamedev programming?

    GPU/gamedev programming deserve better

    Even gamers are sick of slow compilers

    https://gameworldobserver.com/2023/04/07/shader-compilation-...

    When fraudsters and propaganda takes over tech, that's what you get

    • Ygg24 days ago
      > Clone this popular open source game written in Rust:

      > https://github.com/veloren/veloren

      > Compile it, `cargo build` easy

      > Insert "... an hour later .." meme

      Download the repo - 15m

      Cargo fetch - 6m

      Cargo build - 4m34s

      How did you get to 4hrs mark? I have 5900x with 3600MHz RAM on fast SSD and win10.

      Am I the only one on HN that gets semi-normal build times in Rust? Are you all running compilers on i386 or something? Is this on HDD?

    • vardump4 days ago
      I don't know whether Rust will ever be the right language for GPU programming, however your take feels somewhat unfair.

      Please remember there's a lot of optimizations put in the legacy compilers.

      What makes you think Rust compile times won't improve?

      • carlmr4 days ago
        Also anyone who has worked on a significantly large C++ code base will be really happy about 17 seconds iterative compile times.
        • TinkersW4 days ago
          It was 17 seconds for 1 shader file.

          Iterative C++ compile times can be very fast if you know what are you doing, 17 seconds is very long unless you have link time optimizations on(which makes no sense for an iterative build).

          • gpm4 days ago
            As far as I can tell they didn't change a shader at all, they linked to code that looks like it runs on the CPU as part of the main binary not as a shader.
    • 0xEF4 days ago
      It does make me wonder what the next Language of the Moment will be that has everyone on HN salivating, hailing it as the replacement for all else.
      • orangeboats4 days ago
        Comments like yours have been expressed for _9 whole years_ since Rust 1.0 released in 2015. Not so Language of the "Moment" anymore, eh?
    • orangeboats4 days ago
      >Insert "... an hour later .." meme

      The same meme is true for C++ projects, yet I don't see people screaming C++ propaganda when Unreal Engine uses it for development.

      Come on now. You are the same thing you complain about.

    • juliangmp4 days ago
      >When fraudsters and propaganda takes over tech, that's what you get

      ?

    • Ygg24 days ago
      > Clone this popular open source game written in Rust.

      What does this have to do with Rust GPU? A game is compiling slowly, I get that but what is the connection?

    • pytness4 days ago
      I ran `cargo fetch` first to remove the downloading time out of the equation.

      Ran on arch (AMD R7 7800X3D).

      First build:

      > cargo build 2574.91s user 79.89s system 1341% cpu 3:17.84 total

      After change:

      > cargo build 11.97s user 1.62s system 176% cpu 7.719 total

      After another change, this time with --timings:

      > cargo build --timings 12.00s user 1.60s system 176% cpu 7.722 total

      Unit | Total | Codegen

          1. veloren-server v0.16.0  4.9s  3.7s (75%)
      
          2. veloren-voxygen v0.16.0  4.1s  2.0s (49%)
      ...
      • Ygg24 days ago
        I have 5900X, and I got like 4m34s build time on Windows (which should be slower).

        What memory are you using? Are you overclocking? Are you using SSD?

        • pytness4 days ago
          I directly cloned to /tmp. 64GB ddr5, No overclock.

          edit: (also, the machine was recently rebooted and had very few processes running)

          After i posted the comment i tested on a laptop running windows with wsl (i7-12850HX 16c 24t) and the first build was going above 8 minutes.

          • Ygg24 days ago
            So is /tmp a ramdisk? I have 64GB DDR4, but overclocked to double Infinity Fabric timings i.e. 3600 Mhz (it might be different for DDR5/ Zen4-5).

            I ran this on MSVC toolchain on windows. With like 43% memory taken by various Firefoxe and IntelliJ windows.

            Either compilers REALLY love CORES, or the Memory speed is causing issue :/

            EDIT: Windows compilation 8min took less time than Linux 45min?

            • pytness4 days ago
              Yes, in linux there is a file system type called tmpfs which is mapped to memory (most of the time iirc).

              > Filesystem Size Used Avail Use% Mounted on

              > tmpfs 31G 22M 31G 1% /tmp

              Try running `cargo build --timings`, it creates a report about build times. My guess would be storage speed, i would not expect memory speed to be that much of an issue.

              edit:

              > Windows compilation 8min took less time than Linux 45min?

              I dont think i understood this correctly, but in the case you are asking (for clarification) about my compile times, i got around 3m:18s on linux, and around >8 minutes on WSL.

              • Ygg24 days ago
                > Try running `cargo build --timings`, it creates a report about build time

                Yeah, I got a bit longer time now, after `cargo clean `. Here are the timings: https://html-preview.github.io/?url=https://gist.githubuserc...

                It's still strange win 10 was faster to compile on a worse CPU and worse memory :/

                Maybe WSL has some issues that MSVC toolchain doesn't.

                > I dont think i understood this correctly, but in the case you are asking (for clarification) about my compile times

                Yes. I was confused by its output, i.e. 2541.91s

                • pytness4 days ago
                  > Yes. I was confused by its output, i.e. 2541.91s

                  Thats the output of the shell command `time` (im using zsh so the output differs from other shells) eg `time cargo build`.

                  system is the cpu time spent calling kernel functions and user is the cpu time spent outside kernel functions. The time is measured per core, so if the program runs for 2 seconds with 16 threads, the user time would be around 32.

                  Notice there is a cpu metric (1341% cpu), if you do: (user + system) / cpu * 100 / 60 = ~3.29 minutes = 3m:17s