<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [BDW Bisected] OglBatch7 performance reduced by ~7% after enable execlists" href="https://bugs.freedesktop.org/show_bug.cgi?id=87725#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [BDW Bisected] OglBatch7 performance reduced by ~7% after enable execlists" href="https://bugs.freedesktop.org/show_bug.cgi?id=87725">bug 87725</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>(In reply to Eero Tamminen from <a href="show_bug.cgi?id=87725#c11">comment #11</a>) > Wendy provided me data with execlists enabled (default) and disabled > (i915.enable_execlists=0 kernel command line option), for full SynMark > test-set with recent 3D stack. > > Execlists is in no case faster. > > It's ~50% slower in GL context re-creation test, and in other CPU bound Hmm, not looked at that. The cause is fairly obvious since execlists implies even more state to create per context. I think I can safely eliminate most of the extra overhead. Worth filing that as a separate bug (I guess the report got overlooked due to the first regression from enabling ppgtt). > tests it's 5-10% slower: > - Batch5-7 (batching huge triangle strip with ever increasing number of draw > calls) These are what I've been looking at. There is a lot of low hanging fruit we can eliminate in execlist submission that brings us back on par. However, looking at the profile of igt/gem_exec_nop and igt/gem_exec_blt, I came to the conclusion that the largest effect is when the GPU is idle (i.e. the GPU takes longer to respond to ELSP than a TAIL update). Therefore the biggest impact of execlists will be different on different machines depending on just how frequently the GPU stalls waiting for the driver. > - DrvState (mostly CPU bound GL state change test) > - Multithread (GL calls from multiple threads) I presume these will be more or less the same effect as above for execlist submission overheads. Except we will be exercising context switching (and thus ring switching) much more. In the driver we can amalgamate consecutive batches from the same context into a single submission, with more contexts active we will not only have to do more ELSP submissions (i.e. more irq handling and general driver overheads) but also more latency from hw context switches.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>