[dead]
Vulkan1.3 on the M1 in one month
281–290 of 372 posts
Re: Vulkan1.3 on the M1 in one month
#282Earlier quoted context omitted.
When Apple went up on stage and announced Lightning, they said "this is our connector for the next 10 years". 10 years later, almost on the dot, they replaced Lightning on the iPhone with USB-C. Doesn't seem weird at all to me.
It wouldn't be weird if they simply picked one side and stuck with it. They put USB-C on Mac, because obviously Lightning couldn't fill the role they wanted with Thunderbolt. And then they made iPhones Lightning because... they wanted to sell IP to cable manufacturers. And they made the Magic Trackpad/Keyboard accessories use Lightning because... why again? It's just USB, it probably takes more work to make a Lightni…
[deleted]
Re: Vulkan1.3 on the M1 in one month
#283If 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 av…
Thank you -- I appreciate this comment.
I have "dabbled" in OpenGL for 20 years. I am not a pro games programmer, but I do make 3D content for fun in my spare time.
One thing I have not had time is converting over to Vulkan. I guess I just need to pass the init and setup hurdle. I do think once I pass that, there is no going back (to OpenGL)
Point is - your message was a little inspiring.. kinda triggered a part of my brain to do it.
Have a good day.
Re: Vulkan1.3 on the M1 in one month
#284Earlier quoted context omitted.
> 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.
The problem is that there isn't two variants, there is an extension soup of Vulkan variants.
I get by just fine with "one variant" using all the Vulkan 1.3 features that are ubiquitously available on desktop (= almost all of them) platforms with up to date drivers.
The fact that there's n+1 extensions does not mean you have to support 2^(n+1) combinations. I can't recall a single situation where I would've needed even two code paths to get something done in the past few years.
Situations where you need two or more code paths only arise if you use new hardware features like mesh shaders or ray tracing. For "software" features like dynamic rendering or dynamic states (both of which simplify things a lot), there's no need for a fallback on desktop, just require a recent driver version and you're good.
That said, the mobile driver support situation and lack of long term updates is an issue if mobile support is required.
Re: Vulkan1.3 on the M1 in one month
#285Earlier quoted context omitted.
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.
Supporting a different 3D API is really not the complicated or time consuming part of porting a game to another platform, especially when the target API is Metal. The poor game support on macOS is a mix of Apple apathy towards gaming and the low potential sales numbers. Also, of the few new Vulkan apps being released (a whopping 9 in 2023), most actually only support a single platform: https://carette.xyz/posts/state…
>Supporting a different 3D API is really not the complicated or time consuming part of porting a game to another platform, especially when the target API is Metal.
If you have a graphics programmer on hand, no. The vast majority of indie devs are powerless in that domain, though. I don't see many attempts out there to make it easier for them either.
Maintenance is always the time consuming part, be it simple or complex work. People aren't going to support Linux even if Vulkan theoretically makes it straightforward, because the time needed to maintain it isn't worth the lack of customers. Steam + Proton gives even less incentive to bother. So that advantage doesn't translate to much business value when evaluating DX12 vs. Vulkan.
This is an issue going all the way back to the OpenGL vs. D3D days. Nothing fundamentally changes as long as Microsoft completely swamps the PC gaming market.
Re: Vulkan1.3 on the M1 in one month
#286Earlier quoted context omitted.
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.
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 compar…
>The number of games that run on Metal by comparison (natively) is orders of magnitude higher.
When it's the only way to interface with MacOS and especially IOS, I'm not surprised. But that says more about Apple as a platform than Vulkan as a graphics API.
>Apple does now have Game Porting Toolkit
yup, only took some 9 years after they abandoned Khronos to get it up and running. I'm sure nothing signifigant would have developed in that time.
Re: Vulkan1.3 on the M1 in one month
#287Earlier quoted context omitted.
The problem is that there isn't two variants, there is an extension soup of Vulkan variants.
I get by just fine with "one variant" using all the Vulkan 1.3 features that are ubiquitously available on desktop (= almost all of them) platforms with up to date drivers. The fact that there's n+1 extensions does not mean you have to support 2^(n+1) combinations. I can't recall a single situation where I would've needed even two code paths to get something done in the past few years. Situations where you need two o…
[flagged]
Re: Vulkan1.3 on the M1 in one month
#288Earlier quoted context omitted.
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 spen…
Interesting point of view that could also be the other way around, Vulkan support being a hidden tax for the love of open source and free software rather than something really useful the market needed on top of others APIs / GPU architectures / platforms, pushed by a subset / minority of developers more ideological than practical grounded developers who accept that competition of private standards will bring out the…
> more ideological than practical grounded developers who accept that competition of private standards will bring out the best user experience, each platform having its customized architecture.
There's no clean answer here. You push that mentality of "Customers first" too hard, and you get the PS3; an unwieldy architecture that devs are forced to support but end up with worse ports than the Xbox 360. The customer doesn't necessarily "win" here.
You push developers first too hard and you get Linux. You can do anything you want if you dig deep enough. But as we all know, the common consumer barely reads the tutorial, let alone learns how to configure complex settings in a CLI.
There needs to be some middle ground, and not making developers duplicate their work for every new private business is at least a starting point.
>Maybe the society of worldwide developers had better things to do than spend precious time on Vulkan.
Given MacOS's marketshare, I'm sure they did. Let's not pretend that the few metal games we have on Desktop wasn't built on the grounds of some Candy Crush clone that generated billions of dollars 10 years ago and justified the forced upgrade (we can definitely justify from there if "making candy crush run faster" is a better thing to do. But it pays the bills, I guess).
Very few devs want to support Mac and the numbers speak for themselves.
Re: Vulkan1.3 on the M1 in one month
#289Is 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?
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.
Parallels requires a separate license per machine. That restriction alone is a permanent non-starter for me.
Re: Vulkan1.3 on the M1 in one month
#290Earlier quoted context omitted.
I get by just fine with "one variant" using all the Vulkan 1.3 features that are ubiquitously available on desktop (= almost all of them) platforms with up to date drivers. The fact that there's n+1 extensions does not mean you have to support 2^(n+1) combinations. I can't recall a single situation where I would've needed even two code paths to get something done in the past few years. Situations where you need two o…
[flagged]
How is it easier said than done? All three major GPU vendors (Intel, nvidia, AMD) have drivers have a very good support on all three major desktop platforms (Windows, Linux and Macos), and it goes back to quite old hardware (Intel Skylake 2015, Nvidia Maxwell 2014, not sure about AMD).
If you know exactly which driver version(s) you require, you can explicitly check it at init time, or you can just check for the feature flags and require them at init (you need to do this explicitly anyways).
OpenGL 3.3 is a popular choice only because Apple dropped OpenGL support and HW features (tessellation, etc) were required for 4.x. You don't have a situation like that with Vulkan. You get all the latest SW features even on old HW.
Vulkan's explicit extensions/features setup is much much better than OpenGL ever was, and there are no "half assed" implementations out there like there were in OpenGL days. You don't end up using a feature by accident, and then have your app not work on a platform you didn't test on. The conformance test suite is very strict, so if a feature is supported it's very likely to work as advertised, much less driver bugs than in the OpenGL days.