Announcement

Collapse
No announcement yet.

DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

    Phoronix: DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

    DXVK 0.54 is available today as the latest version of this Direct3D-11-over-Vulkan translation layer to benefit Wine gamers looking to enjoy faster D3D11 gaming performance on Linux...

    http://www.phoronix.com/scan.php?pag...-0.54-Released

  • oiaohm
    replied
    Originally posted by VikingGe View Post
    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.

    Leave a comment:


  • VikingGe
    replied
    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.

    Leave a comment:


  • the_scx
    replied
    Originally posted by boxie View Post
    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.

    Originally posted by boxie View Post
    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.

    Originally posted by boxie View Post
    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-1...070_Steam.html
    https://www.playonlinux.com/en/app-1774-FEZ_Steam.html
    https://www.playonlinux.com/en/app-1...set_Steam.html
    https://www.playonlinux.com/en/app-2...War_steam.html
    https://www.playonlinux.com/en/app-1...k_2_Steam.html
    https://www.playonlinux.com/en/app-1...t_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.

    Leave a comment:


  • sdack
    replied
    Originally posted by justmy2cents View Post
    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
    Last edited by sdack; 06-08-2018, 11:07 AM.

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by sdack View Post
    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

    Leave a comment:


  • sdack
    replied
    Originally posted by aksdb View Post
    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.
    Last edited by sdack; 06-08-2018, 05:16 AM.

    Leave a comment:


  • aksdb
    replied
    Originally posted by sdack View Post
    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.

    Leave a comment:


  • sdack
    replied
    Originally posted by smitty3268 View Post

    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?
    Last edited by sdack; 06-08-2018, 04:05 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by smitty3268 View Post
    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.

    Leave a comment:

Working...
X