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

  • #41
    Originally posted by Ananace View Post
    What would probably have to happen to solve that is for DXVK to adopt a similar CI design to what some emulators use, where they have a renderdoc-or-alike (of Direct3D) dump that's run with each commit, and that logs any pixels that differ.
    The Dolphin emulator is one of the projects that does this in order to make sure code changes don't affect rendering.

    Running actual games is just going to be far too chaotic to be able to use as test cases, far too many places where parallelism or randomness - particles etc - could introduce noise in the resulting images.
    That's a good point - I was mostly envisioning a Dolphin-like setup, where functions are tested and actual games are used as performance benchmarks. It's a shame that more games don't have a benchmark mode that forces the RNG to use a particular seed, as that would cut out a lot of the uncertainty.

    Comment


    • #42
      But to be honest. This Project ist so well known by a lot of skilled people and still there are almost no commits and pullrequests by others. This makes me wonder If his documentation is lacking and therefore it does not attract a lot of people which could do some maintance Work.

      Comment


      • #43
        Michael have you read the complete topic?
        He said his code structure is not the issue:
        > If you had all the time in the world, and didn't have to worry about risk, is there a way you would restructure DXVK to be easier to maintain?

        My main issue is that I simply don't understand most of the issues that are popping up everywhere, not that the code base itself is poorly structured. There are some things that could use some cleanups, but the last attempts at doing that have caused exactly the kind of regressions I was complaining about, and it really seems like touching *anything* causes some arbitrary breakage for no particular reason.
        https://github.com/doitsujin/dxvk/pu...ment-564630674

        Comment


        • #44
          Originally posted by Thaodan View Post
          Michael have you read the complete topic?
          He said his code structure is not the issue:

          (...)

          "and it really seems like touching *anything* causes some arbitrary breakage for no particular reason"
          sounds like code that works by sheer luck to me, if random changes break it.

          Comment


          • #45
            Originally posted by yoshi314 View Post
            sounds like code that works by sheer luck to me, if random changes break it.
            I don't think it breaks "generally". But fixing some glitch for game X will suddenly cause game Y to glitch.
            In the end this most likely boils down to all the voodoo done by graphics drivers on Windows. It's totally insane that they bring out a new driver version when a game is released with specific "optimizations" (aka "workarounds") for that game. But then again, this is DX11 and 10 we are talking about. DX12 (and Vulkan) were specifically created to give more low level access to engine developers so THEY can ship their "workarounds" instead of drivers having to circumvent inner workings when a specific game is running. Though I fear that even then there is black magic in shaders and their execution.

            Comment


            • #46
              I think some of the commenters here aren't differentiating enough between "Driver X is released on the same day as Game Y to improve *performance* in Y" and "... to fix a major problem with Y on Card Z".

              MOST of the same-day releases are of the first type, where a specific handful of shaders/etc will be replaced with equivalent-enough versions that are (sometimes much) more performant on that vendor's hardware. A good (real-world) example would be Vendor N's hardware having terrible compute performance but really good texture caches, so that the game's shaders actually used texture lookups for certain math ops rather than calculating the results. Vendor A, OTOH, with good compute but much worse texture management, might suffer a 30% performance deficit thanks to that code, on hardware that is otherwise roughly-equivalent. A can "legitimately" rewrite just a couple of those shaders to use Actual Math instead, and suddenly get the same framerates as N.

              In that example, neither vendor is "cheating", and neither one is really at fault. But that "stupid hack", stupid and hackish though it is, is REALLY important for that vendor to deal with. When you've got a AAA game that's going to sell in the tens of millions, your performance in that game is going to show up in comparison benchmarks for YEARS, and you only get that one shot to turn in a good result. Websites are NEVER going to revisit that game's launch article, so those numbers are going to be not only what people see on release day but also what they see 3 months later when they'll looking at benchmarks for their next upgrade. It doesn't matter that you can release another version of the driver 2 months later saying "x% faster in Game Y" - that ship's already sailed.

              Anyway, that's the sort of thing that has become commonplace in drivers now, and those profiles are a big part of why Windows drivers have gotten literally 100s of MB larger over the years. As skeevy says, profiles are evil - but, while the example I gave was definitely one of the worst cases that actually happened, even "just" 4% or so in performance difference is easily important enough to be worth hacking up a fix for.

              AFTER that, you get into the scenarios where you have to hack the driver to work around cases where games flat out fail to work properly, through either crashes or broken output etc. The classic scenario for that is wglGetExtensionsString, which when the return from that exploded from a couple of hundred bytes to dozens of K over the years, most games exploded along with it. :P
              But those cases are very rare in comparison to the performance ones, and are generally retroactive rather than Day One patches, for obvious reasons.

              Comment


              • #47
                Wont be surprised if someone decides to port it to Rust .

                Comment

                Working...
                X