Announcement

Collapse
No announcement yet.

DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

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

  • the_scx
    replied
    Originally posted by boxie View Post
    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.
    Phoronix: Feral's Former Linux Team Lead Is Now Working For Unity Earlier this month Feral's Linux team lead left the company after a triumphant five years at


    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).
    Version 5.4 has been in beta for almost one week, and is now moving to the main branch. There are some additional fixes and updates in the latest version. Please see the patch notes below for more information. This major and long-delayed update includes full German localisation for the final two episodes, along with Unity engine upgrades and support for DirectX 11. Please note that this is not The Final Cut patch, which we plan to release alongside the PlayStation and Xbox versions this spring.

    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.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by shmerl View Post
    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.
    Last edited by smitty3268; 07 June 2018, 08:12 PM.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by oiaohm View Post

    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.

    Leave a comment:


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

    Leave a comment:


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


    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++.

    Leave a comment:


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

    Leave a comment:


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

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

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

    Leave a comment:


  • sdack
    replied
    Originally posted by shmerl View Post
    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'm not being condescending. You should lighten up, or don't.

    Originally posted by AsusMagick
    DXVK has null interest for Windows gamers
    Nonsense. Of course it has. It isn't not by accident that it is full of issues of Windows games and tries to fix them. You should be more honest with yourself if you think DXVK isn't meant to make Windows games run on Linux.

    A contribution to WINE happens in form of patches to the code base of WINE, such as is the case for wine-vulkan. DXVK is a stand-alone project. The author even says DXVK can run under Windows. You'll have to talk to him why this is a feature.

    This is nothing more than an attempt of getting Windows game onto Linux. Nvidia and Valve are helping out, because they have their own agenda. You forget that we aren't talking about games on Linux written for Linux, but that this is all about getting Windows games onto Linux.

    You love your Windows games too much is what I'm thinking and now you fail to see what's really in front of you.

    Leave a comment:


  • sdack
    replied
    Originally posted by shmerl View Post
    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'm not being condescending. You should lighten up, or don't.

    Originally posted by AsusMagic
    DXVK has null interest for Windows gamers
    Sure, and the issues just happen to be all game related by mere accident. First it's a "contribution to WINE". Now it's only a "contribution to WINE gaming". Come on, be honest. You don't see yourself making excuses?

    It is what it is. It is not a contribution to the WINE project. Contributions to the WINE project happen in form of patches to the code base of WINE, such as wine-vulkan for example. DXVK is a stand-alone project and entirely targeted at Windows games.

    And yes, Nvidia and Valve help out with DXVK, but they do it for their own agenda. Nvidia does it to make their drivers look good and Valve wants to get more Windows game running under Linux.

    You haven't even noticed that we aren't talking about game makers writing games native to Linux. This is simply an attempt to get Windows games onto Linux. It is not the other way around and that's what you need to see.

    I'm thinking you love your Windows games too much.
    Last edited by sdack; 07 June 2018, 12:38 PM.

    Leave a comment:


  • shmerl
    replied
    Originally posted by sdack View Post
    DXVK is free to accept Rust and Fortran code
    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.
    Last edited by shmerl; 07 June 2018, 11:26 AM.

    Leave a comment:

Working...
X