Announcement

Collapse
No announcement yet.

Mesa 19.1 Adds Workaround For Epic Games Launcher With OpenGL

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

  • #21
    There's a known reason nVidia/AMD ship a driver update with every AAA release.

    They all ship broken or highlight bugs in drivers. Which is why it sucks that Ubuntu ships 6 month old drivers making it the worst gaming distro.

    Comment


    • #22
      Originally posted by JPFSanders View Post
      While Valve has a nice contingency plan to avoid the PC turning into a closed platform that benefits the entire industry (including us Linux peasants), Epic is sabotaging steam while leaving itself and the industry vulnerable to Microsoft.
      *When* Steam's DRM servers get decommissioned and go down, the PC won't just be a closed platform, it will be entombed

      Comment


      • #23
        Originally posted by kpedersen View Post

        *When* Steam's DRM servers get decommissioned and go down, the PC won't just be a closed platform, it will be entombed
        It will be a sad day, however I would console myself with the fact that thanks to Steam we have a healthy software graphics stack that rivals the closed source ones, and lots of games that have no DRM at all, not to mention that we could still play cracked games on a very advanced version of Wine for years and years to come.

        For example I love NMS, bought a copy on Steam and another in GOG.

        Not to mention how nice it is to run emulators like Dolphin and run WII games at 1080 with anti-aliasing.

        I do not care per se about Steam's library, I care about our platform benefiting from all this development.

        If Epic or Microsoft get rich they just get rich and our platform of choice languishes in a corner, If Steam gets rich our platform gets better software and more users, and on top of that Valve is not being hypocritical with bullshit about consumer choice, guess which one I would back.

        And the funniest part is that Valve has already proven all of this with more goodies on the pipeline like the Index VR stuff with 0 Day Linux support, for fcuk sake, they even paid Keith Packard to add VR support to X.org.

        I'm not being naive, I know Valve is a corporation and they're doing all this Linux support because they plan on making profit on it (They have a long term plan with all of this I'm sure)

        But which corporation would I back? The one that has given me tons of support and tangible results, it is a no brainer.

        If Tim Sweeney's Epic store starts supporting Linux, and contributing/investing towards the platform in a serious way my stance about them might change, but I doubt they are serious or sincere when they didn't even bother supporting Fortnite on Linux.

        Comment


        • #24
          Normally I would be happy that the launcher is working, but I don't like how Epic run their business and they will never see a penny from me. So i don't really care that you can install the launcher. Also not sure if the spyware is effective on Linux, but it's another reason not to install it.

          Comment


          • #25
            So as default the Epic Launcher is using DX, someone is overriding that to use OpenGL, where a 4.4 core context is requested by the app but compatibility features are used

            I very much doubt Epic will fix this, they're more likely to remove OpenGL support

            This work around is relatively simple and I'm not sure it really warrants this level of discussion - out of the people using the Epic Launcher, how many are using or even knew about the OpenGL backend?

            Comment


            • #26
              This seems to be the status quo on the proprietary gpu driver side, since game developers became coddled man children. I could only imagine the response if Torvalds ran Mesa instead of the Kernel. This issue is going to fade into memory once Stadia drops. They aren't going to be able to side-step standards once the largest monopoly in the World grabs them by the balls and twists.

              Comment


              • #27
                Here's what I don't get: to me, it doesn't seem like there's anything that should prevent the user from applying this change themselves, manually. Although it's not exactly user-friendly to do this, I (as well as seemingly everyone else here) don't like the idea of application-specific patches put into Mesa.
                However, I don't think it'd be such a bad idea to have a separate package from Mesa, largely community driven, that does apply these application-specific fixes or other improvements.

                Originally posted by nanonyme View Post
                While I agree in general this kind of workarounding in drivers should be avoided, this specific thing seems more or less harmless to me
                It's no more harmless than seeing a single ant scout in your house. But the moment that ant finds food and brings it to the colony, you've now got a problem. The point is: making these application-specific patches in and of themselves are relatively insignificant, but this sets a precedent where we're going to see this more and more often, to a point where it'll become a major focus of the drivers (much like how the closed-source drivers are).

                Comment


                • #28
                  I wouldn't use it even if it worked properly. One game launcher is more than enough. Fuck you, Ubisoft, EA, Epic and Microsoft.

                  Comment


                  • #29
                    Seems like the reading of peoples' local Steam files without permission (which AFAIK they admitted to and promised to fix, but haven't done so yet) and the overall haphazard implementation of social features aren't the only places where Epic is showing fairly total technical incompetence. Either they don't know the difference between core and compatibility contexts or then they've got people implementing things using both.

                    I get the feeling that it's most probably some old beard/beards using compatibility contexts, the younger devs using core contexts and management either doesn't care or doesn't want to go in and tell one of the groups to use one or the other. If they're using core contexts then that's very obviously what they're supposed to be using, but due to the old beard/beards being more senior nobody's got the guts or the authority to tell them to throw out their legacy code and start over.
                    "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

                    Comment


                    • #30
                      It has to be technically possible to separate all the hard coded special behaviours into a separate library that can be used at runtime if it's present (package is installed). Right? We have advanced tech like kernel hot swapping, hardware acceleration in VM, etc. etc., this sounds like a no brainer.
                      Last edited by geamandura; 04-23-2019, 09:54 AM.

                      Comment

                      Working...
                      X