DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

[ElectricPrism]

DXVK is free to accept Rust and Fortran code, or to use C for that matter. Only such ignorance doesn't get you very far.

I wouldn't mind Rust code. Fortran - not really. You should stop this condescending tone anyway. Make something better than dxvk to help Linux gaming if you think you can.

I didn't get that from him at all. Plus it's difficult to interpret tone correctly in a multi-cultural, multi-lingual international community. What I picked up was caring enough to jump in someone elses shoes and set someone straight as nicely as possible so they don't keep driving foreward over the cliff.

Commendible.

you'll learn that there are others like you who have the same problem but with your project, and it will be you who doesn't accept their contribution. It's a story as old as the bible, mate.

He even used "mate" to indicate the light hearted tone after sharing his industry insights and experience that programmers generally don't like to accept code in languages different from the base project. As behavioural math, it's as fucking simple as it gets.

If he wanted to condescend I'm sure as a programmer it would be easy to invent many intellectual quips to beat you down with, even in ways you might not be able to pick up on suchas "That's a unique point of view".

Try not to be a victim, this up coming generation has too much of a problem playing the victim, being sensitive and looking for hidden meaning where there is none. It's a very kind thing when someone takes the time to try to communicate something of value to help you succeed in the same industry.

But if you've been following the development then you also know that wine-vulkan couldn't move on, because Vulkan had changed it's license with 1.1. It's lucky that the lawyers removed the problem as quickly as they did, because if not then wine-vulkan and DXVK would have remained at Vulkan 1.0 forever. If DXVK hadn't been built on top of wine-vulkan, then it could already have used features of Vulkan 1.1. So it's not simply an advantage, but an additional layer can be a blessing as well as an impossible hurdle.

I don't believe it needs much of a discussion, because it should be common knowledge that the closer one can build to the bare metal, the better the results will be. It's the story of Linux after all and also the reason for Vulkan's performance. DXVK is really just a cheap glue, but an effective one and it would have been better if it had been built right into WINE from the start.

The moment WINE has caught up with its efforts will DXVK disappear. And there is no guarantee for any of the DXVK code to finds its way into WINE. Probably none of it will.

Maybe when you have seen too many days of bullshit on this earth you'll suddenly understand.

[shmerl]

What I picked up was caring enough to jump in someone elses shoes and set someone straight as nicely as possible so they don't keep driving foreward over the cliff.

I don't see anything "dirving off the cliff" in dxvk effort. It has practical impact on Wine gaming. I.e. improving performance. Bashing it based on the basis that it's using C++ instead of C is inappropriate. The tone above (with Fortran and etc.) didn't sound friendly to me, but may be you see it as joking.

[oiaohm]

Not to mention, Wine still depends on C89 maximum, right? That's even less of a solid and reasonable technical choice as much more sane C standards exist and are basically supported on every platform Wine would ever wish to be usable on.

https://bugs.winehq.org/show_bug.cgi?id=20474

Wine is not C89. It is at least gnuC89. What is C89 with gnu extensions. Gnu extensions are required to allow matching up to some of the MSVC compiler made file behaviours. Its not like items built by MSVC restrict it self to only iSO stuff.

Winegecko is also C++.

[oiaohm]

We can argue whether DXVK would have iterated as fast and been as successful, as it has been... If say DXVK had to be subject to Wine's code restrictions (old C standard, etc.) and slow-review process.

Wine review process is not slow. Wine review process is very thoroughly done even that it down really fast. This means patches will be rejected due to not having test cases or legal issues or technical issues.. Every patch that is put on wine-devel for review is cleared in under 1 week with a yes or no answer and feedback.

Also C standard bit forgets winegecko have C++. So it is possible to have a wine part that is C++. There are reason the core avoid it. Core has to be gnuc89 or better. Please note the gnu its that the core c89+gnu extensions and this is required so libraries built by wine can replicate the behaviour of different versions of MSVC C and C++. C++ forbidden names gets in way with some of the oddities as well. C function names are not restricted. Basically C++ is not suitable for the core of wine. C++ in extension like wine-gecko that builds as a windows dll has been accepted with auto install in past.

DXVK being just DX11 at this stage is going to have a hard time when thoroughly reviewed you have to remember you are dealing with MS office + addons and the like that are worse than games. MS Office with addons can end up with dx9 dx10 dx11 parts at this stage all working with each other and sharing stuff. So you have the horrible question will this DX11 work with programs using DX10/9 as well and in future you can expect to see Dx12 added to that.

[smitty3268]

Wine review process is not slow.

Oh come on, you know what he meant. DXVK could not have gone through the rapid iterations that it has by sending everything through that process.

[smitty3268]

The tone above (with Fortran and etc.) didn't sound friendly to me, but may be you see it as joking.

Plus there's the fact that he got into a trollfest against the DXVK developer in another message thread, with like 30 messages of them sniping back and forth about how much DXVK sucked and how it should change and the DXVK dev telling him he had no clue what he was talking about.

Context matters.

[the_scx]

I think the next steps would be:

• Valve to auto package the games with a wine runtime with flatpak (or snap et al) so the windows games "just run". I am sure there would need to be a feedback thing where Linux users could say "Yes, this worked", "No it didn't"

That will never happen. I've already explained why Steam games can not be flatpaked.

https://www.phoronix.com/forums/forum/software/linux-gaming/1027380-feral-s-former-linux-team-lead-is-now-working-for-unity?p=1027838#post1027838

Anyway, selling games that were not tested at all is simply wrong. Don't remember what was outrage over the titles that used eON? Here it would be even worse. And if someone really wants to run a game designed for Windows, PlayOnLinux can do it. POL allows you to choose the WINE version, install additional components, change the configuration, etc. As for feedback, you can use Wine Application Database (AppDB). And remember, there are no simple answers like "works" or "does not work". This is not binary. It is often "almost works", "works, but with issues", etc.
Please keep in mind, that each game may behave differently on various hardware. Moreover, many titles are regularly updated. The game can start as DX9-based and end up as DX11-based title. This applies not only to early access productions, but also to the episodic ones (e.g. Dreamfall Chapters).

https://steamcommunity.com/games/237850/announcements/detail/508180724923248946

Of course, some developers may decide to release their game as a WINE (or CrossOver) bottle. There have been cases like this. However, each such game was thoroughly tested before its release.

[boxie]

That will never happen. I've already explained why Steam games can not be flatpaked.

https://www.phoronix.com/forums/forum/software/linux-gaming/1027380-feral-s-former-linux-team-lead-is-now-working-for-unity?p=1027838#post1027838

Anyway, selling games that were not tested at all is simply wrong. Don't remember what was outrage over the titles that used eON? Here it would be even worse. And if someone really wants to run a game designed for Windows, PlayOnLinux can do it. POL allows you to choose the WINE version, install additional components, change the configuration, etc. As for feedback, you can use Wine Application Database (AppDB). And remember, there are no simple answers like "works" or "does not work". This is not binary. It is often "almost works", "works, but with issues", etc.
Please keep in mind, that each game may behave differently on various hardware. Moreover, many titles are regularly updated. The game can start as DX9-based and end up as DX11-based title. This applies not only to early access productions, but also to the episodic ones (e.g. Dreamfall Chapters).

https://steamcommunity.com/games/237850/announcements/detail/508180724923248946

Of course, some developers may decide to release their game as a WINE (or CrossOver) bottle. There have been cases like this. However, each such game was thoroughly tested before its release.

The essence of what I want is to not jump through too many hoops.

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 - so it would be up to the community to do it (hence why the winedb exists).

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

[oiaohm]

Oh come on, you know what he meant. DXVK could not have gone through the rapid iterations that it has by sending everything through that process.

The reality is wine project iteration rate is higher than DXVK in different sections at different times. Wine processes include subsystem Reviewers who are assigned to areas going though rapid iterations. So speed of development is not the problem. Wine project due to doing 200+ patches every 2 weeks without fail and to control regressions this has cause has a high Quality Control requirement. Now when you are not sure how stuff need to be implemented high quality control requirement can be really painful. So its not that the wine project processes are slow or unable to do the rate of iterations. When you don't know how stuff exactly will end up and having to do high quality control turns really painful. Doing high quality control on parts you are throwing away is very time costly.

This is why like with winevulkan you saw developer make branch for a while. To work out exactly where the path was before having to do the wine project level quality control. Of course is not that the wine level quality control is bad long term but short term its painful.

[sdack]

Plus there's the fact that he got into a trollfest against the DXVK developer in another message thread, with like 30 messages of them sniping back and forth about how much DXVK sucked and how it should change and the DXVK dev telling him he had no clue what he was talking about.

Context matters.

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. You haven't learned to appreciate criticism. Instead all you've learned is to click the dislike button. It's symptomatic for an entire generation. Or say, how can one help people whose idea it is to deal with criticism, confrontation or a problem by disliking it?

An entire generation has allowed itself to be trapped by Facebook, Twitter and other sites to become ignorant, arrogant and self-entitled. These are however corporations whose goal it is to use all your aversions, to create profiles on you and to find out who you are connected with. They are not helping you to overcome your aversions. They are feeding into them and you get to suffer for this in the end.

Sorry if what I say hurts your feelings, but fact is many young people literally cried tears after the election of Donald Trump, something which I've not seen before. They couldn't understand how this was possible or how democracy is fair, because they now believe that dislike is a solution to everything.

So here you are and you complain once more and you want to tell others how context matters. Please, do start and allow for context to matter. I'd very much like to see you do that. I'm guessing you're just going to press the "mental dislike button" for not wanting to deal with it as you've been trained to do.

I like people, I don't dislike you, but I dislike what you're putting yourself through, and yet I accept it as being your decision. So where do we go from here?