Announcement

Collapse
No announcement yet.

Mesa Threaded OpenGL Dispatch Finally Landing, Big Perf Win For Some Games

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

  • #21
    Originally posted by Veerappan View Post
    From Gregory Hainaut @ https://lists.freedesktop.org/archiv...ry/143190.html
    So by threading the various GL calls, additional synchronization is added. That synchronization *can* lead to performance degradation for some applications depending on how they use the GL API. And this is why the threaded dispatch isn't enabled for applications by default, but would have an environment variable or drirc opt-in mechanism to selectively enable it for applications.
    Apparently this is more paralleled than I expected. Synchronization is the bane of multithreading (that and shared memory...).

    For as long as Linux doesn't have anything like application profiles, it seems this is something that would be better off left disabled by default. Generally speaking, the CPU is usually only a bottleneck when you don't have vsync enabled, so I think keeping this off would yield the best results for most people and most applications. But who knows - with enough attention drawn back to this, it could be designed more efficiently, where the threads are more independent from each other.

    Comment


    • #22
      Originally posted by atomsymbol
      In my opinion, glthread (if enabled from command-line) will be slowing down a large number of OpenGL apps this year (2017) and this issue won't be resolved until year 2018+.
      don't enable it for large number of apps then. enable it for small number. like make borderlands playable
      Originally posted by atomsymbol
      On-disk cache is much closer to being capable of working as expected/intended in year 2017 than glthread
      on-disk cache does not make unplayable game playable. it saves two minutes per app run. it solves easily solvable (keep game running for example or go make a coffee after each start) minor inconvenience which is good but not as good as making unplayable game playable
      Last edited by pal666; 06 February 2017, 02:12 PM.

      Comment


      • #23
        Originally posted by schmidtbag View Post
        The article states the the GL calls are queued
        you can't just queue the call, if call accepts array parameter without ownership, you have to copy whole array. so you have overhead and you win only if your overhead is less than your win on parallelization. if your parallelization sucks, you have only overhead.
        Last edited by pal666; 06 February 2017, 02:13 PM.

        Comment


        • #24
          Originally posted by schmidtbag View Post
          For as long as Linux doesn't have anything like application profiles, it seems this is something that would be better off left disabled by default. Generally speaking, the CPU is usually only a bottleneck when you don't have vsync enabled, so I think keeping this off would yield the best results for most people and most applications. But who knows - with enough attention drawn back to this, it could be designed more efficiently, where the threads are more independent from each other.
          Right from the message:
          It's disabled
          by default, so it shouldn't bother anyone who doesn't want it. There is a drirc option to turn it on (just use the corresponding env var).

          Comment


          • #25
            Would this make wine's CSMT redundant if picked up by all mesa drivers? Or does the gl->d3d3 translation have more overhead, so CSMT would be better than this?

            Comment


            • #26
              Originally posted by treba View Post
              Would this make wine's CSMT redundant if picked up by all mesa drivers? Or does the gl->d3d3 translation have more overhead, so CSMT would be better than this?
              When you run an API upon a same level API, the overall overhead including CPU, GPU, SoundPU (if it's an audio API), memory, will be 50% best case scenario. Nothing can be done here, ever. So WineCSMT will always have half the NineCSMT speed best case (Nvidia). And if you try to emulate x86 on ARM, the best case (LLVM combined, FP in hardware) will be 50% and that's only because ARM has less instructions per clock (less optimizations). Whatever Codeweavers, Nvidia or Loongson say are really marketing tricks. If you want a GPU for Linux, buy Radeon.

              Comment


              • #27
                Originally posted by atomsymbol
                I am totally against application profiles.
                no glthread for you then
                Originally posted by atomsymbol
                A solution superior to application profiles is to analyze application's OpenGL usage patterns and make optimization decisions based on those patterns.
                untill you implement that i will be using what is available

                Comment


                • #28
                  Originally posted by funfunctor View Post

                  This change is to do with the single threaded nature of the GL **API** it has nothing to do with hardware CPU vs. GPU.
                  Still, a multi-threaded API is going to be bottlenecked when it gets to a single-threaded GPU.

                  Comment


                  • #29
                    Veerappan schmidtbag the work is merged just to not be an out-of-tree work. If you'd read the mailing list — it's absolutely not ready for use, so degradations and crashes are expected, which is why it's disabled by default.

                    Comment


                    • #30
                      Originally posted by ldo17 View Post
                      single-threaded GPU.
                      such thing doesn't exist

                      Comment

                      Working...
                      X