[HN Gopher] Vulkan1.3 on the M1 in one month
___________________________________________________________________
Vulkan1.3 on the M1 in one month
Author : todsacerdoti
Score : 795 points
Date : 2024-06-05 15:11 UTC (1 days ago)
(HTM) web link (rosenzweig.io)
(TXT) w3m dump (rosenzweig.io)
| dagmx wrote:
| Very impressive work, and a great testament to the value of
| shared, iterative and open components.
|
| I'll be curious how long it takes Proton to be ported, though I
| suspect even with an optimal Vk implementation, many games will
| run terribly due to the difference in GPU architecture + arm
| translation overhead + proton itself (however negligible).
|
| Still, I remain optimistic that more games will target unified
| memory and ARM in the future on desktops, as SoCs become more
| prevalent like the snapdragon.
| rowanG077 wrote:
| A ton of games which don't require dxvk are running at 60+ FPS.
| See https://vt.social/@lina/112524118075585601
|
| Alyssa, the machine that she is, has also been working on
| improving FEX performance recently.
| ricardojoaoreis wrote:
| Alyssa did some work for Valve, they might have an interest
| in FEX for some ARM version of Proton.
|
| Good thing that we can all benefit from it
| elabajaba wrote:
| She left Collabora last year and now works for Valve as a
| contractor.
| talldayo wrote:
| There will be a small bit of irony if the gaming experience on
| Asahi ends up easier and more straightforward than MacOS.
|
| Really just drives home how big of a mistake it was ignoring
| Vulkan for the past decade on Apple's behalf, but lord knows
| they won't admit that until it's too late.
| rowanG077 wrote:
| Why would that be ironic. Apple wilfully is holding gaming
| back on OSX by ignoring Vulkan and having a pure shit opengl
| implementation.
| bilbo0s wrote:
| You may have a good point with the opengl thing. But the
| number of games that run on Vulkan is so vanishingly small
| that we can't credibly say that not having a Vulkan driver
| holds Apple back on gaming. I'd bet any money that the
| number of games that work on Metal is wayyyy higher than
| the minuscule number of games that run on Vulkan. Which
| should tell you how few Vulkan games there are.
| talldayo wrote:
| > But the number of games that run on Vulkan is so
| vanishingly small
|
| Really? 7 out of the 10 most popular games on Steam work
| fine if you have Vulkan 1.3 drivers:
| https://www.protondb.com/explore?sort=playerCount
| dagmx wrote:
| of the top 10, I count 3:
|
| Counter Strike 2 Dota 2 Stardew Valley
|
| How are you getting 7/10 unless you're also counting
| games that happen to run under Proton, which aren't
| native? And regardless, that's a really small sample size
| to extrapolate from, when it's easy to get a more
| extensive list that is around ~250 games total.
|
| https://www.vulkan.org/made-with-vulkan
| https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games
|
| Of which, a massive percentage are based on engines that
| have Metal support as well.
| talldayo wrote:
| I'm sorting by playercount, which seems to be
| corroberated here: https://steamcharts.com/top
|
| I am counting Proton games because they very explicitly
| are supported by sufficient Vulkan coverage. In case you
| weren't paying attention that's kinda the only reason
| anyone cares about Apple Silicon getting Vulkan 1.3
| coverage in the first place.
|
| > when it's easy to get a more extensive list that is
| around ~250 games total.
|
| You're right, when we push it out to 1000 titles it gets
| closer to 80% playable:
| https://www.protondb.com/dashboard
|
| > Of which, a massive percentage are based on engines
| that have Metal support as well.
|
| ...yeah, you keep telling yourself that. One day, they'll
| _definitely_ flip the switch on MacOS support. Certainly.
| dagmx wrote:
| Okay, so you're counting non-native games when the
| discussion is AGAIN clearly about native games. If we're
| talking about translation layers, then it's irrelevant
| because Whisky/Crossover can run them as well.
|
| This is just you being completely disingenuous now and
| purposefully avoiding the actual point of the discussion.
| talldayo wrote:
| This was never about native games. It would be very
| convenient if Proton didn't exist and native games were
| the only playable option, but in many cases Proton titles
| run better than native Windows. It's an equivalent, if
| not superior, experience.
|
| It would be a lot more disingenuous if the Steam Deck
| didn't exist and Linux gaming was a farce. But... it's
| not. And the only thing stopping Apple from enjoying the
| same spoils is a little bit of humility.
| tracker1 wrote:
| I think it's absolutely fair to count games that are able
| to run in Linux with Proton via DXVK + Vulcan. Since it's
| well established and relatively popular thanks to Valve's
| efforts with the Steam Deck and Proton.
|
| Given those efforts, if Apple/Mac had support for Vulkan,
| Valve would probably make it all just as available on Mac
| as they do on Linux for Proton.
| robertlagrant wrote:
| Well - they might. I don't think Valve would hate being
| the gaming gateway for Mac as well as for PC, but they
| have great Linux support because of the Steam Deck.
| talldayo wrote:
| If I'm not mistaken, supporting MacOS with Proton was the
| implicit plan before Apple disabled 32-bit support in
| Catalina. Several people seem to have gotten early builds
| to compile on Mac with usable performance:
| https://github.com/ValveSoftware/Proton/issues/1344
| vilunov wrote:
| Even with Vulkan support on macOS it would be harder for
| Valve to make many games accessible as they do on Linux -
| unlike Linux, macOS does not support running 32-bit
| binaries anymore.
| guipsp wrote:
| You'd be correct a few years ago, but not anymore. WOW64
| mode is pretty good nowadays.
| rowanG077 wrote:
| Dxvk is notoriously bad on moltenvk. I have tried and
| have completely given up running it.
| jeroenhd wrote:
| The amount of games that work with Vulkan may be very
| small, but at least they have a chance of working. The de
| facto standard API for games on computers, DirectX, will
| never receive a port.
|
| If you think Vulkan support for games is insignificant,
| look at Metal support.
|
| I think Vulkan makes a lot of sense for macOS, actually;
| the Nintendo Switch, to which tons of games have been
| ported already, uses the ARM+Vulkan design and has a
| relatively weak GPU (but much weaker, as it's very old).
| It's not quite native, but a lot of supporting libraries
| that work on the Switch will also work on Mac. Everyone
| is talking about porting Windows games to Mac, but with
| the way things are developing, porting Switch games to
| Mac may actually make more sense, assuming Nintendo's
| promises for the upcoming Switch replacement are to be
| believed.
| troupo wrote:
| > If you think Vulkan support for games is insignificant,
| look at Metal support.
|
| Metal is supported on iOS. You know, one of the largest
| gaming platforms in the world.
| philistine wrote:
| THE largest gaming platform in the world. Users, sales,
| number of games, hours played.
|
| I challenge you to find one metric where the iPhone isn't
| number one.
| talldayo wrote:
| > I challenge you to find one metric where the iPhone
| isn't number one.
|
| Enjoyable gaming experiences?
| amlib wrote:
| And yet most popular games on phones (both ios and
| android) are complete shit full of predatory practices
| with appalling gameplay and simple graphics, which barely
| benefit from those fancy graphics API anyway and could be
| reworked within weeks to use any other API.
|
| I do know apple is trying to push for AAA games on iphone
| but so far its a small drip on a giant cesspool.
|
| If you want actual good games, be it indies, AA or AAA,
| you go for one of the three consoles, windows or steam
| deck/linux.
| guipsp wrote:
| Not true on either users, number of games, or hours
| played.
|
| Remember, android exists, and supports vk.
| pjmlp wrote:
| Only since version 10, as required API, it was optional
| between Android 7 and 10, and unless you are into Samsung
| or Google Pixel Android phones, good luck.
| Dylan16807 wrote:
| What happens if we exclude games that could run in a
| browser canvas with no webgl support? They don't really
| benefit from the API choice.
| flohofwoe wrote:
| > The de facto standard API for games on computers,
| DirectX, will never receive a port.
|
| Apple did just that with the Game Porting Toolkit.
|
| > If you think Vulkan support for games is insignificant,
| look at Metal support.
|
| Pretty much all iOS games run on top of Metal.
| dagmx wrote:
| Vulkan would likely not really have helped macOS gaming in
| any form. I consider it a red herring that people point to.
|
| The number of games that run natively on Vulkan is
| negligible. The number of games that run on Metal by
| comparison (natively) is orders of magnitude higher.
|
| If we're ONLY talking about the ability to use Proton, Apple
| does now have Game Porting Toolkit that does effectively the
| same thing with comparable performance characteristics if you
| take out the other contributing overhead elements.
| talldayo wrote:
| You can't ship Game Porting Toolkit with your game, though.
| DXVK doesn't have this limitation, and developers use it
| all the time. In effect, this means the number of games you
| get with native Vulkan coverage is a magnitude higher than
| the _total sum_ of all Metal-native desktop titles.
| dagmx wrote:
| This isn't completely true. Crossover is allowed to ship
| the GPTK components for API translation (which they
| currently do as of 23.5) and games are allowed to embed
| Crossover elements like they did in the pre-Metal days
| with Cider etc.
|
| All this talk of DXVK doesn't explain why games based on
| engines with native metal support aren't on a Mac either.
| talldayo wrote:
| Crossover is a paid product, and even then has pretty
| poor DX12 support compared to Proton. Up until a couple
| years ago it didn't work at all.
|
| Again; if Apple had just supported Vulkan alongside Metal
| like a normal non-paranoid company, their users wouldn't
| be caught in the middle of this. It's such a blatantly
| obvious solution with no user-facing downsides. It's
| shocking that anyone would defend the status-quo when
| it's so notoriously and obviously broken.
| dagmx wrote:
| Your assertions aren't backed by history though.
|
| Prior to metal and Vulkan, many games used Cider to
| target Mac despite having the same APi (at that point, an
| up to date OpenGL).
|
| And many of the current game devs do have Metal versions
| of their engines that they target towards iOS, yet don't
| have a macOS version.
|
| The fact of the matter is that it comes down to market
| share. Macs have historically not had a large user base
| that also had capable GPUs. It's not been worth
| supporting that tiny market share
|
| It's the same on Linux. Why are there so few Linux native
| games? The argument that Vulkan would have solved this is
| completely incongruent with the reality of the state of
| gaming.
|
| This will inevitably go back to "well at least we could
| have used proton" but that's also not true, and besides
| there's GPTK. And then the argument becomes circular ,
| because all evidence points to: devs just don't care
| about Mac's from a support perspective. You can make it
| easier, they still won't come until the possible
| demographic size is larger.
|
| and even with DXVK, what about all the other platform
| specific differences? Vulkan wouldn't solve those either.
| talldayo wrote:
| I mean I owned a Mac back then, I remember pretty fondly
| that pre-Catalina MacOS was a fairly well-targeted
| platform. OpenGL was working for them; you could play
| first-person shooters, online games with fancy graphics,
| the kit and kaboodle. Things weren't _perfect_ , but
| there was a lot of functional cross-platform software
| back when Apple commit to maintaining common APIs. You
| cannot deny that an entire ecosystem of software that was
| _once_ cross-platform had to now choose sides, if they
| would support Metal or OpenGL. I watched it collapse with
| a single system update.
|
| > Why are there so few Linux native games? The argument
| that Vulkan would have solved this is completely
| incongruent with the reality of the state of gaming.
|
| My brother in Christ, the "reality of the state of
| gaming" is that Mac owners are buying Steam Decks just to
| access the games Apple tries to kneecap. Vulkan fixed it,
| and Valve commoditized Apple's compliment.
|
| I don't _want_ things to be this way. I think Mac owners
| should have easy access to the games they want to play,
| but Apple insisted otherwise for _so long_ and refused to
| ever admit that they were wasting their time. It 's part
| of the reason I got rid of my Mac so I could daily-drive
| Linux; they were wrong, and other platforms were right.
| dagmx wrote:
| Go back and see how many of those games were running
| Cider though. The switch to kill 32-bit games killed more
| games than the deprecation of OpenGL did. The number of
| games that targeted OpenGL was ALSO shockingly low.
|
| This is something that OSS fans do not want to reconcile:
| Open source graphics APIs have LONG lost out to
| proprietary graphics APIs in gaming. OpenGL had a very
| small base in games, Vulkan is even smaller.
|
| and again, you went exactly back to where I knew you
| would and pre-empted it because it's the obvious playbook
| of answers. Vulkan didn't fix gaming on Linux. Proton
| did. And again, you ignore the key part of the sentence:
| NATIVE
|
| Linux has fewer *native* AAA games than macOS. Vulkan has
| not solved that.
|
| The SteamDeck is a product targeted at gamers that
| provided a new value proposition: AAA gaming on the go.
| Which further reinforces my point that API is irrelevant
| to the discussion, its about demographic. Apple has a
| strong gaming demographic on the mobile side (with metal
| no less).
|
| The steam deck didn't introduce new Vulkan/Proton
| capabilities. Why was Linux gaming stagnant before it?
| Doesn't that exactly reinforce that its the form factor
| proposition that made it skyrocket?
| talldayo wrote:
| > switch to kill 32-bit games killed more games than the
| deprecation of OpenGL did.
|
| It did. If you want to parade around how cool Cider is,
| it doesn't make much sense to venerate the update that
| killed it.
|
| > Linux has fewer _native_ AAA games than macOS. Vulkan
| has not solved that.
|
| Imagine all the Steam Deck users that are _pissed_
| because they can 't play Resident Evil 8 and Tomb Raider
| natively! They must be super upset, and envious of
| Apple's superior native version. Surely.
|
| Hey, here's a magic question for you; which do you think
| will get supported longer, a DirectX title running on
| Proton or an Apple-native title running on Apple
| software. Do you trust Apple to keep supporting your game
| as long as Proton would keep supporting it?
| christkv wrote:
| Considering backward compatibility on ios my bet is on
| proton for sure.
| rowanG077 wrote:
| Why do you have tunnel vision on "native". It's a pretty
| meaningless distinction at this point. No steam deck
| users cares that all the games they are playing aren't
| "native".
| jakogut wrote:
| Precisely. Modern games incorporate all manner of
| middleware to add functionality. Compression, video
| codecs, shading, ray tracing, physics, animation, anti-
| cheat. What's one more piece of software in the pile to
| abstract away platform-specific interfaces?
| anthk wrote:
| Also Wine it's just a Win32 subsystem for Unix with a PE
| loader. Also, a hint: on NT Systems, Win32 it's another
| subsystem on top of the NT kernel. I'm pretty sure
| Windows 95/98 software under 2000/XP doesn't run
| 'directly' in the same they did under their original
| OSes.
| anthk wrote:
| You are utterly wrong. Current Wine doesn't even need
| multilib.
| out_of_protocol wrote:
| > The argument that Vulkan would have solved this
|
| but it in fact did! You can play 90% of games on linux
| precisely because of Vulkan. Just boot Steam Deck or
| whatever and play. There is no way it would work out
| without Vulkan
| dagmx wrote:
| And I address Proton specifically in my comment and also
| address why it's not an indicator of increased gaming
| support on Mac.
|
| I truly feel half of the replies here are glossing over
| the things I've already covered and perhaps are people
| who haven't actually tried the equivalent Mac solutions
| and seen where the resultant deficiencies lie or the
| delta between platforms that proton would also have to
| bridge further.
|
| Vulkan isn't the magical silver bullet people think it
| is.
| talldayo wrote:
| Conversely, I'm convinced that _you_ haven 't tried
| Proton and are trying to defend Cider and Whiskey as
| analogs when in-fact they are pale imitations. Gaming on
| Mac is derelict; you can get a _few_ games working, but
| it 's still absolutely pathetic stood-up next to Windows
| or even modern Linux. The number of playable desktop
| games is just a blowout for MacOS.
|
| We've all used tinker-tool applications to get a random
| app running through WINE, but DXVK is more than that. It
| is the solution to a problem Apple refuses to address,
| and even Apple is willing to admit that they need DirectX
| translation in order to make games run on Apple Silicon.
| How is the future of gaming on Mac going to look _any
| different_ if we continue to follow in the footsteps of
| Cider? How long do you think that shanty-utopia will be
| supported on the latest OS update?
| MindSpunk wrote:
| Vulkan has nothing to do with the Steam Deck being able
| to run PC games other than being the API that DXVK and
| VKD3D-proton translate DirectX calls into. Vulkan isn't
| the magic bullet, it's just another API in the stack. The
| "magic" is the phenomenal amount of effort that has gone
| into those DirectX translation libraries.
|
| Vulkan makes the work easier, but it is not what makes
| those games portable.
| gpderetta wrote:
| Yes and no. DXVK didn't happen on top of opengl as the
| impendence mismatch between OpenGL and DX is too large.
| Wine had working but slow DX9 to OGL; incomplete, buggy
| and slow DX11 to OGL; and no hope for DX12 to OGL. DX9,
| DX11 and DX12 are all much easier (but not easy, mind) to
| map to Vulkan.
|
| As Steam Deck is running AMD, a conversion layer on top
| of Mesa Gallium would have been possible, but again DX12
| support never materialized.
| exDM69 wrote:
| Vulkan has a lot of features made specifically so that
| implementing portability layers like DXVK and Zink would
| be possible and performant.
|
| This has been a key project in the past few years and
| lots of work went into it. For more info, look up Vulkan
| portability initiative.
| p_l wrote:
| While it might be true, I'd recommend to check if the
| licenses do, in fact, recurse this way.
|
| They might not.
| LucidLynx wrote:
| > The number of games that run natively on Vulkan is
| negligible.
|
| Yep, that's unfortunately true...
|
| https://www.carette.xyz/posts/state_of_vulkan_2024/
| talldayo wrote:
| I'd be curious to see how many Vulkan-native games there
| are that _don 't_ run under Proton. The only one that
| comes to mind is Destiny 2, but that was more because of
| anticheat as I remember it.
| jsheard wrote:
| Much of the Vulkan support was motivated by Stadia, not
| so much because Stadia was successful, but because Google
| was throwing huge amounts of money at developers to port
| their games to Stadia regardless. When Stadia was
| discontinued at the end of 2022, sure enough the number
| of new Vulkan games immediately plummeted.
| tapoxi wrote:
| Why is this article comparing game engines with games?
| mardifoufs wrote:
| What do you mean? I guess most engines support Vulkan but
| that's not the point of the article, but you might be
| referring to something else.
| caycep wrote:
| these days, is the way to win in the industry to
| basically pour money into the popularity contest of your
| own dev kit vs. Nvidia's and others?
| wlesieutre wrote:
| Star Citizen is another one recently moving to Vulkan,
| they just rolled it out as a graphics option in 3.23, and
| it's slated to replace DX11 once it's working well
|
| _> Vulkan Renderer has now been enabled in Star Citizen.
| This new renderer will be off by default but has been
| added to the Graphics settings menu. In this first
| release, the focus is on hardware /driver issues,
| stability, and any major performance issues. At this
| point we do not expect Vulkan to be outperforming D3D11
| on the CPU usage due to the fact we haven't enabled
| multi-threading of the rendering submission yet, but do
| expect CPU performance to be within a 30% margin. Once we
| have multi-threading enabled we expect a significant net-
| gain. On the GPU side we should be closer to parity._
|
| _> Performance improvements and stability improvements
| will be on-going throughout 3.23, with the aim to make
| Vulkan the default and more performant implementation in
| a following release. In the meantime we appreciate any
| and all feedback towards this._
|
| _> Additionally, you may see a few new folders now in
| Star Citizen 's appdata. These relate to our new Graphics
| Settings file (just includes the Graphics Renderer
| setting for now), Vulkan's Shader Cache, and Vulkan's
| Pipeline Cache._
|
| _> We are currently working with AMD and Nvidia to
| improve functionality and compatibility for later Driver
| Releases. It is recommended that you update to the latest
| GPU drivers for this release but there are still a few
| known issues that could cause instability and crashes
| with Vulkan until a later AMD /Nvidia Driver update. If
| you run into major issues you may want to swap back to DX
| 11. If the game crashes on launch after switching to
| Vulkan, you can reset this by deleting your shader
| folders in %localappdata%\Star Citizen_
|
| https://robertsspaceindustries.com/comm-link//19915-Star-
| Cit...
| shmerl wrote:
| _> Star Citizen is another one recently moving to Vulkan,
| they just rolled it out as a graphics option in 3.23, and
| it 's slated to replace DX11 once it's working well_
|
| Does it work well in Wine on Linux with Vulkan renderer
| now? I tried a long time ago and I was waiting for their
| Vulkan option to revisit it.
| wlesieutre wrote:
| Haven't tried it, but this person says no
|
| https://www.reddit.com/r/starcitizen/comments/1cl0bwn/sta
| r_c...
| shmerl wrote:
| Interesting. Looks like it works but with poor
| performance. I guess I'll wait for them to finish the
| rest of the work to enable more parallelism first.
|
| Also, did they start using EAC? That usually works very
| badly in Wine unless developers flip some switch to allow
| it on their side?
| wlesieutre wrote:
| It does have EAC, but I don't think it's as aggressively
| enforced as some games since people are still able to run
| it on Linux.
|
| There's a Linux Users Group that would know much more
| about it than I do.
|
| https://robertsspaceindustries.com/orgs/LUG
| fngjdflmdflg wrote:
| I think you make a good point in general, but "likely not
| really have helped macOS gaming in any form" I think is
| taking it too far. The reason why many developers only use
| dx11/12 is because adding more graphics backends increases
| their support surface unnecessarily, being that Vulkan only
| works on Windows (and Linux), while dx11/12 work on Windows
| on Xbox. As an extreme example of this, apparently
| Cyberpunk 2077 ran Vulkan on Stadia but did not enable it
| for Windows as an option. (Because what is the point?) If
| Vulkan worked on both Windows and Mac then developers would
| have more reason to support it. It would likely also mean
| game engines would put more time into making Vulkan better.
| For a related example, Apple had to individually contribute
| it's Metal backend to Blender because (presumably) nobody
| wanted to work on it.[0] Why? Because they already have to
| support OpenGL, Cuda, OptiX, Intel OneAPI, ROCm HIP, and
| Vulkan. Clearly, something is very wrong with graphics APIs
| right now. If Apple supported Vulkan, it would have allowed
| everyone who is not Windows to benefit by making Vulkan
| become more standard. Luckily Xbox seems to be kind of
| dying right now so perhaps supporting dx11/12 will not be
| as important in the future. But the point is if you have a
| small portion of the market it just doesn't make sense for
| developers to spend time entering that market for little
| reward.
|
| Another major point is the development cycle. Since Metal
| only works on Apple devices that makes developing for it
| more annoying for game developers which are mainly using
| Windows. It means they will have to switch to a Mac device
| to debug issues with their Metal backend. By supporting
| Vulkan Apple would allow for a much smoother developer
| experience. (While Metal Developer Tools for Windows
| exists, as I understand it it only allows you to compile
| shaders for Metal on Windows, but to actually test that
| anything works you will need an actual MacOS device.).
|
| [0] https://code.blender.org/2023/01/introducing-the-
| blender-met...
| dagmx wrote:
| Many engines support Metal, in addition to the plethora
| of console specific APIs. Saying DX11/12 works on Xbox is
| glossing over that that it's not actually the same DX12
| that works on desktop.
|
| You then say that if they used Vulkan, it would mean they
| wouldn't have to debug on a Mac. This is overly
| optimistic. Even in the OpenGL days, you'd have to test
| on all platforms because there's so many variances. In
| general, the game designers are rarely working multi
| platform, and it's down to the engine devs themselves +
| QA. Neither should or would be blindly trusting that
| things are portable. Vulkan/DX on AMD/NVIDIA also perform
| differently enough that you can't just assume parity.
|
| Your other statement about nobody wanting to work on
| Metal for Blender is a bit odd too. There's no current
| Vulkan or DX backend for it. Does that mean they're not
| desired either? AMD and NvidiA contribute support for
| their favoured API's as well, like Optix that people
| still desire.
|
| > If Apple supported Vulkan, it would have allowed
| everyone who is not Windows to benefit by making Vulkan
| become more standard.
|
| This didn't prove itself out when OpenGL was a thing.
| OpenGL was everywhere but barely used.
|
| > Luckily Xbox seems to be kind of dying right now so
| perhaps supporting dx11/12 will not be as important in
| the future.
|
| That doesn't mean that Vulkan would replace it though.
| Windows gaming still eclipses Linux, and game developers
| have to target multiple APIs either way. There's very
| little upside to them switching to Vulkan for it.
|
| Also bear in mind that DX is much more than D3D. It's a
| lot of APIs. There's many reasons to use DX beyond just
| the 3D graphics APIs.
| fngjdflmdflg wrote:
| >if they used Vulkan, it would mean they wouldn't have to
| debug on a Mac.[...] Neither should or would be blindly
| trusting that things are portable
|
| I didn't mean this, just that you can actually run
| whatever shaders you compile rather than needing a Mac
| just to see your output. My point was that you would get
| "a smoother developer experience," which is true.
|
| > Vulkan/DX on AMD/NVIDIA also perform differently enough
| that you can't just assume parity.
|
| Vulkan has some pretty strict conformance tests[0]. It's
| not like you are going to run into differences between
| conformant Vulkan implementations every day. It's very
| different from not being able to run the shaders you've
| compiled at all. You just need to know what extensions
| are supported. Also, Apple's support for OpenGL was never
| good. They only supported OpenGL 4.1 for years while 4.5
| was out, for example. I don't know if Apple's OpenGL was
| ever even conformant, being that 4.1 is not listed on the
| site.[1]
|
| >There's no current Vulkan or DX backend for it.
|
| There is actually (as an experimental feature
| currently).[2] And Khronos did not have to send
| developers to implement it for them. My understanding is
| that Blender also implemented CUDA/Optix themsleves and
| only got help from Nvidia, rather than Nvidia implement
| the whole thing for them, although I could easily be
| wrong there.
|
| >This didn't prove itself out when OpenGL was a thing.
| OpenGL was everywhere but barely used.
|
| OpenGL was not nearly as performant as direct X. When
| Direct X came out people switched to it. Vulkan and dx12
| are very similar however.
|
| > That doesn't mean that Vulkan would replace it though
|
| Yeah, because each console wants their own special
| graphics API to force on everyone instead of using an
| open standard, despite Xbox and Playstation GPUs being
| from AMD which supports Vulkan on it's consumer GPUs.
|
| >Many engines support Metal, in addition to the plethora
| of console specific APIs
|
| And many don't, including the engines of a lot of AAA
| games like Elden Ring, Cyber Punk 2077 and Baldur's Gate
| 3 (although CDPR are now switching to UE5). And studios
| are generally using modified versions of UE so my guess
| is that means they are generally making low level changes
| sometimes, and so it makes sense to me that they
| sometimes may write their Dx/ Vulkan code for different
| things sometimes. (this is just my guess. I admit to
| being uninformed here). Even if not there are still ways
| that you could program something in UE without writing
| any direct DX/Vulkan code that could still result in
| worse performance for one of the backends vs. the other.
| That is why on games that support multiple graphics
| backends oftentimes one is better than the other. And
| developers will release updates improving only certain
| backends. Adding an extra platform like MacOS is not
| simply clicking a button. although it is easier today
| than before, if it was that simple, then literally every
| UE game would be on MacOS. (Yes, you do 'just click a
| button' to support MacOS in UE5, but there is still more
| to it than that.) And increasing the surface area of
| platform divergence does nothing to help the situation.
| Also, while it doesn't matter for Apple, having to
| maintain multiple backends adds needless extra work for
| engine developers
|
| [0] https://docs.vulkan.org/guide/latest/vulkan_cts.html
|
| [1]
| https://www.khronos.org/conformance/adopters/conformant-
| prod...
|
| [2] https://code.blender.org/2023/10/vulkan-project-
| update/
| philistine wrote:
| Ultimately, the whole discussion surrounding technologies
| is discussing the consequences of the problems, not the
| problem itself.
|
| The problem is that Apple, since it decided it was going
| to make its own GPUs for all its devices, deemed it
| necessary to simplify _their_ support. Apple 's Metal API
| is custom-made to the silicon Apple is making, and Apple
| keeps Metal development strictly focused on their
| hardware. Of course they could have chosen to support
| more APIs, but the strength of iOS clearly helped them
| decide to move iOS game developers to the Mac, rather
| than try to court the so-called AAA companies who are
| stuck in an x86, Windows+console, heat up the wazoo
| world. That whole world is difficult to reconcile with
| Apple's priorities.
| fngjdflmdflg wrote:
| >Apple's Metal API is custom-made to the silicon Apple is
| making
|
| Do you have any examples of this? My guess is that the
| API, being higher level than vk/dx, is designed for ease
| of use by developers, not to expose hardware level
| details. In fact Vulkan would be more suitable for that
| as it is lower level.
|
| >the strength of iOS clearly helped them decide to move
| iOS game developers to the Mac
|
| What do you mean by this? Are there a lot of mobile game
| studios publishing on MacOS now? (this is a legitimate
| question)
|
| >rather than try to court the so-called AAA companies who
| are stuck in an x86, Windows+console, heat up the wazoo
| world.
|
| Why is that? The only actual barrier there is x86. But
| Vulkan is not related to x86 anyway. It is only related
| inasmuchas they are both not supported by Apple. But this
| discussion is itslef about if Apple should support
| Vulkan, so the reasoning here seems circular. Also, if
| Apple doesn't like x86 games that is fine because they
| don't support x86. So it's not like they are not support
| Vulkan because they think developers will start
| distributing x86 games to their customers because that's
| impossible.
|
| >heat up the wazoo
|
| I mean, it will use the same about of energy as any other
| demanding application like Blender or video editing. And
| you can always lower the graphical settings to make it
| consume less power. Similarly mobile game developers
| would likely increase the graphical settings for a mobile
| game that they port to MacOS.
| tcmart14 wrote:
| I don't really know if it counts as 'exposing hardware
| details,' and I may be wrong, but this could be an
| example of where in their API it does make more sense for
| Apple Metal being separate.
|
| The example I am thinking of is with MTLBuffers and
| storage options. You have several different storage
| options for MTLBuffers that wouldn't necessarily make
| sense on non-apple hardware and especially non-apple
| silicon. Options that are not backwards compatible with
| intel macs. When I go to use MTKTextureLoader with the
| newTexture command, I can set in the options an
| MTKTextureLoader.Option.StorageMode as shared storage. On
| Apple silicon, this means that the it is a shared buffer
| by both the CPU and GPU since with the apple silicon
| architecture the came peice of memory can be accessed by
| both. There are a bunch of different storage options that
| may not apply to other configurations outside of the
| Apple silicon configurations.
| flohofwoe wrote:
| > My guess is that the API, being higher level than vk/dx
|
| Metal is not generally higher level than VK/D3D12,
| instead it's a mix of high- and low-level features (where
| the low level features typically had been added in later
| Metal versions and are optional to use).
|
| You can stick to the convenient high level parts of Metal
| v1 (which feels a lot like the spiritual successor to
| D3D11) if that's good enough (which often is), but if
| needed there are lower level and more explicit features
| that match or in some parts go beyond what Vulkan and
| D3D12 have to offer (AFAIK argument buffers allow a
| couple of things that are not possible on D3D12 or
| Vulkan, or at least would require vendor specific
| extensions on Vulkan - like setting the PSO via an
| argument buffer, recorded in a compute shader).
| robertoandred wrote:
| > Yes, you do 'just click a button' to support MacOS in
| UE5, but there is still more to it than that.
|
| Can you expand on this? What happens / doesn't happen
| when clicking that button? Is debugging the additional
| effort, or incompatibilities?
| MindSpunk wrote:
| > Vulkan has some pretty strict conformance tests[0].
| It's not like you are going to run into differences
| between conformant Vulkan implementations every day.
|
| Oh man with every fibre of my being do I wish this were
| true. I'm debugging a different Vulkan driver bug almost
| every 2 weeks. PC drivers are passable, mobile drivers
| are a joke. Shader miscompilations everywhere.
| Performance traps. Arm Mali drivers currently implement
| vkCmdPipelineBarrier2 by calling vkCmdPipelineBarrier in
| a loop for every individual barrier instead of issuing a
| single barrier. I've measured Barrier2 as almost 10 times
| slower than the older version, only on Arm drivers
| though.
|
| You have to test everywhere
| exDM69 wrote:
| It isn't perfect but it's so much better than it used to
| be.
|
| Mobile drivers are still a problem, and part of the
| problem is that they passed their conformance tests years
| ago, and the test suite has improved a lot since then.
|
| But it's a giant surface area to test, it is not perfect.
| But still better than what we had 10 years ago.
| pcwalton wrote:
| > You then say that if they used Vulkan, it would mean
| they wouldn't have to debug on a Mac. This is overly
| optimistic.
|
| Sure, but supporting two variants of Vulkan is less work
| than having to support two incompatible APIs. It's not a
| binary thing.
| pjmlp wrote:
| The problem is that there isn't two variants, there is an
| extension soup of Vulkan variants.
| exDM69 wrote:
| I get by just fine with "one variant" using all the
| Vulkan 1.3 features that are ubiquitously available on
| desktop (= almost all of them) platforms with up to date
| drivers.
|
| The fact that there's n+1 extensions does not mean you
| have to support 2^(n+1) combinations. I can't recall a
| single situation where I would've needed even two code
| paths to get something done in the past few years.
|
| Situations where you need two or more code paths only
| arise if you use new hardware features like mesh shaders
| or ray tracing. For "software" features like dynamic
| rendering or dynamic states (both of which simplify
| things a lot), there's no need for a fallback on desktop,
| just require a recent driver version and you're good.
|
| That said, the mobile driver support situation and lack
| of long term updates is an issue if mobile support is
| required.
| shmerl wrote:
| _> Vulkan would likely not really have helped macOS gaming
| in any form_
|
| Why not? With fully conformant Vulkan you could have run
| all the games that work in Wine without being hit by
| limitations of MoltenVK that affect performance and
| compatibility, same as you can run them on Linux now. So
| Vulkan could totally be very crucial for making gaming on
| macOS not being some second class experience.
|
| Apple simply demonstrate they don't care about gaming and
| gamers. They only care about _" approved by Apple way of
| gaming"_ which is totally not the same thing but which
| Apple always does for everything anyway, shoving in users'
| faces _" we know better than you what you need"_.
|
| That's why I will always say that gamers should avoid using
| Apple.
| astrange wrote:
| You can't "just support Vulkan", it's too low level. To
| benefit, the implementation would have to target the GPU
| specifically since Apple GPUs are different from discrete
| GPUs.
| shmerl wrote:
| Well, Asahi / Mesa developers demonstrated that they can
| "just support Vulkan" on Apple's hardware as the linked
| post explains. So Apple never had any excuse for not
| doing it. Their reasons for sabotaging Vulkan support
| were always political, not technical.
| robertoandred wrote:
| Sabotaging? Metal came before Vulkan.
| shmerl wrote:
| How does that stop Apple from supporting Vulkan on their
| system? It is pure political sabotaging. And you can't
| pull any excuses like "it requires effort". Apple have
| pools of cash to do the right thing for users and
| developers. They simply very intentionally oppose it due
| to their dinosaur lock-in mentality.
| astrange wrote:
| A blog post is different from a real compliant commercial
| implementation. Other reasons you couldn't do it include
| eg someone with a patent on it won't license it to you.
| shmerl wrote:
| Mesa's implementation will get a compliance certification
| once it's ready. I don't see why they would have problems
| with that - other Vulkan drivers got compliance from
| Khronos once they passed needed tests. Patent FUDs are
| nonsense - no one else has such issues and many drivers
| already exist and work fine.
|
| The real reasons are not good at all (i.e. Apple's
| obsession with lock-in) and have no excuse.
| 58028641 wrote:
| https://github.com/KhronosGroup/MoltenVK proves that it
| is possible, but it is limited by having to go through
| Metal.
| astrange wrote:
| Anything's possible, but it wouldn't be performant.
| MoltenVK is just about as good as an untuned native
| Vulkan client would be.
| flohofwoe wrote:
| If Apple would add native Vulkan support to macOS, it
| would most likely also go through a Metal "emulation
| layer" (just like their GL implementation, or the D3D12
| implementation in the Game Porting Toolkit).
| talldayo wrote:
| Because everyone knows from MoltenVK, Metal-based API
| implementations are just _so_ efficient.
| pcwalton wrote:
| Vulkan probably wouldn't help macOS gaming from a users'
| point of view, but it sure would be nice for us engine
| developers. There aren't many Vulkan _games_ , but the big
| 3 non-in-house game _engines_ (Unreal, Unity, Godot) are
| all committed to supporting Vulkan in addition to Metal, so
| we (collectively, the engine dev community) currently have
| to support both. Dropping Metal would reduce the amount of
| engineer time spent chasing down Metal-specific bugs (which
| is not inconsequential), which allows us to spend more time
| on actually interesting features that users want.
|
| Metal is a hidden tax that isn't obvious, but it's there.
| ttoinou wrote:
| Interesting point of view that could also be the other
| way around, Vulkan support being a hidden tax for the
| love of open source and free software rather than
| something really useful the market needed on top of
| others APIs / GPU architectures / platforms, pushed by a
| subset / minority of developers more ideological than
| practical grounded developers who accept that competition
| of private standards will bring out the best user
| experience, each platform having its customized
| architecture.
|
| After all, scientists don't write much CUDA oriented for
| game development anymore or custom maths shaders, they
| have their own CUDA libraries helping them in their own
| domains better than what a gamedev orienter Vulkan would
| do. Any percent shaved off developer time and running
| time is worth a lot of money.
|
| The Apple Metal platform surely is customized to the
| needs of Apple, its devices and its users ultimate needs,
| in a way Vulkan will never be. Unified memory on recent
| Apple silicon M1 M2 M3 where RAM and VRAM are somehow
| merged.
|
| Maybe the society of worldwide developers had better
| things to do than spend precious time on Vulkan.
| _carbyau_ wrote:
| Coverage. Metal only covers Apple. Vulkan covers so much
| more.
|
| But money talks and game engines want a slice of that
| sweet apple pie.
| dev_tty01 wrote:
| > Metal only covers Apple. Vulkan covers so much more.
|
| I'm not sure "more" is the right term here. There are
| about 1.3 billion iPhone users worldwide. Sure, Vulkan
| covers more OS environments, but how important is that to
| a game developer vs. total available users? Does Vulkan
| user reach exceed 1.3 billion?
| nemomarx wrote:
| How many iphone users will pay 60 dollars for a game,
| like you can try and achieve on Steam or Switch? I feel
| like the iOS game market is pretty different.
| jppittma wrote:
| More money is spent/made made on iOS gaming than on
| traditional PC gaming, even if the $60 up front model
| isn't something iOS users are willing to accept. I almost
| think they're right to tolerate mtx models btw. At least
| if games are f2p, companies aren't releasing them
| broken/unfinished.
| mycocola wrote:
| Can't release unfinished/broken games, when what they're
| releasing are not games at all.
| _carbyau_ wrote:
| OS coverage vs pure numbers is something for the game
| developer to be worried about, and by extension the game
| engine devs.
|
| You want to get into the iOS gaming market, go Metal. By
| definition you've expressed you don't care about the
| other OS's.
|
| You want to make a AAA game, you probably don't go Metal
| if you want enough market coverage to recoup your costs -
| though I will be delighted to be proven wrong when a AAA
| iPhone game comes.
|
| If Apple want to change their "AAA game" attractiveness
| they need to address this. It's not that hard - the
| article took a month but even a year is fine. Apple just
| needs to get it done, but it doesn't seem like they care
| to make User<->GameDev relationship easy. Either the
| gamedev needs a whole other version of their game on
| Metal. Or the users have to do a lot of homework and
| fiddling to get a modern AAA game to run.
|
| I wonder if they have Vulkan internally and simply know
| their GPU won't look good in direct comparisons - which
| is fair; beating or even leveling with nVidia is hard.
| But if anyone can show AMD and Intel how to do it....
| pjmlp wrote:
| AAA don't care about Vulkan, they care about Apple, Sony,
| Nintendo and Microsoft proprietary APIs.
| SleepyMyroslav wrote:
| minor nitpick: did care when Google Stadia was in the
| list. But it did not worked out and everyone took a big L
| on that and now Vulkan support has been mostly purged
| already.
| pjmlp wrote:
| The reason why Stadia is no more, is exactly because they
| don't care.
|
| Google was starting to offer a DirectX porting kit on the
| same year they decided to ramp down Stadia, there is even
| a GDC talk on it.
| troupo wrote:
| > You want to make a AAA game, you probably don't go
| Metal if you want enough market coverage to recoup your
| costs
|
| Likewise you don't care about Vulkan. You care about
| DirectX and whatever Playstation has
| talldayo wrote:
| > You care about DirectX
|
| ...exactly. Which is why, unless you're given a license
| to re-impliment DirectX, it makes _so much more_ sense to
| use Vulkan and it 's DX9 through DX12 translation layer.
|
| What am I missing here?
| troupo wrote:
| You're missing that people don't care about Vulkan at
| all: https://carette.xyz/posts/state_of_vulkan_2024/
|
| And the translation layer exists largely due to Valve
| business decisions, not because "community came together
| or something". This glorious amazing support didn't even
| really exist until 2018 (when it was launched with
| official support of 27 games)
|
| 1. Apple has never truly cared about gaming on the Mac
|
| 2. iOS only supports Metal, and Metal serves Apple
| extremely well
|
| 3. Apple's dropping of 32-bit apps and switching to M*
| chips has hurt gaming on Macs much more than any
| perceived harm from not supporting Vulkan.
| atq2119 wrote:
| Surely there are more Android users than iPhone users
| worldwide, and if you target Android you target Vulkan.
| pjmlp wrote:
| Only if we don't care about those using devices where
| OpenGL ES is still more stable, with less buggy drivers.
|
| If you only care about latest Android versions, and
| Samsung and Google phones, sure go Vulkan.
| talldayo wrote:
| My brother in Christ, OpenGL ES is officially depreciated
| on all Apple platforms. It is not "more stable, with less
| buggy drivers", I've used it.
| pjmlp wrote:
| I thought we are talking about Android, and which APIs
| makes business sense, when AAA actually want to get paid,
| instead of having to pay back store returns.
| talldayo wrote:
| I thought we were talking about capable APIs for creating
| enjoyable experiences, not barebones rendering frameworks
| for building flashier online casinos. My mistake.
| talldayo wrote:
| It feels unlikely. Much smaller companies (Broadcom,
| Qualcomm) have no trouble writing compliant Vulkan
| drivers (let alone singular people), so I find it hard to
| give Apple the pass here. Assuming good faith on their
| part, Vulkan _should_ be available; or at least some kind
| of cross-platform API target. Otherwise people are just
| going to ignore Mac and keep focusing on DirectX, like
| the status quo.
|
| Vulkan is everyone's ticket out of that mess. Not _only_
| does it provide Apple an industry-standard API for third-
| parties to develop on, it flips the DirectX problem on it
| 's head. Because you support Vulkan 1.3 you get DXVK
| support alongside DX9, DX11 and DX12 support. Now it
| doesn't matter _what_ third parties do, because you win
| every time; Steam Deck politics.
|
| The status-quo is simply detracting from the value of
| using MacOS; the only feasible explanation is that Apple
| is hoping to somehow force developers into using Metal
| natively. Outside Tomb Raider and Resident Evil, I just
| don't see it happening.
|
| > The Apple Metal platform surely is customized to the
| needs of Apple
|
| That clearly doesn't stop anyone from writing Vulkan
| drivers for the hardware, though. OP appears to be
| blatant evidence of this.
|
| For example; CUDA is well-customized to Nvidia's specific
| hardware, but their hardware _also_ supports Vulkan
| drivers. Same goes for Intel with oneAPI and AMD 's ROCm;
| all of them still support Vulkan. Apple is quite
| literally one of the only mainstream manufacturers that
| does not support it.
| ttoinou wrote:
| Your example of taking games that dare go the full Metal
| route makes me wonder : to which projects was adding 100%
| native Vulkan compatibility / support worth the resources
| spent on this and not something else ? What's the full
| Vulkan platform having a dedicated OS running solely
| Vulkan with a Vulkan based GPU and for which real life
| uses ?
| talldayo wrote:
| > What's the full Vulkan platform having a dedicated OS
| running solely Vulkan with a Vulkan based GPU and for
| which real life uses ?
|
| Steam Deck handles it just fine, alongside OpenGL. You
| use Vulkan to run DirectX games, OpenGL to accelerate the
| desktop and browser (can soon be replaced with Vulkan
| too) and fall back to OpenGL for everything else. I'm not
| aware of any desktop stuff the Steam Deck can't do; it
| edits video, it runs Blender, it can browse the web and
| compile apps.
|
| Granted, Vulkan of course isn't a panacea here. But
| without it, stuff like the Steam Deck simply wouldn't
| exist. Vulkan is valuable because it provides a
| preservation layer for Windows software that Apple is
| unwilling to support themselves.
| pcwalton wrote:
| > the only feasible explanation is that Apple is hoping
| to somehow force developers into using Metal natively
|
| I'm told the problem is some legal spat between Apple and
| Khronos that has led to a "no Khronos standards anywhere
| at Apple" policy. I don't know the details beyond that.
| talldayo wrote:
| Sigh, sadly that sounds in-character. Pour one out for
| the users that didn't get their feature because a C-suite
| needed to make a point with their temper-tantrum.
| inDigiNeous wrote:
| Metal allows Apple to squeeze that extra performance out
| of their devices. They have full control over, and can
| implement whatever they need to deliver Apple Vision Pro
| for example.
|
| With Vulkan, they would have to wait for a committee to
| approve required changes, and still they could not
| probably optimize it to match their GPU an CPU hardware
| profiles in such an efficient way.
|
| And not least at all, to optimize the developer
| experience and tools. Apple GPU debugging tools are
| probably the best tools you get for graphics development
| debugging, and you get that only on macOS.
|
| IMO Metal is a nicer API than Vulkan. At the same time,
| you can ask, why should Microsoft get to keep DirectX,
| and not just write a Vulkan driver ?
| DeathArrow wrote:
| >Metal allows Apple to squeeze that extra performance out
| of their devices. They have full control over, and can
| implement whatever they need to deliver Apple Vision Pro
| for example.
|
| That doesn't stop them from implementing both Metal and
| Vulkan.
| inDigiNeous wrote:
| Sure, but a lot of extra work for something like that.
| Also, Apple Walled Garden..
| IsTom wrote:
| > they would have to wait for a committee to approve
| required changes
|
| Or just make proprietary extensions?
| talldayo wrote:
| > why should Microsoft get to keep DirectX, and not just
| write a Vulkan driver ?
|
| They support both. And sometimes the Vulkan driver is
| faster than their native DirectX one too.
| pjmlp wrote:
| Like in the OpenGL days, Vulkan keeps playing catch up
| with the games consoles, and DirectX APIs, and it is
| already a extension mess just like OpenGL, an achievment
| in a quarter of OpenGL's lifetime.
| pcwalton wrote:
| You're confusing device-specific APIs with OS-specific
| APIs. There's a big difference. DX11, DX12, Metal, etc.
| are themselves all abstraction layers over what are in
| some cases very different hardware designs. (This will
| eventually become less so with Apple moving to in-house
| GPUs, but for now it's still true--Metal targets NVIDIA
| and AMD GPUs as well as Apple's M1/M2s.)
|
| Maybe it'd be interesting to contemplate a world in which
| red team, green team, and blue team all have their own
| proprietary APIs and there are no cross-vendor
| abstractions, but that's not what we're discussing here.
| DeathArrow wrote:
| >The Apple Metal platform surely is customized to the
| needs of Apple, its devices and its users ultimate needs,
| in a way Vulkan will never be.
|
| Maybe Metal is customized to Apple's needs but how is it
| customized to Apple user's needs? One thing is for sure,
| had Apple been using Vulkan, the porting process to macOS
| would have been much easier.
| flohofwoe wrote:
| > the porting process to macOS would have been much
| easier
|
| Porting the 3D renderer to another 3D API isn't the hard
| part of a game port, but also:
|
| Apple is offering a D3D12 porting toolkit since a little
| while which TBH makes a lot more sense than native Vulkan
| support (since there are so many more D3D12 games than
| Vulkan games):
|
| https://developer.apple.com/games/
| talldayo wrote:
| > Apple is offering a D3D12 porting toolkit since a
| little while which TBH makes a lot more sense than native
| Vulkan support
|
| It _would_ make more sense... if GPTK behaved like DXVK.
|
| But instead, you're not allowed to distribute games with
| it, you can't easily modify it, and Apple themselves
| doesn't commit to supporting or updating it. Unlike
| Proton, which is community maintained, GPTK is Apple-
| maintained. If something breaks, your best option for
| "fixing" it is to run upstream DXVK on a properly
| supported machine.
| johnnyanmac wrote:
| > more ideological than practical grounded developers who
| accept that competition of private standards will bring
| out the best user experience, each platform having its
| customized architecture.
|
| There's no clean answer here. You push that mentality of
| "Customers first" too hard, and you get the PS3; an
| unwieldy architecture that devs are forced to support but
| end up with worse ports than the Xbox 360. The customer
| doesn't necessarily "win" here.
|
| You push developers first too hard and you get Linux. You
| can do anything you want if you dig deep enough. But as
| we all know, the common consumer barely reads the
| tutorial, let alone learns how to configure complex
| settings in a CLI.
|
| There needs to be some middle ground, and not making
| developers duplicate their work for every new private
| business is at least a starting point.
|
| >Maybe the society of worldwide developers had better
| things to do than spend precious time on Vulkan.
|
| Given MacOS's marketshare, I'm sure they did. Let's not
| pretend that the few metal games we have on Desktop
| wasn't built on the grounds of some Candy Crush clone
| that generated billions of dollars 10 years ago and
| justified the forced upgrade (we can definitely justify
| from there if "making candy crush run faster" is a better
| thing to do. But it pays the bills, I guess).
|
| Very few devs want to support Mac and the numbers speak
| for themselves.
| ttoinou wrote:
| not making developers duplicate their work for every new
| private business is at least a starting point.
|
| Im sure we all understand the benefits of a unified API /
| same abstraction layer. It's about how the abstraction is
| leaking in real life and how to squeeze every last
| percent of developer's experience and final application
| speed
| flohofwoe wrote:
| I'd take Metal anyday over Vulkan though. It's simply the
| much more ergonomic and much better designed API. A
| native Vulkan version only really makes sense if Android
| needs to be supported (and this will be a rough ride
| because of the poor state of Android Vulkan drivers).
| talldayo wrote:
| That's a shame, Metal supports proportionally less
| software and is maintained by a megalomaniac.
| pjmlp wrote:
| The _commercial_ engine developers also don 't have any
| qualms supporting GNM, GNMX, NVN.
| ribit wrote:
| Bugs notwithstanding (which I agree are a significant
| concern for Metal), I'd frankly much prefer to work with
| a well-designed, streamlined API like Metal instead of a
| needlesly verbose and complex Vulkan.
| SoothingSorbet wrote:
| >The number of games that run natively on Vulkan is
| negligible
|
| Firstly, several games engines and rendering libraries
| support it.
|
| Secondly, it does not have to be _native_, on top of Vulkan
| you can run OpenGL and Direct3D emulation layers, which
| will cover most of the rest. macOS has long since abandoned
| their native OpenGL drivers, and MoltenVK has many caveats.
| lonjil wrote:
| > Firstly, several games engines and rendering libraries
| support it.
|
| So? If no one is using that support to ship PC games
| using Vulkan, who cares? Those same engines all support
| Metal, so clearly this is irrelevant to the question of
| Mac gaming.
| DeathArrow wrote:
| >The number of games that run on Metal by comparison
| (natively) is orders of magnitude higher.
|
| You mean iOS games?
| pjmlp wrote:
| It is still Metal, regardless.
| DeathArrow wrote:
| But since there are more Android phones, there are more
| devices supporting Vulkan than devices supporting Metal.
| pjmlp wrote:
| Only if you ignore the facts that Vulkan is only a
| required API since Android 10, it is an ecosystem full of
| buggy drivers, there are no updates, what exact version
| of Vulkan and extension spaghetti varies widely by phone,
| and only Samsung and Google Pixel phones, do actually
| offer a sane Vulkan experience.
|
| Everyone that wants to keep their 3D sanity keeps
| targeting OpenGL ES, which is exactly why Google is now
| doing ANGLE on top of Vulkan as means to pressure OEMs to
| deliver proper Vulkan drivers.
| talldayo wrote:
| You are literally comparing a bunch of gambling apps to a
| library of desktop gaming experiences.
|
| "It is still Metal, regardless" you say, with your mind
| scrolling full of Zynga dice-rolling games and Supercell
| micro-transaction machines.
| pjmlp wrote:
| I am comparing what brings money home, big boys club
| money, versus hippie feel good complaints.
| talldayo wrote:
| I am comparing where the quality titles live. I (and most
| people who have the freedom of choosing) do not even pay
| a second thought to those shitty mobile casino apps.
|
| Crazy stuff like that happens, when you have access to
| quality entertainment and not drip-feed gatcha games.
| johnnyanmac wrote:
| >The number of games that run on Metal by comparison
| (natively) is orders of magnitude higher.
|
| When it's the only way to interface with MacOS and
| especially IOS, I'm not surprised. But that says more about
| Apple as a platform than Vulkan as a graphics API.
|
| >Apple does now have Game Porting Toolkit
|
| yup, only took some 9 years after they abandoned Khronos to
| get it up and running. I'm sure nothing signifigant would
| have developed in that time.
| burnte wrote:
| > Really just drives home how big of a mistake it was
| ignoring Vulkan for the past decade on Apple's behalf, but
| lord knows they won't admit that until it's too late.
|
| They'll never admit it. They only caved on USB-C because they
| were legally required to. They won't cave on this, or NVidia
| support, or putting the charge port on the side of the mouse
| and not the belly, etc.
| mantas wrote:
| Nobody required USB-C charging for laptops and iPads. It
| would have happened on iPhones eventually too.
| eptcyka wrote:
| They were the (one of the) first ones to usb-c on
| laptops. I don't think they were ever planning to do
| usb-c on the iPhone, they had no reason to be this late.
| chipotle_coyote wrote:
| They didn't have a _technical_ reason to be that late,
| but they probably had a _marketing_ reason -- and I don
| 't mean "they made money by licensing Lightning." (They
| did, obviously, but I don't think it was raking in big
| bucks, at least not Apple standards.)
|
| When the iPhone switched to Lightning from the clunky
| 34-pin iPod connector, a whole lot of people got pissed
| off with Apple and _stayed_ pissed off with them for
| years. Literally years. People were convinced Apple did
| it just to sell more cables. So if you 're Apple, and you
| know the history of the _last_ time you forced everyone
| to buy new cables, and now you have orders of magnitude
| more people using your phone...you probably put this off
| as absolutely long as possible.
|
| Would they have gotten there without pressure from the
| EU? Honestly, I think so -- I used to agree with you, but
| when the iPad Air, not just the Pro, went to USB-C, I
| changed my mind.
| kalleboo wrote:
| When Apple went up on stage and announced Lightning, they
| said "this is our connector for the next 10 years".
|
| 10 years later, almost on the dot, they replaced
| Lightning on the iPhone with USB-C.
|
| Doesn't seem weird at all to me.
| talldayo wrote:
| It wouldn't be weird if they simply picked one side and
| stuck with it. They put USB-C on Mac, because obviously
| Lightning couldn't fill the role they wanted with
| Thunderbolt. And then they made iPhones Lightning
| because... they wanted to sell IP to cable manufacturers.
| And they made the Magic Trackpad/Keyboard accessories use
| Lightning because... why again? It's just USB, it
| probably takes more work to make a Lightning peripheral
| than a USB-C one.
|
| The more you think about MFi and Lightning design patents
| the harder it is to believe that they were simply being
| honest and sticking to their word.
| troupo wrote:
| When they made Lightning USB didn't even have an agreed-
| upon charging standard. Much less all the other
| requirements Apple had for the cable.
|
| Do not try and pretend that USB was any good when
| Lightning was announced. And even USB-C is a mess of
| conflicting and confusing optional specifications.
| talldayo wrote:
| > And even USB-C is a mess of conflicting and confusing
| optional specifications.
|
| Certainly one that Apple didn't struggle to navigate,
| considering they designed Thunderbolt around the
| specification.
| troupo wrote:
| As I understand, original Thunderbolt was mostly Intel's
| work, and Apple figured out how to have it with the mini-
| DP connector.
|
| Later Thunderbolt is Intel doing the right thing: they
| took many of the features that USB-C lists as optional,
| and made them required for Thunderbolt specification.
| That's why the first M1 Macbook was Thunderbolt-
| capable/enabled, not fully Thunderbolt certified
| philistine wrote:
| Apple did USB-C on the iPad before the Europeans forced
| them to do USB-C at all. They could have kept developing
| Lighting, it supported USB-3 speeds for one device (the
| first iPad Pro), but they instead chose to rally around
| the common standard. USB-C on phones was a certainty, it
| was clear to everyone. The problem is not that Apple
| didn't want to standardize, it's that they didn't want to
| be forced.
|
| In the history of technology, Apple has chosen to switch
| connectors countless times. Every single time people
| complain, and every time Apple has the same exact reason
| for choosing a specific connector: its the one that makes
| sense for its customers when the device is released.
| talldayo wrote:
| Speaking of, can you buy a Magic Trackpad that uses USB-C
| yet? I've got a Magic Trackpad 2 that requires this
| annoying special cable no one uses and it ends up making
| me buy trashy gas-station connectors to feed it power.
|
| Maybe we're still waiting for that one to make "sense for
| it's customers when the device was released". Good grief.
| ThatPlayer wrote:
| > it supported USB-3 speeds for one device (the first
| iPad Pro)
|
| I'm always unsure about this because it only supported
| USB 3 _host_ for one specific accessory, the camera
| adapter. I question whether that implementation was just
| a hack or something that could 've scaled to proper USB
| client support and others.
|
| There was never a USB 3 Lightning to USB-A or USB-C
| cable.
| Dylan16807 wrote:
| They did the exact opposite of rally. USB-C on iPhone
| took an extra _eight years_. Even _if_ I agree it was a
| "certainty", that's far too long.
|
| They did not want to standardize. The idea of forcing
| them didn't come up in any significant way until after
| they proved that.
|
| And I don't know what their laziness about USB 3 is
| supposed to prove. They didn't consider 3 support
| necessary for USB-C either.
| oreilles wrote:
| Actually they had one, they released the Lightning
| connector by claiming they would stick with it for at
| least a decade. And they did exactly that.
| troupo wrote:
| > They'll never admit it.
|
| Admit what? That they had their own API before anyone even
| thought about Vulkan? That they have Metal running on one
| of the most popular platforms in the world (iOS)? That
| other major platforms don't support Vulkan (Xbox,
| Playstation; Windows supports DX and defers Vulkan support
| to GPU vendors)?
| talldayo wrote:
| Admit that Metal isn't enough.
|
| People were more willing to write a DirectX translation
| framework for Vulkan than Mac users were willing to write
| one for Metal. And now with Game Porting Toolkit we
| basically have confirmation that nothing has been
| stopping Mac users from playing DirectX games with DXVK
| besides... working Vulkan drivers.
|
| So it would be nice to see Apple's explanation for being
| so insular. Especially when their "solution" is
| repackaged and relicensed free software that we've all
| been using for years.
| troupo wrote:
| > Admit that Metal isn't enough.
|
| By what criteria?
|
| > People were more willing to write a DirectX translation
| framework for Vulkan than Mac users were willing to write
| one for Metal.
|
| There were significantly more games playable on Mac than
| for Linux for years, even after Vulkan's introduction.
| Apple hurt gaming on Mac by dropping 32-bit support and
| changing CPU architectures significantly more than any
| fantasy about not supporting Vulkan (which is really not
| supported by most major platforms, and isn't supported by
| game developers either).
|
| And it wasn't some vague nebulous people willing to write
| a DirectX translation framework. It was Steam pursuing
| its business strategy (and doing an amazing job of it).
| Before steam not a single person could be bothered to get
| off their asses and do a similar job for any platform.
| talldayo wrote:
| > By what criteria?
|
| ...games? Isn't that what we're talking about? How Apple
| suffers from spurning the gaming industry, and does
| absolutely nothing to improve the scenario?
|
| > There were significantly more games playable on Mac
| than for Linux for years
|
| > Apple hurt gaming on Mac by dropping 32-bit support and
| changing CPU architectures significantly more than any
| fantasy about not supporting Vulkan
|
| Oh, well this is just wrong. Box86 had "solved" the x86
| -> ARM translation path before Apple Silicon even
| existed, albeit slowly. The 32-bit depreciation was bad,
| but wasn't a dealbreaker for applications like WINE;
| there is a working codepath for WOW64 in WINE today.
|
| Once again; the OP's post is about how they currently
| have games working on Linux that are flat-out unplayable
| on MacOS. Whether you want to blame fantasy features or
| not, Apple has clearly made some sort of arbitrary
| limitation on the userland capabilities that has stopped
| developers from doing this in MacOS and forced them onto
| Linux. Seems to me that the pretty clear difference is in
| the title of the article; Asahi supports Vulkan 1.3,
| MacOS does not.
|
| > Before steam not a single person could be bothered to
| get off their asses and do a similar job for any
| platform.
|
| Before Steam, there was no incentive to develop it. But
| people most certainly _did_ do the same, job for multiple
| platforms. Codeweavers wrote several D3D translation
| layers over the years, WINE had multiple old and slow DX
| drivers (DirectX-D3DX9) that semi-worked, and even
| without that you could still run most titles through
| software acceleration.
|
| And look; _if_ Steam goes rogue and decides to drop
| support for all platforms but Android Wear, we don 't
| really have to worry that much. The important work is
| upstreamed in DXVK and distributed by multiple parties,
| not just Valve. Frankly, the biggest advantage Valve
| still holds over the community is how smoothly their UI
| goes from clicking "play" to launching the game. I
| struggle to imagine a situation where Valve goes full-
| Monty and the community suffers for it.
| troupo wrote:
| > ...games? Isn't that what we're talking about?
|
| I'm struggling to remember when Apple last truly cared
| about gaming on Macs
|
| > How Apple suffers from spurning the gaming industry
|
| Ah yes. Apple truly deeply suffers. In which reality?
|
| > Oh, well this is just wrong. Box86 had "solved" the x86
| -> ARM translation path before Apple Silicon even
| existed, albeit slowly
|
| 1. No idea what Box86 is
|
| 2. Slowly means it didn't solve it
|
| 3. The actual _reality_ and not some fantasy is that
| after dropping 32bit support hundreds of games otherwise
| supported on Macs became unavailable /unplayable on
| Steam.
|
| There were literally significantly more games available
| for Macs than for Linux. Even after Vulkan was released.
| The parity changed only after Valve released Proton(2018)
| and MacOS dropped support for 32-bit apps (2019).
|
| Come on, this is not some ancient history. This happened
| just 5 years ago. I, a gamer, lived through it. And was
| basically forced to go ahead and myself a Windows PC
| because I couldn't game on the Mac anymore. And this had
| nothing to do with Metal, or Apple not supporting Vulkan.
|
| > Asahi supports Vulkan 1.3, MacOS does not.
|
| Neither does Xbox, or Playstation, or the iPhone. Windows
| only has native support for DirectX and delegates Vulkan
| support to the GPU vendors.
|
| There's also Android where support became mandatory in
| 2019, and Switch (no idea when they added support, but
| I've seen people mention you should go to the native SDK
| and skip Vulkan for performance).
|
| Truly an amazing API that so few platforms or even
| developers people care about:
| https://carette.xyz/posts/state_of_vulkan_2024/
|
| > Before Steam, there was no incentive to develop it.
|
| Steam was released in September 2003
|
| Vulkan 1.0 was released in February 2016
|
| People going out of their way to root for Vulkan seem to
| have a very tenuous grasp on reality, or recent history,
| or both.
|
| > And look; if Steam goes rogue and decides to drop
| support for all platforms but Android Wear
|
| All this is beside the point, or is even orthogonal to
| the point. The only reason Proton exists, and works as
| well as it does, is because Valve sees business value in
| it. That's it.
|
| Had Valve seen business value in having a translation
| layer for DX->Metal, we would've had it as well. They
| don't (for good business reasons), and the amazing
| opensource community bitches about Apple instead of doing
| the work that they couldn't be arsed to do in the first
| place.
| kelnos wrote:
| Metal was released in June 2014[0], and Vulkan
| development started a month later, in July 2014[1].
|
| You can interpret that in a few different ways: perhaps
| Khronos saw Metal's release, went "oh shit, we need to do
| something", and scrambled to start development of a new
| API over the next month. Or maybe Khronos (and Valve and
| others) were already talking about something new for some
| time before that, and only got a fire lit under
| themselves after Apple's Metal release. Or maybe the two
| aren't related at all.
|
| Yes, it took a further two years for any kind of
| reasonable Vulkan support to be out there, but either
| way, I think it's a bit disingenuous to say Apple was a
| trailblazer with absolutely no peer here.
|
| Regardless, the gaming situation on macOS is still... not
| great. Certainly some game developers have adopted Metal,
| but overall the main target is still DirectX, and I feel
| like contemporary/modern OpenGL (ES?) still probably
| leads Metal. Hell, at this point, Vulkan might have seen
| more general adoption than Metal has.
|
| [0] https://en.wikipedia.org/wiki/Metal_(API)#History
|
| [1] https://en.wikipedia.org/wiki/Vulkan#History
| troupo wrote:
| > Metal was released in June 2014[0], and Vulkan
| development started a month later, in July 2014[1]. > >
| You can interpret that in a few different ways
|
| There are no two interpretations. Metal was released
| before Khronos even had their "kick off meeting". The
| official introduction of Khronos didn't happen until
| 2015. Vulkan 1.0 was released _in 2016_.
|
| Prior to 2014 there was no Vulkan, and no idea of Vulkan.
| Sevral companies (AMD among them) tried to peddle their
| own proprietary APIs as a potential future direction
| after OpenGL.
|
| And yes, Khronos scrambled to have a modern API after
| both Microsoft and Apple ended up having one.
|
| > Yes, it took a further two years for any kind of
| reasonable Vulkan support to be out there
|
| No. It took two more years to just release version 1. And
| even in 2024 it's somewhat laughable to talk about
| "reasonable Vulkan support" when the major gaming
| platforms (Windows, Xbox, Playstation) don't support it
| (Windows supports DX natively, and Vulkan support is left
| to the whims of GPU vendors). The actual support _for_
| Vulkan is declining:
| https://carette.xyz/posts/state_of_vulkan_2024/
|
| > I think it's a bit disingenuous to say Apple was a
| trailblazer with absolutely no peer here.
|
| The trailblazer was Microsoft. What is disingenuous is to
| pretend that Vulkan was anywhere at the forefront or that
| Apple had to pay any attention to it, or that Apple is
| somehow in the wrong for not supporting it.
|
| > Hell, at this point, Vulkan might have seen more
| general adoption than Metal has.
|
| Of course it doesn't. Because iOS exists, supports Metal,
| and is a major gaming platform
| zbentley wrote:
| Maybe so. But they did cave on/rethink decisions around:
| the MagSafe adapter; butterfly switches; laptop thinness
| generally (but only a little); onboard HDMI/SD; touchbar
| controls (for now).
|
| Not saying that means they'll immediately see the light WRT
| 3D graphics APIs. Just that they aren't universally hostile
| to revising prior decisions.
| troupo wrote:
| > Really just drives home how big of a mistake it was
| ignoring Vulkan for the past decade on Apple's behalf, but
| lord knows they won't admit that until it's too late.
|
| People who keep saying this have surprisingly short/bad
| memories. And very little idea of the state of the industry.
|
| - Apple already shipped Metal version 1 a full year before
| Vulkan was even an idea. iPhone, one of the largest casual
| gaming platforms in the world, is Metal
|
| - Windows and Xbox is DirectX
|
| - Playstation is their own thing (keep forgetting what it's
| called)
|
| That leaves Android (mostly underpowered and fractured to
| even run games properly) and Switch who really support
| Vulkan.
| talldayo wrote:
| > Apple already shipped Metal version 1 a full year before
| Vulkan was even an idea.
|
| That doesn't stop them from implementing two APIs at once,
| like every single GPU hardware vendor in existence. But
| given their avoidance of OpenGL and OpenCL, we should have
| always assumed Apple's goal was to usurp Open interfaces
| and replace them with only proprietary options. What else
| could they intend to signal?
|
| > Windows and Xbox is DirectX
|
| Yes. DirectX is covered almost in it's entirety by DXVK.
| It's harder to find a DirectX game that _isn 't_ playable
| with Vulkan than one that is.
|
| https://www.protondb.com/explore?sort=playerCount
|
| > Playstation is their own thing (keep forgetting what it's
| called)
|
| Yeah, and it keeps biting them in the ass when they have to
| then backport Playstation-native titles to PC with DirectX.
| It's a notoriously redundant process.
|
| > That leaves Android (mostly underpowered and fractured to
| even run games properly) and Switch who really support
| Vulkan.
|
| Well also Windows, Linux, BSD, HaikuOS, Google Fuchsia,
| QNX, Stadia and Tizen.
|
| And hardware wise you can't forget that Intel, AMD, Nvidia,
| ARM, Qualcomm and Broadcomm all support it in their GPUs.
| robertoandred wrote:
| Apple created OpenCL. It was nvidia who made everyone
| else avoid it.
| talldayo wrote:
| What does that prove, though? Apple gave up. Ironically,
| now Nvidia is one of the only remaining companies that
| supports OpenCL anymore.
|
| Apple is experiencing firsthand what the lack of a CUDA
| analog does to a company. Whether or not they care is up
| to them, but clearly the laser-focus on high-performance
| GPU compute is not doing Apple Silicon any favors in the
| server space or in the desktop.
| robertoandred wrote:
| It proves that the idea that Apple avoided OpenCL is
| ludicrous.
| talldayo wrote:
| Where does Apple support OpenCL today then?
| robertoandred wrote:
| It still works on Apple Silicon
| talldayo wrote:
| Works != supported
| pjmlp wrote:
| Sure, sure, like Google, Intel and AMD aren't to blame
| for having made a mess out of OpenCL on their products.
| talldayo wrote:
| Go ahead, blame literally every single person _except_
| the lead maintainer and developer of the project.
| pjmlp wrote:
| The reality is that Google, AMD and Intel have more than
| enough time since 2009, to provide a developer
| experience, and drivers, that would make people actually
| use OpenCL instead of CUDA.
|
| Instead, Google created the proprietary Renderscript for
| Android, while AMD and Intel kept delivering broken
| drivers, partial implementations of OpenCL, never
| delivered a proper OpenCL 2.x implemenation with mature
| C++ support, IDE and GPGPU graphical debuggers.
| talldayo wrote:
| It wasn't Google, AMD and Intel's job to improve the
| developer experience. You can chew them out for bad
| drivers, but they did improve and now AMD and Intel's
| OpenCL implementations are the reference-quality ones.
|
| Again, you can blame everyone else for doing their own
| thing but the project only has one father that could
| estrange it. Apple's blindness killing OpenCL makes
| everything in Microsoft and Google's graveyard look
| reasonable by comparison. If Apple wants a repeat of the
| Metal for gaming situation in AI, they are more than
| welcome to self-sabotage themselves until they run out of
| energy.
| troupo wrote:
| > That doesn't stop them from implementing two APIs at
| once, like every single GPU hardware vendor in existence.
|
| Apple is not a GPU vendor.
|
| > Yes. DirectX is covered almost in it's entirety by
| DXVK.
|
| You mean a non-official non-supported wrapper. No one is
| stopping _you_ to create such a wrapper for Metal /VK. Oh
| wait, it exists
|
| > Yeah, and it keeps biting them in the ass when they
| have to
|
| Has nothing to do with the reality of Vulkan support
|
| > Well also Windows, Linux, BSD, HaikuOS, Google Fuchsia,
| QNX, Stadia and Tizen.
|
| The only API Windows supports natively is DirectX. It's
| up to the whims of the GPU vendors to provide support for
| Vulkan.
|
| Stadia is a very major player, true. Considering it's
| dead. TVs as gaming platforms (that's what Tizen is) are
| non-existent in the grand scheme of things. Neither is
| Fuchsia. Or HaikuOS.
|
| The only winner here is Linux, but that really only works
| through the thankless work of maintaining the DX->Vulkan
| wrappers. Again, nothing is stopping _you_ from doing the
| same work for Metal.
| guipsp wrote:
| > Apple already shipped Metal version 1 a full year before
| Vulkan was even an idea.
|
| This is only true if you forget how Vulkan came about.
| troupo wrote:
| My timing is only a bit off.
|
| Apple released Metal in 2014
|
| Vulkan as a project was started a month later, also in
| 2014. Officially announced in 2015. First version
| released in 2016.
| pjmlp wrote:
| Playstation has two API, GNM and GNMX, low level and high
| level variants.
|
| Switch does have OpenGL 4.6 and Vulkan support, however if
| you want the full power of the games console, you need to
| use NVN instead.
| jakogut wrote:
| Linux market share is considerably ahead of macOS according
| to the Steam hardware survey. Just this past month, Linux is
| sitting at 2.32% compared to macOS at 1.47%.
| kelnos wrote:
| Genuine question: is it actually reasonable to compare
| desktop/laptop OS market share with handheld market share?
| Like... what does that actually tell us? I suppose in the
| case of gaming it can be useful, since at this point more
| games are played on Linux (due to SteamDeck) than on macOS.
| But otherwise, I always get a weird feeling when someone
| lumps these stats together.
|
| I guess part of the weirdness I feel is when people say
| "Linux is the most used OS in the world" because of all the
| Android devices floating around, which is super misleading,
| since "Linux" isn't really an OS on its own anymore.
| (Technically it never was, but I'm not one of the
| "GNU/Linux" pedants, so...) Android and GNU/Linux are very
| distinct, very different OSes, so it makes no sense to lump
| them together. "Linux is the most-used kernel in the world"
| is a more accurate statement, but, again, I'm not really
| sure what that actually tells us in practical terms.
| jakogut wrote:
| I think it is actually a reasonable thing to compare.
| I've had similar thoughts on the Android comparison. Yes,
| Linux is the most widely used _kernel_ in the world, but
| that doesn 't mean that desktop GNU/Linux is up to the
| same level of usability. That doesn't mean that desktop
| GNU/Linux would provide a good touchscreen experience on
| a tablet. It _could_ , but the entire userspace software
| stack is completely different.
|
| I think what it _does_ indicate is that the kernel is
| featureful, stable, extensible, reliable, and a good base
| to build products and services from.
|
| SteamOS on the Steam Deck is a close cousin of desktop
| GNU/Linux, purpose built for gaming. It might be a
| handheld, but it's also a _PC_. I think the popularity of
| the device tells us that the compatibility of Linux with
| Windows software, games especially, is good enough for
| the average person. It tells us that people are willing
| to tolerate a bit of a learning curve and some
| differences to what they 're accustomed to so long as the
| value is there, and 95% of things just work.
|
| It's also worth noting that many Steam Deck users
| _choose_ to continue using SteamOS, based on Linux, to
| run their Windows games, in spite of the fact that their
| device will also run Windows.
| exitb wrote:
| In this case it seems fine, as SteamDeck is not very
| distinct from a regular PC and SteamOS is really just a
| Linux distribution. Anything compatible with SteamDeck
| can be ran on other Linux installations, as well as other
| form factors.
| duped wrote:
| Gaming on MacOS isn't _hard_ , it's just _bad_.
| talldayo wrote:
| It's kinda both. I think there's ample demand and
| opportunity to create a simplified Asahi install script
| optimized for pushbutton gaming. The biggest constraining
| factor is disc space.
| flohofwoe wrote:
| Supporting a different 3D API is really not the complicated
| or time consuming part of porting a game to another platform,
| especially when the target API is Metal.
|
| The poor game support on macOS is a mix of Apple apathy
| towards gaming and the low potential sales numbers.
|
| Also, of the few new Vulkan apps being released (a whopping 9
| in 2023), most actually only support a single platform:
|
| https://carette.xyz/posts/state_of_vulkan_2024/
|
| Apple also offers a D3D12 porting toolkit now (basically
| D3D12 running on top of Metal, same thing like Proton is D3D
| running on top of Vulkan) which business-wise makes a lot
| more sense than native Vulkan support since there are many
| more D3D12 games than Vulkan games:
| https://developer.apple.com/games/
| johnnyanmac wrote:
| >Supporting a different 3D API is really not the
| complicated or time consuming part of porting a game to
| another platform, especially when the target API is Metal.
|
| If you have a graphics programmer on hand, no. The vast
| majority of indie devs are powerless in that domain,
| though. I don't see many attempts out there to make it
| easier for them either.
|
| Maintenance is always the time consuming part, be it simple
| or complex work. People aren't going to support Linux even
| if Vulkan theoretically makes it straightforward, because
| the time needed to maintain it isn't worth the lack of
| customers. Steam + Proton gives even less incentive to
| bother. So that advantage doesn't translate to much
| business value when evaluating DX12 vs. Vulkan.
|
| This is an issue going all the way back to the OpenGL vs.
| D3D days. Nothing fundamentally changes as long as
| Microsoft completely swamps the PC gaming market.
| flohofwoe wrote:
| If you have somebody on the team who was able to write a
| Vulkan rendering engine, then that same person can also
| easily pop out a Metal port ... just be careful, that
| person probably never wants to touch Vulkan again
| afterwards ;)
|
| Otherwise I would expect that the game either uses a
| library which abstracts away the differences between the
| system 3D APIs (shameless plug:
| https://github.com/floooh/sokol, but also BGFX, WebGPU or
| AFAIK SDL3 is also getting a cross-platform 3D API), or
| uses a complete game engine like Godot, Unity or Unreal.
|
| > Maintenance is always the time consuming part
|
| _This_ is the only thing that matters, it 's not the
| initial port that's the problem, but the long term
| maintenance and customer support and that often doesn't
| make business sense on non-mainstream platforms like
| Linux or macOS. But a cross-platform 3D API doesn't make
| any of that easier (you'll still have to struggle with
| driver bugs for instance, or just plain weird
| configurations, especially on Linux systems - unless
| going through Proton which I'm sure works around a ton of
| compatibility issues and driver bugs under the hood).
| talldayo wrote:
| > it's not the initial port that's the problem, but the
| long term maintenance and customer support
|
| Which is why I ask; which should we prefer, a native port
| that Apple will depreciate for some reason or a
| community-supported translation layer that's based on a
| reasonable cross-platform standard?
|
| I owned an iPhone, I know that the apps you pay for all
| eventually break, and instead of fixing it Apple will
| only tell you to complain to the developer. Compare that
| to Steam, where I can still play Far Cry 2 and Fallout:
| New Vegas in perfect emulation, likely for the
| foreseeable future.
| pmarreck wrote:
| > the low potential sales numbers
|
| All sales are initially low before a market is grown.
|
| If Apple wanted a machine that was also a great gaming
| machine, they could have that, and that market would then
| grow. The fact that they even have a gaming market at all
| left, shows that the appetite is there. (Of all the
| machines I have it installed on, Baldur's Gate 3 for
| example looks best on my Mac screen thanks to the HDR
| stuff)
| talldayo wrote:
| > Apple also offers a D3D12 porting toolkit now
|
| _Now_ they do. After 5 years of people begging them for
| DXVK, Apple gives us... a downstream fork of DXVK retooled
| for Metal.
|
| I really just feel bad for Mac owners. Like; you _could_ be
| playing Apex Legends with us, but can 't. Like I said,
| these changes to Asahi will likely make it easier than
| MacOS to play games on. Who would use MacOS for gaming when
| Steam Play works out-of-box on Linux? A masochist, I say.
| dieortin wrote:
| I doubt anyone buys a Mac to install Asahi on it
| talldayo wrote:
| We'll just have to see. Do you think that will still be
| true when compliant Vulkan 1.3 drivers exist, and Asahi
| users get to play anticheat-enabled online games?
|
| I remember a lot of Mac users that paid for Bootcamp for
| this very purpose, back in the day. It might even be
| _more_ appealing since Asahi is free.
| DeathArrow wrote:
| >Really just drives home how big of a mistake it was ignoring
| Vulkan for the past decade on Apple's behalf, but lord knows
| they won't admit that until it's too late.
|
| Even if Apple supported Vulkan that doesn't mean AAA games
| would be ported to Mac soon. AAA require beefy GPUs and Apple
| silicon isn't going to match Nvidia.
| sspiff wrote:
| AAA can make use of beefy GPUs, but equally it can run on
| more pedestrian hardware.
|
| If AAA games sold only to those with desktops and high end
| graphics cards, PC gaming would have died a long time ago.
| Even today, many games run fine on Pascal era graphics
| cards, and they certainly run fine on mid range laptop
| versions of Nvidias 4050 & 4060.
|
| Apples silicon can keep up with those, plus the simpler,
| less diverse hardware on Mac would probably lead to better
| optimisation if the market was big enough.
|
| I'm not saying Vulkan is the only thing holding gaming from
| Apple computers, because I think the control Apple has over
| software distribution on Mac is also something that scares
| large publishers away from investing in the platform.
| filleduchaos wrote:
| I don't think I know a single AAA game released in the past
| decade that _requires_ a beefier GPU than Apple ships. It
| would be complete financial suicide for a studio whose
| development budget runs in the tens and even hundreds of
| millions these days) to limit their customer base to the
| relative handful of gamers who have their hands on the
| latest and greatest graphics cards.
| lonjil wrote:
| You've got it backwards. Before M1, most Macs that regular
| consumers owned were incredibly bad GPU-wise. M1 was an
| enormous upgrade and finally made Mac usable for gaming for
| the average Mac owner. But years of most Macs being useless
| for gaming drove the game devs away.
| talldayo wrote:
| Unfortunately, I don't think simply having a powerful GPU
| is enough to make people care. The M1 is almost 5 years
| old now, and I haven't seen a single major games studio
| go out of their way to target Apple Silicon. If anything,
| people are giving up on the platform now that OpenGL is
| more or less entirely broken and Metal is mandatory.
| Porting to MacOS is like committing to a console
| ecosystem where things constantly change and _you 're_
| expected to pay the price. Windows developers don't like
| that; they want to push one build out and support it for
| the next decade.
|
| Hope springs eternal, but there's a _reason_ we want
| Vulkan. Native gaming on Mac is awful; it is quite
| literally the worst gaming experience you can have
| between Linux and Windows, both of which can run DirectX
| games without issue. If we had functioning Vulkan drivers
| on Mac, we wouldn 't be begging and grovelling for games
| to work; they just would, like on Steam Deck.
| nox101 wrote:
| Vulkan is the arguably worst of the modern GPU APIs. It's not
| all that portable since you have to check for sooo many
| differences in architecture. It requires the most amount of
| manual synchronization. It lacks a higher-level shading
| language (you generally have to pick a library that
| implements some other higher level language and let it
| generate SPIR-V for you and pray it works portably).
|
| Except for projects like this, Vulkan really only exists on
| Linux and Android. It'a not really a thing on Windows. Sure,
| some games are using it, but they're like 1% or less.
|
| Metal is arguably the best of the 3 APIs, though of course it
| was easier to do without having any legacy behind it and
| without being designed by committee.
| talldayo wrote:
| > It's not all that portable since you have to check for
| sooo many differences in architecture.
|
| And... Metal is better in this regard? I'd take SPIR-V
| generation for two target architectures over a complete
| render overhaul any day of the week.
|
| > Metal is arguably the best of the 3 APIs
|
| Then what harm is there in offering Vulkan alongside it?
|
| If Metal is the obviously superior choice, there should be
| no problem doing the same thing Microsoft does by allowing
| developers to use both. Why is Apple afraid of letting
| their APIs compete?
| DiskoHexyl wrote:
| Lack of Vulkan support is just one (small) reason gaming
| doesn't really exist on Mac.
|
| IMO it's more down to Apple's historic view on videogames and
| software compatibility in general- they are okay with
| frequently breaking things (like they did with 32bit apps)
| and expect developers to just constantly accomodate that.
| With a giant iOS market and its deluge of relatively small
| free-to-play/service-based games, it's a worthy model for
| devs to pursue (until the game is unprofitable, and then, in
| a couple of years, it's delisted as incompatible).
|
| For a more traditional desktop/console style gaming, where a
| long tail is expected, with little further support, it's a
| tough proposition to release on a platform that has a
| miniscule market share AND constantly breaks. Its own
| graphics API is just a cherry on top, I think
| aurareturn wrote:
| I wonder if this effort to add Vulcan to Linux and then translate
| DirectX in Asahi Linux would impact Apple's dream of landing AAA
| games on Apple Silicon.
|
| Apple would like AAA developers to port their AAA games over to
| Metal so that the game has one code base but can run on iPhones,
| iPads, Macs, and the Vision Pro.
|
| Perhaps Mac gamers will install Asahi Linux in order to play AAA
| PC titles.
| littlecranky67 wrote:
| > would impact Apple's dream of landing AAA games on Apple
| Silicon
|
| Apple's dream is not to have AAA games land on Apple Silicon -
| they can do this with Proton-like layer, like they did with
| GPTK. Apple's wet dream is to have AAA games land in the _Apple
| App Store_ - not on Steam or Epic Game store. That is why the
| GPTK effort is only have assed (and the license prevents Valve
| integrating it into steam directly).
| babypuncher wrote:
| > Apple's wet dream is to have AAA games land in the Apple
| App Store
|
| This is why their efforts are largely doomed.
|
| I'd love to play more AAA games on my Macbook, but too many
| of them require a _separate_ purchase from the App Store to
| make that happen, rather than just putting the Mac versions
| on Steam alongside the Windows version.
|
| If you're going to make me choose between playing a game on
| my laptop and playing it on my gaming desktop, I will choose
| the desktop every single time. It would be _nice_ to take
| more of those games with me when I travel, but it 's not a
| frequent enough use-case for me to give up all the benefits
| of real PC gaming.
| littlecranky67 wrote:
| > This is why their efforts are largely doomed
|
| I'm not as certain about that as you are. I think there are
| - as always - different streams withing that mega
| corporation. It is probably sales-oriented people wanting
| nothing but AAA games on the App Store and be okay with the
| Mac not being a major choice for games if that doesn't
| happen. The other stream is probably more enthusiastic
| (especially with the Apple Silicon being "enough" gaming
| machines for 1080p@60) and wants to bring gaming over -
| that is probably the stream that made GPTK happen and give
| a licensing exception to crossover to be able to integrate
| it in their department. I'm in the later department, hoping
| we will see a proton-like GPTK that can run my steam
| library.
| babypuncher wrote:
| > hoping we will see a proton-like GPTK that can run my
| steam library.
|
| I would absolutely LOVE this! I also know a lot of people
| who would be a lot more interested in buying a Macbook if
| this were a thing.
| littlecranky67 wrote:
| Well regarding the Macbook/Laptop case vs. Desktop: With
| me typing this on the MacMini M2 base model (8GB/256GB)
| retailed at 650EUR I can assure you, it is a nice gaming
| machine hardware-wise. Not for latest and greatest AAA
| games of course, but I played through all the Tomb Raider
| reboot games on this machine (using Rosetta2 as they are
| non-native on Steam) on High details with 1080p. Now the
| major issue is _software_ , there is just not enough
| games available. I do use Heroic+Crossover Wine to run
| some other games, but it is just finnicky and only for
| the pro user - not average casual gamers.
|
| Saying this, Apple could launch a 999EUR Mac Mini with
| focus on gamers with a custom M4 design soon, if they had
| a proper Proton-like layer. Heck, size & noise wise, the
| Mac Mini beats the current PS5 and Xboxes. But they only
| treat GPTK as a solution for developers, not gamers. And
| I highly suspect, this is only due to the fact that they
| won't get any percentage from games sales, as Steam is
| the dominant player here.
| behnamoh wrote:
| What do we do as Apple users stuck in this ecosystem whose
| main goal is to extract more money from our pockets? I hate
| Windows with all my gut but at least I had a sense of
| freedom about the software I wanted to install on Windows,
| including games.
|
| On Mac, I'm constantly reminded that beyond this facade of
| user-friendly UI and nice visuals, there's a greedy company
| whose market cap is $3T but doesn't give a flying f* about
| the end-user because it wants to make even more money.
| bsder wrote:
| > What do we do as Apple users stuck in this ecosystem
| whose main goal is to extract more money from our
| pockets?
|
| Leave ... the ... ecosystem.
|
| This is the _whole point_ of things like Asahi Linux.
| Take advantage of the hardware and escape from the
| software.
|
| If all the developers who slave over Apple devices spent
| 10% of their time improving the experience on _something
| else_ , 24 months later Apple wouldn't have a market.
|
| I left. I got tired of fighting bugs in macOS given that
| Apple clearly no longer gives a damn about macOS.
|
| I just bought my second Lenovo Carbon X1 after leaving
| Land-Of-The-Fruit. This one is about $1700 + a Saumsung
| 4TB SSD. Note: I can _actually upgrade the SSD_. It has
| 32GB of RAM for _half the price_ of anything equivalent
| in macOS. The OLED display is right about the equivalent
| macOS resolution, and it 's a _matte_ display. It has a
| useful set of ports--a goddamn HDMI port as well as 2
| USB-C _and_ 2 USB-A ports.
|
| And Lenovo's external dock _actually freakin ' works_.
|
| Yeah, it probably doesn't get the performance or battery
| life as an M3. Given that I didn't notice on my previous
| Lenovo vs an M1/M2, I'm not likely to notice this time
| either.
|
| And, as a "bonus", I can run an actual Windows install if
| I absolutely must.
| Almondsetat wrote:
| What has proton got to do with x86 -> ARM ?
| littlecranky67 wrote:
| x86 -> ARM is already done by apple (rosetta2). What they
| need is a wine layer to mimmick the Windows API to allow a
| large amount of existing games to run on macOS _without_
| the devs porting. Which DOES exist, it is called crossover
| (and uses wine and GPTK). But it is a 3rd party company.
| snarfy wrote:
| Your comment puts it very succinctly.
|
| They don't care about your gaming experience on Mac. They
| care about money.
|
| I wish they weren't so short sighted here. They can't see
| through the trees that maybe they won't make money selling
| games through the app store, but they would make money
| selling more Macs.
| rched wrote:
| Seems like the opposite is true. If their primary
| motivation was more App Store sales why not allow GPTK
| games only through the App Store?
| MBCook wrote:
| They didn't really care about it before the Mac App Store
| either.
|
| The OS and its libraries just aren't designed for high
| performance gaming the way MS has put time into that on
| Windows.
|
| They have Metal, which is supposed to be nice. But that's
| their Direct3D. Where is all the other DirectX equivalent?
|
| From what I've heard anecdotally that seems to be a big
| part of the problem. It's not just that they don't have
| Vulcan (which I think is a red herring). Or the GPUs were
| abysmal (they were on most models before Apple Silicon).
|
| There's no whole-picture. Just pieces.
| skrrtww wrote:
| This is a bit of a tangential rant, so I apologize. But I
| recently tried to update Death Stranding, the flagship AAA
| game that Apple landed on macOS and in the App Store. The
| game itself is 77.5 GB; it had required a little over 150 GB
| to install. I shrugged that off at the time; they haven't
| figured out how to decompress on the fly, whatever.
|
| I had about 50GB free on my (1 TB M1 Max) machine at the time
| of the update, and the App Store told me I didn't have enough
| free space to update. I balked and looked at the update
| description, which was just "Various minor bug fixes." The
| update size was...75 GB. They expect me to re-download the
| entire game for various minor bug fixes.
|
| (I would "just blame the developer" here, but Apple clearly
| invested a lot into having this game available on macOS, in
| the App Store, and got Hideo Kojima to show up at WWDC (a
| full year ago, remember) and brag about how nice the entire
| experience is. Some of Apple's engineers probably worked
| directly on this port.)
|
| It then sunk in that I didn't just need 75 GB of free space.
| I needed 150 GB. The App Store will completely download and
| completely decompress the entire game before replacing it.
| That is the patching process for the game. You need 231 GB
| free at all times on your machine to have and update a 77GB
| game.
|
| This is completely insulting given Apple's storage prices,
| and the fact that the App Store _does not let you install
| apps on an external drive._
|
| Apple clearly doesn't get it. They act like they're nominally
| putting in the effort, but then it's still just completely
| half-assed even when things are played exactly like they
| want.
| coldpie wrote:
| There's like, two guys at Apple who care about gaming.
| Everyone once in a while they manage to convince marketing
| to say something about it and rope in a couple more devs to
| half-assedly hammer out some tickets before they can go
| back to their normal tasking. There's no traction
| internally to taking PC gaming seriously at Apple.
| astrange wrote:
| You don't need indoor hobbies when the weather is this
| nice.
| talldayo wrote:
| Boldly typed
| saagarjha wrote:
| It's the warmest first week of June in a while in
| Cupertino, so I have no idea what you're talking about
| with regards to nice weather.
| astrange wrote:
| Well, Apple employees don't actually live in Cupertino.
|
| (I once went to a city council meeting where residents
| showed up and complained that new housing might allow
| Apple employees to live there and that they might be "too
| poor". Probably would be too.)
| MBCook wrote:
| From what I've heard there are a ton more than 2. But
| none of them have the power.
| bitwize wrote:
| > I had about 50GB free on my (1 TB M1 Max) machine at the
| time of the update, and the App Store told me I didn't have
| enough free space to update. I balked and looked at the
| update description, which was just "Various minor bug
| fixes." The update size was...75 GB. They expect me to re-
| download the entire game for various minor bug fixes.
|
| It is an unfortunate truth that one must now bear in mind,
| that games are for all intents and purposes enterprise
| software. They are as critical to profitability for the
| companies involved as enterprise software. They are large,
| distributed applications which are planned, budgeted, and
| staffed much like enterprise software. Accordingly, there
| is little to no concern for performance except when it's
| absolutely critical: the rendering pipeline and the
| netcode, for instance. For things like updates, where it
| would be easy to make some optimizations to reduce download
| size, those optimizations will not be taken. So you will
| redownload the entire game, including all of the
| _uncompressed_ audio clips, every time someone changes a
| byte somewhere and it 's shipped as an update.
| tomovo wrote:
| Steam updates are often in the order of kilobytes.
| Clearly it can be done.
| bitwize wrote:
| It can be done, and Valve are old-school gamedev bros who
| clearly are interested in making it happen for games on
| their platform. But not every shop is like that, and in
| particular I wince when I contemplate updating a PS4
| game...
| tracker1 wrote:
| You need to buy a new mac so you can pay $200 per 256gb of
| storage.
| crazygringo wrote:
| Wow. Truly that's bizarre.
|
| Clearly the App Store was never meant for distribution of
| 75 GB games, it's clearly meant for mostly <~1 GB packages.
|
| I'm surprised they even allow huge apps like that in the
| first place, and don't have e.g. a 5 GB hard limit for
| usability reasons. They _should_ have a limit if they 're
| not going to support patch upgrades.
|
| Who the heck has 231 GB free on their Mac internal SSD?
| Almost nobody. Why would the developer even distribute this
| via the App Store at all, for such a miniscule user base?
| PokestarFan wrote:
| Xcode used to be absolutely massive, being 10GB+ a few
| years back. They seemed to have done a better job at
| making it smaller.
| kmeisthax wrote:
| This is a problem even for macOS updates, ever since they
| moved to the sealed system volume in macOS 11. When you
| update macOS, it downloads the entire OS and installs it to
| a separate APFS snapshot. The infuriating thing about this
| is that the sealed system volume should actually make it
| _easier_ to provide reliable delta updates, but instead
| they used it as an excuse to remove them.
|
| And of course Apple's always treated app updates as
| "download entire new copy of app to separate container and
| relaunch", ever since day one of the iOS App Store. This
| too could be handled with APFS snapshots.
|
| I really wish Apple - and the rest of the industry - would
| stop being so damned allergic to delta updates. It's
| infuriating knowing how much damned engineering effort,
| say, Google put into shipping deltas on Chrome, and then
| everyone else is "just download two copies of every app
| while you're updating them, bandwidth and storage is free
| if we don't pay for them".
| saagarjha wrote:
| I am pretty sure App Store updates are smarter than that.
| For example Xcode delta installs have taken far less
| space (though they take a lot longer) if you grab them
| from the App Store.
| trissylegs wrote:
| I just rember back when my internet was 512 kbps down and
| iTunes would have a minor bugfix update over >100 MB which
| would take over an hour.
|
| I'd just not update iTunes ever.
| rched wrote:
| This makes no sense to me. Apple does nothing to prevent AAA
| games on the App Store also being released on Steam. I think
| it's more likely that the GPTK license is to encourage
| developers to make high quality native ports rather than devs
| checking a box to make their game available on Mac.
| jandrese wrote:
| For whatever reason Steam just doesn't seem very popular
| with Mac users.
|
| In the latest Hardware survey Mac users were outnumbered by
| _Linux_ users by 50%.
|
| https://store.steampowered.com/hwsurvey/Steam-Hardware-
| Softw...
| jorvi wrote:
| Apple killed support for legacy 32-bit applications a
| good while back, which killed support for virtually every
| Mac game port.
| vanchor3 wrote:
| The funny thing is most games in my library say they
| won't run on macOS because they're 32-bit applications,
| and they won't show up in my library when filtering by
| "Mac". But they all run perfectly fine, so they're
| obviously 64-bit. I think I heard once that they all
| default to 32-bit unless the developer says otherwise...
| coldpie wrote:
| It's because Apple told Steam users to fuck off like 3
| times in 5 years (nuking 32-bit support; no Vulkan/OpenGL
| support; switching to ARM). Users and game devs got the
| message Apple was sending loud & clear.
| robertoandred wrote:
| 32-bit is the only change that actually broke anything,
| and it had been deprecated for a decade.
|
| 64-bit OpenGL/x86 games work fine on ARM.
| scheeseman486 wrote:
| Will x86 games work in 2 years? Will OpenGL? What about
| in 3 years? 5? Then what happens to Valve's Apple owning
| customers purchases?
| nozzlegear wrote:
| I play games on my Mac, but I don't use Steam. I just
| play World of Warcraft which is a native Apple Silicon
| game, and a few other games that don't require Steam.
| vanchor3 wrote:
| I'm sure it doesn't make a big difference but the issue
| with this is it doesn't count Mac users using
| CrossOver/Whisky because they get detected as Windows
| users, while Linux users with Proton are reported as
| using Linux.
| Aerbil313 wrote:
| From what I've seen, for some reason, the people who buy
| a Mac are not the people who game. College students
| buying for schoolwork, business people buying for (I
| assume?) excellent battery life and resulting
| portability, and graphics/video/music creators. The two
| Venn circles just don't overlap.
| AltruisticGapHN wrote:
| I don't get it. They already make a ton of money on mobile
| games - why not embrace Steam and Proton on their platform?
| What's the money in AAA games on their platform?
|
| edit: this is to say if they had "wet dreams" about selling
| AAA games on Mac, we'd have seen the tides moving a long time
| ago.
| viraptor wrote:
| Buying from Steam doesn't give them the appstore cut. And
| nobody buys Macs for gaming, so it doesn't drive hardware
| sales either.
| _carbyau_ wrote:
| What I don't get is that games compete in the attention
| market and are a big money industry next to movies and TV.
|
| Apple is happy to produce its own movies and tv shows but
| not AAA games?
|
| Or maybe they have and I simply didn't see that blip, I am
| honestly not in sync with Apple gaming world.
| Aerbil313 wrote:
| Apple wants to own the entire computing stack for the
| average Joe, for legitimate integration reasons and
| illegitimate monopolistic market capture reasons.
| aurareturn wrote:
| Apple's wet dream is to have AAA games land in the Apple App
| Store - not on Steam or Epic Game store.
|
| This is implied already when I said Apple wants the AAA game
| to be on iPhone and iPad. By definition, the game has to be
| on the App Store.
| jppittma wrote:
| The only way I can see that happening is with an EEE model.
| You'd go grab all of the non-steam publishers and come up
| with a standard format that'd mean that studios can push to
| every platform in a standardized way, then bank on nobody
| bothering to install steam because the app store already has
| all of the games you want, and it's installed by default.
| rowanG077 wrote:
| If Apple truly wanted that they could simply implement Vulkan.
| galad87 wrote:
| Why Vulkan? Let's implement DirectX directly and call it a
| day.
| babypuncher wrote:
| Vulkan is how Direct3D is implemented on non-Windows
| operating systems, thanks to DXVK.
| galad87 wrote:
| I know, but why make a Direct3D wrapper on Vulkan when in
| the end you are going to run only Direct3D games anyway.
| babypuncher wrote:
| Because DXVK already exists, and you do still want to run
| Vulkan anyways. There are AAA games out there using it
| instead of Direct3D. Natively re-implementing Direct3D
| APIs would be a tremendous amount of work for little or
| no real benefit.
| kbolino wrote:
| Direct3D means only Windows and Xbox. Vulkan means
| everything non-Apple except Xbox and PlayStation. It's
| not everything, but it's a larger base.
| galad87 wrote:
| What's larger than Windows + Xbox + Playstation for AAA
| games?
| kbolino wrote:
| No single 3D API is capable of supporting all 3 of those
| platforms. However, if those are the only 3 you're
| concerned with, then Direct3D gets you farther
| (Windows+Xbox) than Vulkan (Windows only). You're still
| going to have to write/use something different for
| PlayStation (which has its own custom API).
|
| The two major platforms that _favor_ Vulkan are Android
| and Switch, but the former is in the "mobile" category
| rather than the "desktop/console" category and few games
| overlap both categories.
|
| But really, Asahi Linux on M1 Mac is about as niche as
| you can get, so broad hardware support for native APIs
| isn't really relevant, and I don't think AAA games are
| necessarily what's meant to be supported either, since
| they generally won't work for other reasons (can't
| install x86-64 Windows kernel driver DRM/anticheat on an
| ARM Linux machine).
| rowanG077 wrote:
| AAA gaming is THE driving factor for getting Vulkan on
| Asahi. There really are only a tiny subset of games that
| require a kernel anti cheat. Let alone the wealth of
| single player games.
| kbolino wrote:
| I'd love to hear about all these DRM-free single-player
| AAA games. If you're talking about older games, then
| maybe we're just talking past each other; I assumed we
| were talking about _recent_ AAA games.
| rowanG077 wrote:
| They don't have to be DRM-free.Here you can play all of
| these on linux: https://www.protondb.com/explore
|
| Highlights include Elden Ring, Baldurs Gate 3 and God of
| War.
| kbolino wrote:
| I upvoted for the link, which is useful to me, but I'm
| not sure this means Steam and all of those games will be
| able to run on Asahi/M1.
| rowanG077 wrote:
| No one can look into the future. But Fex + Vulkan
| definitely have the goal of being able to run those
| games.
| babypuncher wrote:
| Recent AAA games absolutely run on Linux using Proton.
| DRM isn't really a concern. The biggest and most
| successful DRM vendor, Denuvo, even goes out of their way
| to make sure their product does not interfere with Proton
| compatibility.
|
| It's pretty rare for a new game to come out and not be
| playable on the Steam Deck within a week if not on day 1.
| And when that does happen, it's usually a PvP multiplayer
| game with kernel-level anticheat.
| kbolino wrote:
| I'd assume Denuvo DRM works on Linux x86-64 because the
| company has made it work on that platform. I'd be
| surprised, with FEX in the middle, if it doesn't get bent
| out of shape running on ARM: either flagging itself as
| having been tampered with, or the game. Maybe the company
| also has a solution for ARM support though.
|
| I do think the question of "why Vulkan" has been
| thoroughly answered though: 1. DXVK means
| Direct3D->Vulkan translation already exists (but not the
| other direction) and 2. Proton already proves that Vulkan
| gets you most AAA games (with the exceptions having
| nothing to do with the 3D API).
| treyd wrote:
| Microsoft would never allow them to use the trademark.
| jeroenhd wrote:
| While that's true, I don't think they'd need the
| trademark. They can call it Apple StraightforwardY,
| duplicate any trademarked APIs and redirect the old ones
| to their own methods for "compatibility". The Oracle v
| Google lawsuit proved that APIs can be implemented, even
| by competitors.
|
| I see even less incentive for Apple to concede defeat and
| implement Microsoft's API than for them to port Vulkan.
| After all, they've already shipped a graphics engine that
| a handful of games have ever used with their OS so they
| have experience!
| rowanG077 wrote:
| Why would apple Implement an API they have zero control
| over? That's just stupid. In contrast Apple already is a
| member of khronos and you get DirectX for free anyway if
| you have Vulkan due to dxvk. There are only downsides to
| implementing DirectX.
| jakogut wrote:
| There are already high quality implementations of every
| version of Direct3D released over the past couple decades
| built on top of Vulkan.
|
| Writing a Vulkan driver is purportedly a much easier task
| than for higher level graphics APIs like Direct3D/OpenGL.
| andrewmcwatters wrote:
| Direct3D 12 is basically Vulkan.
| wmf wrote:
| Apple already released the Game Porting Toolkit.
| mort96 wrote:
| For some reason I'm completely unable to find its license
| through Google (I swear I used to be able to find this sort
| of stuff with search engines...); but I remember it being
| extremely prohibitive, to the point where even using it for
| personal use to play Windows games is illegal. It's only for
| use by game developers as a tool to help them on the road to
| port their games to macOS.
| talldayo wrote:
| ...which, unlike DXVK, cannot be redistributed with your app
| to make it playable on MacOS. So, by definition, Game Porting
| Toolkit is a mandatory extra-step for Mac users when Linux
| and Windows users press the little green "Play" button on
| their screen.
| AltruisticGapHN wrote:
| Pretty much, Asahi Linux could become the new Bootcamp for Mac
| users who dual booted to play games.
|
| FWIW I played Diablo II Resurrected on a M1 with "Whiskey". I
| was quite impressed that I was able to play a native Windows
| game just like that. It doesn't work anymore just because a
| stupid Blizzard launcher update now crashes and prevents
| starting the game.
|
| I also ran EverQuest II admittedly an old DX9 game but still
| the game ran beautifully on a M1 mac mini at 1440p.
|
| Linux Asahi may help also with older x32 titles like Guild
| Wars.
| thehias wrote:
| Just buy Crossover, then Diablo runs fine on MacOS again!
| Tehnix wrote:
| I've been playing Diablo 4 and Diablo II Resurrected on
| Crossover ever since Whisky didn't work with Battle.net
| anymore. It's been working great tbh!
| drpossum wrote:
| Can someone explain how this relates to MoltenVK? This just
| removes the need for it as it's a native driver?
| gary_0 wrote:
| This is for Vulkan on Asahi Linux on M1 Mac hardware. MoltenVK
| provides Vulkan on top of Metal on MacOS.
| rowanG077 wrote:
| MoltenVK translates metal to vulkan. Metal is the main graphics
| API on OSX (and iOS). This is a native vulkan implementation on
| linux. The blog post itself mentions that as well. This can't
| run directly on OSX so it won't remove the need for MoltenVK.
| Tiberium wrote:
| MoltenVK is an implementation of Vulkan based on Metal so that
| it can be used on macOS to run Vulkan applications. Asahi Linux
| is an in-development Linux distribution to make Linux
| compatible with Apple's M series processors. This specific blog
| post is about making GPU-accelerated Vulkan work on Asahi.
| AltruisticGapHN wrote:
| And I think the point is they will then be able to support
| DXVK to run Direct3D games.
| pantalaimon wrote:
| This is about Vulcan on Linux, not macOS
| jandrese wrote:
| Their shaders contain a peculiar construction:
| if (condition) { while (true) { } }
| condition is always false, but the compiler doesn't know that.
|
| What is the purpose of this other than to be a poison pill for
| people writing compliant shader compilers?
| tombh wrote:
| Is this how shaders "panic"?
| zamadatix wrote:
| Isn't the main point of tests to be poison pills for people
| writing compilers so they can ensure any shaders passed to the
| compiler don't break it? I.e. it's not that the specific code
| is useful as is in practice but if a chunk of a shader ends up
| functionally simplifying to something like this in a particular
| instance your shader compiler still needs to handle it right
| even though it could be written better at that point.
| JakaJancar wrote:
| Maybe an edge-case in some codegen?
| nsajko wrote:
| The purpose of the construction could be to inform the compiler
| of the fact that the condition is always false, so as to enable
| the compiler optimizer more.
|
| Take a look at these features in C++, LLVM or Rust if you're
| not familiar with the concept:
|
| * https://en.cppreference.com/w/cpp/utility/unreachable
|
| * https://en.cppreference.com/w/cpp/language/attributes/assume
|
| * https://en.cppreference.com/w/cpp/memory/assume_aligned
|
| * https://llvm.org/docs/LangRef.html#unreachable-instruction
|
| * https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
|
| * https://doc.rust-
| lang.org/std/hint/fn.unreachable_unchecked....
|
| * https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html
|
| The infinite loop is effectively an unreachable instruction
| (reaching it is not allowed), and an unreachable instruction
| behind a branch effectively becomes an assume instruction.
| SomeoneFromCA wrote:
| No, it cannot, as while (true) {} is not UB and should not be
| optimized out. EDIT: oops, yes you are right, it is not c++
| after all.
| gigatexal wrote:
| When I grow up I want to be half as competent as her at
| programming. Holy smokes. Bravo.
| adastra22 wrote:
| Is any of this usable from within a VM? I dev on macOS and
| generally like it, but run a VMware image of Ubuntu for testing
| things. I do 3D graphics apps, and I'm not sure how good VMware's
| pass through is. Is the Apple Silicon GPU virtualized in the VM?
| Could I run this distro and get better graphics performance?
| thehias wrote:
| No you have to install native. Also Parallels is way better
| than VMware, if you want good 3D performance inside a
| Windows/Linux/MacOS VM on MacOS.
| adastra22 wrote:
| Parallels requires a separate license per machine. That
| restriction alone is a permanent non-starter for me.
| whitehexagon wrote:
| Amazing, I'd only just updated for ES 3.2 support. It feels like
| my M1 was built for Asahi! although to be fair I only booted
| macos once on it, probably during install, or by mistake!
|
| Anyway great work! and nice to have these detailed updates.
|
| Are any browsers supporting 'zero copy rendering' or still layers
| and layers of compositor stuff going on? I seem to recall also
| getting stuck with webgl2 transform feedback triggering read
| backs.
| zamalek wrote:
| Is it possible to remove MacOS entirely? This has me
| considering a mini for travel.
| IntelMiner wrote:
| MacOS is still needed for the various firmware updates and
| other components. But the Asahi installer seems to shrink it
| down to about 30GB which is acceptable
| dlachausse wrote:
| > It begins with a text.
|
| >
|
| > Faith... I think I want to write a Vulkan driver.
|
| >
|
| > Her advice?
|
| >
|
| > Just start typing.
|
| I love this part. It is such great advice and it applies to so
| many things that we want to do in life, but never start because
| we become paralyzed with fear due to what seems to be an
| insurmountable task.
| vramana wrote:
| Exactly me feelings. I am inspired by the work Asahi Linux team
| publishes. As a full stack developer, I feel very very distant
| from this part of the stack. Everything looks like greek and
| latin. Reading this post gives me hope. May be I can someday
| understand how the drivers are written, I leave my fear and
| start writing and reading code.
| ekianjo wrote:
| why use Fex instead of Box86?
| rowanG077 wrote:
| Box86 can't run on apple silicon. There is no 32 bit support.
| tombert wrote:
| A very large part of me is annoyed that Apple didn't open source
| Metal before Vulkan was released. OpenGL definitely was annoying
| to work with, but Vulkan is _impossible_ for the average user to
| do anything with; drawing a spinning cube takes several hundred
| lines of code, which I 've written and I still don't really
| understand!
|
| I realize that Vulkan isn't meant for a "humans" to write, it's
| basically meant to be a target, and that's fine, but it annoys me
| that you get people on forums that say "learn Vulkan instead"
| when people ask for help with OpenGL.
|
| Metal is substantially more fun to write than OpenGL or Vulkan; I
| haven't measured any performance stuff on it, but it certainly
| feels fast enough, and I've been able to do basic graphics
| experiments with it in way less time than I was ever able to
| accomplish with OpenGL or Vulkan.
|
| Still, whether or not it annoys me that Vulkan has become the new
| standard, portability of the standard is important, so obviously
| this announcement is a godo thing.
| hgs3 wrote:
| Please don't misinterpret this as gate keeping, but Vulkan is
| designed by and for professionals (not hobbyists). It is
| certainly not a rapid prototyping tool. Vulkan and OpenGL
| aren't comparable because Vulkan isn't merely a graphics API,
| but rather it's a low-level GPU API. For example you can use
| Vulkan in place of CUDA for running highly parallelized
| computations on the GPU (no graphics implied).
| tombert wrote:
| Yeah, I know, that's why I mentioned it being a target. I
| realize it's meant to be used for extremely low-level stuff.
| Which is fine, I don't get annoyed at x86_64 assembly being
| difficult to write.
|
| As I said, the thing that bothers me is when people act like
| Vulkan is a replacement for OpenGL (presumably because
| they've never actually written either and they just saw some
| YouTube demos), and it really isn't, or at least that's an
| incomplete picture. It's a replacement for OpenGL in the same
| way writing JVM bytecode directly is a replacement for Java;
| they fundamentally do the same or similar things, but one is
| sort of categorically different in its goal.
|
| I do wish that there was a more consumer-friendly API
| announced in addition to Vulkan though; I'm fine with
| replacing OpenGL with something newer and better-fitting for
| newer cards, but that's not what we got. That's why I was
| trying to say that I was annoyed that Apple didn't open
| source Metal, because I feel like it really could have taken
| that role.
|
| Also, while I'm aware that Vulkan doesn't inherently imply
| "graphics", I would also like to point out that CUDA and rocM
| are also considerably easier to write than the Vulkan
| equivalents, at least in the little examples I played with,
| though I will acknowledge that I felt Vulkan was better than
| OpenCL.
| hgs3 wrote:
| > I would also like to point out that CUDA and rocM are
| also considerably easier to write than the Vulkan
| equivalents
|
| I agree that Vulkan has more boilerplate, but I think
| that's because Vulkan is an open standard and makes fewer
| assumptions which means the API has more ceremony. For
| example Vulkan might be implemented for custom embedded
| hardware; its design helps give the manufacturer more
| leeway. CUDA and ROCm were designed by Nvidia and AMD for
| their own hardware and so they can bake in low-level
| assumptions which means a more streamlined API.
| tombert wrote:
| Well ROCm is more or less designed to be portable between
| both; that's not strictly true but it's fairly similar to
| CUDA so I don't know how much of that boilerplate is
| reduced by the fact that it's AMD specific. Your point is
| fair though; Vulkan kind of runs on almost-literally
| everything made in the last nine years or so, so it can
| assume basically zero about any kind of underlying OS
| stuff.
|
| Still, Vulkan has convinced me that I have no desire to
| work that low-level of GPU programming, as I had zero fun
| playing with it. I guess I like having one layer up of
| abstraction; I'm happy enough to write CUDA, and I'm
| happy enough to write anything higher level than that.
| garaetjjte wrote:
| >I do wish that there was a more consumer-friendly API
| announced in addition to Vulkan though
|
| Maybe WebGPU could be that?
| flohofwoe wrote:
| > but Vulkan is designed by and for professionals (not
| hobbyists)
|
| Vulkan is designed by committee, and that's its single
| biggest problem (and this was also the single biggest problem
| of OpenGL).
| andrewmcwatters wrote:
| > Please don't misinterpret this as gate keeping, but Vulkan
| is designed by and for professionals (not hobbyists). It is
| certainly not a rapid prototyping tool. Vulkan and OpenGL
| aren't comparable because Vulkan isn't merely a graphics API,
| but rather it's a low-level GPU API. For example you can use
| Vulkan in place of CUDA for running highly parallelized
| computations on the GPU (no graphics implied).
|
| This is bullshit and it doesn't mean anything. In the days of
| OpenGL, you used the same initialization code regardless if
| you were a "professional" or a "hobbyist." Code is code.
|
| It especially doesn't mean anything because people use CUDA
| for CUDA, and want to use Vulkan for graphics because OpenGL
| has been discontinued.
| dlachausse wrote:
| I wonder how feasible a Metal compatibility library wrapped
| around Vulkan would be? That way you could use Metal on other
| platforms.
|
| Also, what is the best resource for learning Metal if all you
| know is some OpenGL 1.x from the old "Lego" book?
| tombert wrote:
| > I wonder how feasible a Metal compatibility library wrapped
| around Vulkan would be?
|
| Sort of an inverse of the MoltenVK project? I don't see any
| reason why that would be infeasible other than "no one really
| wants this but me".
|
| > Also, what is the best resource for learning Metal if all
| you know is some OpenGL 1.x from the old "Lego" book?
|
| To be clear, I am not a graphics person, I'm a dude who dicks
| around with graphics occasionally to play with some kind of
| more graphical algorithm I read about, but I really don't
| know what I'm talking about.
|
| That said, I went through this book, It's good enough:
| https://a.co/d/b3yjPMp
|
| A former coworker of mine also wrote this one if you're
| interested in iOS game dev, though I have not read it so I
| cannot speak to its quality: https://a.co/d/c99oE0Q
| dlachausse wrote:
| Thanks! I always wanted to learn Metal, but it doesn't seem
| like there are many resources on it other than Apple's
| website.
| tombert wrote:
| I also think FNA is pretty cool as well. It's kind of
| "mid level" instead of low level, more or less like a
| light Direct3D. I think MonoGame is supposed to be
| comparable but I haven't used it.
| delta_p_delta_x wrote:
| Hacker News regularly makes me feel very stupid, and none more so
| than blog posts by Alyssa Rosenzweig.
|
| I couldn't even write an engine that _used_ Vulkan in six months,
| nor a software rasteriser; meanwhile, Alyssa wrote an entire
| compliant driver on a non-native operating system running on
| locked-down hardware in one month flat.
|
| What am I doing with my life?
|
| EDIT: I point this out because I'd eventually like to write GPU
| drivers too, having been fascinated by video games since I was
| like three.
| wmf wrote:
| You're making wrong comparisons is what you're doing. If you
| _had already written N game engines_ , could you write a new
| one in a month? Yes, right? Alyssa didn't spring from the head
| of Zeus fully formed; she has been developing GPU drivers for
| years. Pick something you want to work on and work on it for
| years.
| tcmart14 wrote:
| Yes, definitely want to back this up. Alyssa is definitely a
| really skilled and competent engineer. But she also has years
| of domain knowledge she has built up. That isn't to knock
| down her skill, but more of, don't let it demotivate it you
| because it too also took Alyssa time to get where she is.
| fermuch wrote:
| She is also great at communicating her advancements, which
| is a greatly useful skill to cultivate.
| tcmart14 wrote:
| That is something I was just thinking about a few moments
| ago. I've haven't watched any of Hector latest stuff if
| he is still streaming. But between Hector, Alyssa, and
| Asahi Lina, they all 3 are pretty motivated and pretty
| excited to share. Which is great and something I wish we
| had more of. It helps to demystify these systems some.
| For many, GPUs and graphics APIs are just black boxes of
| magic and it can be hard to get past that. But content
| like this helps to remove the black box and make it more
| approachable.
| TheAmazingRace wrote:
| More like just Hector and Alyssa. Asahi Lina isn't a real
| person, but more of a mascot.
| zeeveener wrote:
| You're living it the best you can with what you have. As the
| other commenter stated, you are making unfair comparisons.
| Focus on comparing your tomorrow self with your today self. As
| long as that comparison trends in the right direction, you're
| doing well.
| erichocean wrote:
| > _What am I doing with my life?_
|
| Not working on GPU drivers for third-party hardware?
|
| These blog posts are fun, but they're in the same genre as
| porting game boy emulators.
| a1o wrote:
| It takes more lines of code to draw a triangle in the screen
| with Vulkan than it takes to write a Gameboy emulator that
| can play Pokemon Blue. Vulkan is a modern stack, Gameboy
| isn't.
| xcv123 wrote:
| Wow. triangle.cpp 1181 lines (1048
| loc) * 56.2 KB z80.cpp 493 lines (440 loc)
| * 19.3 KB z80.h 37 lines (30 loc) * 720
| Bytes
|
| https://github.com/SaschaWillems/Vulkan/blob/master/example
| s...
|
| https://github.com/rasky/cz80/blob/master/z80.cpp
| phkahler wrote:
| >> Alyssa wrote an entire compliant driver on a non-native
| operating system running on locked-down hardware in one month
| flat.
|
| Well if it makes you feel any better, remember that she has
| spent a few years doing very in-depth work on other graphics
| drivers for this hardware so she knows the hardware, shader
| compilers, etc inside and out. There is also a full test suite
| for Vulkan and existing driver code for other hardware to start
| from. Nevertheless, you're still seeing a great programmer at
| the top of their game :-)
| braiamp wrote:
| No programmer ever work from zero. If you see the header files
| for the new drivers, most of them have multiple copyright
| information. The files themselves were "stolen" from other good
| drivers to reduce the amount of code that has to be rewriten
| and the potential bugs that could be avoided by simply reusing.
| jamesu wrote:
| Writing an engine from scratch is debatably more complicated
| since you need to do a lot of guesswork around what
| capabilities you actually need and how badly the artists and
| gameplay programmers will break everything - assuming your not
| doing it all solo.
| Sparkyte wrote:
| Experience is everything.
| Osiris wrote:
| I often also feel imposter syndrome. But it's also good to
| realize that some people are just better at things than others,
| others have more free time, more motivation, more experience,
| etc.
|
| Don't let other people's success bring you down.
|
| Of course I've been dealing with imposter syndrome my whole
| life because my older brother is a genius and it's taken me my
| whole 44 years of life to try not to compare myself to him.
| speedgoose wrote:
| Some people are simply better in most aspects. And it is
| fine.
| htatche wrote:
| Maybe you're just enjoying it rather than spending all your
| waking time writing code?
| anyfoo wrote:
| That's a big assumption. Alyssa may very well not spend all
| her walking time writing code (setting aside the implication
| that writing code is not "enjoyable" for now).
|
| Feynman was a very successful physicist. A nobel price
| medalist, among other things. He very famously was also
| someone who enjoyed a life outside of physics a great deal.
|
| Paul Erdos, on the other hand, did at least outwardly seem to
| have spent most of his life focused on doing mathematics. And
| nobody can convince me that he did not enjoy his life as
| well...
| thegrim33 wrote:
| One complicating factor is also there's a huge range of time
| required for different levels of quality.
|
| Something that's quickly hacked together with limited error
| handling, limited security, limited flexibility/reusability,
| vs. something very high quality and enterprise quality.
| lemoncucumber wrote:
| > I couldn't even write an engine that used Vulkan in six
| months, nor a software rasteriser; meanwhile, Alyssa wrote an
| entire compliant driver on a non-native operating system
| running on locked-down hardware in one month flat.
|
| Apple Silicon Macs are explicitly _not_ locked down, it 's just
| that the hardware is totally undocumented. This means that
| there's no jailbreaking necessary, just a lot of reverse
| engineering (which is still very difficult of course).
|
| From https://asahilinux.org/about:
|
| > Apple allows booting unsigned/custom kernels on Apple Silicon
| Macs without a jailbreak! This isn't a hack or an omission, but
| an actual feature that Apple built into these devices. That
| means that, unlike iOS devices, Apple does not intend to lock
| down what OS you can use on Macs (though they probably won't
| help with the development).
| __madness wrote:
| I sometimes feel like her success is driving me into madness, I
| feel like Salieri looking at Mozart when I look at her work.
|
| Here is the Alyssa timeline:
|
| * She started programming at ~3 with MIT Scratch. Her Father
| introduced it to her, he works at Intel and is a very
| successful person.
|
| * I think around age 11-12 she knew C very well, worked on some
| low level networking stuff for games, she wanted to make an
| MMO.
|
| * At 12 she made a project to convert LLVM IR to MIT Scratch.
|
| * She was involved with libreboot, not sure to what degree.
|
| * She was 15 when she worked to the open source RPI firmware.
|
| * Interned at FSF
|
| * I think she was ~16 when she developed the Panfrost GPU
| driver.
|
| I can't help but wonder how my life would be if I was a native
| English speaker. Lived in USA and had a great father and
| mentors like hers. I gave everything to programming, everything
| I have to give. Wonder if I am hitting the limits of my nature
| or just had worse nurture.
| bn-l wrote:
| It is brutal. Especially when you read about this:
| https://chesswizards.com/buzz/Chess-biography-the-Polgar-
| sis....
|
| And think if only I had a parent like this.
| internet101010 wrote:
| It's like being born a Gracie and starting jiu jitsu before
| you can walk. Of course you are going to be proficient in
| that field at a young age due to being taught by an expert at
| a time when the mind is most malleable.
| darkwater wrote:
| She probably was born with already very good genetics for her
| brain to grasp those concepts + bespoke tutorship from a very
| competent tutor very early on, that's a winning combination
| (at least concerning low-level programming)
| masto wrote:
| You think you feel stupid, I don't even know what a Honeykrisp
| Compliant Vulkan is. Sometimes Hacker News makes me wonder if
| I've had a stroke.
| SushiHippie wrote:
| > I couldn't even write an engine that used Vulkan in six
| months
|
| There is now a blog post on the frontpage where someone wrote a
| game engine using Vulkan in 3 months ;)
|
| https://news.ycombinator.com/item?id=40595741
| exDM69 wrote:
| If you're unfamiliar with Vulkan 1.3 but are interested in low
| level graphics API work, you should check it out. It is a game
| changer and a huge difference to Vulkan 1.0.
|
| Once past the initial hurdle it's a pleasure to work with, with
| all dynamic states and no render pass up front set up, it is much
| easier to work with, even easier than OpenGL (which I've used for
| 20 years). Graphics programming is fun again.
|
| It's available, or at least most of the features, on all desktop
| platforms with GPUs less than 10 years old give or take as long
| as drivers are up to date.
|
| Unfortunately there is no "reasonable defaults" framework to get
| you off the ground but there are a lot of useful helper libraries
| for several languages.
| HexDecOctBin wrote:
| Is there any tutorial/documentation to get started with Vulkan
| 1.3 specifically? Last time I looked, all I found was a
| hodgepodge of techniques using old and new methods haphazardly
| in various combinations. Though that is exactly how OpenGL used
| to be, so maybe the apple (heh!) doesn't fall far from the
| tree. Well done, Khronos...
| eliasdaler wrote:
| https://vkguide.dev/ is fantastic.
| masfoobar wrote:
| Thank you -- I appreciate this comment.
|
| I have "dabbled" in OpenGL for 20 years. I am not a pro games
| programmer, but I do make 3D content for fun in my spare time.
|
| One thing I have not had time is converting over to Vulkan. I
| guess I just need to pass the init and setup hurdle. I do think
| once I pass that, there is no going back (to OpenGL)
|
| Point is - your message was a little inspiring.. kinda
| triggered a part of my brain to do it.
|
| Have a good day.
| machine_coffee wrote:
| Something crashes, it's _never_ a compiler bug ...
|
| April 16 Oh, it actually is a compiler bug!
|
| Can confidently say I've never experienced one in my career, but
| at some level of abstraction I guess it's less rare to find them.
| anyfoo wrote:
| It's never a compiler bug, and it's definitely never a CPU bug.
|
| Unless you're a low level kernel developer, then it's both!
|
| (Jokes aside, it's still much, much more often not than it is,
| but it definitely does happen.)
| mschuster91 wrote:
| > Unless you're a low level kernel developer, then it's both!
|
| Or you're working in cryptography code and have to fight
| against compilers optimizing away sensitive stuff [1] - or
| adding junk back in [2].
|
| [1] https://www.redhat.com/en/blog/security-flaws-caused-
| compile...
|
| [2] https://pqshield.com/pqshield-plugs-timing-leaks-in-
| kyber-ml...
| mort96 wrote:
| I mean she wrote the compiler didn't she? At least the register
| allocator part
|
| "It's never a compiler bug" doesn't really apply when it's your
| own work-in-progress compiler you're testing...
| RecycledEle wrote:
| I assumed this means a ULA rocket would be transported down a
| British highway.
| mschuster91 wrote:
| > Some formats are implicitly reordered. Common "BGRA" formats
| swap red and blue for historical reasons.
|
| JFC that brings up _nasty_ memories dealing with OpenCV. One
| might think this kind of stuff would be solved by now and people
| would have converged on something sane, but no, it isn 't...
| TheAmazingRace wrote:
| Alyssa strikes again with some amazing coding wizardry. I don't
| know how she does it, but I'm glad she's fighting the good fight.
| signa11 wrote:
| this:
|
| '''
|
| April 16
|
| The tests for "descriptor indexing" revealed a compiler bug
| affecting subgroup shuffles in non-uniform control flow. The M1's
| shuffle instruction is quirky, but it's easy to workaround.
| Fixing that fixes the descriptor indexing tests.
|
| '''
|
| is just bonkers !
___________________________________________________________________
(page generated 2024-06-06 23:02 UTC)