(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 Desktop Packages, 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 Status in X.org xf86-video-intel: In Progress Status in “xserver-xorg-video-intel” package in Ubuntu: Triaged Bug description: After enabling the SNA acceleration method and rebooting, I noticed that graphical glitches appeared in the letters on Chromium's tab bar during the mouse hover animation. I've attached a screenshot illustrating this, particularly with the letter "g" in the screenshot. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: xorg 1:7.7+1ubuntu4 ProcVersionSignature: Ubuntu 3.7.0-7.15-generic 3.7.0 Uname: Linux 3.7.0-7-generic x86_64 ApportVersion: 2.8-0ubuntu1 Architecture: amd64 Date: Thu Jan 10 16:00:55 2013 InstallationDate: Installed on 2012-09-24 (107 days ago) InstallationMedia: Kubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120822.2) MarkForUpload: True SourcePackage: xorg UpgradeStatus: Upgraded to raring on 2012-09-25 (107 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/1098334/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
