Question: there are no code updates for more than a year?

Is there a reason why there are no code updates for more than a year already?

What's happening, guys? What did I miss?

#250

Although I'm not sure how to find time to do this... Help would be much appreciated!

Wait, don't tell me this whole project is just @kvark doing all the work in his spare time? 😄 Jesus, no wonder then. Can Valve fund this or something?

[kvark]

Yes, basically we haven't gotten a volunteer to port/rewrite gfx-portability on top of wgpu-hal.
Maintaining the current approach isn't feasible either, for the same reason - no time/volunteer to do it.
So the project is on hold since last summer.

I see, thanks for answer!

I linked your reply on Embark's Rust channel on Discord, maybe they can help in some way, they're the biggest driving force behind Rust that I know of: https://discord.com/channels/750717012564770887/750717169066704927/949203686167552012

Copying @repi 's reply here, in case you're not on Discord, @kvark !

if the project had maintainers/developers on it and that were looking for sponsorship then that would definitely be something we would consider sponsoring. but looks like their main problem is not having any maintainers/volunteers to work on it and that has to be the first step.

for our own use cases MoltenVK works well enough for us to have Vulkan on Mac. though a pure Rust version would be preferable but huge amount of work

[kvark]

I exist on Discord as kvark#9787, but I don't check it often.
Thank you for relaying the answer!

I think Embard is slightly dishonest here: if they were truly interested in pure-Rust stack, they'd use gfx-portability from the start. Or at least they'd give it a fair chance and report all of the missing bits and issues encountered. As far as I understand, they haven't tried. The lack of use/interest is definitely one of the major contributors to the project being on hold now.

I think gfx-portability should first pass Vulkan conformance tests like other real drivers. If gfx-portability will be minimally conformant to be functional enough, other possible show stopping bugs will expose missing tests in the conformance test suits.

Because once gfx-portability is conformant, it is expected to work without a crash for a game with a functional Vulkan backend, which Embark already has, afaik.

[kvark]

That's an unreasonable requirement at this point. It's not like MoltenVK passes the conformance tests today. What they are doing is basically marking off the groups of tests they can't pass by introducing more flags. Nobody will check for these flags, for the most part.

So the portability workflow is the same with MVK and gfx-portability: you try to run it, report issues back, and see what can be done.

I see, thanks for the insight, I didn't know that.

What they are doing is basically marking off the groups of tests they can't pass by introducing more flags. Nobody will check for these flags, for the most part.

I hope all these flags are part of VK_KHR_portability_subset extension? Because if not, that's not conformant to the spec.

The unfortunate part is that people target only MoltenVK because it works today on a mac, but that means their programs are now ARM with Apple-specific ABIs and APIs sprinkled all over them. Ironic, they wanted portability, but in the end they got only Apple-specific binaries no other Vulkan Portability implementation can run.

I guess WebGPU is the real portable API here, because it must work on many platforms at the end of the day. Fingers crossed people will target native WebGPU API you guys already provide, but I feel like the reality will be hard-to-extract-from-servers DRMd wasm binaries with web APIs sprinkled all over them, à la MoltenVK Situation Part 2.

All that aside, when IHVs will start dropping Vulkan support from their drivers, either no one will care because everyone already was targeting other APIs like DirectX or MoltenVK or WebGPU, or there will be people with now not working Vulkan code, and who knows how many of these people we will get. Currently, a see a tumbleweed in a desert.

(side note: this exists, and I don't know why exactly (yet)): https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Dozen-VLK-D3D12

[kvark]

(side note: this exists, and I don't know why exactly (yet)): https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Dozen-VLK-D3D12

Interesting! I wonder if they are doing it for Microsoft's WSL2, so that Vulkan is available under WSL2 (over DX12).

I hope all these flags are part of VK_KHR_portability_subset extension? Because if not, that's not conformant to the spec.

Now that we aren't contributing to the spec, we aren't stopping them too hard from essentially add all of the things they can't do as flags there. I.e. VK_KHR_portability_subset becomes less of a standard and more of just "this is how MVK works". What's most disturbing is that flags are added very liberally now, including cases where some engineering investment would make them unnecessary. That's why I said "nobody is going to check for them". There will be a standard, and possibly some validation, but people who want to run on Vulkan Portability can't be expected to look at too many flags. They'll just run and see what works (diminishing the value of the standard).

Interesting! I wonder if they are doing it for Microsoft's WSL2, so that Vulkan is available under WSL2 (over DX12).

Yep, probably that, I just don't know their specific use case for it, for example, their OpenGL and OpenCL over DX12 projects were started to run Blender and Photoshop on Qualcomm's ARM-based Windows laptops that have only DX12 drivers, I currently don't know what important Vulkan software exists that they need to run, maybe none and this one is just for completeness, but I doubt.

I.e. VK_KHR_portability_subset becomes less of a standard and more of just "this is how MVK works".

Yea, I was thinking the same when I looked into it.

There will be a standard, and possibly some validation, but people who want to run on Vulkan Portability can't be expected to look at too many flags. They'll just run and see what works (diminishing the value of the standard).

I hope their flags are actually subsetting Vulkan, because I don't think they can contradict to the core Vulkan standard and change the behavior of things that must behave a certain way according to the standard. If they just subset, then the flags for the features they don't support today may inform other implementations what not to implement too. If the flags change the behavior of things and deviate from the core Vulkan standard, then one can write portability conformance tests that enable these flags but check against the core Vulkan spec's expected behavior to show that the implementation is not really spec conformant.

But then all the other ISA/ABI/API mess of today's operating systems that basically forces asking and begging developers to recompile on other platforms to make their binaries run on your portability implementation that targets those platforms.

I just had a thought of asking developers for their Apple+MoltenVK optimized and stripped LLVM IR object files Clang generates anyway: unlike the final executables, they have no ISA or ABI specifics yet, they strip sensitive source code and, unless I miss something, should be enough for compiling an executable on another platform. The only work left will be to implement Apple APIs and libraries on which object files depend.