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

[phoronix]

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

[CrystalGamma]

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.

[Zplay]

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 ?

[curaga]

If it translates to GL it cannot really improve on it much.

[Steffo]

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

See the docs:

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.

[Nille_kungen]

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

[cmr~]

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...

[bjz_]

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

[CrystalGamma]

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?

[cmr~]

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.