Mesa Git Should Now Work With Intel/RADV Vulkan For Doom Under Wine

[phoronix]

Phoronix: Mesa Git Should Now Work With Intel/RADV Vulkan For Doom Under Wine

Running the Doom (2016) game under Wine with Vulkan may now yield better success if using the Intel ANV or Radeon RADV Vulkan drivers due to a fix in Mesa's SPIR-V common code...

http://www.phoronix.com/scan.php?page=news_item&px=Doom-Fix-Mesa-Git

[andrei_me]

They should check this fix at each Mesa release, if they can remove it by then

[humbug]

Bad trend.

[Shevchen]

Hmm - this may be an uncommon suggestion, but why not have an optional package for "app-optimization"? Something like "mesa-gaming-lib"?

In the end - if this trend continues - we would have hundreds of game-specific optimizations in the driver, which isn't really the idea behind a driver. It could also be used as "wall of shame".

[microcode]

You know, one way to avoid putting crap like this in the driver, is to make a layer for it.

[Strunkenbold]

We need a public database listing all those game bugs and corresponding fixes in the driver, in the hope that game devs looking at this and fixing their bugs.
But I dont think its a good idea to let the users wait for months for fixes just because we expect that game devs fix their bugs right after we reported them. Dooms last update was in December since then we wait for something to happen.
Its sad not every company is like Feral...

[nanonyme]

I blame the proprietary drivers for this, not Doom developers. Not everyone reads the spec religiously and if the driver works with your code, how will you ever know your code had a bug? For that reason as well it might be better to hide this behind some whitelist so if someone actually tests their game on new Mesa, they won't create the same bug

[dungeon]

Bad trend.

Trends are always bad, as people are never perfect nor will ever be.

Expecting that any APIs are perfect is plain crazy, do anyone claim how all the way from initial API version up to the very recent one everything was correct and that drivers were correct all the time? Esspecially early adopters app devs who deal with unfinished API, unfinished alpha/beta drivers, sometimes they even want to do exactly what current API does not but is in current discussion and might be or not be allowed in future, etc...

If nVidia and AMD blobs alows that and don't complain, well who are you to claim that they are wrong... and that even by running app which is not even native

I don't blame anybody, people nor what people do is never perfect and if someone wanna claim the opposite he can find something interesting in his ass - there is some rigorous shit there isn't it

[VikingGe]

I blame the proprietary drivers for this, not Doom developers.

You shouldn't blame either, since this was apparently caused by the shader compiler that ships with the Vulkan SDK. Doom developers probably won't care about the generated SPIR-V, and the drivers aren't doing anything wrong if they magically make something work that isn't even specified. It might even be coincidence that it works on those drivers.

Not everyone reads the spec religiously and if the driver works with your code, how will you ever know your code had a bug?

a) If you are coding for Vulkan, you most certainly should read the spec. Vulkan spec is more like an API documentation and therefore very developer-friendly, you probably won't get very far without it in the first place.
b) Use validation layers, that's what they are for.
c) Test on as many implementations as possible.

But none of that would have prevented this particular problem from happening.

[Farmboy0]

This is a horrible idea, working around application bugs in the driver, no matter what or who caused it.