Announcement

Collapse
No announcement yet.

Asahi Linux Continues Making Progress On Apple Silicon Graphics, Promising OpenGL Speed

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

  • #11
    Tim Cook's death camps literally suck the life out of those who build their products. If workers don't work hard enough on their 16 hour days, they end up as involuntary organ donors. It still amazes me that people do not see the slavery behind Apple products.

    Comment


    • #12
      Originally posted by Vorpal View Post

      Do you have proof or a citation for that claim?

      Don't get me wrong: I'm no fan of Apple, but I'm even less of a fan of baseless claims.
      No proof or citation, I don't remember the details too well since driver/graphics programming a bit over my head, but they specifically engineered M1 to not have some standard features/optimizations that OpenGL and Vulkan take advantage of, but Metal doesn't.
      Not so much "explicitly neglecting to optimize" as it is just not supporting a feature they don't use, but you have to admit it sounds pretty intentionally baked into the design of M1 and Metal.

      Comment


      • #13
        Originally posted by Developer12 View Post
        completely missed in the article: the M1 GPU driver is now revolutionary in *two* ways, no longer one

        Previously it was merely one of the first drivers written in rust. Now it stands as one of only two drivers to be exclusively explicit-sync, while being the furthest ahead.

        Every other driver in mesa, with the exclusion of intel xe, is forced to support implicit sync and all of the performance-killing bookkeeping that comes with that. Along the way they've encountered and solved significant issues the intel team weren't even aware of.
        Pretty much every other driver does support explicit sync and can bypass implicit sync if userspace supports it.. and this is done in some environments (for ex, android). Supporting implicit sync in the kernel isn't that big of a deal, there are helpers for that. Emulating it in userspace amounts to the same thing so implicit sync window systems like x11 aren't going to see any benefit. If I were starting from scratch (ie. post 6.0 kernel) I'd probably take the same approach of forcing userspace to deal with emulating implicit sync to avoid dealing with it in the kernel, and xe seems to be (rightly) taking the same approach. But you still have to deal with it somewhere, so this is really just shuffling the implicit sync problem from one place (kernel) to another (userspace).

        Comment


        • #14
          Originally posted by anarki2 View Post
          There's a difference between not putting effort into making it fast, and deliberately making it slow.
          This is true. One costs more money. Which that is depends on the market.

          Of course, the end result is the same.

          Comment


          • #15
            Originally posted by robclark View Post

            Pretty much every other driver does support explicit sync and can bypass implicit sync if userspace supports it.. and this is done in some environments (for ex, android). Supporting implicit sync in the kernel isn't that big of a deal, there are helpers for that. Emulating it in userspace amounts to the same thing so implicit sync window systems like x11 aren't going to see any benefit. If I were starting from scratch (ie. post 6.0 kernel) I'd probably take the same approach of forcing userspace to deal with emulating implicit sync to avoid dealing with it in the kernel, and xe seems to be (rightly) taking the same approach. But you still have to deal with it somewhere, so this is really just shuffling the implicit sync problem from one place (kernel) to another (userspace).
            The important bit is that by shuttling it into userspace *only* userspace has to worry about it.

            It no longer has to be dealt with on both sides, which means not being involved in the uAPI and it's eternity-plus-one-day stability guarantees.

            Comment


            • #16
              Good job and fuck Apple and their share holders for being so backwards and not embracing Linux support OOTB. Shame on you wankers

              Comment


              • #17
                Lina is currently livestreaming some x86 Steam games (via Fex) with the new GPU drivers under Asahi:

                Hello everyone, Asahi Lina here! It's time for what you've been waiting for!! Can we get Steam running on the M1 GPU?In order to run Steam and Proton, we nee...


                I haven't been watching, alas, but I think I saw in the chat that "Portal" had been found to work ... ?

                Edit: Now playing - "World of Goo"

                Comment


                • #18
                  but can it run Crysis? (i think it's OpenGL so maybe it actually can!!!)

                  anyway, doing a beter job than MacOSX on Apple hardware is awesome and the fact that this is partially due to Apple deprecating OpenGL on their OS is not really detrimental to how awesome this is

                  it proves an opensource OS that's not gatekeeped by a single company can do better than Apple's flagship "only if I am totally in control of your device and you aren't can it be such a great device" OS thesis

                  Comment


                  • #19
                    Originally posted by marlock View Post
                    but can it run Crysis?
                    Not yet

                    Originally posted by Lina
                    I also tried Crysis but it hangs at 100% after the loading screen for some reason, though the main menu was very smooth too ^^;;

                    Thank you everyone who sent me game gifts so I could try them!!!
                    Edit: No idea why the heart emoji is so humungous, but I'm not removing it

                    Comment


                    • #20
                      Originally posted by Developer12 View Post

                      The important bit is that by shuttling it into userspace *only* userspace has to worry about it.

                      It no longer has to be dealt with on both sides, which means not being involved in the uAPI and it's eternity-plus-one-day stability guarantees.
                      Yeah I don't see what point he is making in his argument. Shifting it to userpsace is a good thing because you don't want these slow overhead workarounds on the driver level/kernel space. The fundamental issue with Linux wrt implicit/explicit sync is that part of its core in kernel graphics stack/drivers is still dealing with implicit sync. We will always have to deal with implicit sync somewhere, but the ideal situation is that we only deal with it in userspace.

                      Comment

                      Working...
                      X