Tweet
Originally posted by Ananace
View Post
-
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. -
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
-
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.
Comment
-
sounds like code that works by sheer luck to me, if random changes break it.Originally posted by Thaodan View Post
Comment
-
I don't think it breaks "generally". But fixing some glitch for game X will suddenly cause game Y to glitch.Originally posted by yoshi314 View Post
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
-
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
-
Wont be surprised if someone decides to port it to Rust
.
Comment
Comment