Re: i915 #GP [was: mmotm 2010-02-01-16-25 uploaded]
On 02/05/2010 09:34 AM, Jiri Slaby wrote: On 02/03/2010 10:41 PM, Jiri Slaby wrote: On 02/02/2010 01:25 AM, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2010-02-01-16-25 has been uploaded to Hi, when thunderbird appears on clean X+xterm I get this with the snapshot: [drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at index 1 general protection fault: [#1] SMP last sysfs file: /sys/devices/pci:00/:00:1e.0/:04:00.0/resource CPU 0 Pid: 3412, comm: X Not tainted 2.6.33-rc6-mm1_64+ #941 To be filled by O.E.M./To Be Filled By O.E.M. RIP: 0010:[812579ef] [812579ef] i915_gem_do_execbuffer+0x3ef/0xbf0 RSP: 0018:8801c2313c68 EFLAGS: 00010202 RAX: 8801c2f6a7c8 RBX: 0002 RCX: 0049 RDX: 6b6b6b6b6b6b6b6b RSI: 81237e70 RDI: 8801c2a28738 RBP: 8801c2313d18 R08: R09: 0200 R10: R11: 0004 R12: 8801c2f6a7b8 R13: 8801c2313d38 R14: R15: fff7 FS: 7f4910c476f0() GS:88010020() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f48fb928000 CR3: 0001c2cd5000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process X (pid: 3412, threadinfo 8801c2312000, task 8801c3539c00) Stack: 81803580 00d0 8801c2e043d8 00d7ba90 0 0060 810be556 8801c5f918f8 8801c2f6a7b8 0 8801cbc0a048 8801c2f6a7b8 8801c5f918d8 Call Trace: [810be556] ? __slab_alloc+0x266/0x2f0 [81258584] i915_gem_execbuffer+0x1b4/0x360 [81253516] ? i915_gem_sw_finish_ioctl+0x96/0xd0 [812363ed] drm_ioctl+0x1bd/0x480 [8108fe12] ? unlock_page+0x22/0x30 [812583d0] ? i915_gem_execbuffer+0x0/0x360 [810a9dbb] ? handle_mm_fault+0x18b/0x3c0 [810d7468] vfs_ioctl+0x38/0xd0 [810d7ca0] do_vfs_ioctl+0x80/0x340 [81024841] ? do_page_fault+0x131/0x2d0 [810d7faa] sys_ioctl+0x4a/0x80 [81002e6b] system_call_fastpath+0x16/0x1b Code: 44 8b 5a 08 45 85 db 74 4f 31 db 4c 8b 65 a0 49 89 d5 66 2e 0f 1f 84 00 00 00 00 00 48 63 c3 49 8d 04 c4 48 8b 10 48 85 d2 74 25 48 8b 92 80 00 00 00 c7 82 a0 00 00 00 00 00 00 00 48 8b 38 48 RIP [812579ef] i915_gem_do_execbuffer+0x3ef/0xbf0 RSP 8801c2313c68 ---[ end trace 99140c91bbc9294a ]--- opposing to 2010-01-15-15-34 which was OK. This is a setup with no KMS with 2.9.1 intel X drv. Does reverting 859ddf09743a8cc680af33f7259ccd0fd36bfe9d help? For me it fixes the problem. (Adding some CCs) And when I revert drivers-gpu-drm-drm_crtc_helperc-fix-setting-of-fb_changed-in-drm_crtc_helper_set_config.patch I can even use KMS with intel. The fb_changed patch causes X to not render the screen, I can blindly move windows after X starts, cursors changes, but the screen is always black. regards, -- js -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume
On Fri, 2010-02-05 at 11:29 -0800, Jesse Barnes wrote: On Thu, 4 Feb 2010 21:42:02 +0100 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday 04 February 2010, Soeren Sonnenburg wrote: On Mon, 2010-02-01 at 01:22 +0100, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 after suspend-resume Submitter : Soeren Sonnenburg so...@debian.org Date : 2010-01-10 20:09 (22 days old) References: http://marc.info/?l=linux-kernelm=126315457519505w=4 yes still exists in current git. Thanks for the update. Just updated the corresponding FDO bug (https://bugs.freedesktop.org/show_bug.cgi?id=24314). There are some hw bugs related to FBC handling on 945GM though, so we may have to disable it on some machines. FYI: With the patch from #14897 it was working for the last day and a half at least... Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume
On Sat, 2010-02-06 at 06:11 +0100, Soeren Sonnenburg wrote: On Fri, 2010-02-05 at 11:29 -0800, Jesse Barnes wrote: On Thu, 4 Feb 2010 21:42:02 +0100 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday 04 February 2010, Soeren Sonnenburg wrote: On Mon, 2010-02-01 at 01:22 +0100, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 after suspend-resume Submitter: Soeren Sonnenburg so...@debian.org Date : 2010-01-10 20:09 (22 days old) References : http://marc.info/?l=linux-kernelm=126315457519505w=4 yes still exists in current git. Thanks for the update. Just updated the corresponding FDO bug (https://bugs.freedesktop.org/show_bug.cgi?id=24314). There are some hw bugs related to FBC handling on 945GM though, so we may have to disable it on some machines. FYI: With the patch from #14897 it was working for the last day and a half at least... Just after I wrote that email it was happening again. So I take that back. Flickering and display - off just happened with that patch. Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm compile warnings fixes
On Thu, 2010-02-04 at 19:48 -0500, Kristian Høgsberg wrote:
On Thu, Feb 4, 2010 at 2:23 PM, Matthew W. S. Bell
Additionally, the function libdrm/xf86drmSL.c:drmSLLookupNeighbors()
appears to be completely broken as it computes on the variable update
which is unconditionally undefined.
Yeah, nothing really uses the skip list and I'd like to drop it and
the hash table. I guess it's not a big deal though...
Well, it's a small function that's part of a public API, it should
either do something other than return undefined results or be removed.
As such, here is a patch removing it.
Also attached is a patch for another warning fix.
Matthew W.S. Bell
From 3203bcbae14611fa4c3df8b1c9fe81a738991814 Mon Sep 17 00:00:00 2001
From: Matthew W. S. Bell matt...@bells23.org.uk
Date: Sat, 6 Feb 2010 04:10:31 +
Subject: [PATCH 1/2] Cast type for printf to silence warning.
---
tests/drmstat.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/drmstat.c b/tests/drmstat.c
index 345b8d2..ea9d12f 100644
--- a/tests/drmstat.c
+++ b/tests/drmstat.c
@@ -288,7 +288,7 @@ int main(int argc, char **argv)
drmError(r, argv[0]);
return 1;
}
- printf(0x%04lx byte shm added at 0x%08lx\n, size, handle);
+ printf(0x%04lx byte shm added at 0x%08lx\n, size, (unsigned long)handle);
sprintf(buf, cat /proc/dri/0/vm);
system(buf);
break;
--
1.6.5
From 04c7443cc7f16578c00d45617c91b51c26bdec17 Mon Sep 17 00:00:00 2001
From: Matthew W. S. Bell matt...@bells23.org.uk
Date: Sat, 6 Feb 2010 04:11:02 +
Subject: [PATCH 2/2] Eliminate drmSLLookupNeighbors as it appears to want an
SLLocateNeighbors function that never existed.
---
xf86drm.h |3 ---
xf86drmSL.c | 51 ---
2 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/xf86drm.h b/xf86drm.h
index 9b89f56..9cec066 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -682,9 +682,6 @@ extern int drmSLDelete(void *l, unsigned long key);
extern int drmSLNext(void *l, unsigned long *key, void **value);
extern int drmSLFirst(void *l, unsigned long *key, void **value);
extern void drmSLDump(void *l);
-extern int drmSLLookupNeighbors(void *l, unsigned long key,
- unsigned long *prev_key, void **prev_value,
- unsigned long *next_key, void **next_value);
extern int drmOpenOnce(void *unused, const char *BusID, int *newlyopened);
extern void drmCloseOnce(int fd);
diff --git a/xf86drmSL.c b/xf86drmSL.c
index acddb54..f3328de 100644
--- a/xf86drmSL.c
+++ b/xf86drmSL.c
@@ -96,9 +96,6 @@ extern int drmSLDelete(void *l, unsigned long key);
extern int drmSLNext(void *l, unsigned long *key, void **value);
extern int drmSLFirst(void *l, unsigned long *key, void **value);
extern void drmSLDump(void *l);
-extern int drmSLLookupNeighbors(void *l, unsigned long key,
- unsigned long *prev_key, void **prev_value,
- unsigned long *next_key, void **next_value);
#endif
static SLEntryPtr SLCreateEntry(int max_level, unsigned long key, void *value)
@@ -259,30 +256,6 @@ int drmSLLookup(void *l, unsigned long key, void **value)
return -1;
}
-int drmSLLookupNeighbors(void *l, unsigned long key,
- unsigned long *prev_key, void **prev_value,
- unsigned long *next_key, void **next_value)
-{
-SkipListPtr list = (SkipListPtr)l;
-SLEntryPtrupdate[SL_MAX_LEVEL + 1];
-int retcode = 0;
-
-*prev_key = *next_key = key;
-*prev_value = *next_value = NULL;
-
-if (update[0]) {
- *prev_key = update[0]-key;
- *prev_value = update[0]-value;
- ++retcode;
- if (update[0]-forward[0]) {
- *next_key = update[0]-forward[0]-key;
- *next_value = update[0]-forward[0]-value;
- ++retcode;
- }
-}
-return retcode;
-}
-
int drmSLNext(void *l, unsigned long *key, void **value)
{
SkipListPtr list = (SkipListPtr)l;
@@ -410,21 +383,6 @@ static double do_time(int size, int iter)
return usec;
}
-static void print_neighbors(void *list, unsigned long key)
-{
-unsigned long prev_key = 0;
-unsigned long next_key = 0;
-void *prev_value;
-void *next_value;
-int retval;
-
-retval = drmSLLookupNeighbors(list, key,
- prev_key, prev_value,
- next_key, next_value);
-printf(Neighbors of %5lu: %d %5lu %5lu\n,
- key, retval, prev_key, next_key);
-}
-
int main(void)
{
SkipListPtrlist;
@@ -442,15 +400,6 @@ int main(void)
print(list);
printf(\n==\n\n);
-print_neighbors(list, 0);
-print_neighbors(list, 50);
-print_neighbors(list, 51);
-print_neighbors(list, 123);
-print_neighbors(list, 200);
-print_neighbors(list, 213);
-print_neighbors(list, 256);
-printf(\n==\n\n);
-
drmSLDelete(list, 50);
print(list);
printf(\n==\n\n);
--
1.6.5
signature.asc
Description: This is a
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Thu, Feb 4, 2010 at 11:23 PM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 4 Feb 2010 22:05:59 +0100 Ingo Molnar mi...@elte.hu wrote: Regressions are not limited to 'same config' kernels, last i checked. If that has changed (or if i'm misunderstanding it) then it would be nice to hear a clarification about that from Linus. The way i understand it is that there are narrow exceptions from the regression rules, such as completely new drivers for which there can be no prior expectation of stability by users. (but for even them we are generally on the safer side to list bugs in them as regressions as well - especially if we expect many users to enable it.) AFAIK there's no exception for new sub-features of existing facilities or drivers, even if it's default-disabled. This issue materially affects quite a few bugs i'm handling as a maintainer. Many of them are under default-off config options - most new aspects to existing code are introduced in such a way. It would remove quite a bit of urgent-workload from my workflow if i could strike them from Rafael's list and could deprioritize them as plain bugs, to be fixed as time permits. IMHO it would be rather counter-productive to kernel quality if we did that kind of regression-lawyering though. Yes, it's mainly semantics. From the user's point of view kernel N: boots, works, plays nethack kernel N+1: goes splat That kernel regressed for that user. He'll shrug and will go back to kernel N and we lost an N+1 tester. And the distros who ship N+1 get a lot of hack work to do. If the feature is this buggy, it was wrong to make it accessible in Kconfig. That's why some features are marked as _experimental_ and disabled by default. If the feature is not marked as such, then yeah, I would consider it a regression. -- Felipe Contreras -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 Lukas Weber laochai...@web.de changed: What|Removed |Added CC||laochai...@web.de --- Comment #25 from Lukas Weber laochai...@web.de 2010-02-06 09:23:45 PST --- I finally got KMS working with thursday's mesa and xf86-video-ati having the same issue: game runs at full speed with OffscreenRenderingMode=backbuffer but only the menus are drawn. With OffscreenRenderingMode=fbo ingame is visible but the game is still slow (~20fps) like in the bug at winehq, which seems to be not radeon specific. I use 32bit only so I think Allen's theory is disproved. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Question about Radeon 5450
Hi, I would like to ask whether current Mesa and xf86-drv-ati supports the new low cost, passively cooled Radeon 5450? Thanks in advance, Zoltán Böszörményi -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26459] New: False Output detection.
http://bugs.freedesktop.org/show_bug.cgi?id=26459 Summary: False Output detection. Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: nill...@freenet.de On an KMS Environment the Display connectors are false Detected. He use DVI-1 as DVI-0 and DVI-0 as DVI-1. If you now use an KMS, non KMS environment or an Dual Boot you get some Troubles. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26459] False Output detection.
http://bugs.freedesktop.org/show_bug.cgi?id=26459 --- Comment #1 from Alex Deucher ag...@yahoo.com 2010-02-06 11:43:14 PST --- The output ordering is different in some cases with KMS compared to UMS. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D OpenGL applications eat CPU ressources
2010/2/4 Jerome Glisse gli...@freedesktop.org: IIRC old radeon drm doesn't have any thing to dump GPU command stream. Look at http://www.x.org/docs/AMD/R5xx_Acceleration_v1.4.pdf to see what radeon GPU stream command looks like (packet pm4 stuff). Note that dump GPU command stream can quickly eat Gigs of data and finding what is causing the lockup is then very cumberstone especialy as in your case it sounds like it's a timing issue. You might want to force your card into pci mode to see if it's agp related. Yep, setting Option BusType PCI in /etc/X11/xorg.conf prevents from GPU lockup. A a side note, strace glxinfo and strace glxgears still give me read() errors on /tmp/.X11-unix/X0, so they're probably not related to GPU lockup. Anyway, I don't know whether this is due to PCI mode or not, but OpenGL performances, although there's no more GPU lockup, are poor. And serious OpenGL applications, as simulated by the SPECviewperf test suite, have very irregular frame rates. If I'm not mistaken, the BusType option is specific to the radeon driver (or maybe other drivers too)? I mean, it's not a X.org wide configuration option, isn't it? This would thus narrow my investigation path to the AGP code of the radeon driver, right? Émeric -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26459] False Output detection.
http://bugs.freedesktop.org/show_bug.cgi?id=26459 --- Comment #2 from Niels P. nill...@freenet.de 2010-02-06 11:51:51 PST --- (In reply to comment #1) The output ordering is different in some cases with KMS compared to UMS. Has it an special reason? Because with this ordering its hard to use one configuration for some Installations. Special if you use KMS and non KMS environments. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D OpenGL applications eat CPU ressources
On Sat, Feb 6, 2010 at 2:47 PM, Émeric Maschino emeric.masch...@gmail.com wrote: 2010/2/4 Jerome Glisse gli...@freedesktop.org: IIRC old radeon drm doesn't have any thing to dump GPU command stream. Look at http://www.x.org/docs/AMD/R5xx_Acceleration_v1.4.pdf to see what radeon GPU stream command looks like (packet pm4 stuff). Note that dump GPU command stream can quickly eat Gigs of data and finding what is causing the lockup is then very cumberstone especialy as in your case it sounds like it's a timing issue. You might want to force your card into pci mode to see if it's agp related. Yep, setting Option BusType PCI in /etc/X11/xorg.conf prevents from GPU lockup. A a side note, strace glxinfo and strace glxgears still give me read() errors on /tmp/.X11-unix/X0, so they're probably not related to GPU lockup. Anyway, I don't know whether this is due to PCI mode or not, but OpenGL performances, although there's no more GPU lockup, are poor. And serious OpenGL applications, as simulated by the SPECviewperf test suite, have very irregular frame rates. If I'm not mistaken, the BusType option is specific to the radeon driver (or maybe other drivers too)? I mean, it's not a X.org wide configuration option, isn't it? This would thus narrow my investigation path to the AGP code of the radeon driver, right? AGP is somewhat broken by design. There are alots of subtle incompatibilities and quirks between different AGP and GPU combinations. Your best bet is to play with the agp options in your bios, or try adjusting the agpmode option: Option AGPMode x where x = 1 or 2 or 4 or 8 If you find a mode that works, we can add a quirk for your chipset/gpu combination. Alex -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCHES] further radeon drm kms hw i2c fixes
These patches add further fixes to the hw i2c code. Still left to do: - Find a way to not expose the internal bit algo bus used by radeon algo - Figure out why hw i2c isn't working for LVDS on mac laptops - Any other remaining bugs Alex 0001-drm-radeon-kms-straighten-out-hw-i2c-gpio-lines.patch Description: application/mbox 0002-drm-radeon-kms-protect-hw-i2c-engine-with-a-mutex.patch Description: application/mbox 0003-drm-radeon-kms-take-the-pm-mutex-when-using-hw-i2c.patch Description: application/mbox -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D OpenGL applications eat CPU ressources
Anyway, I don't know whether this is due to PCI mode or not, but OpenGL performances, although there's no more GPU lockup, are poor. And serious OpenGL applications, as simulated by the SPECviewperf test suite, have very irregular frame rates. If I'm not mistaken, the BusType option is specific to the radeon driver (or maybe other drivers too)? I mean, it's not a X.org wide configuration option, isn't it? This would thus narrow my investigation path to the AGP code of the radeon driver, right? No it narrows it down the to the AGP hardware in your machine along with the probable lack of info on it, and maybe some tweaks that we know nothing about. If it was as simple as a codepath in the radeon driver I think we'd have fixed it by now. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
