3 ms·

To embrace gaming, Apple needs to level up its game porting toolkit

4 points by ingve 3y ago

smoldesu 3y ago
Or just, ship Vulkan drivers. That's it. I know it's a war drum everyone is tired of hearing, but Game Porting Toolkit has DXVK code in it; it's time to just support the API natively.
- dagmx 3y ago
  And what games would that support? A very small minority of games support Vulkan.
  - smoldesu 3y ago
    You've seen Proton, no? Supporting Vulkan 1.2 basically gives you de-facto coverage of DX9-DX11 for free, along with most of DX12 in beta. It's leagues better than Codeweaver's driver and makes D3DMetal look like a derelict project by comparison. Supporting Vulkan at the hardware level would better enable SPIR-V optimization, and just be generally nice. I don't even give a shit about them supporting it on Apple Watch or AppleTV, it's just starting to get painful watching people get GTX 960 raster performance out of a $4500 TSMC N3 laptop.
    - dagmx 3y ago
      You’re assuming a lot about what the hardware supports natively and conflating that to performance. A lot of the performance loss is hard to measure without considering the vast difference in GPU architecture. Android supports Vulkan and most Qualcomm GPUs are similar. Why is proton on Android not a thing and performant?
      - smoldesu 3y ago
        > You’re assuming a lot about what the hardware supports natively and conflating that to performance. I think you're assuming a lot about Apple Silicon that doesn't affect Vulkan conformance. Apple can support Vulkan featuresets without directly accelerating every feature in-hardware. Even a low-quality official driver would allow people to use upstream DXVK without additional translation layers. ...in other words, it would basically be what Game Porting Toolkit should be, if Apple wasn't chronically afraid of supporting something upstream. > Why is proton on Android not a thing and performant? Proton is a thing on Android, and it is relatively quite high-performance: https://youtu.be/N7Y-YegXoMk https://youtu.be/N7Y-YegXoMk The main blocker was (and continues to be) a high-speed x86 translation layer. The GPU side of things has effectively been "solved" for years now.
        dagmx 3y ago
        My point is not just about feature support (hence why I mention arch), though even then a lot of features would likely end up emulated reducing performance . It’s that a lot of the performance difference comes from the difference between a mobile tile based GPU and a desktop one. And if you’re okay with software emulation of features, then you go back to not being able to compare performance against proton running on like for like hardware. Again, you’re making many leaps of faith to suggest things are suboptimal now and that a different implementation would magically be faster. How much of the performance delta is the implementation of the translation layer and how much is the GPU arch difference is something you can’t just assume Vulkan would solve for. And yes I know there’s proton on Android, but it’s far from prolific of performant (which is what I asked about specifically). You conveniently are giving it the benefit of the doubt when it’s much closer to desktop Linux. You don’t know how much overhead is attributed the x86 to arm translation, on top of the win32 to Darwin, on top of the D3DMetal on top of the GPU arch differences. Yet you’re making very confident claims of how amazingly it could work, while excusing the closet example where it doesn’t work well.
        smoldesu 3y ago
        > It’s that a lot of the performance difference comes from the difference between a mobile tile based GPU and a desktop one. I just told you - a tile-based GPU can impliment every single raster feature Vulkan 1.2 requires. You haven't demonstrated a single reason that couldn't be true, and instead you're just claiming it's too different to work. Why can't Apple Silicon support a Vulkan API, from your informed perspective? I must have missed something - Qualcomm's tile-renderer GPU has no problem with it. Even Nvidia's steaming dogshit Vulkan drivers get pixel-perfect DXVK coverage, mobile or desktop. > And yes I know there’s proton on Android, but it’s far from prolific of performant It's incredibly performant. The GPU was at a fraction of max usage while translating the entirety of GTA-V's shaders. I'll say it again - the GPU side of Proton is "solved". Pending a better solution, it is the definition of performant.

4 points by ingve 3y ago

Or just, ship Vulkan drivers. That's it. I know it's a war drum everyone is tired of hearing, but Game Porting Toolkit has DXVK code in it; it's time to just support the API natively.

dagmx 3y ago
And what games would that support? A very small minority of games support Vulkan.
- smoldesu 3y ago
  You've seen Proton, no? Supporting Vulkan 1.2 basically gives you de-facto coverage of DX9-DX11 for free, along with most of DX12 in beta. It's leagues better than Codeweaver's driver and makes D3DMetal look like a derelict project by comparison. Supporting Vulkan at the hardware level would better enable SPIR-V optimization, and just be generally nice. I don't even give a shit about them supporting it on Apple Watch or AppleTV, it's just starting to get painful watching people get GTX 960 raster performance out of a $4500 TSMC N3 laptop.
  - dagmx 3y ago
    You’re assuming a lot about what the hardware supports natively and conflating that to performance. A lot of the performance loss is hard to measure without considering the vast difference in GPU architecture. Android supports Vulkan and most Qualcomm GPUs are similar. Why is proton on Android not a thing and performant?
    - smoldesu 3y ago
      > You’re assuming a lot about what the hardware supports natively and conflating that to performance. I think you're assuming a lot about Apple Silicon that doesn't affect Vulkan conformance. Apple can support Vulkan featuresets without directly accelerating every feature in-hardware. Even a low-quality official driver would allow people to use upstream DXVK without additional translation layers. ...in other words, it would basically be what Game Porting Toolkit should be, if Apple wasn't chronically afraid of supporting something upstream. > Why is proton on Android not a thing and performant? Proton is a thing on Android, and it is relatively quite high-performance: https://youtu.be/N7Y-YegXoMk https://youtu.be/N7Y-YegXoMk The main blocker was (and continues to be) a high-speed x86 translation layer. The GPU side of things has effectively been "solved" for years now.
      - dagmx 3y ago
        My point is not just about feature support (hence why I mention arch), though even then a lot of features would likely end up emulated reducing performance . It’s that a lot of the performance difference comes from the difference between a mobile tile based GPU and a desktop one. And if you’re okay with software emulation of features, then you go back to not being able to compare performance against proton running on like for like hardware. Again, you’re making many leaps of faith to suggest things are suboptimal now and that a different implementation would magically be faster. How much of the performance delta is the implementation of the translation layer and how much is the GPU arch difference is something you can’t just assume Vulkan would solve for. And yes I know there’s proton on Android, but it’s far from prolific of performant (which is what I asked about specifically). You conveniently are giving it the benefit of the doubt when it’s much closer to desktop Linux. You don’t know how much overhead is attributed the x86 to arm translation, on top of the win32 to Darwin, on top of the D3DMetal on top of the GPU arch differences. Yet you’re making very confident claims of how amazingly it could work, while excusing the closet example where it doesn’t work well.
        smoldesu 3y ago
        > It’s that a lot of the performance difference comes from the difference between a mobile tile based GPU and a desktop one. I just told you - a tile-based GPU can impliment every single raster feature Vulkan 1.2 requires. You haven't demonstrated a single reason that couldn't be true, and instead you're just claiming it's too different to work. Why can't Apple Silicon support a Vulkan API, from your informed perspective? I must have missed something - Qualcomm's tile-renderer GPU has no problem with it. Even Nvidia's steaming dogshit Vulkan drivers get pixel-perfect DXVK coverage, mobile or desktop. > And yes I know there’s proton on Android, but it’s far from prolific of performant It's incredibly performant. The GPU was at a fraction of max usage while translating the entirety of GTA-V's shaders. I'll say it again - the GPU side of Proton is "solved". Pending a better solution, it is the definition of performant.