[HN Gopher] Asahi Linux project's OpenGL support on Apple Silico...
___________________________________________________________________
Asahi Linux project's OpenGL support on Apple Silicon officially
surpasses Apple
Author : throwaway2037
Score : 326 points
Date : 2024-02-15 15:26 UTC (7 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| BirAdam wrote:
| Honestly, I have been a bit disappointed by Apple. On one hand,
| they make some seriously awesome hardware with amazing
| performance doing tasks like rendering and whatnot. On the other
| hand, they seem incapable of getting awesome performance in other
| areas, the hardware is incredibly locked away from the supposed
| owners of the devices, and the pricing for RAM and storage are
| insane. I don't want to dislike Apple because the hardware is
| great and their stand against US law enforcement on things like
| encryption, but a handful things shatter the experience for me.
| Asahi seems to be solving part of the problem, but the hardware
| being so ... expensive and locked away remains an issue.
| echelon_musk wrote:
| > their stand against US law enforcement on things like
| encryption
|
| Are you referring to the San Bernadino shooter's iPhone?
|
| Because Apple's attempt to introduce CSAM scanning is certainly
| not what I would call a stand against US law enforcement.
| buildbot wrote:
| I imagine they are, as well as the e2e encryption added to
| icloud after they dropped the CSAM thing.
|
| My pet theory is basically a rouge VP started the on device
| scanning project with whatever external org they worked with,
| and basically blindsided the rest of the company. Tim Cook
| probably called the person and was like what the fuck. Or at
| least I'd like to imagine that. I wonder if that VP still
| works at Apple?
| threeseed wrote:
| There is only VP responsible for software and that is Craig
| Federigihi who is still there.
|
| And their leadership team meets weekly so your theory is
| pretty ridiculous.
| stephenr wrote:
| My understanding is that on-device scanning was _meant_ to
| prevent an argument from {government, law enforcement,
| 'think of the children' types} against E2EE solutions.
|
| Apple's solution for a _lot_ of things in general, is to
| favour on-device solutions.
| wkat4242 wrote:
| True but it's really hard to imagine how they ever expected
| the "my own device spies on me by design" to fly. Maybe
| they miscalculated that the "for the children" argument
| would convince the consumer which was obviously a huge
| miscalculation. Even though they clearly thought of
| safeguards so it wouldn't lead to many issues in practice,
| it's just so incredibly wrong at the core that it creeps
| people out just thinking of it.
|
| I can't think of anyone in my circles who would accept
| this. It's just so extremely out of bounds. And I lost a
| lot of respect for Apple as a result considering they
| thought it was ok to propose this.
|
| And it would have been total theater anyway because
| obviously the real offenders would just use something else.
| paulmd wrote:
| one could argue that it _was intended_ not to fly and
| that apple successfully threaded the needle of getting
| E2EE out the door without invoking a legislative response
| on the basis of "think of the children/terrorists".
|
| look at what apple did: they lined up E2EE, got the
| pushback from law enforcement, floated a solution that
| would have accomplished the stated goals, then
| effectively invoked the court of public opinion which
| said "hell no" and then just launched E2EE anyway.
|
| Now we are in the end-state of successfully having E2EE
| without a bunch of backdoors, and the only real victim is
| apple's public reputation with a bunch of android nerds
| who were never going to like them anyway.
| wkat4242 wrote:
| > the only real victim is apple's public reputation with
| a bunch of android nerds who were never going to like
| them anyway.
|
| I don't agree. I have several Apple fan friends whose
| admiration for Apple really dropped. They're still on iOS
| and Mac because they're so invested (walled garden and
| all). But the enthusiasm and deep devotion is gone.
|
| Not just because of that, though it was the first drop.
| But also the recent sideloading malicious compliance
| thing. That deep trust is gone.
|
| I used to be an apple fan too but I already dropped off
| earlier (for want of deciding what I can run on my own
| hardware). So I'm definitely an android nerd. But this
| made waves even inside the Apple camp.
| r00fus wrote:
| > Because Apple's attempt to introduce CSAM scanning is
| certainly not what I would call a stand against US law
| enforcement.
|
| I do. Because they listened to the dissent and changed
| course. CSAM scanning offline on the phone is effectively
| dead.
| astrange wrote:
| Automated CSAM scanning is another Europe thing. The US
| doesn't require it and isn't going to.
| threeseed wrote:
| > Apple's attempt to introduce CSAM scanning
|
| Apple almost certainly has CSAM scanning and has had so for
| years.
|
| They just wanted to move it to your device where it's private
| rather than doing so server side.
| kjkjadksj wrote:
| It feels like the hardware engineers are just marching blind
| making stronger hardware for these computers by the year. Like
| the hardware feels like it has no constraints when you run a
| game. The emulation layers the game has to run through seem to
| limit the fps to 40, but interestingly there is zero
| performance impact to changing graphical settings all the way
| to ultra for many games that are able to run through rosetta.
| This shows there is a ton of headroom available if apple
| developers bothered making it easy for game developers to write
| natively for these computers.
|
| Instead, good faith between apple and third party developers is
| totally burned and not even Valve is writing games for mac
| anymore despite how absurdly performant these devices are,
| especially compared to ten years ago when mac gaming was
| supposed to get its renaissance per apples marketing and the
| good relationships they had with developers back then.
| steveklabnik wrote:
| Are these the Rust-based drivers they've talked a ton about, or
| different ones?
| urschrei wrote:
| These are the Mesa drivers linked from the blog post:
| https://gitlab.freedesktop.org/asahi/mesa, so not Rust AFAICS
| alexlarsson wrote:
| The rust part is in the Kernel
| dathinab wrote:
| yes, rust-based drivers at the core
|
| but also a bunch of other things
|
| like it uses mesa and similar parts of the normal GPU support
| stack
|
| and also involved some kernel patches outside of the rust
| kernel module as far as I vaguely remember
|
| really a grate achievement where in the end rust was like a
| tool to make certain parts easier but all the hard parts are in
| the end unrelated to rust (like reverse engineering, coming up
| with solutions for the many issues of mapping GPU APIs Apple
| doesn't care much about to hardware mainly focused on on just
| Metal etc.)
| neogodless wrote:
| See also:
|
| https://news.ycombinator.com/item?id=39371669 (100+ comments)
|
| _Conformant OpenGL 4.6 on the M1_ (rosenzweig.io)
| larrik wrote:
| I switched to an M1 Air back at the beginning of 2021, was on
| Linux (desktop machine) about a decade before that. It's
| basically purely a work machine (software and management).
|
| The hardware is amazing. The battery life is astounding.
|
| The software, in almost every area, is inferior to my experience
| in Linux. The Apple parts generally worst of all (only Microsoft
| Office on it is worse). In the end, I'm probably 70% as efficient
| on macOS as I was on Linux after 3 years of using it.
|
| The one thing macOS did better than my Linux box, hands-down, was
| supporting a 4k monitor. My Linux install was a little long in
| the tooth, though, so hopefully it's gotten better?
|
| I really look forward to using Asahi when/if it's ready. I'd love
| to go back to Linux.
|
| Example gripes:
|
| - macOS offers this great feature that announces the time every
| half hour (or whatever you set it to). For a year, after a major
| OS update, it just didn't work after reboot unless you went in
| and changed it. Solutions? Wait for Apple to fix it (or write a
| wonky script to fix it on boot, which I did). Eventually they
| did, but ug.
|
| - to support using 3 finger clicks as middle-click I had to _buy
| software_. On Windows this is just built in. On Linux it 's on by
| default.
|
| - to make Spotify work somewhat properly I had to download
| separate software (BeardSpice). After 3 years, I forget what that
| actually does
|
| - if I open Spotify and hit the Play button on my keyboard,
| _Apple Music opens_. (Once I actually play Spotify it fixes it,
| though)
|
| - it took me a LONG time to figure out how to set Excel to open
| CSVs instead of Apple's Numbers app
|
| - The Apple calendar app alerts me whenever I create an event in
| another app (Outlook, Google, whatever). Like I got invited. To
| an event I created. It didn't used to do that...
| kjkjadksj wrote:
| The way these modern macs are set up in terms of permissions is
| really strange and has put some projects on a backburner for
| me.
|
| My latest woe is getting newsboat to refresh my rss feeds
| either as a cronjob or launchd service. On my mojave machine
| this was as trivial as it sounds, either a single line in
| crontab or a single line with some window dressing to make it
| into a launchd plist file then its OK. I try and do this now
| and it doesn't work, since it appears newsboat runs and pulls
| changes but is unable to actually write changes to the cache
| database now.
|
| I have gone down the rabbit hole now of giving full disk access
| to the shell, cron, launchd, launchctl, and the newsboat
| binary, but no dice. I can't get it to work and I can't find
| anything about why this shouldn't work other than permitting
| full disk access. Even then that shouldn't be required because
| the cache.db file sits in the users home directory.
| frizlab wrote:
| Oh that's interesting to me. I've gone deep into the
| automation and stuff on macOS and it really _should_ work...
| Do you have logs?
| zamadatix wrote:
| By 4k monitor do you mean a high DPI monitor? Not much has
| changed in regards to resolution support, that should always
| have been fine, but a lot has changed in regards to high DPI
| support with Wayland now having "real" (direct) fractional
| scaling which makes it even better at approaching the problem
| than macOS which has "fake" (render and scale) fractional
| scaling. KDE Plasma and QT apps (the default desktop
| environment for Fedora Asahi) should support this already, I
| don't remember if Gnome has gotten around to defaulting to the
| newer protocol yet or if it was still experimental.
| jwells89 wrote:
| "Better" still has some asterisks, for example though KDE is
| by far the best of the major DEs in terms of fractional
| scaling support under Wayland, it still has some oddities
| like Aurora window decoration themes not drawing properly
| with fractional scaling, limiting the user to one of a tiny
| handful of C++ window decorations (the overwhelming majority
| are Aurora). GTK apps under KDE can act a bit funny too, with
| e.g. your cursor drawing at 2x when hovering over a GTK
| window.
|
| I deal with these things daily using a Thinkpad with a
| display that requires 1.5x scaling to be usable. Can't wait
| for these issues to be solved and for the asterisks to
| disappear.
| NekkoDroid wrote:
| > GTK apps under KDE can act a bit funny too, with e.g.
| your cursor drawing at 2x when hovering over a GTK window.
|
| Yea, GTK4 to my knowledge until now doesn't support
| fractional scaling, but the new(tm) ngl and vulkan
| renderers should be able to do fractional scaling. If it's
| actually hooked up to do so is another question.
|
| https://blog.gtk.org/2024/01/28/new-renderers-for-gtk/
| larrik wrote:
| Sure, high DPI. I really mean scaling.
|
| On Linux, I plugged in the 4k and everything is tiny tiny
| tiny. I tried to make it a little bigger, and some stuff
| grows, other stuff doesn't, and some stuff just broke. Then
| in the end I was sort of stuck in this weird frankenstein of
| settings that looked like crap on any monitor. Like I said,
| this was over 3 years ago and the Linux install was very old
| at that point (I think it was a Linux Mint based on 18.04 at
| the latest, possibly even 16.04 still).
|
| Mac has a slider that changes the scaling of everything,
| smoothly and all at once.
|
| I probably should have just gotten a bigger 4k
| viraptor wrote:
| This is just a slider in KDE these days. You tried it on an
| ancient system where it wasn't implemented yet.
| Sunspark wrote:
| If using Gnome, only use integer scaling. 100%, 200%, 400%.
|
| KDE will have working fractional scaling for the DE and
| apps using QT and there you can adjust a slider to a % you
| like.
| mavamaarten wrote:
| See but that's exactly the thing, on Mac you can just
| pick a scaling and every scaling option looks flawless
| across the board.
|
| Integer scaling is silly for me: it's either huge or
| tiny.
|
| Yes, KDE does it better and with Wayland you can also do
| fractional scaling. But the original point stands: it
| sucks on (most) linux and works flawlessly on Mac.
| zamadatix wrote:
| It's not that Gnome can't, it's that it's not
| recommended. Gnome actually handles e.g. 150% scaling the
| exact same way as macOS does: render at a higher
| resolution then downscale. The reason it's not
| recommended over integer scales is that's inefficient,
| not that it doesn't work. The same recommendation exists
| on macOS. The difference in quality of life is macOS is
| generally better about assuming a given display should be
| high DPI the first time you use that display (and doesn't
| even show you the tiny options at all by default in such
| cases). So long as you select the same scale things
| should seem identical between Gnome and macOS though.
|
| Windows/Android also use the superior direct render
| approach. The reason you always heard about Windows
| having horrible scaling was due to legacy Windows apps
| not having an understanding of how to use scaling, the
| actual scaling approach itself is very good (and most all
| apps still getting updates should be good by now).
| Scubabear68 wrote:
| It seems a lot of those gripes are about specific apps, or
| simply not understanding that MacOS does somethings
| differently.
|
| By contrast I have never been able to use Linux successfully as
| a desktop OS because there is a dearth of polished commercial
| apps, and the HW compatibility has always been iffy. MacOS
| generally works out of the box with the HW, and the apps are
| generally highly polished.
|
| I caveat the apps as "generally" because there are some turds
| for sure. iTunes and now Music have always been horrible, and
| somehow they managed to make Music even worse than iTunes.
|
| Historically Macs do benefit from 3rd party software (see also
| Alfred), over time the best of it seems to eventually get baked
| into the OS. I don't see that as a downside really.
| Sunspark wrote:
| Linux's desktop experience also lacks polish in a lot of
| areas. It's not a talent or expertise issue, it just comes
| down to lack of resources. You can do a lot of polishing if
| you say here's 50 million dollars and a staff of 50, have at
| it.
| benn0 wrote:
| This x100. I have regularly tried to set up a Linux
| environment, thinking that there really isn't that much of a
| barrier to being productive on Linux, but with the lack of
| polished commercial apps and the hardware quirks I always
| seem to spend more time finding workarounds than actually
| working.
|
| I have found more recently that I can get something
| reasonable (for me) set up, although I'm confident I'll
| always need a Mac nearby to do some things on.
| makeitdouble wrote:
| It's always about specific apps. I need about 10 apps to work
| on my work machine, and if any of them is fighting the OS it
| would be enough to degrade the whole experience.
|
| In the olden days it was having a decent unix comand line
| environment. Windows didn't, osx and linux did, and many of
| us switched. For other it's a good Adobe suite experience.
| For other it will be Excel and Office etc.
|
| I totally sympathise with parent and Apple Music starting up
| every damn time the play button is pressed without a media
| app already started. That's a button I used to press a lot,
| and at some point stopped playing music on mac altogether.
|
| The move to kill kernel extension nullified a lot of the
| historical advantage of the mac: many stuff that was changing
| low level behavior became a lot more unreliable . Having
| keyboard remappings get stuck or unresponsive depending for
| instance.
| Phemist wrote:
| My main gripe - how on vanilla MacOS alt(cmd)-tabbing cycles
| through applications first and then _all their windows_ rather
| than windows first, doing _nothing_ on a per application basis.
|
| I cannot imagine how this matches at all to anyone's workflow.
| Nobody at apple works on a single project across multiple
| applications (documentation in browswr, your IDE, an emulator,
| some terminals, etc.).?
|
| You have to install a specific app and give it some crazy
| permissions to fix those issues. Pfft
| jwells89 wrote:
| Command-` is the shortcut you want for cycling through
| windows within an app, otherwise Expose/Mission Control is
| the layer that can be configured to think in "windows"
| instead of in "applications".
| ace2358 wrote:
| Don't forget to add the shift key to scroll backward
| through the apps or windows.
| monooso wrote:
| Some people prefer Linux (or Windows) to macOS, and that's
| perfectly reasonable. Some of your gripes are a little curious,
| though:
|
| > Solutions? Wait for Apple to fix it (or write a wonky script
| to fix it on boot, which I did). Eventually they did, but ug.
|
| Writing a wonky script to fix something on boot sounds eerily
| like my Linux experiences.
|
| > to support using 3 finger clicks as middle-click I had to buy
| software. On Windows this is just built in. On Linux it's on by
| default.
|
| This could also be phrased as "in some ways macOS works
| differently to Windows and Linux. However, there is a solution
| for those who prefer the Linux way."
|
| > to make Spotify work somewhat properly I had to download
| separate software...
|
| That's Spotify, not macOS.
|
| > if I open Spotify and hit the Play button on my keyboard,
| Apple Music opens
|
| Yes, Apple Music opening for inexplicable reasons is very
| annoying.
|
| > it took me a LONG time to figure out how to set Excel to open
| CSVs instead of Apple's Numbers app
|
| That's just not understanding how macOS works. A 10-second web
| search would have ended your suffering.
|
| > The Apple calendar app alerts me whenever I create an event
| in another app (Outlook, Google, whatever).
|
| That doesn't sound entirely unreasonable to me.
| paulddraper wrote:
| > in some ways macOS works differently to Windows and Linux
|
| No one will disagree.
|
| OP would be a bit more specific, and say "worse."
| jlund-molfese wrote:
| The tone of the community is really different, too--and imo the
| worst thing about the transition from Linux -> OS X. And ok,
| it's not a fair comparison, because Linux users tend to be way
| more technical due in part to the OS family's barriers of
| entry.
|
| Still, it's annoying when you search for how to do something in
| OS X and the first few threads are full of people saying "that
| isn't how it works! Instead of wanting to change it, you need
| to understand and follow the Apple Way(tm)!" You're usually
| able to find the solution after a bit more searching, but the
| Apple Forums are especially bad.
| wtallis wrote:
| If your mental model for how the software works is not an
| accurate abstraction for how it actually functions, you're
| going to be frustrated. If, when confronted with evidence
| that your mental model is inaccurate, you refuse to update
| your mental model, you will have difficulty coming up with
| solutions for the things that bug you, and difficulty even
| asking the right questions.
|
| Being mad at software for operating in a different paradigm
| than you are used to is not productive. This all applies just
| as much to users coming to macOS from Windows (or imitations
| thereof) to macOS as it does to users coming to git from svn.
| tech_ken wrote:
| Okay yes but git and an OS are very different pieces of
| software. One does one thing (version control), and to be
| effective at that single task its highly opinionated. This
| is fine and good; he restriction allows the tool to laser
| focus on being good at a few things. OTOH an OS needs to do
| many very different things, as many different things as
| there are users. Creating a single paradigm, and
| obstructing basic configuration stuff like mouse input
| settings, is the opposite of what you want in this case. An
| OS should be flexible customizable, to allow the user to
| fine-tune it to match their use case needs as closely as
| possible. Just telling an OS user "get with the program"
| kind of misses the point, IMO. I prefer OSs which meet my
| needs, rather than the other way around.
| wtallis wrote:
| You may wish to note that I'm explicitly _not_ telling
| the OS user to just "get with the program". I'm telling
| the OS user that they need to understand the OS before
| they can effectively modify it to suit their needs.
| tech_ken wrote:
| > Still, it's annoying when you search for how to do
| something in OS X and the first few threads are full of
| people saying "that isn't how it works! Instead of
| wanting to change it, you need to understand and follow
| the Apple Way(tm)!"
|
| > Being mad at software for operating in a different
| paradigm than you are used to is not productive. This all
| applies just as much to users coming to macOS from
| Windows (or imitations thereof) to macOS as it does to
| users coming to git from svn.
|
| I guess I can see how you intended your comment to mean
| what you're saying, but reading these two comments in
| sequence I think one can understand my confusion. You may
| wish to directly say what you mean, rather than speak in
| glib generalities.
| wtallis wrote:
| I don't think I'm the one being glib here. I'm trying to
| both illustrate that there's a problem that truly is
| general and not specific to macOS, and trying to make the
| fine distinction between telling users to understand and
| suck it up vs telling users to understand so that they
| can better figure out how to get what they want. That
| latter distinction is what you seem to be having more
| trouble with.
| tech_ken wrote:
| Okay good talk
| michaelcampbell wrote:
| I'm reminded of a saying... The reasonable man expects to
| change to fit in the world. The unreasonable man expects
| the world to change around him.
|
| Thus, all progress is made by unreasonable men.
| (Paraphrased)
|
| > Being mad at software for operating in a different
| paradigm than you are used to is not productive.
|
| Indeed, it is often the ONLY thing that causes progress.
| wtallis wrote:
| The "unreasonable men" who come up with better solutions
| are usually the people who have the deepest understanding
| of what is wrong with the status quo. I don't think the
| people who refuse to understand the problem are usually
| coming up with good solutions.
| curt15 wrote:
| I still remember the apologists (circa 2011) trying to
| justify OS X's system-wide autosave feature when it came out
| despite its obvious pitfall -- users could make inadvertent
| edits to their documents without noticing. When users pointed
| out that Apple's own XCode didn't adopt that feature, the
| apologists' excuse was simply "IDEs are different".
| ace2358 wrote:
| What?
|
| Autosave also has versioning. You can always go back
| through the auto save history. You can also revert to the
| original opened file. This is done from the file menu.
|
| Also, if like a good mac user you have Time Machine
| configured and on, you can browse your versions further
| into the past.
|
| Heavy iWork user, I don't know about Xcode though.
| breather wrote:
| Meanwhile linux keybindings appear stuck in the 80s
| shrimp_emoji wrote:
| How? They exist and they're customizable, unlike Windows's.
|
| And I'll bet you you can't bind xkill to Ctrl-Alt-Esc, and
| your cursor turns into a little skull-and-crossbones, and
| whatever you click immediately vaporizes via a SIGKILL, on a
| Mac. :p
| breather wrote:
| I'm referring specifically to the use of ctrl as a primary
| key for both the shell and the ux. How did this happen?
|
| Anyway, keybindings are certainly changeable if you're
| ready to dive into a hundred distinct projects each
| defining their own key handling. There's no truly system
| wide way to alter system keybindings in any meaningful
| sense.
| sunshowers wrote:
| On balance, I really like that Ctrl is overloaded in that
| way. Means that Super/Win/Cmd can be used for a wide
| variety of things on top.
|
| For example, I use Super for tiling window management,
| launching programs, and other things. On macOS, with
| Yabai and skhd, you can't use plain Cmd to do that.
|
| Overloading Ctrl has downsides, but I think it is a net
| benefit overall.
| kps wrote:
| It happened because Windows adopted IBM CUA, and the
| 'desktop Linux' crowd had a fetish for copying Windows.
| Before that, X11 programs were typically fully
| configurable, with key bindings in X resources.
|
| Currently I think KDE is the least-bad option, as common
| shortcuts can be remapped globally, but it could be a
| _lot_ better -- Qt can universally remap 'Control'
| shortcuts to the GUI key, but it 's only available on Mac
| builds.
| opan wrote:
| Tiling WMs tend to make heavy use of the super key. I would
| hate to lose all my keybinds because of copy/paste and such
| moving. I do think the macOS approach is conceptually cool
| (emacs/readline binds everywhere is neat) and makes sense,
| but I also hate actually using macOS, especially window
| management stuff. I guess if there were a way for people to
| have it both ways, all would be well.
| benn0 wrote:
| I'm trying to manage working on both Linux and MacOS, and
| this has been the number one frustration. Fortunately,
| toshy.app (as well as into) exists and does a pretty great
| job at mapping shortcuts to match MacOS.
| askonomm wrote:
| Your list sounds more like app related things rather than OS
| related things to be honest. Also, contrasting your issue list
| with the issue list of Linux, where Wayland barely works, audio
| issues are constant, the whole system is so delicate that an
| automatic update can easily brick the OS, 10 different ways to
| install apps leading to no consistency at all (flatpak, snap,
| .tar.gz, AppImage, native binary, apt-get, software center
| ...), makes MacOS sound really great.
| koiueo wrote:
| Your list sounds more like Ubuntu related, rather than Linux
| related to be honest.
| BodyCulture wrote:
| You must be doing something wrong. I have zero problems with
| Linux updates since many years.
| 12345hn6789 wrote:
| Those are all issues with Ubuntu. Switch to arch
| tech_ken wrote:
| Upside: better than Ubuntu. Downside: wait too long to
| update and your computer is headed for the shadow realm.
| mavamaarten wrote:
| MiddleClick is a free app that brings middle click
| functionality: https://github.com/artginzburg/MiddleClick-
| Sonoma
| btown wrote:
| One of the coolest things (IMO) about the entire Asahi effort,
| and why I'm not at all surprised that they surpassed Apple, was
| the dedicated effort to build bespoke developer-friendly Python
| tooling early in the reverse engineering process.
|
| https://asahilinux.org/2021/08/progress-report-august-2021/
|
| > Since the hypervisor is built on m1n1, it works together with
| Python code running on a separate host machine. Effectively, the
| Python host can "puppeteer" the M1 and its guest OS remotely. The
| hypervisor itself is partially written in Python! This allows us
| to have a very fast test cycle, and we can even update parts of
| the hypervisor itself live during guest execution, without a
| reboot.
|
| > We then started building a Python implementation of this RPC
| protocol and marshaling system. This implementation serves a
| triple purpose: it allows us to parse the DCP logs from the
| hypervisor to understand what macOS does, it allows us to build a
| prototype DCP driver entirely in Python, and it will in the
| future be used to automatically generate marshaling code for the
| Linux kernel DCP driver.
|
| Code here:
| https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/m1n...
|
| If you watch any of Asahi Lina's streams from the time before
| they had their full drivers implemented in Rust, she's able to
| weave together complex bitflag-manipulating pipelines at the
| speed of thought with self-documenting code, all in Python
| running on the host machine, all while joking with viewers via
| her adorable avatar. I've never seen anything like it before. The
| whole workflow is a tremendous and unprecedented accomplishment
| by the entire Asahi team.
| panick21_ wrote:
| I really like this talk by Bryan Cantrill on tool making.
|
| https://www.p99conf.io/session/sharpening-the-axe-the-primac...
| jjice wrote:
| I completely agree, this is a great talk. I can listen to
| Bryan and friends speak for hours. I'm not sure if he's a
| natural story teller or if he's learned over time, but that
| combined with his experience just makes for a treat.
| binsquare wrote:
| Watched asahi Lina's stream and her ability to multitask while
| working on an what appears to be a very delicate problem is
| incredible.
| notyoutube wrote:
| Mmh, is that a similarity with postmarketos? I have a fuzzy
| memory that pmbootstrap or some other tool was kind of
| important to start porting to new devices?
| gyomu wrote:
| Knowing how to build effective scaffolding, in the right
| sequence, that continuously enables tighter and faster
| iteration loops on a project is a huge meta-skill that
| contributes to why the high end of experienced engineers are
| orders of magnitude more effective than others.
| Aurornis wrote:
| The original article ( https://rosenzweig.io/blog/conformant-
| gl46-on-the-m1.html ) has more details.
|
| The important part to note is that the M1 hardware doesn't map
| well to newer OpenGL standards because Apple deprecated OpenGL in
| 2018:
|
| > Regrettably, the M1 doesn't map well to any graphics standard
| newer than OpenGL ES 3.1. While Vulkan makes some of these
| features optional, the missing features are required to layer
| DirectX and OpenGL on top. No existing solution on M1 gets past
| the OpenGL 4.1 feature set.
|
| > How do we break the 4.1 barrier? Without hardware support, new
| features need new tricks. Geometry shaders, tessellation, and
| transform feedback become compute shaders. Cull distance becomes
| a transformed interpolated value. Clip control becomes a vertex
| shader epilogue. The list goes on.
|
| OpenGL has been officially deprecated since macOS Mojave (2018),
| so it shouldn't come as a surprise to anyone that in 2024 the
| hardware doesn't map well to newer OpenGL features. The media
| narrative is trying to push this as an "outdoing Apple at their
| own game" thing, but Apple very clearly stopped supporting OpenGL
| and did so with advance warning years ago.
|
| That said, it's an impressive accomplishment that they managed to
| translate the newer calls into compute shaders and other tricks.
| It's very impressive work.
| wkat4242 wrote:
| They shouldn't have deprecated OpenGL though. It's really
| important for desktop software. Several games have lost Mac
| support due to this like elite dangerous.
|
| Of course they push metal but that's not interesting to desktop
| developers.
| selectodude wrote:
| OpenGL itself has been depreciated for almost 7 years now. I
| won't wade into Vulkan vs Metal but depreciating OpenGL seems
| pretty reasonable to me.
| pests wrote:
| It's a little different from depreciating since OpenGL was
| still impented and available on non-M Mac.
| jijijijij wrote:
| > The media narrative is trying to push this as an "outdoing
| Apple at their own game" thing
|
| Big Linux at it again, eh?!
| dang wrote:
| Discussed yesterday:
|
| _Conformant OpenGL 4.6 on the M1_ -
| https://news.ycombinator.com/item?id=39371669 - Feb 2024 (103
| comments)
| psanford wrote:
| I love this work, but I will point out that the Asahi GPU driver
| still struggles on certain real world workloads.
|
| The one I run into quite often is that Google Maps will hang for
| long periods of time. This is a known issue and they are working
| on it, so I'm sure it will be fixed sometime this year.
| paulmd wrote:
| wouldn't surprise me if google maps had some obscene amount of
| drawcalls instead of proper culling/"LOD"
| psanford wrote:
| From the gpu issue tracker[0]:
|
| > For a bit of context -- Google Maps loads images to the GPU
| at.. inopportune times. While games would typically load
| their images during a load screen (so slow image loading just
| means longer loading screens), Google Maps loads when
| scrolling around I think (so slow image loading means the
| whole map stutters). I don't think there's a fundamental
| driver bug we can fix here, but we can make image loading a
| lot faster which makes the symptoms go away.
|
| [0]: https://github.com/AsahiLinux/linux/issues/72#issuecomme
| nt-1...
| whitehexagon wrote:
| 6 years ago I said I'd never give apple another cent, but the
| Asahi Linux project, and especially their efforts around OpenGL,
| or more specifically their ES 3 support, finally convinced me to
| pick up a secondhand M1 last month. Amazing work by the team!
|
| I wonder if one day the USB4 ports will be able to fully support
| USB3, so confusing.
|
| Anyway I haven't felt the need to boot macos so far :) and the
| installation was a breeze, big thanks to the team.
|
| As a bonus the unified memory allowed me to get an LLM running
| locally, but I suspect it is CPU bound and probably not using the
| new GPU driver.
| blastersyndrome wrote:
| I thought Asahi Linux's sole developer didn't allow discussion of
| his project here? I remember there being quite a lot of fallout
| from that, what happened?
| larvaetron wrote:
| > didn't allow
|
| How would he even enforce this?
| chippiewill wrote:
| IIRC it was if you link directly to the Asahi Linux website
| then a bit of javascript picks up the HN referrer and blocks
| viewing the page.
| blastersyndrome wrote:
| for a short time, he was monitoring the referral header and
| made his website display an offensive message if you clicked
| the link from HN.
|
| HN's mods then edited links to his domain so they would emit
| the referral header, and he responded by implementing a
| browser exploit to detect if certain HN URLs were in your
| browser history.
|
| In any case, I apologize for using the wrong wording.
| E39M5S62 wrote:
| How can someone forbid discussion of something on a site they
| don't own/control?
| ZekeSulastin wrote:
| They can't forbid discussion but they can try to make it so
| people visiting from HN can't see the page; they aren't the
| only ones, either, as the poster upthread mentioning jwz's
| image redirect noted.
| nozzlegear wrote:
| Everyone else is asking how they wouldn't allow discussion on
| HN, but I'm more interested in _why_ they don't want discussion
| on HN?
| RobotToaster wrote:
| Someone here pointed out that one of the developers on the
| project is actually the primary developer's vtuber persona.
|
| That's literally it.
| cobertos wrote:
| Probably just not wanting to deal with the unsavory side of
| the lurking userbase on HN or the poor, ill-informed
| discussion on sensitive/political topics? There are certain
| things HN is not good at talking about
|
| There are multiple people I've seen express this in-desire
| towards HN
| pests wrote:
| Someone in the project considers HN not a safe-space for
| queer viewpoints / racist / homophobic.
|
| I am very much at a loss as well as this has never been my
| experience.
|
| A lot of the arguments started with "when you enable
| showdead, there's lots of dead comments of people being
| vile".
|
| Just not sure what to say.
| squigz wrote:
| Here's some context [0]
|
| Indeed, it does often boil down to dead comments being...
| not great, unsurprisingly.
|
| [0] https://news.ycombinator.com/item?id=36226845
| zamadatix wrote:
| Asahi Linux has many developers, the author of this driver
| (Alyssa Rosenzweig) isn't even the lead developer (Hector
| Martin).
| dylan604 wrote:
| Just the thought of how to prioritize things in all of the
| reversing is enough to make me overwhelmed. Have they talked
| about how they prioritize?
|
| "Asahi's most recent update blog post, published in mid-January,
| highlighted HDMI support, support for DRM-protected websites via
| Google's proprietary Widevine package, Touchbar support for the
| handful of Apple Silicon Macs that use one, and more."
|
| Seems odd to me that a Linux open source focused something would
| spend so much effort on supporting DRM over USB3 functionality.
| So for them to go that direction implies to me they have good
| reasons. Are they trying to satisfy users? My knee jerk reaction
| would be the users willing to use this would be accepting of not
| supporting DRM.
| chippiewill wrote:
| The Asahi team isn't some monolithic corporation with a
| prioritised backlog.
|
| The skillsets and amount of work involved in getting Widevine
| working (quickly porting the binary from ARM64 ChromeOS) vs USB
| 3 (reverse engineer Apple's unique undocumented implementation
| and write a Linux kernel driver for it) are completely
| different.
|
| It's open source, if someone volunteers a Widevine
| implementation for Asahi then the maintainers aren't going to
| say no.
|
| Generally speaking Alyssa does GPU reverse engineering, Marcan
| does the other hardware reverse engineering, Asahi Lina writes
| the GPU driver and everyone else does various miscellaneous
| bits (like userspace binaries).
| HeWhoLurksLate wrote:
| for one data point, I'd _much_ rather have DRM supported than
| USB 3 support- one lets me do casual things and use my machine
| while I relax or do whatever, and for _most_ USB 3 devices I
| can just suck it up and wait for a file transfer, or do what I
| normally do and work off of my NAS.
| Sunspark wrote:
| Apple should embrace this if the project is in need of reference
| materials.
|
| Apple is a hardware company primarily, so if someone buys their
| hardware because it will be compatible with an OS they may like
| more, that's still a sale for Apple. No funds are lost, because
| MacOS doesn't charge for a new install on Apple hardware.
| palata wrote:
| I really love the project, but I would guess that Apple just
| doesn't care because it's not bringing enough profit for them
| to care.
| overstay8930 wrote:
| Apple does not want to be a hardware company, in fact when they
| sell lots of hardware their stock price goes down. If they
| can't charge a monthly fee for it, they're not doing it.
| Juicyy wrote:
| Only 20-25% of Apple's revenue is services. about 50% is
| iPhone about 8% for Mac and 8% for iPad. They're a hardware
| company.
| threeseed wrote:
| Apple has always been a hardware _and_ software company.
|
| Nobody is buying the iPad or iPhone because it has better
| specs. Most don't even know how much memory they have.
|
| It's because of the OS, apps, ecosystem etc.
| pockmockchock wrote:
| using Asahi on my m2 for a year now and it's awesome, the install
| is straight forward my grandmother could do it. also love the
| rolling releases.
| tiffanyh wrote:
| Source post: https://rosenzweig.io/blog/conformant-gl46-on-
| the-m1.html
| johnmaguire wrote:
| > Rosenzweig's blog post didn't give any specific updates on
| Vulkan except to say that the team was "well on the road" to
| supporting it. In addition to supporting native Linux apps,
| supporting more graphics APIs in Asahi will allow the operating
| system to take better advantage of software like Valve's Proton,
| which already has a few games written for x86-based Windows PCs
| running on Arm-based Apple hardware.
|
| Does anyone know whether these improvements will also help with
| gaming on macOS? I assume that Mac ships its own driver without
| these APIs, but e.g. will Proton for Mac or Whisky (Wine for Mac)
| be able to make use of them?
___________________________________________________________________
(page generated 2024-02-15 23:01 UTC)