DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

[aksdb]

If only you did. You see, in the thread you've mentioned all context got lost from the start and it wasn't me who made it a trollfest. It's the same here again. You read what you want to read.

So if a whole bunch of people (apparently) misunderstand you, it's their fault?
You may want to evaluate your world view.

[sdack]

So if a whole bunch of people (apparently) misunderstand you, it's their fault?
You may want to evaluate your world view.

No, you need to evaluate your world view. You use the word "misunderstand", which literally means that you do not to understand. This is your fault.

[justmy2cents]

You see, in the thread you've mentioned all context got lost from the start and it wasn't me who made it a trollfest.

you certainly created it here with pointless raging

just because he is creating something that can be used with Wine doesn't necessarily means he has to work on Wine. especially since DX11 is pretty much completely standalone thing.

he might as well have tons of legitimate reasons why keeping it standalone like
- he doesn't want to be envolved in Wine politics and everything else
- he doesn't want to be restricted by Wine development restriction politics
- he wants to keep his own release schedule
- he only wants to deal with bugs that are connected to his project
- he has different testing environment as he is not interested in bugs that are in Wine due to not yet implemented features. doing that would require him working on multiple layers
... i could go on and on

it is simply his choice on how he wants to work.

one thing you should realize. when developer cannot go with his own choices and own belief just to serve entitled people who (DON'T) know better... it is not really FOSS anymore, it is slavery in its purest form (unless you forgot to tell us you are the one fully covering his development costs). because, being slave is on everyone's wishlist for being so fun.

for anyone who is not entitled like you seem to be his process is really simple. he wants to make something usable to gamers. not just linux, not just windows... everyone that needs it and he only concentrates focus into one single part. right now his work is pointless for windows users, but if windows somehow removes support for older DX situation might change. and since he is working on standalone part, he also wants to check it only against proper environment where guess what... if wine is missing something relevant underlying, it is up to Wine users and developers to make it happen if they want to use it with his work

[sdack]

you certainly created it here with pointless raging
...

I'll cut you off right there. There is no rage here. I'm happy to post here. Why you don't see this and end up seeing rage, anger, condescension and what not is beyond me. Maybe you just don't know what happiness looks like.

Nobody however is denying him anything. All I have been doing is to state facts, such as when people claim it was a contribution to WINE, to point out that it isn't and how it is different.

This somehow gets you ruffled up for reasons unknown to me. I'm merely happy to point out the difference. You don't seem to be happy at all, maybe you hardly ever are happy and so you don't know what it looks like, but this is no problem of mine!

Cheers, mate

[the_scx]

You are right though with the not releasing something that is not tested and is known working. The problem here is that many game devs won't do this

Valve won't want to be responsible for something that even the developers themselves do not care about.

so it would be up to the community to do it (hence why the winedb exists).

Look at how AppDB looks like now: outdated test results, contradictory information, etc. Few people carry out reliable tests of games, going through the entire campaign or even playing a few hours. It often happens that a game gets "Platinium" status after a few minutes of testing, and in practice it turns out that it works very unstably under WINE.

Does PlayOnLinux support looking at your existing steam library and determining if it is a Linux or Windows install that is required?

Of course not and will never happen. To do this, you actually would need a new Steam client developed by the community. It is possible to do, you can even use the existing SteamCMD (Steam Console Client) as a base. In my opinion, however, it would be overkill.

https://developer.valvesoftware.com/wiki/SteamCMD

However, PlayOnLinux already provides tools for easy installation of Steam games designed for Windows. Everyone can create simple recipes, publish them, and the community can provide feedback on them. Here are some examples:

https://www.playonlinux.com/en/app-1623-Anno_2070_Steam.html

https://www.playonlinux.com/en/app-1774-FEZ_Steam.html

https://www.playonlinux.com/en/app-1874-Hard_Reset_Steam.html

https://www.playonlinux.com/en/app-2698-Napoleon_Total_War_steam.html

https://www.playonlinux.com/en/app-1882-System_Shock_2_Steam.html

https://www.playonlinux.com/en/app-1624-Torchlight_2_Steam.html

As you can see, it does not work as you would like to. Where are the masses of users ready to test games and create recipes? Where is the mystical community always ready to give feedback? Do you really think that the new Steam client would change anything here? I don't think so. And if you publish thousands of untested recipes that only a small percentage works correctly, even fewer users will be interested in using it.

[VikingGe]

Oh, the good old "why is this not part of wine" discussion.

To be honest, I don't really see what's wrong with this being an independent project and why that would be "driving over a cliff". It's easy to set up in a standard wine environment, Lutris supports it, and apparently there seems to be some effort going on in adding it to winetricks. Which is more than adequate for a piece of software that works with some games but breaks some other applications as oiaohm mentioned above.

This whole thing started out as a fun little project that just turned out to work better than expected, but at no point did I intend it to replace (parts of) wined3d. There are multiple reasons why I went downt this route, one of them being that there was simply no real Vulkan ecosystem in wine at the time aside from the rather basic Vulkan implementation in wine-staging. winevulkan just didn't exist and vkd3d hadn't even been publicly announced yet. Another reason is that I had more than enough to learn in the D3D11 and Vulkan department and wanted to get actual work done instead of learning yet another massive thing which is the Wine code base.

And meson and C++ are just my personal tools of choice to get things done quickly. Neither is exotic in any way.

[oiaohm]

To be honest, I don't really see what's wrong with this being an independent project and why that would be "driving over a cliff". It's easy to set up in a standard wine environment, Lutris supports it, and apparently there seems to be some effort going on in adding it to winetricks. Which is more than adequate for a piece of software that works with some games but breaks some other applications as oiaohm mentioned above.

Wine quality control kicks adding something that is known to break some applications equal patch not being accepted until those problems can be addressed or at least a plan to address those problems exist. Maybe one day dxvk as a independent project grows to a point where it can deal with those problems of mixed direct x applications and then maybe it could come a winehq hosted project.

Gallium nine project runs into the same problem with wine project quality requirements.

Of course how vkd3d develops and expands over time is also still up in the air if it will remain dx12 only but there are reason to suspect it will expand. As well as how much performance can be pulled out of newer opengl. We still don't have opengl 4.6 GL_ARB_spirv_extensions provided by many drivers. So direct x shaders to spirv for vulkan could possibly be used with opengl when spirv for opengl lands.

With apple looking to end opengl support and say metal only. This bring hell to wine and possible some hell to dxvk as well. dx 7-12 application back end may be transformable to vulkan and use MoltenVK this could see vkd3d dx version converge expanded. This still leaves opengl applications that still leave a problem and a half. Current MoltenVK and MoltenGL are not great if you don't know shaders ahead of time. You need to covert shaders in MSL. Nothing like apple ruining everyone day. This will effectively mean 1 system for apple products and 1 system for Linux/BSD.... Maybe apple might see the light and support vulkan.