(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.
> 
> That's the sacrifice, we have to stop sending commands to the GPU and wait
> for it complete those in flight (quite frequently). Or else new rectangles
> overwrite vertex entries still being used by later entries 
> 
> > So the question here would be - isn't the corruption based on  triangle
> > surface size ? So i.e. GPU is able to  process a lot of small ones - but has
> > bug with bigger ones ?
> > 

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.

> Not really, you have to predict when a VUE being used by the end of the
> pipeline will be overwritten by a new rectangle at the start of the
> pipeline. This is completely internal state - the primitive command we want
> to feed to the GPU can contains thousands of rectangles. Instead of counting

Well I've tried even 8 max triangles - and the error appeared after a while,
so far '6' is magic.

> rectangles, you want to start counting fragments (actually texel reads since
> that will be the ratelimiting factor) and flush if we queue up too much work
> for the GPU. If you also model how fast the gpu is retiring fragments so

But in case the same page is rendered with problems as well as without problems,
then it doesn't look like texel read is problem, it rather looks like some
kind of memory mapping/ordering.

Also is there some explanation why  intel_gpu_top is showing so much
higher GPU usage when the flickering is visible ?

-- 
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

Reply via email to