Skip to content
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

Requirements for DXVK support.. #203

Open
oscarbg opened this issue Jul 27, 2018 · 78 comments

Comments

@oscarbg
Copy link

commented Jul 27, 2018

Hi,
this is just a report of "things" missing in MoltenVK to support DXVK now that Wine supports Vulkan on MacOS via MoltenVK (I use v1.0.12 included in Vulkan MacOS SDK 1.0.77)..
I tested DXVK 0.6.3 on Wine 3.13 with Vulkan support enabled on MacOS and simple programs like included d3d11-compute or d3d11-triangle failed due to unsupported extensions so I checked logs and seems it needs this extensions (as of 0.6.3):

From:
https://github.com/doitsujin/dxvk/blob/master/src/dxvk/dxvk_extensions.h
we see requirements for DxvkInstanceExtensions:
VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2
the other two are emulated by Wine already..

for DxvkDeviceExtensions it needs:
VK_KHR_DEDICATED_ALLOCATION_EXTENSION_NAME,
VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME,
VK_KHR_GET_MEMORY_REQUIREMENTS_2_EXTENSION_NAME,
VK_KHR_IMAGE_FORMAT_LIST_EXTENSION_NAME,
VK_KHR_MAINTENANCE1_EXTENSION_NAME
VK_KHR_MAINTENANCE2_EXTENSION_NAME
VK_KHR_SHADER_DRAW_PARAMETERS

I modified code of this exts from DxvkExtMode::Required to DxvkExtMode::Optional but then it complains it can't create a D3D device with support for any feature levels ranging from D3D_FEATURE_LEVEL_9_1 to D3D_FEATURE_LEVEL_11_1..

it's because needs features missing in MoltenVK (as of 1.0.12 in Vulkan SDK 1.0.77):
code checking feature level is here:
https://github.com/doitsujin/dxvk/blob/master/src/d3d11/d3d11_device.cpp
`

if (featureLevel >= D3D_FEATURE_LEVEL_9_1) {
enabled.depthClamp = VK_TRUE;
enabled.depthBiasClamp = VK_TRUE;
enabled.fillModeNonSolid = VK_TRUE;
enabled.pipelineStatisticsQuery = supported.pipelineStatisticsQuery;
enabled.sampleRateShading = VK_TRUE;
enabled.samplerAnisotropy = VK_TRUE;
enabled.shaderClipDistance = VK_TRUE;
enabled.shaderCullDistance = VK_TRUE;
enabled.robustBufferAccess = VK_TRUE;
}

if (featureLevel >= D3D_FEATURE_LEVEL_9_2) {
  enabled.occlusionQueryPrecise                 = VK_TRUE;
}

if (featureLevel >= D3D_FEATURE_LEVEL_9_3) {
  enabled.multiViewport                         = VK_TRUE;
  enabled.independentBlend                      = VK_TRUE;
}

if (featureLevel >= D3D_FEATURE_LEVEL_10_0) {
  enabled.fullDrawIndexUint32                   = VK_TRUE;
  enabled.fragmentStoresAndAtomics              = VK_TRUE;
  enabled.geometryShader                        = VK_TRUE;
  enabled.logicOp                               = supported.logicOp;
  enabled.shaderImageGatherExtended             = VK_TRUE;
  enabled.textureCompressionBC                  = VK_TRUE;
}

if (featureLevel >= D3D_FEATURE_LEVEL_10_1) {
  enabled.dualSrcBlend                          = VK_TRUE;
  enabled.imageCubeArray                        = VK_TRUE;
}

if (featureLevel >= D3D_FEATURE_LEVEL_11_0) {
  enabled.shaderFloat64                         = supported.shaderFloat64;
  enabled.shaderInt64                           = supported.shaderInt64;
  enabled.tessellationShader                    = VK_TRUE;
  // TODO enable unconditionally once RADV gains support
  enabled.shaderStorageImageMultisample         = supported.shaderStorageImageMultisample;
  enabled.shaderStorageImageReadWithoutFormat   = supported.shaderStorageImageReadWithoutFormat;
  enabled.shaderStorageImageWriteWithoutFormat  = VK_TRUE;
}

if (featureLevel >= D3D_FEATURE_LEVEL_11_1) {
  enabled.logicOp                               = VK_TRUE;
  enabled.vertexPipelineStoresAndAtomics        = VK_TRUE;
}

`

had to comment these lines (due to missing MoltenVK support):
for getting up to D3D_FEATURE_LEVEL_9_1:
enabled.sampleRateShading = VK_TRUE;
enabled.shaderCullDistance = VK_TRUE;
enabled.robustBufferAccess = VK_TRUE;
for D3D_FEATURE_LEVEL_9_3:
enabled.multiViewport = VK_TRUE;
for D3D_FEATURE_LEVEL_10_1:
enabled.fullDrawIndexUint32 = VK_TRUE;
enabled.geometryShader = VK_TRUE;
enabled.logicOp = supported.logicOp;
for D3D_FEATURE_LEVEL_11_0:
enabled.shaderFloat64 = supported.shaderFloat64;
enabled.shaderInt64 = supported.shaderInt64;
enabled.tessellationShader = VK_TRUE;
enabled.shaderStorageImageWriteWithoutFormat = VK_TRUE;

with all these "hacks" it doesn't complain but crashes executing simple d3d11 apps because it may be using missing features..

of course MoltenVK supporting DXVK might be a herculean effort but DXVK has shown it's able to run lots of DX11 modern games and this will be awesome on Mac..
this is just a report of things needed to do (as a means of guiding priorities of things to implement)..

hope is useful for someone..

@johnothwolo

This comment has been minimized.

Copy link

commented Aug 15, 2018

How did you get wine to recognise moltenVK? I get

checking for -lMoltenVK... not found

@oscarbg

This comment has been minimized.

Copy link
Author

commented Aug 15, 2018

I think had some issues but copied everywhre /lib /usr/lib /usr/local/lib..

@KenThomases

This comment has been minimized.

Copy link

commented Aug 15, 2018

You configure with LDFLAGS="-L/path/to/the/MVK/libdir". At runtime, you need to set the DYLD_FALLBACK_LIBRARY_PATH environment variable to contain the same path. However, System Integrity Protection will strip any DYLD_* environment variables when a system executable is run and that included shell script interpreters. So, depending on how you're running Wine, you may need to take extra measures.

If you're running your own build using the top-level "wine" script, create a file names .winewrapper next to it that contains "export DYLD_FALLBACK_LIBRARY_PATH=/path/to/the/MVK/libdir:/usr/lib". That will be automatically sourced by the wine script at a point after SIP has done its stripping.

If you're running an installed Wine, then the "wine" command may be just the Wine loader program, not a shell script. In that case, SIP is not involved.

@iain-benson

This comment has been minimized.

Copy link

commented Aug 21, 2018

I've been experimenting with this on my fork (https://github.com/iain-benson/MoltenVK/tree/dx11), as I was hoping to play Witcher 3 on the Mac, without rebooting.

  • Added (and implemented) vkGetPhysicalDeviceFeatures2KHR and vkGetPhysicalDeviceProperties2KHR
  • Added stubs for the remaining methods for VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2, and the methods listed above
  • Set the flags to true for the device features required for DX11

It gets further, and starts setting up the shader modules, but the conversion of the SPIR-V code fails as it tries to use an undefined method spvTexelBufferCoord.

I am fully aware the changes I made wouldn't actually result in a working system, but I was looking to see what work was required, and will continue attempting to implement what I can, to see if I can get anything working.

@oscarbg

This comment has been minimized.

Copy link
Author

commented Aug 26, 2018

Hi @iain-benson,
nice work..
strange thing is spvTexelBufferCoord seems to be introduced recently in https://github.com/KhronosGroup/SPIRV-Cross/blob/master/spirv_msl.cpp by :
KhronosGroup/SPIRV-Cross@4c5142b
"Emit and use spvTexelBufferCoord() function to convert 1D texel buffer coordinates to 2D Metal texture coordinates."

uint2 spvTexelBufferCoord(uint tc)
{
    return uint2(tc % 4096, tc / 4096);
}

just for curiosity what MoltenVK version are you using? from 1.1.82?

kergoth added a commit to kergoth/Proton that referenced this issue Aug 27, 2018
dxvk isn't of any real use on mac until it's able to link to MoltenVK
See KhronosGroup/MoltenVK#203 and
doitsujin/dxvk#601.

Signed-off-by: Christopher Larson <kergoth@gmail.com>
@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Aug 31, 2018

So far, of those extensions, I've implemented VK_KHR_maintenance1, VK_KHR_shader_draw_parameters, VK_KHR_get_physical_device_properties2, and VK_KHR_descriptor_update_template. The patches for the first three were merged (#230, #232, #235). The patch for the last one depends on another patch I have to implement VK_KHR_push_descriptor (#236), which vkd3d (a different library for D3D12) wants but doesn't need to work. The reason for that is that those two extensions interact--there's a call that's available only if both extensions are supported. You can see the patch for VK_KHR_descriptor_update_template at my fork.

I still need to investigate the core Vulkan features that DXVK needs but MoltenVK doesn't have yet.

@oscarbg

This comment has been minimized.

Copy link
Author

commented Aug 31, 2018

Amazing work @cdavis5e !!
I thought we were months from seeing real progress on this..
Thanks..

@banzr

This comment has been minimized.

Copy link

commented Sep 2, 2018

Hey, I'd love to help but I'm not sure where to start. Can someone help fill me in on what references/documentation are out there? Thanks! I stumbled on this while trying to install Steam Proton on my macbook pro. I'm a Sr CS undergrad with no experience with DXVK or vulkan, but I am very familiar with C/C++.

@oscarbg

This comment has been minimized.

Copy link
Author

commented Sep 3, 2018

Hi @banzr,
I don't know what's the best answer I can gave you, but I will try..
basically for this specific issue you need to gain some Metal and Vulkan knowledge/experience..
as this is what MoltenVK is about..
For Metal see:
https://developer.apple.com/documentation/metal
(deprecated) https://developer.apple.com/library/archive/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Introduction/Introduction.html
useful will be:
https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf
also see : https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf
(some things are only avaiable in newer OS or GPUs)
then familiarize with MoltenVK codebase and also SPIR-V Cross as this is used for shader translation.. then seeing the extensions/optional Vulkan features DXVK needs (first post in this thread) and try to know how you map these to Metal and implement it..
in theory, you don't even need to know anything about DXVK.. as far as MoltenVK exposes all required DXVK Vulkan functionality you are done..
or you may forgot everything I said until now and go the opposite way.. of learning as needed to implement individual items.. let's take two examples:
1)Imagine you want to add double precision support to MoltenVK (really DXVK can use it but not useful in real games):
you read Metal-Shading-Language-Specification and see:
"Metal does not support the double.."
so it can't be done.. well not easily.. it can be emulated by doing something similar to guys in Mesa have done:
"The Student Working On "Soft" FP64 Support Is Good News For Older GPUs"..
on mesa cgit you should find shader code emulating doubles via floats..
2) Similar thing will be found for geometry shader, you will find Metal doesn't support it..
3) Imagine you want to add tesselation support to MoltenVK:
read in Apple how it's exposed:
https://developer.apple.com/library/archive/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Tessellation/Tessellation.html
find a Vulkan simple sample:
https://github.com/SaschaWillems/Vulkan/tree/master/examples/tessellation
you will find MoltenVK uses SPIR-V Cross for shader translation you will need to add translation from tesselation stage to Metal..

hope it helps (a little)..

@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Sep 4, 2018

SPIRV-Cross #675 should fix the issue with spvTexelBufferCoord().

@oscarbg

This comment has been minimized.

Copy link
Author

commented Sep 8, 2018

@cdavis5e I see you are contributing lots of SPIRV-Cross patches/improvements too.. thanks..
let me ask two questions:

  1. are they fixing (simiar to spvTexelBufferCoord issue) some MoltenVK bugs for DXVK or VKD3D?
    I say as sadly seems MoltenVK is still referencing an "old" SPIRVCross tag without all you improvements so would l like to know what benefits I get by compiling SPIRV-Cross up to latest commit..
  2. will all your MoltenVK & SPIRV-Cross commits (& possibly your pull requests not yet merged on this two repos) is DXVK simple included apps like d3d11-triangle and d3d11-compute working?
    have you an estimate of how much work/patches still remaining to get these two "simple" demos (d3d11-triangle and d3d11-compute) working under MoltenVK?
    thanks..
@billhollings

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

@oscarbg I'll be doing a MoltenVK release this weekend that will include an upgrade to the latest SPIRV-Cross...including all the wonderful work @cdavis5e has been contributing.

@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Sep 8, 2018

@oscarbg Yes, these are to fix bugs in MoltenVK for vkd3d (which will inevitably benefit DXVK as well). Eventually, I would like to get the DXVK samples running. Hopefully I should be able to have them up within about a week—a month, tops.

Real support for cull distances (which DXVK apparently wants to create a device at all) might be difficult, though: Metal doesn't support them directly, so we'd probably need to have some sort of pre-processing stage to support that at all. In the meantime, I wonder if we could get away with saying we have it even though we don't. Logic op is similar, though I'm less sanguine about the prospects for emulating that one.

The big ones, of course, are geometry and tessellation shaders. Since Metal doesn't directly support tessellation control (hull) or geometry shaders, those need preprocessing similar to cull distances. My plan right now is to run these shaders as part of a compute pipeline that runs right before the graphics pipeline. This is the way Apple actually recommends tessellation be done. I think we can fully support geometry shaders this way, too. Supporting the two together will be a real pain, though, since we'll need to run three preprocessing steps before we can run the graphics pipeline: the vertex and tess. control shader in a compute kernel, the tessellator and tess. evaluation (domain) shader, then the geometry shader in another compute kernel.

I think it should be possible to just turn on robustBufferAccess, shaderImageGatherExtended, and drawIndirectFirstInstance right now. Most of the remaining needed extensions and features shouldn't be too hard to implement.

@KenThomases

This comment has been minimized.

Copy link

commented Sep 9, 2018

This may not be a good idea, but it's possible to do geometry shading in a Metal vertex shader if you change the draw command. See my StackOverflow answer here. This is mostly useful if rasterization is enabled, since it can feed directly into the rasterizer stage without switching from render to compute and back to render.

My SO answer was mostly contemplating hand translation. For automated translation, you'd generate code that parallels the geometry shader much more closely (because you pretty much have to). The "emit" operations would, first, track which output primitive and vertex within that primitive they're working on. Then, they'd check if the current output primitive and vertex are the ones for the current thread/invocation. If so, they'd set the output value. If not, they'd do nothing.

@oscarbg

This comment has been minimized.

Copy link
Author

commented Sep 10, 2018

@billhollings many thanks for updating SPIRV-Cross and doing a release!

@cdavis5e also many thanks for your great detailed overview..
as you talk about cull distances & "pre-processing stage to support that at all".. I would love to know what do you think also about swizzle Metal limitations.. seems will require similar preprocess stage and seem like AAA Vulkan games (like Doom and Wolfenstein II) and other Vulkan programs (RPCS3 via Wine ( #205 ) ) make use of it..
I posted results of running these two games under Wine+MoltenVK around a month ago here showing swizzle limitations:
#204 (comment)
#204 (comment)

really I was just asking about d3d11-triangle and d3d11-compute DXVK samples as seems DXVK is asking for a lot of things, that these simple two programs don't need to run, and even simple hacking DXVK to not use missing caps&exts. , as it's shown in first post, samples still crash.. last time I tested they were failing at spvTexelBufferCoord step.. so maybe they are fixed now or may work soon as you share are also interested in getting it working..

@KenThomases thanks for sharing the idea here.. maybe that's what's doing Vmware in his Fusion product.. as you know probably for almost a year since Fusion 10 it supports DirectX10 via Metal.. I have run some DX10 geometry sample programs and it works OK.. mainly from NV DX10 SDK(http://developer.download.nvidia.com/SDK/10/direct3d/samples.html):
Lightning,Rain,MetaBalls ,Fur - Shells and Fins..
also interesting is "Lightning" sample uses also stream out:
"efficiently implemented using geometry shaders and stream out"
so Vmware is emulating stream out also in Metal, I say because stream output much in the news these days like on khronos.org "Some Vulkan members are developing a multi-vendor EXT extension for transform feedback" right now because seems is the last big Vulkan "missing feature" for DXVK playing DX11 games using it "correctly" like "Witcher 3".. so eventually might make sense for MoltenVK to support also that extension..

@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Sep 10, 2018

@oscarbg I just hit an issue that will require swizzling (related to #243). In this case, D3D puts the stencil value in green, but Metal puts it in red. By default, Vulkan also puts it in red; that's why vkd3d uses a swizzle to make it appear in green. To make this work for any arbitrary swizzle, we'll probably need to apply a technique similar to what wined3d does when the GL_ARB_texture_swizzle extension isn't available, by manually swizzling the texture and/or fixing up the shader to do a swizzle on every load.

@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Sep 24, 2018

OK, I've implemented support for all extensions that DXVK needs, and I have some patches outstanding to implement the remaining few it wants in addition (#273), and I've also turned on and/or implemented quite a few core features as well. If I then force on all the other features that DXVK needs (see attached patch), I can get MS's D3D11 samples to successfully create a device using DXVK... and then it crashes and burns because DXVK sets a (0, 0, 0, 0) swizzle and Metal doesn't support arbitrary swizzles. Don't worry; I'm working on the swizzling issue: see KhronosGroup/SPIRV-Cross#706.

@doitsujin

This comment has been minimized.

Copy link

commented Sep 26, 2018

I could get rid of the (0,0,0,0) swizzle if that helps. It's only used to provide support for unbound textures, but since the image used with that view is cleared to zero anyway, i could just use an identity swizzle there.

Some other swizzles are necessary, though.

@Rastafabisch

This comment has been minimized.

Copy link

commented Jan 9, 2019

I just wanted to report the current status to those curious (like I've been). With the latest MoltenVK as of today (v1.0.30 - including @cdavis5e preliminary DXVK patch), the latest non-rc wine version (3.21) and the latest DXVK libraries (0.94) I was able to launch the Witcher 3. While it does not crash, and starts playing the prolog audio and reacts to keyboard input (skipping the prolog), it does not draw anything to the screen. It's just black (using DXVK 0.81 - the last pre stream output version the screen was blue but apart from this it was just about the same. So to draw a line: Anyone involved already achieved some huge progress.

About the only error messages regarding dxvk/moltenvk are the following:

[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: Vertex shader function could not be compiled into pipeline. See previous error.
err:   DxvkGraphicsPipeline: Failed to compile pipeline
err:     vs  : VS_71ac5766523bfe85650fb70fe2faa3b7a4efa3b8
err:     fs  : FS_a06e822f5ba921672573f4b95e59a40b14bf6ed7
[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: Shader library compile failed (error code 3):
Compilation failed: 

program_source:8:31: error: 'function_constant' attribute requires Metal language standard macos-metal1.2 or higher
constant bool cb0_bound_tmp [[function_constant(0)]];

Here is the entire wine log, in case it proves to be somewhat helpful:
Wine_MoltenVK_DXVK.txt

Wine was actually build with an older version of MoltenVK. Just the runtime library have been updated, though I do not expect it to be a problem.

@billhollings

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2019

@Rastafabisch

What version of macOS are you running?

The complaint about requiring MSL 1.2 or higher would imply you are running macOS 10.11.

@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

The log also says that MSL 2.1 is supported, as well as GPU Family 2 and GPU Family 1 v4, implying that this was run on macOS 10.14.

@cdavis5e

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

It looks like I need to implement geometry shader emulation and VK_EXT_transform_feedback to make this particular game work:

err:   D3D11: CreateGeometryShaderWithStreamOutput:
  Transform feedback not supoorted by device
@oscarbg

This comment has been minimized.

Copy link
Author

commented May 25, 2019

just wanted to point that since DXVK 1.1, the @cdavis5e MoltenVK simple patch/way of "supporting" DXVK via:

_features.shaderCullDistance = true;
_features.geometryShader = true;
_features.logicOp = true;

isn't enough as DXVK starts using Vulkan events API calls like vkCreateEvent, etc....
of course well know limitation:
from https://github.com/KhronosGroup/MoltenVK/blob/master/Docs/MoltenVK_Runtime_UserGuide.md
Known MoltenVK Limitations:
"VkEvents are not supported."
never known if it's due to much needed work to support it or some underlying Metal API limitation vs Vulkan..

EDIT: I opened DXVK issue (doitsujin/dxvk#1077 (comment)) and answer seems to be that it must be solved by MoltenVK by implementing events support..

@Rastafabisch

This comment has been minimized.

Copy link

commented May 28, 2019

Update to my previous report.

IT DOES NOT WORK. (Just so nobody would get too exited.)

The Witcher now starts and displays anything like it should, up to the menu (sequences, movies, etc.). Any options can be customised to your liking without triggering a crash.
Starting a new game the initial sequence is shown including parts which look like live rendering, rather than a movie in the end (unconfirmed). However I never got into the game as the executable just crashes silently thereafter.

DXVK: various versions from 0.94 up to 1.2.1 (latest)
Wine: Wine4.7
MoltenVK: latest as of today (a684b47) with @cdavis5e's fake-extensions patch
(opposing @oscarbg's previous command, although indeed the log is spammed)

[mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: vkCmdSetEvent(): Vukan events are not supported.
[mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: vkResetEvent(): Vukan events are not supported.
[mvk-error] VK_ERROR_FEATURE_NOT_PRESENT: vkCreateEvent(): Vukan events are not supported.
err:   DXVK: Failed to create GPU event

This – as previously determined – does not happen with dxvk 1.0.3 and below.

The setup is run within an unofficial Wineskin Wrapper, with a patched wine64-preloader script injecting the DXVK and swizzling environment variables.

MoltenVK_DXVK_The_Witcher_3

Here you have the wine.log, after The Witcher crashed. The main issues here seem to be the following:

[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Under Metal, vertex attribute offsets must not exceed the vertex buffer stride.

&

[mvk-error] VK_ERROR_INVALID_SHADER_NV: Vertex shader function could not be compiled into pipeline. See previous logged error.

[…]

[mvk-info] Shader library compilation succeeded with warnings (Error code 4):
Compilation succeeded with: 

program_source:14:15: warning: unused variable 'cb0_bound'
constant bool cb0_bound = is_function_constant_defined(cb0_bound_tmp) ? cb0_bound_tmp : true;
              ^
program_source:22:15: warning: unused variable 'cb1_bound'
constant bool cb1_bound = is_function_constant_defined(cb1_bound_tmp) ? cb1_bound_tmp : true;
              ^
program_source:24:15: warning: unused variable 't0_bound'
constant bool t0_bound = is_function_constant_defined(t0_bound_tmp) ? t0_bound_tmp : true;
              ^
program_source:26:15: warning: unused variable 't1_bound'
constant bool t1_bound = is_function_constant_defined(t1_bound_tmp) ? t1_bound_tmp : true;
              ^
program_source:28:15: warning: unused variable 'omap0_r'
constant uint omap0_r = is_function_constant_defined(omap0_r_tmp) ? omap0_r_tmp : 0u;
              ^
program_source:30:15: warning: unused variable 'omap0_g'
constant uint omap0_g = is_function_constant_defined(omap0_g_tmp) ? omap0_g_tmp : 1u;
              ^
program_source:32:15: warning: unused variable 'omap0_b'
constant uint omap0_b = is_function_constant_defined(omap0_b_tmp) ? omap0_b_tmp : 2u;
              ^
program_source:34:15: warning: unused variable 'omap0_a'
constant uint omap0_a = is_function_constant_defined(omap0_a_tmp) ? omap0_a_tmp : 3u;
              ^
@Gcenx

This comment has been minimized.

Copy link

commented Jun 11, 2019

@Rastafabisch your log says Wine-Staging-4.7, by chance is that from my MEGA folder?
If so you should know those were all the cross-compiles were built using the 10.11 SDK since osxcross only recently added support for newer SDK versions. That would explain the Metal 1.2 issue from earlier.

@oscarbg & @cdavis5e I wanted to ask is the Metal level now detected correctly for the running system or is it still locked to the SDK that’s used at wine compile time?

@doitsujin

This comment has been minimized.

Copy link

commented Jun 11, 2019

Under Metal, vertex attribute offsets must not exceed the vertex buffer stride.

To clarify, this is mostly needed to emulate "null" vertex buffers properly. When a D3D11 application binds no vertex buffer to a given slot, DXVK will instead bind a small buffer which contains nothing but zeroes, and set the stride to 0 to avoid out-of-bounds access.

I don't know any better way to emulate this that would work with this restriction. Some D3D11 apps may also do something similar themselves.

@vskllee

This comment has been minimized.

Copy link

commented Jun 11, 2019

哇哦!!!

@Rastafabisch

This comment has been minimized.

Copy link

commented Jun 11, 2019

@Rastafabisch your log says Wine-Staging-4.7, by chance is that from my MEGA folder?

You got me. I can send you my (minor) edits, if you like? (It might be worth it implementing a way to add environment variables. Basically expanding the wrappers existing WINEDEBUG variable GUI.)

If so you should know those were all the cross-compiles were built using the 10.11 SDK since osxcross only recently added support for newer SDK versions. That would explain the Metal 1.2 issue from earlier.

@oscarbg & @cdavis5e I wanted to ask is the Metal level now detected correctly for the running system or is it still locked to the SDK that’s used at wine compile time?

True, but this got fixed, as I recall.

Under Metal, vertex attribute offsets must not exceed the vertex buffer stride.

To clarify, this is mostly needed to emulate "null" vertex buffers properly. When a D3D11 application binds no vertex buffer to a given slot, DXVK will instead bind a small buffer […]

So if possible the easiest way might be ignoring the error and continuing, if this does not break subsequent functions.

@Gcenx

This comment has been minimized.

Copy link

commented Jun 11, 2019

@Rastafabisch I was only concerned that being compiled with the 10.11SDK could have caused false positives, I always use the current Vulkan SDK so that shouldn’t cause an issue.

As for the other thing sure just open an issue here as it’s not really related to MoltenVK directly. And I might forget if it’s not an open issue ;)

@kristofferR

This comment has been minimized.

Copy link

commented Jun 14, 2019

Here's the issue for adding the necessary Vulkan Events support:
#192

@Quenz

This comment has been minimized.

Copy link

commented Aug 10, 2019

#192 fixed and closed, supported added in #708

@ryao

This comment has been minimized.

Copy link

commented Aug 15, 2019

@Rastafabisch Would you retest to see if things work better now?

@ryao

This comment has been minimized.

Copy link

commented Aug 15, 2019

By the way, D9VK forked DXVK to implement Direct3D 9. Of the 3 features stated to be what DXVK still needs, D9VK only needs cull distance estimation. May I suggest that whoever is working on implementing the remaining three features implement cull distance estimation first? Getting D9VK working would be a nice milestone on the way to getting DXVK working.

@ovvldc

This comment has been minimized.

Copy link

commented Aug 15, 2019

We had this list of things that DXVK support requires, and VkEvents are now supported. So the infrastructure is there. Many thanks for all that hard work, progress has been impressive.

So how are things on geometry shader emulation, cull distance emulation, and VK_EXT_transform_feedback? I understand that it is fairly easy to fool DXVK or any app into thinking that these features are present, but would that not lead to performance loss and/or horrible graphics glitches and/or crashes?

@Degerz

This comment has been minimized.

Copy link

commented Aug 15, 2019

@ovvldc It's impossible to fully emulate transform feedbacks just using GPU compute shaders on Metal. If geometry shaders or tessellation produces an unknown a number of primitives it's nearly impossible for GPUs to be able to correspond the output data in order with the input data ...

Metal would need to expose features specific to AMD's Navi/RDNA GPUs to be able to properly emulate transform feedbacks properly such as the NGG pipeline (primitive shaders) and global ordered append (DS_Ordered_Count) ...

@ovvldc

This comment has been minimized.

Copy link

commented Aug 15, 2019

Thanks for the explanation. That is a pity. Is there any other way of pulling out the buffers? Some games depends on transform feedbacks, though not all.

@Degerz

This comment has been minimized.

Copy link

commented Aug 15, 2019

@ovvldc No, it's unfeasible to patch out the rendering logic in games. Apple should just expose geometry shaders and transform feedbacks even if it's solely just for their Mac products instead of wasting everyone's time. If they desire parity so badly either they implement some of the hardware features from AMD's Navi GPUs or implement Nvidia's mesh shaders (I wonder if this is enough to emulate transform feedbacks) because hardware features do actually matter in this instance.

You could only get away with partially implementing transform feedbacks if you knew that input/output data were statically generated with an N:N ratio such as only having a vertex shader. Variably generated input/output data with an N:M ratio such as geometry shaders or tesselation which are known for doing data amplification are impossible to properly emulate with transform feedbacks unless you had certain hardware features to make it far easier.

@ryao

This comment has been minimized.

Copy link

commented Aug 15, 2019

Many games worked with DXVK before transform feedback support was added to Vulkan. There were a large minority of games that had issues such as crashing (a significant number of unity games), black screens (e.g. Job Simulator 2050), missing models (e.g. The Witcher 3) or missing effects (e.g. Overwatch) and other misrenderings (e.g. Waltz of the Wizard), but just getting to the point where transform feedback is all that is needed would be a huge step forward.

You would also have D9VK working, which would be a huge step forward in itself.

@doitsujin

This comment has been minimized.

Copy link

commented Aug 16, 2019

Variably generated input/output data with an N:M ratio such as geometry shaders or tesselation which are known for doing data amplification are impossible to properly emulate with transform feedbacks unless you had certain hardware features to make it far easier.

You could technically do geometry shaders since you know the maximum number of output vertices that are going to be generated, but you'd have to compact the range afterwards (which will hurt performance). It also doesn't work with tessellation or indirect draws.

So yeah, this is a mess and ultimately the main reason why I insisted on getting a Vulkan extension rather than adding weird hacks that only cover half the possible use cases. Note that most games whould be happy with those restrictions, but RenderDoc, which uses VK_EXT_transform_feedback for its mesh view, requires proper support for this.

@Gcenx

This comment has been minimized.

Copy link

commented Aug 16, 2019

You would also have D9VK working, which would be a huge step forward in itself.

@ryao
The thing is how many 64Bit games use DirectX9?
Remember wine can’t currently make use of MoltenVK only wine64 can as Metal is a 64Bit API.

@kode54

This comment has been minimized.

Copy link

commented Aug 16, 2019

Well, yeah, but with the 32/64 shim and thunk dance Wine will have to start doing on Catalina to support 32 bit code, it may as well also shim 32 bit processes to be using 64 bit Metal. The real problem then becomes exchanging data between that low 32 bit address space and whatever the heck the system libraries want to map their stuff to.

@ovvldc

This comment has been minimized.

Copy link

commented Aug 16, 2019

Let's hope that Apple start moving all their laptops to 8 core CPUs ASAP. Otherwise, we won't have the performance needed to run anything.

@ryao

This comment has been minimized.

Copy link

commented Aug 17, 2019

@ovvldc A Hat In Time is the only Direct3D 9 game that I know to be 64-bit. There are likely others. @kode54’s point about the thunking does make it a moot point though.

By the way, the lack of geometry shader emulation, cull distance emulation, and VK_EXT_transform_feedback should be added to the known limitations list for MoltenVK.

@K0bin

This comment has been minimized.

Copy link

commented Aug 17, 2019

64 Bit D3D9 games:

  • A Hat in Time
  • Risen 3
  • Sims 4
  • Blade Symphony
  • Final Fantasy 9
  • Guild Wars 2

By the way, the lack of geometry shader emulation, cull distance emulation, and VK_EXT_transform_feedback should be added to the known limitations list for MoltenVK.

I disagree. The known issues with MoltenVK are in regard to the Vulkan CTS. Unlike D3D11, geometry and tessellation shaders are not mandatory for complient Vulkan implementations. It lets you query if geometry/tessellation shaders are supported. Same for the extension obviously. Most Android drivers don't support those either.

@ovvldc

This comment has been minimized.

Copy link

commented Aug 19, 2019

Depends on who is the target for the documentation. If for developers who are up to speed on the entire Vulkan ecosystem, you can refer to compliance with CTS. If for people who are not deeply into Vulkan and want to know if MoltenVK can cover the features of some application, then having a section of limitations that go beyond the CTS would be good. Just as a bit of friendly guidance to the wider ecosystem.

@ryao

This comment has been minimized.

Copy link

commented Aug 20, 2019

He might have been pulling my leg, but gamedev1909 in the yuzu discord claims that renderdoc works with Witcher III and hairworks enabled in Parallels Desktop 15 on Mac OS X. He sent me this screenshot (which sadly does not appear to show renderdoc):

He declined to comment here despite multiple requests. Parallels Desktop 15 implements Direct3D 11 using Metal. If his claim is accurate, then there could be an undocumented API extension in Metal for getting transform feedback that Parallels Desktop 15 uses.

@ryao

This comment has been minimized.

Copy link

commented Aug 27, 2019

Is it just me seeings things incorrectly or are the limitations of Metal that MoltenVK is hitting in supporting DXVK all in areas unfriendly to tiling GPU architectures like the one used in the iPhone?

@K0bin

This comment has been minimized.

Copy link

commented Aug 27, 2019

No, from what I know geometry shaders and especially transform feedback are generally unfriendly to modern desktop GPUs as well.

Metal supports a lot of stuff that's not supported on any of their mobile GPUs.
https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf

@Kreyren

This comment has been minimized.

Copy link

commented Sep 17, 2019

Referencing Winetricks/winetricks#1318

Any news on MacOS support for DXVK?

@Degerz

This comment has been minimized.

Copy link

commented Sep 29, 2019

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_mesh_shader.txt

(7) Do we support transform feedback with mesh shaders?

 RESOLVED:  No.  In the initial implementation of this extension, the hardware doesn't support it.

:/

Turing's mesh shaders are not totally capable of emulating the traditional geometry pipeline like I had hoped as it is with AMD's Primitive Shaders with global ordered append ... (supersede vs superset)

If D3D standardizes this behaviour then there is very little hope for Metal to be able to realistically provide full transform feedback functionality ...

@ryao

This comment has been minimized.

Copy link

commented Oct 19, 2019

Most Mac OS X systems are using either AMD or Intel graphics, and Vulkan extensions are not available from Metal. Why is the Vulkan extension for Turing relevant? Is there an equivalent function exposed in Metal that you are using the Vulkan documentation to understand?

@Degerz

This comment has been minimized.

Copy link

commented Oct 20, 2019

@ryao Mesh shaders are getting standardized in D3D and with imposed limitations on all 3 desktop hardware graphics vendors. If Nvidia can't support transform feedbacks with mesh shaders then D3D likely won't as well ...

Apple still cares about portability with Metal even with Nvidia GPUs because they don't want to be tied down to either AMD or Intel on macOS for the foreseeable future so if Apple decides to include mesh shaders as well in Metal then it'll come with the same limitations or with even more limitations judging by Apple's history to water down features ...

Besides, global ordered append is way too specific to AMD HW so it's not a portable mechanism to expose for relying on emulating transform feedbacks. (Apple has no desire to expose low level access for any other vendors except maybe for themselves with their own iOS GPUs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.