Announcement

Collapse
No announcement yet.

Rust's Low-Level Graphics Abstraction Layer Is Showing A Lot Of Potential

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

  • Rust's Low-Level Graphics Abstraction Layer Is Showing A Lot Of Potential

    Phoronix: Rust's Low-Level Graphics Abstraction Layer Is Showing A Lot Of Potential

    The Rust programming language's "GFX-RS" initiative that is backed by Mozilla continues working on exposing a universal "Vulkan-like" graphics API within Rust that in turn would have back-ends for Vulkan, OpenGL, Metal, and Direct3D 11/12 in order to reach all major platforms. Early benchmark results are quite promising for GFX-RS...

    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
    inb4 jokes about people who like Rust and the abstraction layer fest that's been going on since low level graphics APIs became a thing

    Comment


    • #3
      I'd like to know how it compares performance wise to native Vulkan on Linux/windows.

      Comment


      • #4
        Since they can’t change the Dota source code, I don’t quite understand how the portability layer works. MoltenVK basically links the translation functionality to the binary AFAIK. Is gfx-rs like a driver that in turn uses the metal driver?

        Comment


        • #5
          I guess they intercept Vulkan calls? Unless MoltenVK is statically linked, it should be doable.

          Comment


          • #6
            Did I misread something? They are creating a yet another new low level api? Instead of just using vulkan and coverting to/from that if on mac?

            Comment


            • #7
              Originally posted by ua=42 View Post
              Did I misread something? They are creating a yet another new low level api? Instead of just using vulkan and coverting to/from that if on mac?
              The original and primary purpose of gfx-rs is to be a portable Rust API wrapper for graphics... basically to Rust and the GPU what SDL is to C and the OS.

              This is a case of "We already have a very Vulkan-like Rust API with backends for all the major platform graphics APIs... why not write a thin little shim to translate actual Vulcan calls from other applications to it?"

              Comment


              • #8
                Originally posted by ua=42 View Post
                Did I misread something? They are creating a yet another new low level api? Instead of just using vulkan and coverting to/from that if on mac?
                The motivation behind this might come from RedoxOS, where they want the whole system to be programmed in rust. This way they can have temporary support for Rust in Redox OS with drivers written in C.

                Comment


                • #9
                  Originally posted by ua=42 View Post
                  Did I misread something? They are creating a yet another new low level api? Instead of just using vulkan and coverting to/from that if on mac?
                  From what I know about it it's not just "yet another" API. It's an API designed to be idiomatic Rust and not need any "unsafe" code. That's a huge plus compared to something like pure Vulkan.

                  Comment


                  • #10
                    Originally posted by GruenSein View Post
                    Since they can’t change the Dota source code, I don’t quite understand how the portability layer works. MoltenVK basically links the translation functionality to the binary AFAIK. Is gfx-rs like a driver that in turn uses the metal driver?
                    MoltenVK in Dota is a dynamically linked library. They just pretend to be MoltenVK, so that uses their implementation instead of MoltenVK.

                    As exaplined on Reddit:
                    Originally posted by kvarkus
                    They have a Vulkan rendering engine, and there is a DLC that downloads libMoltenVK.dylib in their library path, which is used as a dynamic library implementing the Vulkan driver. Since we also implement a Vulkan driver, all we needed is just setting DYLD_LIBRARY_PATH to find our path first and aliasing the name of libMoltenVK.dylib See earlier discussion on the topic.

                    Comment

                    Working...
                    X