Announcement

Collapse
No announcement yet.

Valve-Sponsored Mesa Work Makes Games Load A Lot Faster

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

  • Valve-Sponsored Mesa Work Makes Games Load A Lot Faster

    Phoronix: Valve-Sponsored Mesa Work Makes Games Load A Lot Faster

    Improvements to Mesa done by LunarG and sponsored by Valve in a new open-source patch-set means that popular Linux games should take significantly less time to load -- including titles like Dota 2 and Counter-Strike: Global Offensive -- by speeding up the shader compilation process...

    http://www.phoronix.com/vr.php?view=MTY4MjA

  • #2
    And this right here is why open source wins in the long run over proprietary software. Instead of having to live with bugs, slow performance and other issues, developers using the related stacks can fix the system and push changes upstream helping everyone.

    Comment


    • #3
      Did anyone else not get a warm fuzzy from reading this article? I know when I play a game I usually have to suffer through a lot of stuttering until the GL cache is built.

      Another +1 for D3D.

      Comment


      • #4
        updated builds of CS:GO and DOTA2 for Linux
        Did I miss when they released CS:GO for Linux? Or is this just referring to internal betas?

        Comment


        • #5
          we encourage developers shipping on Linux to use that same pattern when compiling their shaders as well as enabling this new feature in their environment, as it's too good to pass on.
          He is talking about lazy shader reflection, right? I'm confused, what should be done different on graphics/game engine side to take advantage of parallel shader compilation on driver side? We usually load vertex/geometry/fragment GLSL shaders required for every material one by one from disk, compile and finally link them

          Comment


          • #6
            This is very nice work, but it fixes the symptoms, not the cause of problems. Dota 2 for Linux, probably because of how ToGL implements shader translation uses 2x more memory than the Windows counterpart.

            I did some testing here, and the situation is still same as it was back in august of last year. http://vrodic.blogspot.com/2013/08/d...native-vs.html

            Comment


            • #7
              siavashserver: You just need to do some other work between glCompileShader and trying to fetch the compile status / info log, or link. If you're already doing that, then great

              Comment


              • #8
                Originally posted by johnc View Post
                Did anyone else not get a warm fuzzy from reading this article? I know when I play a game I usually have to suffer through a lot of stuttering until the GL cache is built.

                Another +1 for D3D.
                No, it doesn't! The single part it does, it lets max out all cores as it compile the shaders. In fact it needs less shuttering as it loads, as it can in fact animate (it can spin a wheel) on the main UI thread in the time the other threads do compile shaders.

                Yes, D3D is better (as most commercial software) but the gap is getting narrower with every improvement like this.

                You could write: +0.2 for D3D instead of +0.4 because of D3D (without this fix)

                Comment


                • #9
                  For those that were afraid (or hysteric) about the proprietary "invasion" into Linux....

                  Comment


                  • #10
                    Originally posted by ciplogic View Post
                    No, it doesn't! The single part it does, it lets max out all cores as it compile the shaders. In fact it needs less shuttering as it loads, as it can in fact animate (it can spin a wheel) on the main UI thread in the time the other threads do compile shaders.

                    Yes, D3D is better (as most commercial software) but the gap is getting narrower with every improvement like this.

                    You could write: +0.2 for D3D instead of +0.4 because of D3D (without this fix)
                    When did You heard that Mesa is NOT commercial?

                    AMD use it for commercial activities (in embeded world), Intel use it for commercial activities (desktop & mobile Linux including Android), RH use it for commercial activities (RHEL)....

                    Valve use it for commercial activities (cause Intel allow everybody to help them)....

                    Comment


                    • #11
                      Originally posted by verde View Post
                      For those that were afraid (or hysteric) about the proprietary "invasion" into Linux....
                      To be fair.

                      Valve help AMD and Nvidia both ... with their proprietary drivers.

                      r600g, radeonSI take advantage by nature of Intel driver.

                      Comment


                      • #12
                        Originally posted by chrisf View Post
                        siavashserver: You just need to do some other work between glCompileShader and trying to fetch the compile status / info log, or link. If you're already doing that, then great
                        Actually I wait for compile status like most tutorials out there do, pretty serial What about loading all shaders from disk at once, then rapidly issuing glCompileShader and waiting for their compile status? Ofcourse this can be further improved by having two feeder/consumer threads to minimize disk IO wait and/or let it do its business in a separate OGL context.

                        Thanks for hint!

                        Comment


                        • #13
                          Originally posted by przemoli View Post
                          Valve help AMD and Nvidia both ... with their proprietary drivers.
                          I don't really see what do you mean as "help" there. I doubt Valve have access to their drivers source code or can pay to 3rd party company to drivers optimization.

                          Also if AMD actually execute their plan about moving proprietary part to user space, then their proprietary drivers will benefit open source drivers too because both will use same kernel module which mean improvements for power and memory management.

                          Even Nvidia start to push some code and docs for Nouveau and this clearly related to what's Valve doing.
                          Last edited by _SXX_; 05-05-2014, 03:57 AM.

                          Comment


                          • #14
                            Originally posted by _SXX_ View Post
                            I don't really see what do you mean as "help" there. I doubt Valve have access to their drivers source code or can pay to 3rd party company to drivers optimization.
                            Most developers have in house tools that allow them to constantly benchmark and test things. At some point a developer might find a bug or issue that causes huge performance loss. Back when the Radeon 8500 was ATI's best of the best graphics card, John Carmack found a massive bug in their drivers that when fixed gave it a huge performance increase.

                            Even the Dolphin emulator developer has a lot of negative things to say about Linux drivers. I would imagine that nothing frustrates him more then hours of banging your head into the wall, only to find out it wasn't your code.

                            Even Nvidia start to push some code and docs for Nouveau and this clearly related to what's Valve doing.
                            Nvidia hasn't done much to help with Nouveau. Not like AMD or Intel has.

                            Comment


                            • #15
                              To give you an idea the Dolphin developer didn't like AMD or Nvidia's response time for the issues they found, but like the Open Source drivers response time to fix issues to be a lot better.

                              Code:
                                  Wrong GLSL built-in functions results with UBO arguments, fixed in Mesa 9.1.1, 7 days after we reported the bug.
                                  Dithering effects with UBOs, centroid and i965, fixed in Mesa 9.2.0.
                                  Mesa bug causing black screen on r600 (radeon), patch provided 10 minutes after we reported the issue on IRC, merged the same day and released in a stable version 2 weeks later (9.1.3).
                                  Nouveau black screen issue with UBOs larger than 64KB, debugged by one of our developers, merged 1 day after the bug was reported and released in a stable version a week later (9.1.6).

                              Comment

                              Working...
                              X