[HN Gopher] Vulkan1.3 on the M1 in one month
___________________________________________________________________
Vulkan1.3 on the M1 in one month
Author : todsacerdoti
Score : 502 points
Date : 2024-06-05 15:11 UTC (7 hours 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.
| 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
| 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.
| 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?
| 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.
| 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...
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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.
| 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.
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| wmf wrote:
| Apple already released the Game Porting Toolkit.
| 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!
| 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?
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.)
| 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...
___________________________________________________________________
(page generated 2024-06-05 23:00 UTC)