Announcement

Collapse
No announcement yet.

A New High-Performance, Bindless Graphics API Comes To Rust

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

  • A New High-Performance, Bindless Graphics API Comes To Rust

    Phoronix: A New High-Performance, Bindless Graphics API Comes To Rust

    Gfx-rs is the name of a new high-performance, bindless graphics API that tries to be better than OpenGL, at least when dealing with the maturing Rust language...

    http://www.phoronix.com/vr.php?view=MTg0MDA

  • #2
    Great.

    This was one of the things I thought was missing for Rust.
    Now excuse me while I dive the docs to see how good it is.

    Comment


    • #3
      Could someone explains me the meaning of "bindless" in this article ? I don't understand what does it means

      Is it like php PDO and java JDBC but for graphics ?

      Comment


      • #4
        If it translates to GL it cannot really improve on it much.

        Comment


        • #5
          Originally posted by Zplay View Post
          Could someone explains me the meaning of "bindless" in this article ? I don't understand what does it means
          See the docs:

          Originally posted by gfx-rs doc
          Graphics APIs like OpenGL still require the developer to 'bind' and 'unbind' objects in order to perform operations on them. This results in a large amount of boiler plate code, and brings with it the usual problems associated with global state.

          Comment


          • #6
            Originally posted by Zplay View Post
            Could someone explains me the meaning of "bindless" in this article ? I don't understand what does it means

            Is it like php PDO and java JDBC but for graphics ?
            http://www.nvidia.com/object/bindless_graphics.html

            Comment


            • #7
              Originally posted by curaga View Post
              If it translates to GL it cannot really improve on it much.
              While that's true in the limit, we do state caching and use the newest GL APIs supported by the driver, which removes a lot of the pain of using GL by-hand efficiently. An in-progress refactoring allows for multiple backends, and I have a D3D11 backend basically ready to go for that. I've been keeping a close eye on Metal (Apple's mobile API) compatability, and we should also be good for Mantle and GLNG. gfx-rs is still a heavy WIP, it isn't ready for all this publicity it's getting...

              Comment


              • #8
                Originally posted by CrystalGamma View Post
                This was one of the things I thought was missing for Rust.
                Now excuse me while I dive the docs to see how good it is.
                As ~cmr says, unfortunately we are not yet ready for prime time, so the docs and API will still look a tad 'rusty' (hah). In particular we are still awaiting some language features that should make the API a great deal cleaner and more flexible, but that should be coming along really soon. One of our key contributors, recently did a talk at the Toronto Rust Meetup (starts from ~53:00). Might be of some interest to you guys.

                If you are interested in having a chat with us, feel free to hop on our gitter room or join #rust-gamedev (irc.mozilla.org). We could really use more contributors with experience in this area. You can also post an issue if you have any suggestions, queries, or criticisms. We look forward to hearing

                Comment


                • #9
                  Originally posted by cmr~ View Post
                  While that's true in the limit, we do state caching and use the newest GL APIs supported by the driver, which removes a lot of the pain of using GL by-hand efficiently. An in-progress refactoring allows for multiple backends, and I have a D3D11 backend basically ready to go for that. I've been keeping a close eye on Metal (Apple's mobile API) compatability, and we should also be good for Mantle and GLNG. gfx-rs is still a heavy WIP, it isn't ready for all this publicity it's getting...
                  Is there a reason why you're using u32s for the Handles?
                  If a backend were to use opaque objects as handles instead of numbers, wouldn't that cause unnecessary indirection?

                  Comment


                  • #10
                    Originally posted by CrystalGamma View Post
                    Is there a reason why you're using u32s for the Handles?
                    If a backend were to use opaque objects as handles instead of numbers, wouldn't that cause unnecessary indirection?
                    Those are the cases where the underlying OpenGL calls take/return u32s (for example, buffer ids). These are conceptually a per-backend type, but we haven't finished the work to make it an actual generic type yet.

                    Comment

                    Working...
                    X