<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - [sna gen4] corrupt rendering (and flickering on redraw)" href="https://bugs.freedesktop.org/show_bug.cgi?id=55500#c100">Comment # 100</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - [sna gen4] corrupt rendering (and flickering on redraw)" href="https://bugs.freedesktop.org/show_bug.cgi?id=55500">bug 55500</a> from <a class="email" href="mailto:zdenek.kabelac@gmail.com" title="Zdenek Kabelac <zdenek.kabelac@gmail.com>"> Zdenek Kabelac</a> <pre>(In reply to <a href="show_bug.cgi?id=55500#c99">comment #99</a>) > (In reply to <a href="show_bug.cgi?id=55500#c97">comment #97</a>) > > (In reply to <a href="show_bug.cgi?id=55500#c96">comment #96</a>) > > > (In reply to <a href="show_bug.cgi?id=55500#c93">comment #93</a>) > > > > The bad part is - while before I've been getting 3.7Mchar/s in x11perf > > > > -aa10text - now it's like 1.3Mchar/s so significantly slower. > > But as I said before - if that would be plain hw defect - IMHO it would > > simply always appear - but it seems like it's working for a while - then > > 'something' happens - and flickering starts to appear - with (assumingly) > > same amount > > of texels/triangle/vertices - and than something again may happen, > > and the problem is gone for a while. > > It does. You do not have quite as much control over your tests as you > presume. Well I understand there are some weird things underneath - but when I've a page where the scrolling up/down is showing heavy intel_gpu_top usage, and flickering of pictures is visible - then I make nothing else then page reload - I've just naive assumption, that this redrawn page is just using different memory buffers - but otherwise the number of graphical objects pushed to GPU should be approximately the same. (I'm using plain good old xfce, so no fancy Gnome3 shell composite desktops...) > No. I did not say the texel reads where the problem, just an indicator as to > how long the EU would execute any particular shader for a fragment. Also > there is only a single sampler and many EU running many more threads, so > contention will also play a factor into how long each fragment takes to > process, and so how long buffers will be active for. Look more closely at > what it is going on, it is clearly that the hardware is not tracking > lifetimes of its URB correctly. > > > Also is there some explanation why intel_gpu_top is showing so much higher > > GPU usage when the flickering is visible ? > > Other than the flickering correlates with GPU activity? Well the same page could be scrolled with either i.e. 15% 'render busy' - and no flickering - or with ~50% 'render busy' and visible problems. I could make a debug build - but it would be probably needed to have some kind of 'signal support' to dump needed data when necessary instead of logging GB of data all the time. > > i.e. I'd have expected if there would be a large press on GPU - but in this > > case it just appear random pixel start to be drawn instead of some letter - > > maybe some font cache corruption ? > > It's still the same bug. So maybe we could start at this - since MAX 64 is giving the problem exposed very easily - it's enough to run gnome-terminal on my desktop.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>