Wine staging is getting more and more outdated, is Dxvk usable with wine-vulkan ? about dxvk HOT 53 CLOSED

Back to the question how to handle 3rdparty wine plug-ins:

It would be great to have an upstream solution, that does work with vanilla wine. Not only nine, dxvk, vk9 would benefit.

Here's the idea:
There should be a subfolder $LIBDIR/wine/3rdparty that is used to install non default wine dlls into.

• Every project creates it's own sub-folder i.e.: $LIBDIR/wine/3rdparty/dxvk/
• Every sub-folder contains a LICENSE, VERSION and DESCRIPTION file, along with other files that need to be shipped (here d3d11.dll.so, ...)
• A new tab is added to upstream winecfg, which lists all 3rdparty modules and show the VERSION and DESCRIPTION contents. The user will be able to enable/disable the override using winecfg.
• Wine's dll loader needs to be patched to first look into that sub-folder if it has been enabled in winecfg
• Package maintainers will simply install into $LIBDIR/wine/3rdparty

Having such mechanism requires no DLLRedirects and no symlinks.
The proposed solution needs to be discussed with wine devs.

from dxvk.

@SveSop Don't confuse different APIs with feature levels. D3D11 with D3D_FEATURE_LEVEL_9_1 is still D3D11 and has pretty much nothing in common with D3D9 as it is implemented in d3d9.dll.

Similarly, D3D12 is a totally different API that has almost nothing in common with D3D11.

@roothorick

Or alternately, dxvk should be split into two projects, a "driver" agnostic of DX version and a frontend that implements dx11

That's actually kind of how DXVK works under the hood already, although in no way compatible to Dx12. In theory it is possible to implement other APIs on top of it.

@oiaohm

There is no need for dxvk and vk9 to be duplicating HLSL compiler and other parts individually that can be shared between dx9 and dx11

Except that the shader models used in D3D8-9 is incompatible to the ones used in D3D10-12. There's very little duplication going on between the two projects because the APIs are fundamentally different.

So dxvk would have already partly implemented dx10 just not exposing this to interfaces to dx10 applications..

I'm fully aware of that and it will be done eventually. It's just a matter of priorities, and the priority of adding D3D10 interfaces is very low at best since there's a ton of core API features still missing. Asking for full compatibility at this stage is absurd.

Of course it's worth discussing interoperability between the different project at some point. But VKD3D wasn't even publicly announced when I started this project, VK9 has been around even longer, and none of the three projects are in any sort of stage that deserves to be called "mature" or "production-ready".

Ultimately though, different projects have different goals, and this is not a wine project. Neither is VK9, and neither is Gallium Nine that you keep disrespectfully ranting about. Please respect that.

from dxvk.

https://wiki.winehq.org/Wine-Staging_DllRedirects
The current implementation of DLL redirects does not store any information about loaded dlls which were redirected. This causes trouble if an application tries to manually load the target of a redirection while the same library is already loaded under a different name. Wine does not notice that the library was already loaded and tries to load it a second time. The behaviour of builtin/native DLLs is slightly different, but in both cases an application might be confused.

Raffarti I am sorry to bring you bad new there is reasons why Dllredirects are not mainline wine. Cherry-pick it in is current form is not a hot idea. Now if you are going to spent the time to fix the above problem then it could be merged mainline. The test driven wine development forbids merging mainline something with a known defect like that. It was merged into staging for testing CSMT with application known not to walk straight into the above problem.

Wine does not have a dkms has not need one because there has not been much third party stuff.
https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

This would be a different feature to Dllredirect this would be adding something to WINEPREFIX so that when wine updates particular setting and changes could be reapplied. This is why us doing support when applications go stupid we recommend people reinstall the application and see if problems goes away. Its also a lot of times with winetricks overrides we have not need them after updates any more so it breaking and people having to reinstall has not been classed as a major problem.

Current wine update process is a simple sledge hammer reapply wine.inf you will find this loader/wine.inf.in in source.
Run a fake.dll fix. done.
Now of course for what you are doing have a
WINEPREFIX/inf/ directory when you could put extras to be applied on update would be good.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx
To be aware its the above feature that forbids gallium nine(D3D9 state tracker) from merging into wine.

dxgi is the unification point between dx 9, dx10, dx 11 and dx 12. So welcome to possible hell there are applications out there that include dx9, dx10, dx11 code in one application rendering to 1 window.

I know gallium nine has performance but with what you are doing I would recommend look at vk9
https://github.com/disks86/VK9
Now its not complete if both of you implement in way that the dxgi interfaces work between your two implementations this would be a good thing. Of course that leaves a gap to fill of dx10.

Please note there is also some buffers sharing features between dx 8 to dx 9 but those are not a problem person working on dx10, dx11 and d12 problem those would be the those working on dx 9 problem. I have not seen any dx10 or dx11 application go back and use something dx8 if anyone knows of such a beast I would be interested to hear of it.

Really with dxgi we need vk9, dxvk and wine project vkd3d to attempt all be on the same page on dxgi of course that still leaves the problem of dx 10. Remember applications exist that use dx9, dx10, and dx11 in the same application I will not be surprised if I see application using dx9, dx10, dx11 and dx12 in one application. Its we updated the application to claim dx 11 support at the moment but we really did not update back-end code so we just did enough so we could claim it. Of course I don't see game developers being any less evil with dx12 and keeping old dx11,dx10 and dx9 code in their applications while those bits of code work.

You need to remember items don't get refused merge into mainline wine on personal reasons they are not merged because they break applications. You just might not be using the effected applications so you think things are fine. This is why cherry picking from staging patches is extremely dangerous sport because everything in there is known broken for something because if the stuff worked for everything tested it would be in development branch.

from dxvk.

Please have a look at https://github.com/iXit/wine/tree/wine-stable-3.0/programs/ninewinecfg
It is able to work with vanilla wine by setting symlinks in system32 / SysWoW64 or by using wine-staging's dll redirect feature. Both do work on wine staging and it allows us to ship nine as separate wine package (on many distros). All you need to do is to run wine ninewinecfg.exe and enable "d3d9-nine.dll".

@doitsujin
Creating the symlinks in wine's system32 does not break on wine updates or wine-nine updates. It does break if you uninstall the add-on package without removing the symlink. In that case you have to clean the wine prefix by hand, or install the add-on package again. Of course it doesn't work if you switch wine prefix, but that's expected behaviour.

@oiaohm
The DLLRedirect feature is quite good and works in 99% of all cases. Only some libraries have issues, like apitrace (that can be worked around).

I would like to see Dxvk to be usable on wine-vulkan. Sound like a task for package maintainers, not dxvk devs.

from dxvk.

@doitsujin Please note I work by action. Not though objectives. So using a patch that is not progressing to mainline and depending on with having solution that is working it way to mainline or is in mainline sends to me a message not seriously interested in mainlining. The big issue here is if the number of non mainline heading patches increase the process of attempting to mainline can get harder and harder until it never happens. This is just something to lay down a few rules so you don't dig yourself back into the same problem of depending on a particular fork of wine like you ends up with wine staging Dllredirect. The plan to mainline needs to have some rules current issue shows those rules either don't exist or need addition so this don't happen again where you use a feature not preceding to mainline without at least alternative option that is in in mainline. I am kind of tough in this regard as it better to nip this in the bud now than let it happen again with risk of possibly being more bound to patches not heading to mainline.

In theory, yes, although the current build/install system doesn't really cater to that.

Something else people don't know is wined3d is in fact made so it can be built for windows. . Us doing support with wine at times know about it.
https://fdossena.com/?p=wined3d/index.frag
You find current wined3d dx1 to dx11 for windows at the above link and the wine project accepts bugs on it.

Its highly useful at times to run wined3d on windows to see if the fault is wined3d or some other part inside wine effecting the game engine like error in locking. Do note that wined3d for windows since they are out side the main projects rules have taken the staging patches and applied it to 3.0 themselves.

The reality here is if you did have a windows form this will allow you to register on the appdb and this would allow opening and associating a bug in the main wine bugzilla for like the cases where update is nuking your important settings. So instead of having to work around a problem forever attempting a path to have mainline fix it in future so you can drop the work around with a proper stable fix.

@Raffarti understand this you can work around problem. Or you can work around problem and have problem reported to mainline to attempt to get a forever fix that will reduce your future maintenance.

@Raffarti and @doitsujin to me this project is a little too far separated from the main wine project. A few steps need to be done to close the gap.

1. Windows version so you can list in the appdb.
2. Bugs like the wine update nuking your settings need to be in the wine bugzilla so wine core developers are aware that this is causing you trouble so could think about addressing it. No bug in the wine bugzilla to wine core developers the problem does not exist. Its not useful to have your problems not exist to wine core developers.
3. Rule about insane care doing stuff not to become dependant on patches not heading to mainline where possible. Even if this means having a horrible back up plan like has just been done using straight dll override replacement instead dllredirect because straight dll overrides is mainline and stable.
4. Always remember if a patch is stuck in staging or being totally rejected by wine maintainers there is stuff serous-ally wrong with patch and it can take serous research to find out what the problem is before having it cause you issues due to those defects.

My task around wine is to provide support and advice so people do like appdb correctly do bug reports so that stuff stands a chance of being fixed. Without it you are stuck with the problems that keep on remaining.

from dxvk.

I'm not sure I follow the bit about all the versions being combined. When developing DirectX drivers on Windows the different versions have different headers and in user space they are different libraries.
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/header-files-for-directx-9-0-drivers

Also wasn't DXGI introduced in vista and only used for d3d10 forward?
https://msdn.microsoft.com/en-us/library/windows/desktop/ee417025(v=vs.85).aspx

As for previous versions of d3d it was my understanding the issue in wine was that before 9 static linking was more common so they can't just redirect a DLL. I believe I saw reference to that in the wine mailing list but I don't have a link handy.

Anyway vulkan support is on the roadmap for Wine. Using staging or some other patch is just temporary for testing purposes. That is the reason I test VK9 on Windows. Vulkan in wine will get sorted out we just need to give it time. There is plenty of work to do on dxvk and vk9 anyway.

from dxvk.

Raffarti the reality here if this development would find Dllredirects useful getting to fixed properly so to a state it could be merged mainline wine would be a valid move. And if Dllredirects went mainline development branch when wine-vulkan rebases from mainline development branch it would pick up the feature. The reason why wine-vulkan is more stable than wine-staging is it does not contain the questionable patches that in in wine-staging.

As GabrielMajeri pointed out there is a mop up operation at the moment on staging. Because people have been submitting patches to staging and not submitting them for review or update to enter mainline.

Lingering patches with issue was one of the counter arguments against having wine-staging in the first place. So people submitting to wine-staging and not attempt to fix patches for mainline may cause wine-staging to disappear.
https://dev.wine-staging.com/timeline/ Notice that Jacek Caban from codeweavers is now a lot more active with wine-staging.

So yes lingering patches not working to merge with mainline has a price and not a good one. Its also not that slacker has disappeared he is quite able to be located on irc. Just there are some really serous questions about those who have been submitting patches to staging and not submitting to wine-devel mailing list for review and up-streaming leading to multi-able duplication events.

I don't know of a open bug in wine bugzilla on the update wine breaking key settings.

Reality you were suggesting lets make another wine fork. The problem at hand another wine fork will just make life more complex.

Both wine-vulkan and the galluim-nine patched versions of wine re-base on wine development branch at regular intervals. So getting the features you need mainline instead of being Lingering patches will solve those two at the same time and any other fork anyone else decides to start.

Yes the idea of cherry picking patches and adding them instead of fixing them for mainline include with wine is only a path to make life more complex. If dllredirect had been worked on to mainline by now you should not be having problems. This is the price of hey lets use staging and depend on a feature not working way to mainline. Staging development can be frozen for random amount of time if the patch collection appears to be getting out of control because people are not working to mainline.

from dxvk.

I think we should all calm down for a bit and focus on what the actual problems are:

1. wine-staging being outdated, and
2. wine-vulkan not providing a reliable and non-invasive way of getting DXVK DLLs to work

Nobody is trying to make a wine fork.

from dxvk.

@Raffarti : i guess your last comment wasn't meant to be sent into my direction :) .

@Raffarti and @doitsujin : thank you very much for adding the possibility to use dxvk without the dll redirect option !

from dxvk.

@mirh I haven't fully followed this thread, but to me this whole DllRedirects feature is a bit hacky. It kind of is a next step behind regular DllOverrides. I think just using DllOverrides in this case is enough just flip that between native / builtin to flip between builtin and dxk assuming the dll names are the same.

from dxvk.

@oiaohm I dont understand why you say staging is not supposed to be based on the dev branch? Is there something new this round? I mean pre. 3.0, 2.0.x was the latest stable, and 2.x was the latest dev branch.
Will we not get a 3.x dev branch? Stable 3.0.1 and 3.x as "dev" branch which staging could be based on?
Waiting until wine gets to 4.x dev will take 1+ years, so if staging wont happen before that... well.

When it comes to Vulkan, i have some hope atleast. And i totally agree that this should be a combined effort to bring DX9-10-11-12 -> Vulkan, cos doing ONLY DX12 -> vulkan may not work for a lot of titles. I play World of Warcraft mostly, and in its current state WoW uses a mixture of different DX versions. That may also be why the performance is rather abysmal, cos WoW w/DX11 is slower than WoW w/dx9. There is some datamining done for the next beta and upcoming expansion lines with DX12... And they now have a warning box that DX9 will be dropped in next xpac. Does this mean that WoW will redo the whole codebase and use DX12 functions exclusively? My personal meaning is that they will (once again) jerryrig some mixture of DX10/11/12 functions and that if you try to use VKD3D with a game of that nature it will be a total misshap.
Bringing a general DX -> Vulkan instead of HLSL translator to GL would ofc be the way to go, but for all i know it is totally impossible to do so.

Wine and DX10 does not play nice together either, so i am not sure what could be done there? Interest i guess is mostly DX9 -> DX11 skipping most of DX10 as that was a "short lived" thing? I dont know..

Having all these "hack projects" going - nine, staging, DXVK++ - as "sideprojects" is perhaps not a perfect solution.

Seeing the crap-infestered-black hole that is called "Bugzilla" being the one place to make feedback to the devs.. well.. I fear its time to either stop gaming, or bend over to the mighty M$ (once more...)

from dxvk.

@SveSop I am sorry I was suffering from going from a project where lead number was default and I mixed that project version number method with wine method in my head.

I forgot wine more messy 3.0.x stuff stable 3.x development where that is a 1. I should have wrote 3.1 or 3.2 before we will see if staging will be back.

And i totally agree that this should be a combined effort to bring DX9-10-11-12<<
This would be matching what Windows 10 provides.

To match what windows 7 provides you need dx 7-dx 11, To match what XP provides you need dx 7-dx9. Between all those versions there is buffer sharing to worry about.

This is been a problem with a lot of the projects attempting to re-implement dx they have not really got how driver implementation for direct x are bundled. This is why I say there really should never been a tracker for dx 9 or dx 10 as this is not how windows drivers are implemented. a dx7 to dx9 tracker would make sense. a dx9 to dx 12 tracker would make sense.

from dxvk.

Long story short, it does, but requires more work.

wine-vulkan requires the user to install vulkan-sdk and to set it up properly, it doesn't support dlls redirections thus the current script to setup dxvk into a wineprefix will not work.

from dxvk.

ok, thank you very much for the info. I will try to get it working by simply copying the correct d3d11 and dxgi dlls into the correct directories like it worked before using the setup script..

from dxvk.

I was looking into how gallium nine worked w/o staging. Their solution is to set d3d9 to native and replace d3d9.dll in system32/syswow64 with a symlink to the correct library. It will work fine for d3d11 and dxgi as long as no other dll is loaded from a game folder or something.

from dxvk.

wine-vulkan seems to be in a good enough shape right now that it should be able to run DXVK, and if it supports debug callbacks (which wine-staging doesn't), it might also make development easier. With wine-staging being more or less dead we don't have any option but to support it anyway.

The elephant in the room is obviously getting the DLLs to load in a reliable way. Not a huge fan of creating symlinks in the wine prefix since it will break with every single wine update, but if there is no less invasive way of doing it I guess we have to do the same thing.

from dxvk.

@doitsujin I've successfully tested a .bat which deletes d3d11.dll when wineboot -u calls windows Run registry key (so it should run automatically when the wine version changes). Would adding that to the current script be a viable solution?

from dxvk.

Is that guaranteed to run before wine updates all the DLL links? If so, it's at least a temporary solution. Again I'm not a huge fan of this, but I don't have any better ideas either.

from dxvk.

Did anyone of you had luck with wine-vulkan already ? I have 64 bit vulkan apps working, but not the 32-bit ones. And i guess that is also necessary for making dxvk working for 32 bit apps, correct ?

from dxvk.

@pingubot I had it working a couple of days ago, now it suddenly stopped working and I can't get why.

from dxvk.

@pingubot well I've lost an entire day chasing weird errors to eventually find out that my wine build wasn't generating winevulkan.dll at all (the old one was lingering in the wineprefix and was failing to load). Running autoreconf -fi in the wine build directory fixed it.

from dxvk.

@doitsujin I've eventually found out that while wineboot -u will execute the bat file, normal wine updates does not.
Without that the script is quite simple, it registers dlls overrides and replace native libraries with symlinks.

from dxvk.

alternatively, commits f6b5a7cf9056c1e2bd2d1baf6f212782eaf2c80e..c37159631455db1fce3c8d620ab94380649d97c5 from iXit/wine can be cherry-picked into wine-vulkan to add dll redirections support (wine-stable-3.0 branch can also be rebased on it).

from dxvk.

I don't think we need to worry about wine-staging becoming deprecated.

The issue is that the main staging developer has been MIA since the last update. The Wine devs noticed that, and are focusing on moving the staging patches into mainline. They've improved their patch submission / approval process, so hopefully more people will be encouraged to work directly with Wine and not Wine-Staging.

If you look at the Wine Staging dev website you will notice that there's been little patch / review work, but more and more devs are working on moving their patches into normal Wine [1] [2].

Right now, the best bet is to wait for stable Wine to have Vulkan support (and they're working hard on that). Until then, you can use wine-staging (which is not too old yet) or wine-vulkan (which is a bit more complicated).

from dxvk.

@oiaohm I wasn't proposing to merge them into the mainline, since dointsujin mentioned some advantages of wine-vulkan over staging for testing (and wine-vulkan have to be built from source anyway) I just meant to provide another way to ease up testing. While I wasn't aware of the specific reasons, I surely don't expect long time lingering patches to be merged now on my suggestion.

from dxvk.

@oiaohm Yet again, I wasn't suggesting in any way that a wine fork should be generated. I was merely suggesting to those who, like myself, are testing dxvk with different setups, to locally cherry pick those commits as temporary measure.

from dxvk.

@doitsujin It does not matter how you do if wine-staging remains every year when there is a stable release it development will freeze solid and be patch swept for those that should have be merged. Also every year an evaluation will be performed if wine-staging required to still exist. Wine-staging is on thin ice.

Also staging is not to be based on the stable branch. So even that site says devel currently is 3.0 since that is a stable number staging is not be re-based against it. So I would not be expecting to see a new Wine-staging version before wine-devel goes 4.0 possible not before either 4.1 or 4.2. Staging at is best is normally 1 version behind the last proper development version. So wine-staging being currently stopped at 2.21 is perfectly valid. Staging is meant for allowing usage of patches that have failed to get into the latest open development version. Not to have to rebase those patches wine staging is always at least 1 version behind wine development version always sometimes 3 to 4. Also the staging maintainer is not required release matching version to every wine development release if they as staging maintainer due to collection of patches decided doing a release every 3 months instead of the 2 weekly they are allowed to-do that.

Yes do remember every year when a new stable is done evaluation if staging should remain existing is performed. All this will be yearly event. So wine-staging being outdated should be seen as normal.

This does bring me to another point.
Can DXVK be used under windows.
https://appdb.winehq.org/objectManager.php?sClass=version&iId=34647
If DXVK can run under windows then entry for this project can in fact have a appdb entry and that entry can be linked to bugs of items DXVK needs in wine development branch fixed so attempting to have a plan to get yourself out of trouble for good. At least the Vulkan parts.

Wine-vulkan is not being done as a long term branch by that developer. So at some point is going to cease to be current.

I am not meaning to mean or hard. The reality is depending on wine staging with no plan to get to wine development version is problem.

Testing reports for staging, development and stable can all be submitted to the appdb.

So I see this as a integration problem and failure to understand upstream.

@Raffarti even for testing using patches that are not heading for the wine development branch just will create issues in future. Yes short term fix to problem long term cause of nightmares like you currently have. That wine-vulkan will cease to exist some point in the future and if you start depending on patches that are unique to it and not heading upstream you be in time back in the same hole you are in now with wine staging. Lets try to have a plan that digs you guys out of this hole for good with hopefully no possibility of falling back into the hole..

from dxvk.

Can DXVK be used under windows.

In theory, yes, although the current build/install system doesn't really cater to that.

The reality is depending on wine staging with no plan to get to wine development version is problem.

I believe you are misunderstanding the situation entirely. DXVK does not depend on wine-staging or wine-vulkan. It depends on Vulkan support, which wine-mainline just doesn't have yet. But claiming that there is "no plan" to ever support wine-mainline is just complete nonsense.

Once Vulkan support lands in mainline - who knows when that will be - then DXVK will of course support wine-mainline as well.

from dxvk.

@oiaohm I do what is within my ability to do. I never contributed to wine and I don't have any experience in that field (dlls and whatnot). So, while we wait for someone with skills, time, and interest, we do what we can. And this is exactly why this issue is still open -- because it has not been solved. Also, this is not strictly a problem of this project itself.

from dxvk.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx
To be aware its the above feature that forbids gallium nine(D3D9 state tracker) from merging into wine.

AFAIK the officially upstream raised problems were just these (which slacker always repeated to the bitter end, without ever checking back progresses @siro20 @iXit @zhasha made in the last years)
Mixed APIs environments had never been a concern.

I mean, not saying it couldn't, but 1) fallbacks and hidden toggles are always a thing 2) d3d10 state tracker had also been a thing in the past (though of course, with no clear green light to even dx9.. what was the point?)

Now, I know they switched to a different idea (which still gives me this wrong feeling), but still.
I hope their pinging will be able to lead to further insights.

from dxvk.

@siro20 DLLRedirect wrong logic really fact you can find cases where does not work and straight dll override as what is mainline works perfectly is why DLLRedirect is not merged mainline.

Apitrace is not a minor problem either it is for you guys limit yourself to dx9. dx10 and dx11 applications like world of warcraft yes I know its dx9 problem Error Reporter in World of warcraft uses apitrace when when you are on dx10 and dx11 when directed to but not in dx9 mode.

So breaking apitrace will over time break applications that appear with more advanced crash reporting in very random ways. Why does someone like Blizzard Entertainment. with World of Warcraft want to collect apitrace is because apitrace is what gpu driver developers open or closed accept in error reports.

@siro20 like it or not if you wish to use DLLredirect long term it need to be fixed because sooner or latter there will be too many applications using apitrace or equal in their bug reporting. The 99% claim is what galluim-nine basically blocked from wine include. Lets ignore the problems that the wine developers are aware of that are growing problems.

Even on staging is questionable if you should be using DLLredirect in it current form without knowing if application is compatible or not.

from dxvk.

@mirh you failing to hear the problem. Mix API/ABI is the problem.

The current wine VKD3D project goals are to redo wined3d or at least sections of it on vulkan. One of the plans is to nuke the HLSL is the High Level Shading Language to GLSL out of wined3d that is single compiler that does from dx9 to dx11 and replace it with the VKD3D one that will both GLSL and SPIR-V out that does dx9 to dx12+. OpenGL 4.6 to be conforming requires implementation to support SPIR-V.

Windows GPU driver developers don't write a HLSL shader compiler per direct x version. They write one shader compiler for the highest version of direct x the card support then have flags that limit features when being used with lower versions of direct x for compatibility issues.

There are plans for vkd3d to be is own git so that vk9 and dxvk don't have maintain unique shader compiler and other parts that can be shared.

Reality is gallium nine idea made no sense to the wine developers. From wine project point of view it should have been a generic direct x tracker. In there you implement the feature the windows gpu drivers provide like what the wined3d.dll.so in wine provides. Neither the direct x 10 or direct x 9 tracker made any sense to wine developers.

There are reasons why i am saying vk9, dxvk and vkd3d need to work with each other to reduced the duplication in effort.

Yes vkd3d is following the windows gpu developer way of driver implementation as in implement the highest version dx then removed the old versions by redirect to the newer version.

from dxvk.

gallium nine made little sense to me too. The performance benefit over a Vulkan implementation (i.e. vk9) can only be laughably minimal, especially given that pure dx9 applications aren't exactly taxing on hardware that works with the right versions of Mesa (which generally have a passable Vulkan implementation as well). I can only assume that project got started before implementing dx9 in Vulkan sounded viable to anyone.

Anyway. It sounds like, as I mentioned in #27, there needs to be some common library that vk9, dxvk, and vkd3d would integrate together, to coordinate with each other and allow mixed API applications to function (and with a hint of luck, it'll be something I can use too). The catch is getting the maintainers of each respective project to agree on something. Who should get that conversation started and how? I don't think I'm properly knowledgeable to take the lead on this one.

from dxvk.

I think @disks86 needs to get pinged here.

from dxvk.

@mirh you failing to hear the problem. Mix API/ABI is the problem.

Again, it may even be as you say - what I'm telling you is that nobody of "official team" had ever mentioned this in the past.

Moreover, if you are telling me that codeweavers should have to rebase GL around 4.6 and gl_spirv, I'm starting to seriously doubt how accurate your "reportage" of their actual will is, given their unconditional love for mac compatibility is famous.
But I'd better leave technical discussions to siro.

gallium nine made little sense to me too. The performance benefit over a Vulkan implementation (i.e. vk9) can only be laughably minimal

Even the performance benefit of "native d3d9" instead over "GL translation" should be, at least in theory, pretty slim. And yet we are here.
Not to mention that there is hardware that "works well" with the newest mesa versions, and yet doesn't support vulkan.

Anyway. It sounds like, as I mentioned in #27, there needs to be some common library that vk9, dxvk, and vkd3d would integrate together

That would sound as a really, really nice idea.
But maybe you might want to discuss that on one of the issues trackers of yours?
(this is getting already crowded enough 😛 )

from dxvk.

Number 1 Android is a bigger possible market target than Mac now.

Number 2 codeweavers always had long term plans. spirv support will be useful when gl_spirv is open from particular drivers. I did not say rebase on 4.6. wined3d will keep on supporting older opengl but as newer versions of opengl appears it will include the features to take advantage of it. The Shader compiler for vulkan need to be spirv and glsl for itself to have full fall back.
https://www.khronos.org/registry/vulkan/specs/misc/GL_KHR_vulkan_glsl.txt
Its if you are doing something in spirv that has a issue on vulkan having the glsl to use with what Nvidia has added gives you a fall back yes slower but slower and works is better than faster and does not work. So having 1 universal HLSL shader converter for opengl and vulkan makes sense. As the newest version of opengl will take spirv and vulkan a lot of implementations can take glsl as a fall back when your own generated spirv code hits a feature that is implemented properly in that driver.

Number 3 wined3d has always had options to use opengl features on Linux that mac never has on the theory that some mac release in future will update their opengl. So wined3d/vkd3d planning has never been limited by what current opengl drivers supports be it mac, Linux or windows.

@mirh really the mac focus by code weavers that galluim nine people have uses as poiint is baseless as so as you sick your nose in wine source code and notice it using a lot more opengl than mac supports. Its funny how something can be famous yet totally wrong. Now if codeweavers are so heavily Mac why are they doing vulkan instead of metal.

Even the performance benefit of "native d3d9" instead over "GL translation" should be, at least in theory, pretty slim. And yet we are here.
To be correct direct x over desktop opengl is fairly stuffed due to a nasty drivers issue. Most of your direct x are in fact designed to multi thread. Opengl ES as requirement has to support mulithreading(what you find on Android). Desktop opengl the bugger it is optional if multi thread works. Yes in wgl from Microsoft has a multithread promise. Glx(Nvidia) and dri for X11 desktop does not have the multi thread promise. Mac random mess of somethings will multi thread other parts will not.

The one of the main reason for looking at vulkan in more places in wine is that has requirement to support multi threading.

Again, it may even be as you say - what I'm telling you is that nobody of "official team" had ever mentioned this in the past.
Its in the winehackers irc log and the mailing list debates. So saying nobody on the official team had ever mentioned it is wrong. slacker had been repeating an abraded version of the original debate on the topic with me. Also it did not help that when ever wine developers asked when was galluim nine going to do 10/11 the response was never not why is that critical. Now I asked why was that critical and I got the answer from the wine core developers because I was curious.. Basically galluim nine stone wall by saying only doing X version of direct x has result in not asking the right questions.

from dxvk.

Glx(Nvidia) and dri for X11 desktop does not have the multi thread promise.

Actually both of them do (__gl_threaded_optimizations and mesa_glthread respectively)...
And I'm kinda on the sure side that the only thing that ever scratched performance-parity was nine.

So saying nobody on the official team had ever mentioned it is wrong

I wasn't aware of that, so I'll have to trust you on it (it didn't help that slacker never brought the matter up, only echoing again the outdated critics even when pinged directly)
Your grammar is quite lacking there then, but I still cannot see why theoretically gallium couldn't do it all from nine to 11 (or even beyond? lol).

wined3d will keep on supporting older opengl but as newer versions of opengl appears it will include the features to take advantage of it

Good. Then if everything you said is not mutually exclusive with anything else, I don't see why gallium current shortcomings cannot be treated like any other practical inadequacy.
Or hell, just report maximum system directx version to 9 when it is in use? Report a d3d9-only graphics driver? "Prefer it" only when XP is selected? Options to avoid such nefarious situations are a lot.

from dxvk.

@mirh

And I'm kinda on the sure side that the only thing that ever scratched performance-parity was nine.

It not like there are not performance problems. It would be great to have a opengl/vulkan extention that can take HLSL so that it only need to run though a compiler process once instead twice. Of course have this designed to be used for dx9 to dx12+. But this is not what galluim-nine has implemented.

I wasn't aware of that, so I'll have to trust you on it (it didn't help that slacker never brought the matter up, only echoing again the outdated critics even when pinged directly)

Slacker is only the maintainer of staging. To get exactly why you need to be attempt to submit patches to mainline and speak to mainline developers. So you were dealing in Chinese whispers instead of going to the source. I went to source and got answers. You don't have to trust me instead do what I did an go talk the mainline developers. Find out that galluim-nine is not merge because there is quite bad design choice.

Or hell, just report maximum system directx version to 9 when it is in use? Report a d3d9-only graphics driver? "Prefer it" only when XP is selected? Options to avoid such nefarious situations are a lot.

Other than the fact that does not work without requiring users messing in settings. Because you have dx1-7, dx8 dx9 hybrid applications on XP that galluim-nine does not support either. So galluin-nine has issues with older and newer direct x. Yes XP is not direct x 9 only. A direct x 9 driver include support for 8 and 7 direct x(and 7 covers 7 to 1 dx). So you really need to do direct x 1 to direct x 9 as one group if you want to replace direct x in XP mode in wine so that everything works or at least be properly compatible with existing implementation. This is why I said the tracker should have been just direct x targeting a particular version alone does bring hell because Microsoft did not implement the direct x versions independent from each other but instead are progressive development stacking on top of prior work at driver level.

This is the mistake when you look at windows direct x drivers other than dx1 every dx driver support multi versions of direct x with the idea that you program could be using multi versions of direct x at the same time.

Reality under windows there is no such thing as a d3d9 only graphics driver so applications don't have to be design to deal with that beast.

from dxvk.

Yes, but unless surface sharing also existed between d3d9 and previous versions, there's no foreseeable breakage or "hole" there..
I had never thought about gallium for previous versions (I guess like that could be some additional deal of fun), anyway for the time being it seems like Nine is not even in need of fixing or additions.

It would also certainly be great to have the same stuff implemented in Vulkan (for intel and proprietary nvidia users, if not any) and I wish you all best luck.
Maybe @roderickc could shed some light on the merits and demerits of symlinks/redirection.

from dxvk.

Also wasn't DXGI introduced in vista and only used for d3d10 forward?

Yes, but then 7 (also Vista w/ platform update) introduced in turn Direct3D 9Ex (which is what supports surface sharing oiaohm was talking about). still stands for his XP point

from dxvk.

@disks86
https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx
This is where it gets interest above is how DXGI is hooked up.
You are right DXGI is Vista+ . But in Vista DXGI was added as extension to Dx9. So DXGI goes from Dx9 in vista to latest version of Dx.

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/header-files-for-directx-9-0-drivers
re read over this and you will notice Microsoft documentation mentions doing a dx7-dx9 driver.

This is a key page.
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/direct3d-version
A DirectX display driver must support DirectX 7.0 and earlier versions of the DirectX runtime.
That rule on that page disappears when you get to Windows 10 not before.

When building dx driver for XP you had to set DIRECT3D_VERSION and that mandates that you in fact include in your direct X driver support for Dx 7

Now if you want the version of windows you need so you have dx9 without requiring old version support. That windows 10 but then you need to support dx9 to dx12.

@mirh

Yes, but unless surface sharing also existed between d3d9 and previous versions, there's no foreseeable breakage or "hole" there..

Due to the fact dx 7 8 and 9 are implemented in overlapping driver code. When you do a buffer allocation in dx 7 you can then use that allocation straight in a dx 9 function or that what should work but you find out with how galluim-nine is currently implement that don't work. So yes surface sharing exists between dx7, dx 8 and dx 9. Its dx 9 to dx 10 is where special handling appears in vista but that is because they got to work and changed some of the structures in background in incompatible ways at Vista..

from dxvk.

So let me get this straight. You're of the opinion that vk9 specifically shouldn't exist, and scope of dxvk should be expanded to 9 through 12? Or alternately, dxvk should be split into two projects, a "driver" agnostic of DX version and a frontend that implements dx11, meanwhile vk9 should be rewritten to use the same "driver" and there should be new projects doing the same for 10 and 12? The latter certainly seems reasonable on paper, but runs the risk of duplicating the work of vkd3d, or worse, becoming dependent on such, which could handicap what I see as an important secondary application of dxvk (a D3D implementation for native Linux applications to make porting easier).

Trying to follow the thought process here. The architectural details are actually pretty relevant to what I've been trying to accomplish elsewhere.

from dxvk.

@roothorick There have been many directx to opengl conversion tools they made the same mistake as well.
https://github.com/ValveSoftware/ToGL
Basically implementing a single version of direct x. Problem is a heck lot of codes bases are mixed beasts of direct x using more than 1 version.

There are sane groups of direct x to implement. dx9-dx12 as a group means you can target applications built for Windows 10. dx7,dx8,dx9 as a group would be target applications at XP
Vista is dx7, dx8, dx9, dx10
Windows 7/8 is dx7 ,dx8, dx9, dx10,dx11

When you implement dx7 you in fact implement dx1 to dx7 in one process.

How many versions of direct x you need alters with applications targeting what version of Windows.

Thing to remember you are already duplicating work that vkd3d is going to cover in the shader compiler because vkd3d going to be used all the way back to dx9 in wine mainline intel is working on mainline their opengl 4.6 right now for Linux. I also understand that you might not get along on license.

dxvk and vk9 are both under zlib/libpng license. You do need to talk with each other and format you license page/file the same way.

Of course vkd3d is going to be under LGPL this license may not be compatible with what you guys want. So due to license duplicating what vkd3d is doing may be required.

There is no need for dxvk and vk9 to be duplicating HLSL compiler and other parts individually that can be shared between dx9 and dx11 think this could be implemented as common shared library and both projects are the same license so you are going to be writing code that does exactly the same thing under the same license and effectively doing less testing. So doing it twice for no good reason and that doing it twice it going to cost quality. There is a reason to duplicate vkd3d due to license but this is up to your projects decide.

dxgi and dx7-dx9 buffer sharing this is help by the different direct x versions sharing the same common code at driver point. Yes there need to be common driver code so that buffers can be shared without needing copy in memory any more than you have to.

You need to drop the idea of individual trees per direct x version it does not make that much sense. dx10 and dx11are not complete rewrites. So when you implement dx11 you are also implement functions that could be exported as dx10 because Microsoft did not change everything.
https://msdn.microsoft.com/en-us/library/ff476190(v=VS.85).aspx even there own documentation tells you this.

You also find this same thing with dx9 and dx8 where dx9 is expanded dx8..

So it makes sense to be for there to be a dx1-dx7 project, dx8-dx9 project, dx10-11 project and dx12+ project. So currently all of direct x just breaks down into 4 related segments.

So dxvk would have already partly implemented dx10 just not exposing this to interfaces to dx10 applications.. vk9 has implemented sections of dx8 that they are not providing interfaces either.

This is the problem tunnel visions on a direct x version means you fail to see that direct x versions by Microsoft come in groups..

This is why I say the mesa trackers made no sense and what you are doing is not making much sense.
So lets attempt to avoid duplicating without need.

from dxvk.

I agree that if bringing DKV3D as DX12 also implies dx9-10-11-12 is all supported, that is no problem. Is it like that tho?

Does wine only come with d3d9.dll to support older software that are totally unaware of d3d11.dll and its feature level implementation? And if i load d3d11.dll and request "feature_level 9_1" this should work with d3d11.dll? Is that the way wine does it currently? Or does d3d9.dll gets loaded in case of a "feature_level 9_1" request?

from dxvk.

#52 is a good example of a game using d3d10 and d3d11.

from dxvk.

@doitsujin I think that was kinda what i WAS believing, but then all the talks about "DX11 has all the stuff older DX's has" was put above, and i started wondering...

So, should my question be: Since some (many?) games actually is not 100% true to using 1 DX version, how would a "pure" DX11 -> Vulkan translation work? I mean, game developers is very likely to be in the world of "If it works in windows hacking a mash of different DX9/10/11/12 things together = WIN!".

For quite a few games they release it with eg. DX9. Then they "upgrade" it to DX10 with using some new functions and shaders and whatnot, but do not change the whole graphics engine.. and the same again for DX11... and possibly DX12. Sure, those new torchflames or whatever looks just awesome if you choose "Graphics API = DX11", but my theory would then be that perhaps the wall that the torch is hanging on is still using DX9 crap to be drawn.... because the coders were too lazy to rewrite everything to DX11? :)

from dxvk.

@SveSop Its not exactly lazy. Its cost. Not everything is performance critical or will provide any gain being upgraded to newer direct x other than been less tested and possibility introducing more cost chasing down bugs.

dxgi was made particularly to allow mixing of direct x versions. Dx9 back to dx7(dx7-dx1) that it worked was depending on the fact the driver was shared in background.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx

Also notice the interconnect on this page particular from direct2d. That right the old direct2d is not connected to dx11 but is connected to dx10. So you want to do some direct2d for your menus hello your direct x 11 application now is using direct x 10 parts and this is by Microsoft design.

So its not just game developers who don't update everything to use the latest direct x. Microsoft also does not update everything to use the latest direct x. Yes DX11 has access to all the functionally of prior DX10 but all the API/ABI provided by Microsoft don't connect to DX11 and application are not expecting them all connected. There are video play back things where the codecs work with dx9 that are not usable with DX10,DX11 and DX12 without the dxgi system.

Direct X need to be viewed as a integrated mess attempting to do a single version walks you into paths of hell. So complete feature access requires at least dx9 to dx12 implemented. Because there are parts in the Microsoft API/ABI that are only connected to dx9 or dx10 or dx11 or dx12 so to use everything you have to use 4 versions of direct x. Applications using more than 1 are not exactly rare. In the time of XP it was more common to have pure dx9 applications but even then there were dx7,dx8 and dx9 hybrids.

This is something that was not done when this project started of mapping out how direct x in fact is hooked into windows so have gone blindly forwards without the key information.

from dxvk.

@doitsujin

Except that the shader models used in D3D8-9 is incompatible to the ones used in D3D10-12. There's very little duplication going on between the two projects because the APIs are fundamentally different.

Unfortunate not true.
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx

If a Dx11 program request any of the 9_x feature levels you are meant to drop back to Shader Model 2.0 the same as dx 9.

So to correctly support DX11 you need to implement Shader model 5.1, 4.x, 4.0 and 2.0 same ones you need to implement of DX12. Yes DX12 you need to implement them all as well. If you were implement dx 10 you need 4.x, 4.0 and 2.0 and implementing dx9 you need 2.0.

https://www.lifewire.com/determine-directx-version-and-shader-model-812997
Really Shader model 1.0 to 3.0 are direct evolution on each other.

From DX11 you cannot request a DX 8 Shader Model.

@doitsujin

There's very little duplication going on between the two projects because the APIs are fundamentally different.

API to userspace applications are different at driver level all this stuff comes unified and this is why you see Dx 9 shader complier exposed to Dx10, 11 and 12. The shader complier is shared part.

https://msdn.microsoft.com/en-us/library/windows/desktop/ff476150(v=vs.85).aspx
Also you have to replicating in 9.x mode even the dx 9 feature restrictions on dxgi. So to get all your Dx11 behaviours right for the feature levels you will end up needing to implement dx9 backend with all the restrictions so the dx9 feature level works right in dx11

Get it yet Dx11 required to be able to duplicate the backend behaviours of dx9 and dx10 at times when applications request that mode. So the idea that there is no share code between dx9 and dx11 is totally wrong.

from dxvk.

Technically the right way to implement d3d11 and other versions is to implement a user mode graphics driver. I haven't followed the latest model, but in the past it was called DDI. The D3D runtime would load the user mode driver (e.g. OpenAdapter call), you provide some capabilities and callbacks and the D3D runtime does the rest. In the old days this handled some of the backwards and forwards compatibility.

There are probably some good block diagrams, but it seems the driver model is kind of similar. https://msdn.microsoft.com/en-us/library/windows/hardware/ff570118(v=vs.85).aspx

While technically this is the right way to do things (and allows native d3d9.dll and others to work) in Wine we didn't have good benefits for going this way as it just adds more layers. In addition not all the documentation and headers might be public enough (e.g. needing Windows DDK), so implementing is trickier. Overall implementing the user mode side, would likely make it all easy to share buffers as this is ultimately what is common now between the different d3d versions.

If dxvk is intended for use on Windows as well it might make sense to implement this mechanism else you would need to inject dxvk its d3d11.dll into game processes and copy protections may interfere. However for use on Wine the d3d9, d3d10 etcetera runtimes would need to be implemented, which again is a pain as well.

from dxvk.

Not to be too pessimistic here then, but what i gathered from the last two posts above would more or less indicate that unless DXVK supports some kind of "talking" to DX9/DX10 (or DX7-8 for that matter), the project is perhaps just for a "technical fun aspect" of things, as it would be too hard to make this a proper translation thingy.

So, how is it with Wine today then? Is DXGI "fixing" the problems where games/programs talk with several DX API's? I know the DX10 api in wine is somewhat lackluster as the "pure" dx10 tests/benchmarks i have tried to get to run fails miserably, but DX9 and DX11 usually works. The differences i have understood with my incredibly low understanding of this is that in Wine DX9 runs faster with GLSL disabled - ie. the GLSL/HLSL translation that happens is disabled. If i enable GLSL it is usually slower. DX11 is (perhaps) based on the GLSL translation, as no DX11 programs work with this disabled. GLSL is used to detect and set up the DX11 feature set/SM5++ from what i can gather from some logs no?

Now, if a DX11 app requests some DX9 stuff that in windows would just load whatever d3d9.dll needed and run, wine would do the d3d9 <-> GLSL translate/setup thing for that stuff under DX11? If so, that would make perfect sense why some DX11 games like World of Warcraft is slower under DX11 than DX9 (w/GLSL disabled). Enabling this in Windows tend to make the game 20+% faster than DX9, but under wine the other way around :)

As said.. i dont really have a clue, im just looking for input and trying to understand..

Hmm.. with DKVK is then the GLSL <-> HLSL translation replaced by HLSL <-> Vulkan? And if so, would not the DX9 "functions" in DX11 just be translated with the same given that they are added ofc? :)

from dxvk.

@SveSop its not that clean. If DX11 program request to be in feature level 9_x then it accessing the dx9 part of the common driver for shaders under windows not accessing d3d9.dll part. So a program ported to dx11 but not all the shaders have been updated can be using a feature level 9 mode to use the old dx9 shaders.

Dx9 programs had to be design for the nightmare that they only had a Dx7 driver that has no shaders this is why under a lot of dx9 programs you can kill GLSL under wine and they still work but do the same to a dx10/dx11 and they fail because dx10/11/12 min driver is a full dx9 driver with at least 2.0 shaders so no shaders at all is not something a dx10+ application has to be designed for. This caused some of the problem with Vista where people were my graphics card would work with dx9 under XP and Vista say dx9 capable card but their cards driver was dx7 or dx8. This is one of the fun fact is dx driver version does not have to align to dx version in usage their will be side effects using a lower version dx driver with higher version dx userspace but programs can be designed to cope inside particular limitations..

DXGI is having to be implemented fully under wine and its being a uphill battle because not enough of the common was done.so now working out how to get from exist to commonly shared this is seeing code added/moved to wined3d.dll yes the wined3d.dll does the job of the direct usermode driver in the wine dx stack. So yes there is a usermode driver in wine direct x it does not exactly match the Microsoft direct x one for interface.

A lot of DX11applications are in fact using direct2d under DX10. Wine DX10 may not be complete but it does have enough to so direct2d on DX10 works and the dxgi of that from DX10 to DX11 works.

Wine does HLSL->GLSL in the wined3d currently.
The vkd3d libirary is working on HLSL->SPIR-V. SPIR-V is the shader solution Vulkan users along with opencl and other things. SPIR-V started life in opencl.

This project would be doing HLSL->SPIR-V and vk9 would require to-do the same thing to fully support dx9..

Vulkan includes as a userspace feature GLSL->SPIR-V compiler added by Nvidia this is only sane as a fail location under Vulkan. HLSL->GLSL->SPIR-V-> driver stuff means you have extra processing.

Why did Nvidia add GLSL to Vulkan even low performing to make porting simpler so you convert your core code to Vulkan yet you can still use opengl GLSL shaders.

https://fosdem.org/2018/schedule/event/spirv/attachments/slides/2609/export/events/attachments/spirv/slides/2609/2018_gl_spirv_fosdem_talk.pdf
GLSL→GLSL IR→NIR→Intel IR
Current in opengl looks like above. Plan Intel is following
Under wine it
HLSL→GLSL→GLSL IR→NIR→Intel IR
Each of those arrows is a conversion and cpu consuming.
Intel long term plan/mesa.
GLSL→SPIR-V→NIR→Intel IR
But even in the short term plan
SPIR-V→NIR→Intel IR long side the GLSL→GLSL IR→NIR→Intel IR path.
This makes HLSL →SPIR-V→NIR→Intel IR path is shorter under is vulkan or opengl 4.6+ than the current HLSL→GLSL→GLSL IR→NIR→Intel IR path. Also the GLSL IR path can be attempting to optimise and change the passed GLSL a lot more than the SPIR-V stuff so the GLSL IR bit is quite heavy.

So in theory GLSL on Vulkan should end up performing as bad as GLSLon opengl with the SPIR-V path when you have access to it being faster be it opengl 4.6+ or vulkan.

Some of galluim nine speed is a shorter for converting HLSL.

The reality here is I would love to see a HLSL→NIR opengl/vulkan extension so that HLSL→NIR→Intel IR is possible. This would be useful for porting dx applications to opengl/vulkan.

from dxvk.

@siro20 : i like that idea. would make wine much easier to extend with different non standard modules.

from dxvk.

Closing this since the original issue - dxvk not being usable on wine-vulkan - has been resolved.

from dxvk.