https://bugs.freedesktop.org/show_bug.cgi?id=46213
--- Comment #8 from piranna(a)gmail.com 2012-03-03 03:09:48 PST ---
Sorry for answer so late, this is not my main computer (it's my parents one).
Ok, after some regular usage (reading mail, surfing web...) with System Monitor
at panel to see how system evolutes:
* CPU is always about 5-10% and system load about 0.5-1
* just moving the mouse CPU increases to 40%
* browser scrolling (Chromium 17.0.963.56) increase CPU to 80-100%
* loading a webpage with about 100 thumbnails freezes browser with CPU 100%
about two seconds
* Gnome Mahjongg gets frozen with CPU 100% at refreshing window when going from
windowed to maximized and viceversa for about 2 seconds
Also i'm thinking about try with old Ubuntu Live-CDs to look for when started
the regression.
I'll try to do the sysprof this afternoon (i need to learn to use it). Where
must i use the INTEL_DEBUG=fallback flag? As kernel parameter un Grub?
And no, i'm not excited about rendering frames i will not see ;-) I disabled
vsync just for try and it was the only thing that did relative small YouTube
videos (320x240) didn't drop frames and get frozen... :-/ I really would love
to have vsync back... :-D Oh, and i don't want to use compiz (i hate it and in
fact i'm using a plain no-effects Gnome panel desktop), maybe just some games
like Warmux or Quake 3 (this would be a good performance test to put in
perspective since my old P3 1.1GHz computer with an i815 graphic card played it
very good, i'll try later). Compiz was just an example that the graphic card
was enought powerful to use it without problems... :-)
P.D.: i've attached the pending log files. It keeps some with boot flags, i'll
try to upload later.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=46213
--- Comment #16 from Chris Wilson <chris(a)chris-wilson.co.uk> 2012-03-03 11:02:33 UTC ---
You need to find something that performs absymally due to a mistake in the
driver. Otherwise, we will continue to insist that everything is as good as it
is going to get on that hardware...
The best examples will be taken from your usual workloads as that will give the
greatest perceived improved, and that's the challenge you face.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=45281
Bug #: 45281
Summary: [8xx] Assertion failure whilst running dangerball
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/i830
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: chris(a)chris-wilson.co.uk
>From the xscreensavers (/usr/lib/xscreensaver/dangerball):
dangerball: intel_tris.c:128: intel_extend_inline: Assertion 'intel->prim.flush
== intel_flush_inline_primitive' failed.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=46213
Eric Anholt <eric(a)anholt.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |NOTABUG
--- Comment #2 from Eric Anholt <eric(a)anholt.net> 2012-03-02 17:52:23 PST ---
The numbers in this report talking about glxgears just reflect surprise at
vsync. It is an intentional choice to avoid tearing, and not something we will
change by default. If you're excited about seeing tearing in your apps and
rendering frames you'll never see, you can disable vsync in driconf.
If you can come up with a specific application that is using CPU where it
didn't before and a sysprof profile showing that CPU usage (and probably
INTEL_DEBUG=fallback output explaining the software fallback), then we might be
able to do something.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=41913
Eric Anholt <eric(a)anholt.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution| |FIXED
--- Comment #3 from Eric Anholt <eric(a)anholt.net> 2012-03-02 17:51:05 PST ---
3 links to bug reports elsewhere instead of putting the info in the bug report,
and none of them even have a backtrace. Sigh.
Anyway, this got fixed thanks to another bug report:
commit 024ece7523f1735d2fca0067c0a3bdcf53fde8f9
Author: Kurt Roeckx <kurt(a)roeckx.be>
Date: Fri Mar 2 15:34:45 2012 -0800
i915: Compute maximum number of verts using the actual batchbuffer size.
We were looking at the size of batch.map for how big the batchbuffer
was, but on 865 we just use a single-page batchbuffer due to hardware
limits.
v2: Removed check for sizeof map < bo->size, since that's always false.
[change by anholt]
NOTE: This is a candidate for release branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41495
33b07893e92dcee495908c549be872887096c894
Author: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Wed Nov 9 22:21:16 2011 +0000
i830: Compute initial number of vertices from remaining batch space
In order to prevent an overflow of the batch buffer when emitting
triangles, we need to limit the initial primitive to fit within the
current batch. To do we need to measure the remaining space and thence
compute the maximum number of vertices that fit into that space.
Reported-by: Kurt Roeckx <kurt(a)roeckx.be>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41495
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
NOTE: This is a candidate for release branches.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.