Announcement

Collapse
No announcement yet.

Mesa Developers Discuss The Possibility Of Rust Graphics Driver Code

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

  • #11
    Originally posted by bug77 View Post
    Tbh this isn't about adding Rust or C++ to Mesa code directly, but rather to Mesa drivers. I think that's a smart approach, if it doesn't pan out, you only have to revert one or two drivers.
    Rereading the thread, there are also desires to use Rust in core parts like GLSL, although a driver is the pragmatic/cautious first step/experiment. Also, Mesa does use a bit of C++ already, though apparently there's still work needed to deal with the C/C++ impedance mismatch.

    Comment


    • #12
      If there is not much c++ api in mesa, then better add rust now, before one has to deal with c++ APIs

      Comment


      • #13
        Originally posted by oleid View Post
        then better add [LANG_B] now, before one has to deal with [LANG_A] APIs
        Adding a high(er) level language like C++ or Rust causes issues when interfacing with it from any other languages. You provided a very good example why both C++ *and* Rust should be kept out of a number of underlying codebases.

        Mesa already has C++ in it so in many cases you would need to go C++ <> C <> Rust to communicate between them. This is messy, fragile, wasteful of resources and will likely also undermine many of Rust's interesting safety mechanisms anyway.
        Last edited by kpedersen; 02 October 2020, 12:59 PM.

        Comment


        • #14
          In my opinion it would be better to focus on improving current drivers than thinking on switching into a newer programming language which will almost mean starting from scratch...

          Comment


          • #15
            Originally posted by kpedersen View Post

            Adding a high(er) level language like C++ or Rust causes issues when interfacing with it from any other languages. You provided a very good example why both C++ *and* Rust should be kept out of a number of underlying codebases.

            Mesa already has C++ in it so in many cases you would need to go C++ <> C <> Rust to communicate between them. This is messy, fragile, wasteful of resources and will likely also undermine many of Rust's interesting safety mechanisms anyway.
            That's disingenuous. Firstly Mesa barely has any C++ code.
            And Rust was pretty much designed to have good compatibility with C code due to most of Mozilla's code being written in C.
            The point is that the code that ends up written in Rust, has a reduced attack surface (even if other attack surfaces still exist), having low attack surface drivers is has been important for like 10 years but little has been done in that direction and this would be a big step.
            Last edited by cb88; 02 October 2020, 01:31 PM.

            Comment


            • #16
              Originally posted by cb88 View Post

              That's disingenuous. Firstly Mesa barely has any C++ code.
              And Rust was pretty much designed to have good compatibility with C code due to most of Mozilla's code being written in C.
              The point is that the code that ends up written in Rust, has a reduced attack surface (even if other attack surfaces still exist), having low attach surface drivers is has been important for like 10 years but little has been done in that direction and this would be a big step.
              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.

              Comment


              • #17
                Originally posted by kpedersen View Post
                The difficulty arises trying to have good compatibility between two higher level languages (C++ <> Rust). .
                Isn't it simple? Do it like librsvg. Require a C API for the outside (i.e. driver/mesa internals) and be done.

                Originally posted by kpedersen View Post
                But my vote is simply keep to homogenous C with everything and just AddressSanitize like hell. It gives a cleaner architecture overall.
                Not really. It means you have to think less about architecture.
                Last edited by oleid; 02 October 2020, 01:43 PM.

                Comment


                • #18
                  Keeping things as is for the time being is an argument I get. Moving to C++ instead of moving to Rust when they are already considering moving? That I don't get. And I'm saying it as a someone who likes C++ in general. But Rust is so much better!

                  Though reading through the comments, most actually agree there that Rust is a better option than C and C++. So outlook is positive in that thread.
                  Last edited by shmerl; 02 October 2020, 02:22 PM.

                  Comment


                  • #19
                    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?

                    Comment


                    • #20
                      Originally posted by ed31337 View Post
                      Yeah, and then when Mozilla implodes and takes down Rust with it, what then?
                      I guess you didn't hear the recent news about Rust being spun off from Mozilla. I personally think they have enough momentum to become their own entity and get funding elsewhere.
                      https://blog.rust-lang.org/2020/08/1...ts-future.html

                      Comment

                      Working...
                      X