Feedback on Vulkan Portability Initiative #23

Open
Khronoswebmaster opened this Issue Feb 26, 2018 · 12 comments

Comments

Projects
None yet
10 participants
@Khronoswebmaster
Contributor

Khronoswebmaster commented Feb 26, 2018

On February 26th, 2018, Khronos announced open source tools to bring Vulkan applications to Apple platforms as part of the Vulkan Portability Initiative. These tools include the free MoltenVK run-time library from The Brenwill Workshop, and a macOS port of the LunarG Vulkan SDK.

The Khronos Portability Initiative is defining and evolving a subset of Vulkan 1.0 that can be mapped at native performance levels to Metal and DX12. The released Apple tools are the first deliverables from this work.

Khronos and the members of the Vulkan Working Group have placed these tools into open source, and we welcome any feedback here on this issue or on the tool repositories below. We are particularly interested in functionality or performance issues that developers uncover, so we can work with the community to continually improve these porting solutions.

@procedural

This comment has been minimized.

Show comment
Hide comment
@procedural

procedural Feb 26, 2018

Please don't implement the portability layers in Rust, that will be a disaster!

Please don't implement the portability layers in Rust, that will be a disaster!

@msiglreith

This comment has been minimized.

Show comment
Hide comment
@msiglreith

msiglreith Feb 26, 2018

@procedural Out of interest, why not?

@procedural Out of interest, why not?

@rootext

This comment has been minimized.

Show comment
Hide comment
@rootext

rootext Feb 26, 2018

Is there public list of pitfalls/drawback Vulkan over MoltenVK in terms of converting Vulkan calls to Metal calls?
It would be great to have pages similar to
https://github.com/Microsoft/angle/wiki/Getting-Good-Performance-From-ANGLE and
https://github.com/Microsoft/angle/wiki/Known-Issues.

rootext commented Feb 26, 2018

Is there public list of pitfalls/drawback Vulkan over MoltenVK in terms of converting Vulkan calls to Metal calls?
It would be great to have pages similar to
https://github.com/Microsoft/angle/wiki/Getting-Good-Performance-From-ANGLE and
https://github.com/Microsoft/angle/wiki/Known-Issues.

@kvark

This comment has been minimized.

Show comment
Hide comment
@kvark

kvark Feb 26, 2018

Contributor

@procedural this is an unreasonable request. Anyone is free to implement Vulkan Portability initiative, it's is much welcome by the portability technical subgroup. You may choose Node.JS if that gets you desired performance and maintainability characteristics.

We believe that a portability layer has to be zero-overhead and robust against hitting undefined behavior, thread safety issues, and memory violation crashes. Rust can do this.

Contributor

kvark commented Feb 26, 2018

@procedural this is an unreasonable request. Anyone is free to implement Vulkan Portability initiative, it's is much welcome by the portability technical subgroup. You may choose Node.JS if that gets you desired performance and maintainability characteristics.

We believe that a portability layer has to be zero-overhead and robust against hitting undefined behavior, thread safety issues, and memory violation crashes. Rust can do this.

@hrydgard

This comment has been minimized.

Show comment
Hide comment

hrydgard commented Feb 26, 2018

@kvark

This comment has been minimized.

Show comment
Hide comment
@kvark

kvark Feb 26, 2018

Contributor

Khronos Group usually drops reference implementations for proposed initiatives

Consider this case to be unusual then. Portability sub-group was operating within the context of multiple implementations from the start. MoltenVK is not a Khronos reference implementation, it's an implementation of Metal side of portability subset.

What will be not hilarious is that people like me would have to reimplement it in C to integrate with already-written-in-C pipelines without injecting a non-ABI-stable compiler as yet another wacky dependency.

Do C/C++ have a stable ABI? Unstable Rust ABI would only be a concern if a Khronos-delivered library had Rust API. This is not the case here. gfx-portability compiles to a regular static/dynamic library that is not distinguishable from other libraries on the target system. No need to rewrite anything in C to use it.

Shove your thread safety you know where, threading is user's problem, not yours.

Well, this is just rude.
As you may know, some of the state in Vulkan driver/layer is internally synchronized. Getting this wrong leads to hard to reproduce issues, ranging from visual corruption to crashes and UB. A brief search over the young MoltenVK repo shows a few examples.

Contributor

kvark commented Feb 26, 2018

Khronos Group usually drops reference implementations for proposed initiatives

Consider this case to be unusual then. Portability sub-group was operating within the context of multiple implementations from the start. MoltenVK is not a Khronos reference implementation, it's an implementation of Metal side of portability subset.

What will be not hilarious is that people like me would have to reimplement it in C to integrate with already-written-in-C pipelines without injecting a non-ABI-stable compiler as yet another wacky dependency.

Do C/C++ have a stable ABI? Unstable Rust ABI would only be a concern if a Khronos-delivered library had Rust API. This is not the case here. gfx-portability compiles to a regular static/dynamic library that is not distinguishable from other libraries on the target system. No need to rewrite anything in C to use it.

Shove your thread safety you know where, threading is user's problem, not yours.

Well, this is just rude.
As you may know, some of the state in Vulkan driver/layer is internally synchronized. Getting this wrong leads to hard to reproduce issues, ranging from visual corruption to crashes and UB. A brief search over the young MoltenVK repo shows a few examples.

@dokipen3d

This comment has been minimized.

Show comment
Hide comment
@dokipen3d

dokipen3d Feb 26, 2018

Are compute shaders supported? (in the limitations it mentions geometry and tessellation are not supported so hopefully that means compute is).

Are compute shaders supported? (in the limitations it mentions geometry and tessellation are not supported so hopefully that means compute is).

@nsubtil

This comment has been minimized.

Show comment
Hide comment
@nsubtil

nsubtil Feb 27, 2018

Member

Wanted to remind everyone that this issue tracker is managed by the Khronos Group. Interactions here should follow the Khronos Code of Conduct (https://www.khronos.org/news/events/code-of-conduct), which prohibits aggressive or derogatory language. Please keep the discussion friendly and civil.

Member

nsubtil commented Feb 27, 2018

Wanted to remind everyone that this issue tracker is managed by the Khronos Group. Interactions here should follow the Khronos Code of Conduct (https://www.khronos.org/news/events/code-of-conduct), which prohibits aggressive or derogatory language. Please keep the discussion friendly and civil.

@BenFields724

This comment has been minimized.

Show comment
Hide comment
@BenFields724

BenFields724 Mar 6, 2018

Got Vulkan up and running with GLFW on my mac machine without any problems. Nice to have some more support on the mac side of things! Nice Work!

Got Vulkan up and running with GLFW on my mac machine without any problems. Nice to have some more support on the mac side of things! Nice Work!

@jwtowner

This comment has been minimized.

Show comment
Hide comment
@jwtowner

jwtowner May 9, 2018

A portability layer in Rust would be difficult to use on platforms where we're restricted to using only the C/C++ toolchains provided with the platform devkits, or because it would require stakeholder buy-in on using Rust, which could be difficult to achieve. Think game consoles, UWP/Windows Store, Android.

When you're already running a C/C++ based shop, having to tool-up with Rust in order to build a portability layer would be more costly than if it were simply written in C/C++. It's another dependency in your build pipeline that can cause breakage, you need to train developers, etc.

With a little work, you can get Angle working for Xbox One, as it already supports UWP out-of-the box. A portability layer written exclusively in Rust just wouldn't work here, you'd be leaving a large segment of the industry out in the cold and having to come up with their own portability solution.

MoltenVK is great. Would love to see something that does the same for DX12.

jwtowner commented May 9, 2018

A portability layer in Rust would be difficult to use on platforms where we're restricted to using only the C/C++ toolchains provided with the platform devkits, or because it would require stakeholder buy-in on using Rust, which could be difficult to achieve. Think game consoles, UWP/Windows Store, Android.

When you're already running a C/C++ based shop, having to tool-up with Rust in order to build a portability layer would be more costly than if it were simply written in C/C++. It's another dependency in your build pipeline that can cause breakage, you need to train developers, etc.

With a little work, you can get Angle working for Xbox One, as it already supports UWP out-of-the box. A portability layer written exclusively in Rust just wouldn't work here, you'd be leaving a large segment of the industry out in the cold and having to come up with their own portability solution.

MoltenVK is great. Would love to see something that does the same for DX12.

@kvark

This comment has been minimized.

Show comment
Hide comment
@kvark

kvark May 9, 2018

Contributor

@jwtowner

A portability layer in Rust would be difficult to use on platforms where we're restricted to using only the C/C++ toolchains provided with the platform devkits, or because it would require stakeholder buy-in on using Rust, which could be difficult to achieve. Think game consoles, UWP/Windows Store, Android.

Which stakeholders do you mean? I believe all the nuts and bolts to deliver Rust code on those platforms are already in place, and it's a matter of making them polished and more accessible. Here is a quote from Rust Chucklefish whitepaper:

Even after taking into account the ten days needed to customize Rust for the Xbox, PS4, and Nintendo Switch consoles, Chucklefish saved time previously spent debugging cross-platform idiosyncrasies.


With a little work, you can get Angle working for Xbox One, as it already supports UWP out-of-the box. A portability layer written exclusively in Rust just wouldn't work here, you'd be leaving a large segment of the industry out in the cold and having to come up with their own portability solution.

Why wouldn't Rust code work there? UWP also doesn't look like a blocker: it has COM interface, and the bindings are already there.

In other words - yes, if your C++ shop wants to build and maintain a fork of the library, some Rust knowledge would (obviously) be helpful. But I don't see showstoppers to use one.


MoltenVK is great. Would love to see something that does the same for DX12.

FYI, there are a few D3D12 portability projects written in C++ in early stages: Rostkatze and VulkanOnD3D12, if you are so desperate :)

Contributor

kvark commented May 9, 2018

@jwtowner

A portability layer in Rust would be difficult to use on platforms where we're restricted to using only the C/C++ toolchains provided with the platform devkits, or because it would require stakeholder buy-in on using Rust, which could be difficult to achieve. Think game consoles, UWP/Windows Store, Android.

Which stakeholders do you mean? I believe all the nuts and bolts to deliver Rust code on those platforms are already in place, and it's a matter of making them polished and more accessible. Here is a quote from Rust Chucklefish whitepaper:

Even after taking into account the ten days needed to customize Rust for the Xbox, PS4, and Nintendo Switch consoles, Chucklefish saved time previously spent debugging cross-platform idiosyncrasies.


With a little work, you can get Angle working for Xbox One, as it already supports UWP out-of-the box. A portability layer written exclusively in Rust just wouldn't work here, you'd be leaving a large segment of the industry out in the cold and having to come up with their own portability solution.

Why wouldn't Rust code work there? UWP also doesn't look like a blocker: it has COM interface, and the bindings are already there.

In other words - yes, if your C++ shop wants to build and maintain a fork of the library, some Rust knowledge would (obviously) be helpful. But I don't see showstoppers to use one.


MoltenVK is great. Would love to see something that does the same for DX12.

FYI, there are a few D3D12 portability projects written in C++ in early stages: Rostkatze and VulkanOnD3D12, if you are so desperate :)

@jwtowner

This comment has been minimized.

Show comment
Hide comment
@jwtowner

jwtowner May 9, 2018

@kvark
Stakeholders such as publishers, funders, non-technical executives, and so on who have a stake in the intellectual property being developed. The more people you have to convince, especially in a studio where C++ is already entrenched, the more difficult such a task becomes and it can be very frustrating getting anywhere.

Sometimes, the reasons aren't technical ones, but rather due to business. Licensing agreements with publishers stopping you from deviating away from the straight and narrow provided by the devkits. Indie developers have a lot more freedom.

Rostkatze looks promising, thanks for the links.

jwtowner commented May 9, 2018

@kvark
Stakeholders such as publishers, funders, non-technical executives, and so on who have a stake in the intellectual property being developed. The more people you have to convince, especially in a studio where C++ is already entrenched, the more difficult such a task becomes and it can be very frustrating getting anywhere.

Sometimes, the reasons aren't technical ones, but rather due to business. Licensing agreements with publishers stopping you from deviating away from the straight and narrow provided by the devkits. Indie developers have a lot more freedom.

Rostkatze looks promising, thanks for the links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment