Announcement

Collapse
No announcement yet.

"Honeykrisp" Is A New Vulkan Driver For Apple M1 On Linux - Derived From The NVK Driver

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

  • #11
    Looks like it won't be long before applie hardware will just simply work better on linux than their own os lol.

    Comment


    • #12
      One month from starting a fork to getting vulkan 1.3 compliance is insanely productive. It is amazing what talented coders paired with good abstraction can do!

      Comment


      • #13
        All of this is going to become much more important pretty soon if past history keeps as it has.

        Apple won't be supporting the M1s all that much longer any more at this point. M1 probably only has what, 1 or 2 years of support left and then Apple says "buh bye!"

        Comment


        • #14
          Originally posted by ezst036 View Post
          All of this is going to become much more important pretty soon if past history keeps as it has.

          Apple won't be supporting the M1s all that much longer any more at this point. M1 probably only has what, 1 or 2 years of support left and then Apple says "buh bye!"
          M1 easily has 4 years of mainline macOS support and probably a few more years of bugfixes beyond that. No idea where you’re getting the 1-2 year idea from.

          Comment


          • #15
            Originally posted by scottishduck View Post

            M1 easily has 4 years of mainline macOS support and probably a few more years of bugfixes beyond that. No idea where you’re getting the 1-2 year idea from.
            Monterey currently supports 2018 Macs and newer, so 2 years for the last major macOS version to support M1 to release is not totally unbelievable, though it will be another probably ~year before the next version that actually drops M1 will release, and the last supported macOS on M1 will certainly still get security updates for a while. But that's kinda a worst case scenario, since Apple still hasn't dropped x86, and IMHO it's unlikely Apple will drop x86 and M1 at the same time. From a development standpoint, dropping x86 is going to be the real opportunity for large architectural cleanup, while dropping M1 would likely only be useful from a "hope users care enough about dropped support to buy new hardware" standpoint, but the reality is that most users aren't even hardly aware when their OS goes EOL.

            That said, as someone writing this from a work-owned Mac (gotta be able to build/test the iOS version of the app), 100% Linux support can't come soon enough for me. Gnome is just flat out better than macOS, wayyyyyyyyyy fewer papercuts. Daily-driving stock macOS feels like death by a thousand papercuts, and I've had to put what feels like a thousand 3rd-party band-aids just to make the OS almost sane. Finder is still atrocious, no way to fix that without disabling SIP and co which gave a weird error last I tried...

            Comment


            • #16
              Originally posted by scottishduck View Post

              M1 easily has 4 years of mainline macOS support and probably a few more years of bugfixes beyond that. No idea where you’re getting the 1-2 year idea from.
              Hes spreading bullshit

              Comment


              • #17
                Originally posted by dragon321 View Post

                NVK is not even 2 years old and it is already Vulkan 1.3 capable and in some applications it is able to achieve over 50% of proprietary driver performance. Yeah, nice progress.

                I was surprised that NVK serves as base but since it is already quite solid and written in Rust as well the it makes sense.
                Nvk is absolutely not written in Rust (I wish). The nak compiler is but that’s it.

                Comment


                • #18
                  Originally posted by dragon321 View Post
                  NVK is not even 2 years old and it is already Vulkan 1.3 capable and in some applications it is able to achieve over 50% of proprietary driver performance. Yeah, nice progress.

                  I was surprised that NVK serves as base but since it is already quite solid
                  Opinion noted!

                  Originally posted by dragon321 View Post
                  and written in Rust
                  It's written in C.

                  And you already said it's quite solid, in C!!!

                  How does that make you feel, you ignorant Rust shill?

                  Comment


                  • #19
                    In her post she says:
                    For Honeykrisp, let’s follow NVK’s lead and treat all state as dynamic. No other Vulkan driver has implemented full dynamic state and shader objects this early on, but it avoids refactoring later. Today we add the code to build, compile, and cache prologs and epilogs.

                    Putting it together, we get a (dynamic) triangle:
                    And it's super funny to me because I don't know the value of a dynamic pipeline and how difficult it is to implement (I assume very difficult) and her casual "we get a dynamic triangle" is so simple it's funny. Really great work Alyssa! I love reading your blogs and your technical deep dives

                    Comment


                    • #20
                      Originally posted by rmfx View Post

                      Nvk is absolutely not written in Rust (I wish). The nak compiler is but that’s it.
                      Yeah, I confused it with NAK and Nova kernel driver, thanks for clarification.​

                      Originally posted by Weasel View Post
                      Opinion noted!

                      It's written in C.

                      And you already said it's quite solid, in C!!!

                      How does that make you feel, you ignorant Rust shill?
                      Considering the fact that most important code is already written (kernel driver for Apple Silicon GPU and NVK compiler) or is going to be written (Nova kernel driver for NVIDIA GPUs) in Rust quite good actually. I guess less significant code can stay with C when it's running on solid Rust base.

                      Comment

                      Working...
                      X