Announcement

Collapse
No announcement yet.

DXVK Reportedly Going Into "Maintenance Mode" Due To State Of Code-Base

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

  • schmidtbag
    replied
    Well, this has kept my sanity in check. Not long ago, I was questioning some of DXVK's priorities, not because they were bad (any improvement is welcome) but rather there were more important things that needed more attention. People got angry at me, assuming I didn't like bug fixes or that there weren't more significant bugs to be fixed. Well, turns out, the lead developer of DXVK seems to agree with my sense of priority.


    Anyway, I actually have had very smooth experience with DXVK and am grateful for its existence. The only recurring issue I encounter is an occasional shadow glitch, but it's nothing game-breaking.
    Last edited by schmidtbag; 11 December 2019, 10:02 AM.

    Leave a comment:


  • jrch2k8
    replied
    First of all, Thanks a million times to DXVK dev since this is by far hands down the best DX layer for wine(and Windows) and has made basically most games playable on Linux(note D9vk is a beast as well).

    Basically i think Codeweavers and Valve should hire this guy full time, maybe he can fix the horrible mess wineD3D is, i don't means this as a disrespect to codeweavers developers but current wineD3D for any generation is a CPU hog barely using the GPU behemoth stacked on layers of bugs that on the best possible conditions qualifies as barely usable.

    Now about DXVK regression i think his problem comes from try to support BLOB drivers with workarounds from AMD and nVidia, because both are randomly and heavily broken(depending the release) whereas RADV very rarely breaks and if it does it usually fixed in a blink of an eye.

    If i was him i would probably clean of the codebase removing all workarounds for BLOB and only accept reports from RADV and ANV and use to Valve to put pressure on nVidia to fix their POS implementation and honestly simply give up support on AMDVLK(which i think he did) because honestly is a broken mess(not talking shit here, tested last week or something release and is broken on POLARIS again(put big freaking bold letters dripping blood AGAIN), Skyrim ENB simply destroy the driver to the point it hard reset my PC while RADV work through like a 60+ FPS boss while doing CAS with vkBasalt(<--- love this btw) )

    Leave a comment:


  • otikscypi
    replied
    The fact that he intend to spend some serious amount of time on refactoring is actually making me feel optimistic for the future of DXVK. Project was growing very fast, adding features in leaps, so eventual code-spaghetti was unavoidable. It's good that dev sees that and is ready to spend some time working on it.

    Originally posted by Mystro256 View Post

    What he needs is a nice CI to run a bunch of game tests automatically. One person testing all those games is not really sustainable.
    I do not think that it would be a wise idea. Maintaining such CI suite would be extremely time consuming. Most games does not have API that let you automate movement or hooks to test if something happens. Otherwise we would have much more game benchmarks in PTS. I recall Michael complaining about this in at least one post.

    Leave a comment:


  • R41N3R
    replied
    DXVK is working extremely well, it is something that has not been achieved before and this in a short time frame. What is exhausting are probably the many different driver and linux versions, new introduced bugs with every new release, binary blobs, game workarounds and wine specifics. As a software developer you want to develop some stable code that is reliable in the long term, but this is quite impossible with the current platform, not sure if a CI system could be designed to test with every commit a broad game base. Development without the fear of break something fundamental is essential! I still wish wine would jump in to support D*VK as a stable foundation. WineD3D seems quite obsolete except for some corner cases.

    Anyway, DXVK is a master piece and I'm very thankful for it!

    Leave a comment:


  • polarathene
    replied
    Originally posted by xxmitsu View Post
    perhaps Nvidia will have a reason to fix their driver. Even more specific, if the bug is only present on specific generation of nvidia cards, then it is more obvious where the problem is.
    Does nvidia care that much for Linux gaming support? I thought their driver support was mostly intended for professional usage, where gaming was just a bonus?

    Leave a comment:


  • mphuZ
    replied
    Lol. That was the end of the tale.

    Originally posted by mlau View Post
    So, Valve needs to hire him full-time so he can refactor it, and assign a sidekick to him he can delegate grunt-work to
    No. This means that Valve made a mistake. It was necessary to conclude an agreement / truce on time with the developers of Wine, who assembled a whole team. And who just wouldn’t leave DXtoVK because of the routine work.

    Leave a comment:


  • polarathene
    replied
    Originally posted by aufkrawall View Post
    gaming in Wine + DXVK often works more reliably for me than native Windows gaming.
    I've found it better than "native" Linux ports at times. Dying Light for example was running at 1FPS or something on my i5-6500 + GTX1070, switch to Proton and it runs waaaay better. The menu is possible to navigate and I could actually play the game.

    Leave a comment:


  • TehCorwiz
    replied
    Originally posted by Mystro256 View Post

    What he needs is a nice CI to run a bunch of game tests automatically. One person testing all those games is not really sustainable.

    I wonder if there's a gaming company that has a huge library of games, has the resources to put this together, and a vested investment in dxvk... *cough*value*cough*
    He should without a doubt get in touch with the Dolphin Emulator about that. They have FIFOCI https://dolphin-emu.org/blog/2015/01...ucture/#fifoci, which allows them to automate testing against the enormous Gamecube + Wii games library. While they're enabled in this regard by being the arbiter of both CPU and GPU (ah the luxuries of a pure emulator) I think it's worth exploring a similar approach here as well.

    Leave a comment:


  • xxmitsu
    replied
    Why is he bothering so much with nvidia ? I mean, I know that is important because of the market share for that vendor, but if you continue making workarounds in your code because that vendor hasn't followed the specs exactly, then you'll end up like this. An hard to maintain code base with a lot of particular cases. If it doesn't work on nvidia and it works on everyone else, perhaps Nvidia will have a reason to fix their driver. Even more specific, if the bug is only present on specific generation of nvidia cards, then it is more obvious where the problem is.

    We already had this bad situation with GL where nvidia has dictated the specifications because the apps were designed to work with 'nvidia bugs in mind'. Better not follow the same approach.

    Just respect the Vulkan and DX specifications.

    If it works on one vendor driver, it means the game is ok and the specifications are ok.

    If it doesn't work on the other driver, it means it needs to be fixed on that driver side.

    Leave a comment:


  • ThoreauHD
    replied
    Having all the debugging for every game on one guys shoulders doesn't scale. I'd freeze it too.

    Leave a comment:

Working...
X