5 ms·

> 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 do

> 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.
  - dagmx 3y ago
    I'm not saying it cannot implement Vulkan. Go back and read my responses, that has never been in any of them. You're injecting an argument I'm not even close to making. I am saying that your idea that Proton would necessarily be faster than D3DMetal is making assumptions that nobody outside Apple can realistically know. You don't know what their GPU supports natively and what would require software emulation. It might be faster, I'm not saying it wouldn't be. I'm just saying you cannot know without making a lot of logical leaps first. If by your own earlier comment, you allow for software emulation of certain features to get support parity, then you cannot make a realistic claim on the comparison of the performance of the translation layer since they're not 1:1 With regards to tile based rendering, many games do suffer when ported to tile based renderers. A lot of access patterns change, and things like post processing effects and full screen deferred buffers become more expensive. You cannot compare NVIDIA's tile based implementation to Apples. The similarity is in name only. Anyone who's ported desktop engines and games to mobile devices has experienced this. with regards to GTA:V, GPU usage alone doesn't tell you enough unless you specifically know where your bottlenecks are. Going by the gamer concept of "its gpu/cpu bound" doesn't really mean much for performance analysis beyond trying to guess what you should upgrade. GTA-Vs lowest resolution shaders (as in that video) would not be demanding for any modern GPU. The Rockstar engine scales very well by design. But unless you know where the CPU side is stalling, you don't know how you're starving the GPU or not. Anyway to reiterate, because you keep trying to insert a different argument: "You cannot know your claims are true because you don't have enough reasonable data to do so" <- That's it. You can hypothesize all you want, but it'll come down to that and that is ALL I am arguing.

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.
- dagmx 3y ago
  I'm not saying it cannot implement Vulkan. Go back and read my responses, that has never been in any of them. You're injecting an argument I'm not even close to making. I am saying that your idea that Proton would necessarily be faster than D3DMetal is making assumptions that nobody outside Apple can realistically know. You don't know what their GPU supports natively and what would require software emulation. It might be faster, I'm not saying it wouldn't be. I'm just saying you cannot know without making a lot of logical leaps first. If by your own earlier comment, you allow for software emulation of certain features to get support parity, then you cannot make a realistic claim on the comparison of the performance of the translation layer since they're not 1:1 With regards to tile based rendering, many games do suffer when ported to tile based renderers. A lot of access patterns change, and things like post processing effects and full screen deferred buffers become more expensive. You cannot compare NVIDIA's tile based implementation to Apples. The similarity is in name only. Anyone who's ported desktop engines and games to mobile devices has experienced this. with regards to GTA:V, GPU usage alone doesn't tell you enough unless you specifically know where your bottlenecks are. Going by the gamer concept of "its gpu/cpu bound" doesn't really mean much for performance analysis beyond trying to guess what you should upgrade. GTA-Vs lowest resolution shaders (as in that video) would not be demanding for any modern GPU. The Rockstar engine scales very well by design. But unless you know where the CPU side is stalling, you don't know how you're starving the GPU or not. Anyway to reiterate, because you keep trying to insert a different argument: "You cannot know your claims are true because you don't have enough reasonable data to do so" <- That's it. You can hypothesize all you want, but it'll come down to that and that is ALL I am arguing.