Requirements for DXVK support.. #203
Comments
|
How did you get wine to recognise moltenVK? I get
|
|
I think had some issues but copied everywhre /lib /usr/lib /usr/local/lib.. |
|
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. |
|
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.
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. |
|
Hi @iain-benson, just for curiosity what MoltenVK version are you using? from 1.1.82? |
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>
|
So far, of those extensions, I've implemented I still need to investigate the core Vulkan features that DXVK needs but MoltenVK doesn't have yet. |
|
Amazing work @cdavis5e !! |
|
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++. |
|
Hi @banzr, hope it helps (a little).. |
|
SPIRV-Cross #675 should fix the issue with |
|
@cdavis5e I see you are contributing lots of SPIRV-Cross patches/improvements too.. thanks..
|
|
@oscarbg Yes, these are to fix bugs in MoltenVK for 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 |
|
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. |
|
@billhollings many thanks for updating SPIRV-Cross and doing a release! @cdavis5e also many thanks for your great detailed overview.. 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): |
|
@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 |
|
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. |
|
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. |
ghost
mentioned this issue
|
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: Here is the entire wine log, in case it proves to be somewhat helpful: 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. |
|
What version of macOS are you running? The complaint about requiring MSL 1.2 or higher would imply you are running macOS 10.11. |
|
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. |
|
It looks like I need to implement geometry shader emulation and |
@Gcenx there is any place to track progress on this? hoped we will have support for that by now.. |
|
@oscarbg mostly just tracking upstream wine. |
|
thanks.. @Gcenx seems following these links also will keep up to date on this efforts: |
billhollings
added
the
Metal improvement required
|
This issues a bit of a meta-issue, but I am curious where things stand now. A lot of work has clearly been done :). Of big ticket items that are missing, I understand that geometry shaders are being worked on by Jan Sikorski in pull request 1815 (#1815), and both geometry shaders and transform feedback support have been developed for the Ryujinx emulator's MacOS version (https://blog.ryujinx.org/progress-report-january-2023/). I have no idea if any of that is helpful and/or sufficiently performant. If anyone has a good overview of how much is still left on that long list of things enumerated in the first comments, I'd be happy to read it. |
I believe Bill working on this in private where the WIP from Jan was reworked from something Chip had done for CW internally, however going off the other PRs from Jan they seems to get stuck in limbo.
Ryujinx seems to be falling back to OpenGL for these functions, Apple allows you to draw using OpenGL and Metal at the same-time this is lightly something Bill wants to avoid.
Same |
I highly doubt that. It would mean running two render backends at the same time and also making Ryujinx work on Apples ancient OpenGL 4.1 drivers. They generally require OpenGL 4.5. |
is this a good or desirable idea? no. is it not only permitted to mix opengl and metal at the same time, but specifically documented by apple how to do this? weirdly, yes. as for ryujinx itself, yes, opengl 4.1 is quite inadequate for their needs, but the point here is that they aren't using opengl as the backend. it's moltenvk, with some workarounds glued on top. i haven't looked closely enough to tell personally if they are using opengl in those bits, but if so, they still don't need the whole opengl 4.5 API featureset for it. so it's plausible, particularly given that apple specifically blesses doing nonsense like this. edit: i have since looked, they are definitely involving opengl for their workarounds for the bits moltenvk doesn't cover: |
|
This is what gdchan has done to emulate GS and TF. Huge Respect for this Dev.
|
|
Yes, I had seen that Ryujinx blog post. My question was more if it is a helpful example for MoltenVK, and what else still needs doing. And respect to everyone doing coding in this field. Good graphics programming is hard, and fitting a round peg into a square hole is also hard... |
Impressive! To what project was this work added? |
|
@billhollings |
|
Adding on to the Geometry Shader/Transform Feedback pile with the release of Crossover 22.1, Genshin Impact became runnable. Some stuff doesn't render likely due to these missing features.
See missing enemy and Aether's body |
|
Unity uses transform feedback for skinned meshes. |
|
OpenGL is not used on Ryujinx on macos. We have a graphics abstraction layer which allows both OpenGL and Vulkan backends to be used in the same way, so methods or capability reporting has to be added to both backends (generally with a preset value on opengl due to expected minimum feature level). That's all the changes to OpenGL in macos related PRs are. |
I tried adapting a patch from Dyson Sphere Program, another Unity program that suffers from the same issue with skinned meshes, but I was unsuccessful |
|
They worked just on their own internal renderer they didn't customize MoltenVK to achieve that I guess. |
I mean Ryujinx doesn't really have a 'renderer'. Switch games have a massive degree of variability in their rendering techniques, so Ryujinx has to essentially emulate the functionality of the GPU in order to be flexible enough to render a wide range of games. I can't comment on that feature itself has it's not open-sourced yet but there still might but useful stuff to gleam from the internal team's implementation. |
Well by renderer I meant Backend. |
@IsaacMarovitz Currently, to bypass transform feedback error in unity games, just edit the |
|
What are the issue or status of MoltenVK to support d3d9 in DXVK? When running 32bit directx9 games crossover/wine has terrible performance. |
That's not because of MoltenVK, It's because d3d9 is 32-bit, and Wine for Mac has to fall back on OpenGL which is notoriously slow on the latest macOS versions, also there's the 32 to 64-bit conversion that further slows down performances. |
Interesting, thank you. On LINUX DXVK has directx9 support, on mac it doesn't (only dx10 and 11), because I've been told that MoltenVK doesn't support the extension to make DXVK-macos dx9 work. |
If you managed to override d3d9 on wine and don't use opengl that's different then... |
Yup that's basically what I'm interested in. Does anyone know the issue or status of MoltenVK to be able support d3d9 in DXVK so we don't need to use OpenGL. |
There’s no native OpenGL driver on Apple Silicon instead it’s provided via Metal for WebGL. CrossOver-22.1.0 added thunks for Vulkan that’s why it’s now able to run 32Bit DirectX10/11 titles. The conversion between 32 and 64 has a slight performance impact but nothing too major. Here’s an example of a 32Bit DirectX11 game |
OpenGL over Metal within Wine is proving to be too slow for the more resource intensive directx9 win32 titles. Mortal Kombat Komplete Edition and Ultra Street Fighter IV won't reach 60 FPS even on the lowest setting on my M2 Max. See one report here: https://github.com/Gcenx/WineskinServer/issues/388. Parallels performance is good. DirectX 10 and 11 games that If tested are performing well. |
and others
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;
}
`
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..
The text was updated successfully, but these errors were encountered: