(In reply to comment #99) > (In reply to comment #97) > > (In reply to comment #96) > > > (In reply to comment #93) > > > > 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. -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xserver-xorg-video-intel in Ubuntu. https://bugs.launchpad.net/bugs/1098334 Title: [gen4 sna] Font corruption in Chromium tab bar To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1098334/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
