Wine staging is getting more and more outdated, is Dxvk usable with wine-vulkan ? #38
Comments
|
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. |
|
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.. |
|
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. |
|
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. |
|
@doitsujin I've successfully tested a .bat which deletes d3d11.dll when |
|
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. |
|
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 ? |
|
@pingubot I had it working a couple of days ago, now it suddenly stopped working and I can't get why. |
|
@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 |
|
@doitsujin I've eventually found out that while |
|
alternatively, commits f6b5a7cf9056c1e2bd2d1baf6f212782eaf2c80e..c37159631455db1fce3c8d620ab94380649d97c5 from iXit/wine can be |
|
https://wiki.winehq.org/Wine-Staging_DllRedirects 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. 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. https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx 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 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. |
|
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 |
|
@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. |
|
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. 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. |
|
@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. |
|
I think we should all calm down for a bit and focus on what the actual problems are:
Nobody is trying to make a wine fork. |
|
@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 ! |
|
@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. 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.. |
In theory, yes, although the current build/install system doesn't really cater to that.
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. |
|
@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. |
|
@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.
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. 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.
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. |
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) 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. |
|
Please have a look at https://github.com/iXit/wine/tree/wine-stable-3.0/programs/ninewinecfg @doitsujin @oiaohm I would like to see Dxvk to be usable on wine-vulkan. Sound like a task for package maintainers, not dxvk devs. |
|
@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. |
|
@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. |
|
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. |
|
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. 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.
The one of the main reason for looking at vulkan in more places in wine is that has requirement to support multi threading.
|
Actually both of them do (
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)
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. |
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.
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.
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. |
|
Yes, but unless surface sharing also existed between d3d9 and previous versions, there's no foreseeable breakage or "hole" there.. 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. |
|
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. Also wasn't DXGI introduced in vista and only used for d3d10 forward? 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. |
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 |
|
@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. |
|
@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. 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. 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...) |
|
@disks86 https://docs.microsoft.com/en-us/windows-hardware/drivers/display/header-files-for-directx-9-0-drivers This is a key page. 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.
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.. |
|
@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<< 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. |
|
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. |
|
@roothorick There have been many directx to opengl conversion tools they made the same mistake as well. 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 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. 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. |
|
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? |
|
#52 is a good example of a game using d3d10 and d3d11. |
|
@SveSop Don't confuse different APIs with feature levels. D3D11 with Similarly, D3D12 is a totally different API that has almost nothing in common with D3D11.
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.
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.
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. |
|
@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? :) |
|
@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. |
Unfortunate not true. 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 From DX11 you cannot request a DX 8 Shader Model.
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 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. |
|
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. |
|
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? :) |
|
@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. 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 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. |
|
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:
Having such mechanism requires no DLLRedirects and no symlinks. |
|
@siro20 : i like that idea. would make wine much easier to extend with different non standard modules. |
|
Closing this since the original issue - dxvk not being usable on wine-vulkan - has been resolved. |
Hi,
as wine-staging is becoming more and more outdated and for me it looks pretty dead atm (no changes since 3 month), i am wondering if dxvk is designed that it also will work with wine-vulkan ?
Many thanks !
Christian
The text was updated successfully, but these errors were encountered: