Rust wire backend

[pcwalton]

What do you think about a Rust code generator for the wire protocol, in addition to the C++ one? The idea is statically-enforced memory safety to prevent sandbox escapes, as an additional layer of defense over fuzzing. I'd be happy to maintain it or bear responsibility for finding someone who can.

For now it could generate C++-compatible objects for consumption by the backends.

[kainino0x]

This is something I've been thinking about as well. I think it would be of great value especially for Firefox and/or Servo to pick up. I don't think it would be difficult to interface with the C++ backends since the wire command structures are all C structs. I'll let @Kangz comment further since he wrote the wire code. I think @kvark will be very interested as well if something like NXT ends up being the direction of the W3C CG.

(On a side note, as much as I would love to write the whole backend in Rust, it unfortunately probably wouldn't be feasible to get a Rust language dependency into the Chromium build process.)

We've also had some discussions about exposing the API to Rust (for user code targeting WebAssembly or native). We've decided not to work on that yet since the API is changing too rapidly, but I definitely think it should be a launch goal for whatever "GPU for the Web" ends up being.

[Kangz]

It would be great if / when NXT is used in Firefox or Servo. The real API is a C structure full of function pointers that allows us to swap implementations easily: the app doesn't know if it is running on the wire, or directly on the backend. This means everything can be handled by the Rust FFI, and wouldn't need C wrappers for C++ objects (just lots of unsafe).

However I would advise you to not spend too much effort on this in the near-term. The API is still very much in flux, with lots of missing features including some that will need manual implementations in the wire (buffer mapping). Also if NXT isn't the direction the W3C CG goes, we will drop the prototype. On the plus side, for Chrome's constraints we are going to make sure whatever comes out of the CG is IPCable.

Rust bindings would are definitely something we want to do at some point, and would remove whole class of errors, for examples the builders could be consumed on GetResult.

[pcwalton]

Great to see interest. :)

I could see this becoming an important part of the Rust ecosystem as well as a Web component. Rust is in need of an idiomatic cross-platform GPU abstraction layer (the closest is https://github.com/tomaka/vulkano, but it's VK-only), and NXT could fit the bill quite nicely.

[Kangz]

Yep, our hope is that the library implementing the Web API, NXT or not, will be used in other contexts.

[kvark]

@pcwalton

I'd be happy to maintain it or bear responsibility for finding someone who can.

It's great to see Mozilla volunteering to develop and maintain a part of Google's NXT prototype, way before the actual API draft is made by the working group. If only we had our own proposal to contribute to...

Rust is in need of an idiomatic cross-platform GPU abstraction layer (the closest is https://github.com/tomaka/vulkano, but it's VK-only), and NXT could fit the bill quite nicely.

This is wrong on so many levels...

• Rust has a cross-platform GPU abstraction
• ... and vulkano has nothing to do with it
• NXT doesn't fit Vulkan(o) nicely, but there is another proposal that does

[pcwalton]

Oh, apologies for the confusion. I should clarify that I would like to work on whatever API comes out of the working group, not to favor one over the another. I'm not endorsing either API; I just think some cross-platform GPU API would be healthy for Firefox/Servo/Rust.

Also, I completely forgot about how far gfx-rs has come. Sorry :(