<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Performance degradation when one display is in rotation" href="https://bugs.freedesktop.org/show_bug.cgi?id=93864#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Performance degradation when one display is in rotation" href="https://bugs.freedesktop.org/show_bug.cgi?id=93864">bug 93864</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>Well that was contrary to my expectations. The change should be to apply the bbox of the damage rather than the individual boxes, which is beneficial when they are approximately the same - worst case is a pixel damaged top-left and pixel bottom-right. Tracking damage bbox per CRTC may be a compromise - that would help the case of having a clock in one corner of the display and rendering in the other. However, I think that doesn't explain the result with both being rotated. I wonder if there is not something fishy with the rotation code. Since this is is a 915gm, it will have to create a temporary surface with which to do the rotation as the source framebuffer will be much larger than the render pipeline can handle natively. Similarly the source framebuffer will be larger than a fence and so untiled - but the intermediate and final should be tiled. There's enough oddity here that having a read through of a full-debug log would be interesting. Could you recompile with ./configure --enable-debug=full and attach an xz compressed Xorg.0.log of ~10s of the various setups? The full-debug logs will be huge.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>