Mesa Developers Discuss The Possibility Of Rust Graphics Driver Code

[cb88]

Isn't it simple? Do it like librsvg. Require a C API for the outside (i.e. driver/mesa internals) and be done.



Not really. It means you have to think less about architecture.

Exactly... its not like Mesa is exposing itself as a high level library like LLVM... its providing C APIs..

[kpedersen]

Exactly... its not like Mesa is exposing itself as a high level library like LLVM... its providing C APIs..

Possibly a very bad source of data but it seems the mirror on GitHub suggests that just over 22% of mesa is C++ code. Interacting that with Rust is not going to be feasible without a lot of binding machinery to go down to C and then back up again to the other high level language.

Plus if in the future it is decided to bring even more languages into the internals of Mesa, they will have to bind against Rust and/or C++ and that will be difficult compared to if it was C throughout.

Getting Rust in mesa will be great for Rust because it will help cement the language into the real world but I believe it may add maintenance burden onto these guys. Luckily they are the ones that are going to make the choice so who knows.

[aspen]

I'm not really talking about having good compatibility with C code. That is "easy" because C is so flexible and simple to work with. The difficulty arises trying to have good compatibility between two higher level languages (C++ <> Rust). That is much harder and Rust doesn't do anything particularly magical here. Having a lot of Rust (or C++) in Mesa will block any newer high level languages in future.

I don't disagree that Rust is safer than C and C++ (and certainly *much* safer than how many developers use C++). But my vote is simply keep to homogenous C with everything and just AddressSanitize like hell. It gives a cleaner architecture overall.

Erm, what? Rust can easily expose functions, structs, and enums in a C-friendly fashion. And there's high-quality tools for exposing a C API from Rust (and vice-versa).

Yeah, and then when Mozilla implodes and takes down Rust with it, what then? Mesa developers will have to take up maintaining Rust in addition to Mesa?

No matter what you "C purists" or whatever you goobers call yourselves think, Rust's fate isn't tied to Mozilla anymore.

[moltonel]

22% of mesa is C++ code. Interacting that with Rust is not going to be feasible without a lot of binding machinery to go down to C and then back up again to the other high level language.

The direct Rust<->C++ interop solutions (without going through a C ABI) are actually pretty decent. Not every C++/Rust types can be used, but it's better than C<->C++ or C<->Rust interop. It's remarkable that Rust already has this, most languages don't bother and only implement a C ABI FFI.

Also, I'm not sure which components are in C++ but they don't seem to be central ones. A Rust driver will probably only need to talk to the C core.

[elatllat]

Rust can use more RAM, but it's about the same speed as C and the extra safety in Rust is well worth it's negligible costs.

[Alliancemd]

The issue with Rust is still that there is no proper compiler that just creates proper bytecode, just this LLVM thing. I guess if GCC could compile Rust, this can be asked again.

You realize that almost all native compilers rely on "this LLVM thing" nowadays? You have no idea what you are talking about but still complain about it.
And no, Rust doesn't "create bytecode"...

Yeah this is actually one of my major concerns.
I'm really relucant to be packed into the LLVM bandwagon

You don't work on the compiler, you have absolutely nothing to do with LLVM. Rust binaries don't depend on LLVM.
Yet another example of somebody that has absolutely no idea what he is talking about but still decides to complain about it.

[Alliancemd]

Rust can use more RAM, but it's about the same speed as C and the extra safety in Rust is well worth it's negligible costs.

Very small, example Rust binaries use a little bit more RAM but as the project gets bigger, Rust applications usually use less RAM due to how it's memory management works(or what it allows to do without having to track an address through thousands of method calls like in C/C++).
Rust allows to easily write Zero Copy parsers and to pass references worry-free, resulting not only in less memory consumption but also significantly better performance.
It's one of the reason why usually Rust tools are the fastest version of that tool.
grep: https://blog.burntsushi.net/ripgrep/...rch-benchmarks
find: https://github.com/sharkdp/fd#benchmark
etc...

[polarathene]

I'm not really talking about having good compatibility with C code. That is "easy" because C is so flexible and simple to work with. The difficulty arises trying to have good compatibility between two higher level languages (C++ <> Rust). That is much harder and Rust doesn't do anything particularly magical here. Having a lot of Rust (or C++) in Mesa will block any newer high level languages in future.

Eh? A common pain point I've heard about with C++ is it's lack of interoperability with other languages. There are popular C++ projects that get the effort to produce Python wrappers, such as TensorFlow and Qt, but these too my knowledge aren't easy to integrate high level language support to due to the C++ base. This is not a problem with most other languages that can expose a C API for FFI. You'd have far less issue with Rust than you would if C++ seeps in.

Rust has it's own drawbacks, but I'm more positive about those than the drawbacks of dealing with C++ tbh (which I'm not overly experienced in, I've mostly read about how there's so many footguns that the language itself is quite an investment to learn how to do it right, while Rust is sorta geared with it's own learning curve but far more resistant to you having to learn how to do it right, it'll catch a lot of the problems that C++ wouldn't, I haven't kept up with C++ so maybe tooling has improved there). My experience with C doing embedded work was awful (no std lib available IIRC and I was mostly used to higher level languages at the time), it's how I came across Rust in 2016 and would still prefer it over C or C++.

[polarathene]

Rust can use more RAM, but it's about the same speed as C and the extra safety in Rust is well worth it's negligible costs.

That's configurable afaik? If referring to memory allocator that can be swapped out these days to one that fits your needs more. How memory is arranged for structs is also configurable IIRC, and then we have zero-copy stuff where the language can optimize well.

[zxy_thf]

You don't work on the compiler, you have absolutely nothing to do with LLVM. Rust binaries don't depend on LLVM.
Yet another example of somebody that has absolutely no idea what he is talking about but still decides to complain about it.

It is YOU who have ZERO KNOWLEDGE about how rust works.

$ ldd `which rustc`
linux-vdso.so.1 (0x00007fffe71cd000)
librustc_driver-a65f53cf2e449c04.so => /lib64/librustc_driver-a65f53cf2e449c04.so (0x00007f4547f7e000)
libstd-ce0075fa4a63cdc8.so => /lib64/libstd-ce0075fa4a63cdc8.so (0x00007f4547e7e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4547cb4000)
[B][COLOR=#e74c3c]libLLVM-10.so => /lib64/libLLVM-10.so (0x00007f4542f33000)[/COLOR][/B]
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4542d43000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4542d3c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4542d18000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4542cfd000)
/lib64/ld-linux-x86-64.so.2 (0x00007f454bdb7000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4542bb7000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f4542bac000)
libedit.so.0 => /lib64/libedit.so.0 (0x00007f4542b6f000)
libz.so.1 => /lib64/libz.so.1 (0x00007f4542b55000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f4542b24000)

CAN'T YOU SEE? Or are your ignorant of static linking?

LLVM is the ONLY back-end of rust compiler. This is COMMON SENSE.