-
Notifications
You must be signed in to change notification settings - Fork 423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VKD3D Vulkan requirements.. #214
Comments
+1 for VK_KHR_maintenance1 The viewport y-flipping in particular is useful for D3D-based games. For what it's worth, Dota 2 also relies on the vkAllocateDescriptorSets behavior in VK_KHR_maintenace1. Currently there are a lot of errors printed in dota on MoltenVK because we are relying on vkAllocateDescriptorSets to fail - it works over MoltenVK, but with maintenance1 enabled those should not be errors. |
Understood about MoltenVK already supports negative viewport height via |
I'm closing this as a duplicate of enhancement #12. |
Hi, |
Hi @billhollings, just tested a master VKD3D build with latest MoltenVK on a simple D3D12 sample.. so would like to hear, from @cdavis5e also, if possible, how difficult is to support VK_KHR_timeline_semaphore under MoltenVK.. |
Hi @billhollings @cdavis5e ,
from their notes, theoretically MoltenVK is OK with current requeriments (as long as VK_EXT_descriptor_indexing minor details can be sorted out).. |
AFAIK, MoltenVK doesn't have |
We do, but we only support |
What I don't get is why
|
@cdavis5e |
Since this is an active discussion, as well as Apple wish-list, I'm reopening this issue for visibility. |
We're aware that Metal cannot support the D3D12 binding model at the moment; it's hard enough to make it work properly on native Vulkan drivers especially if we want to get useful performance out of it. It is not a priority for vkd3d-proton, although the original vkd3d project should still work as it does not use descriptor indexing (but also doesn't support |
just pointing VKD3D 2.1 was released few weeks ago adding support for VK_VALVE_mutable_descriptor_type extension.
hope MoltenVK support for this extension can be implemented efficiently via Metal eventually.. |
No it can't. Metal can't even support descriptor indexing properly because on top of having to specify the descriptor type as in sampled image, storage buffer,... you also have to specify the texture dimensions (2D, 3D) and whether or not it's multisampled. And even if that wasn't an issue, the highest limit for argument buffers (500k) is not good enough for D3D12 which requires 1 million for tier 3 and many games rely on that. |
We already have to build
I've asked Apple to support texture arguments where the texture type is unknown (FB7069952), and also for an argument type that can be either a texture of any type or a buffer pointer (FB7648288). In addition, in light of @K0bin's other comment:
I've asked them to raise the limits (FB8877050). (Note that tier 3 requires 1 million of each kind of resource--CBV, SRV, UAV. That's 3 million in total. It's tier 2 that only requires a million SRVs. I have accounted for this in my request.) I guess we'll just have to wait and see. |
Should the VKD3D discussion continue here in the bug, or move to the shiny new discussion forum? |
just doing a quick update as some new extensions are now required: *VK_KHR_separate_depth_stencil_layouts (part of VK1.2 so part of: #1567) EDIT: running on Wine 7.5 + VKD3D 2.6 and MoltenVK 1.1.9 |
@oscarbg upstream wine merged VKD3D-1.3 and builds as PE from wine-7.4 see wine-mirror/wine@97db56a The VKD3D 2.6 version makes me think your attempting to use VKD3D-proton that’s much less lightly to work. |
@Gcenx yes I know thanks.. just want also MoltenVK to keep adding exts for eventual VKD3D-proton support.. as it's more advanced in D3D12 support.. |
@cdavis5e @billhollings
just asking here if it's possible to support in MoltenVK this subset.. i.e. if Metal supports this three additional indirect capabilities.. |
Metal does have similar functionality with indirect command buffers but D3D12 uses GPU VAs to set vertex/index buffers and Metal does not support directly using VAs. |
I’d make VKD3D-Proton it’s own issue since they love to change requirements often and push for new extensions to meet there needs, that’s ignoring the common practice of dropping support for older GPUs. |
thanks @K0bin for info.. with Crossover in 2023 looking for D3D12 support on Macos hope someone is feeding Apple with requests like these for Metal API to match D3D12 better.. |
In case you haven't heard and are interested, at today's WWDC event apple announced Metal 3 which seems to support buffer device address, so it should be possible to implement class Buffer : public NS::Referencing<Buffer, Resource>
{
public:
NS::UInteger length() const;
void* contents();
void didModifyRange(NS::Range range);
class Texture* newTexture(const class TextureDescriptor* descriptor, NS::UInteger offset, NS::UInteger bytesPerRow);
void addDebugMarker(const NS::String* marker, NS::Range range);
void removeAllDebugMarkers();
class Buffer* remoteStorageBuffer() const;
class Buffer* newRemoteBufferViewForDevice(const class Device* device);
uint64_t gpuAddress() const;
} |
Consolidating in discuss #1616. |
I don't think it's feasible to implement D3D12 on Metal. D3D12 is bindless, so MoltenVK would have to use Argument Buffers to implement the binding model. |
Is this still a problem with Metal 3? During WWDC they covered how “to make your app's bindless journey a joy by simplifying argument buffers, allocating acceleration structures from heaps, and benefitting from the improvements to the Metal's validation layer and Debugger Tools.“ - https://developer.apple.com/videos/play/wwdc2022/10101/ |
Yes, all of this is still a problem with Metal 3. |
It isn't just for barriers. Those methods are a signal to Metal that it needs to keep those resources' memory paged in for the duration of the command encoder. In D3D12, pageability is controlled explicitly by the application ( Also, you only really need to do this if you're using
What they want you to do in that case is use |
Yeah, it conflates residency with cache flushing/image layouts. Given that Vulkan has no explicit concept of residency, you'd have to maintain a global list of all resources or (like MoltenVK does right now) use all resources in a descriptor set.
As far as I understand it, it's necessary for argument buffers too because the API has no way of knowing which resources you're gonna access. Heaps do indeed cut down on the number of residency API calls but still leave the problem that all writable resources need Ideally Metal would need a barrier function that transitions resources and keeps them in that state, so you wouldn't have to call |
Wouldn't something like a generation gc help in that? A readonly and a rw generation. |
Resource lifetimes and how they are used is entirely controlled by the application and the driver (MoltenVK in this case) doesn't have enough information or enough wiggle room to do anything clever here. |
Apple's documentation on this is unfortunately very incomplete, but are we sure that That said, I can imagine that there might be a feasible way of approaching this problem (with the caveat that I am not familiar with MoltenVK codebase):
Is there something obvious I am missing (aside the non-trivial performance overhead obviously?) |
BTW, is it possible that setting |
I don't know if it does synchronization but given that it seems to do cache flushing/invalidation and/or image layout transitions, it probably needs to be synchronized externally if it doesn't do it on its own. From "Explore bindless rendering in Metal"
I don't think your proposed approach will work because:
This is basically impossible with full UPDATE_AFTER_BIND and descriptor indexing. The app could calculate the final index for the storage image descriptor in a million different ways.
useResource still seems to handle cache flushing/invalidation, so this probably doesn't work. |
Hi,
there are patches for VKD3D, adding MacOS Support...
https://source.winehq.org/patches/data/149222
I tested triangle and gears demos and they work although they print:
err:vkd3d_check_extensions: Required device extension "VK_KHR_maintenance1" is not supported.
err:vkd3d_check_extensions: Required device extension "VK_KHR_shader_draw_parameters" is not supported.
[MoltenVK ERROR] VK_ERROR_EXTENSION_NOT_PRESENT: Vulkan extension VK_KHR_maintenance1 is not supported.
[MoltenVK ERROR] VK_ERROR_EXTENSION_NOT_PRESENT: Vulkan extension VK_KHR_shader_draw_parameters is not supported.
interestingly DXVK also needs VK_KHR_maintenance1 and VK_KHR_shader_draw_parameters but far less than DXVK requires..
regarding optional features must dig a little more.. will add later as I find it..
The text was updated successfully, but these errors were encountered: