Announcement

Collapse
No announcement yet.

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

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

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

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      Bad trend.

      Comment


      • #4
        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".

        Comment


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

          Comment


          • #6
            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...

            Comment


            • #7
              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

              Comment


              • #8
                Originally posted by humbug View Post
                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
                Last edited by dungeon; 21 June 2017, 04:36 AM.

                Comment


                • #9
                  Originally posted by nanonyme View Post
                  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.

                  Originally posted by nanonyme View Post
                  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.
                  Last edited by VikingGe; 21 June 2017, 04:33 AM.

                  Comment


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

                    Comment

                    Working...
                    X