radeon driver stops C3 if DRI is enabled
Hi, I saw this reported on the acpi list too [1], so I thought I would post it here hoping it's the right place to send it. Using the radeon driver from recent X.org CVS (on Linux 2.6.11.10), my CPU never enters C3 while under X. This causes me to lose about 30 minutes of battery life. This is due to the radeon driver causing bus master activity: if I switch to a text console C3 starts getting used again, and if drm.ko is not available when X starts (or if dri is disabled [1]), the CPU enters C3 under X too. Is there something that can be done to fix this? Cheers, Lorenzo [1] http://sourceforge.net/mailarchive/forum.php?thread_id=7785754forum_id=6102 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
Aapo Tahkola wrote: atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Yep, color tiling is a big win here. When I turned it on, ./atlantis -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps (not fulscreen) went from 10 FPS to ~200 FPS. I also get 1000 FPS in glxgears while before I used to get ~500. This is on a rage mobility 9600 M10 (RV350) on a Pentium M 1.4 GHz. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. For reference, I get ~26 FPS with wireframe and ~19 without (not full screen). With no HW acceleration I get 7 FPS. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Why should increasing window size affect framerates? I thought that as far as the graphics chip was concerned, a triangle was just a triangle irrespective of size, and we're not hitting fill rate limits here... or is there something I'm missing? Cheers, Lorenzo --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
Peter Zubaj wrote: Some of r300 driver lockups are card dependant (and for now I have only these card dependand lockups). Cards which will lock (soon or later) are 9500 Pro (maybe 9500 too), 9700, 9800. What card do you have ? According to lspci, it's an ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Try to load fglrx 2d driver first, then uload it and then use r300 driver. I don't use fglrx, both because it's closed source and because I don't want to litter my system with a lot of files I don't know about. Would installing it help to debug the problem or is it just a workaround? If it's only a workaround, I can simply not try to use Xglx: it doesn't work anyway... Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
Nicolai Haehnle wrote: According to lspci, it's an ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] That chip is actually known to work fine. Have you tried to run ordinary OpenGL applications within the normal X.Org server (e.g. Glean, TuxRacer, Cube, ...)? Are you seeing lockups there, too? Yes, in fact, mostly it does work fine, and has done so for a while now: - glxgears works, though it only gives me 500 fps (on a Pentium M 1400 - I should get at least 1000 or 1500, right?) - The xscreensaver GL hacks work fine, apart from some display problems on some of them (e.g. mirrorblob) and slowness in uploading textures - Quake3 is a little bit slow but works fine. If the lockups happen only with Xglx, this could well be an Xglx-specific software issue. In this case, you should try enabling the DRM debugging options (modprobe drm debug=1) and have a look into the dmesg/syslog/wherever kernel messages end up on your system to see what happens around the the time of lockup. Also, you should obviously make sure that all your components are recent (X.Org CVS, r300 CVS, Mesa CVS). Ok. I'll see if I can get the messages then. I don't think the machine locks up completely. If it's a bug on our (i.e. the driver's) side, we should fix it, whether or not Xglx itself is in a usable state. It's likely that Xglx hits code paths that aren't used by most programs. That's what I thought as well. Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] r300 driver locks up with Xglx
Hi, every now and then I try to run Xglx with the DRI r300 driver. It doesn't really work at all, but you never know, maybe soon r300 will be complete enough to get it working properly, so I try. However, every time I run metacity under Xglx, X locks up immediately. I was wondering if this might be useful to debug the r300 lockup problem people are trying to solve. If so, let me know how I can help debug it... Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: When I first boot it's fine, but when the laptop comes back from S3, even if everything else works, the serial console just prints a couple of characters of garbage and then dies. :( You do get the nice serial console printout at boot right, it's only not working on resume? Ben said he would be back this week. He is the expert on this code. Yes, that's right. It works fine when I first boot, but after resume from S3 it's broken. Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: When I first boot it's fine, but when the laptop comes back from S3, even if everything else works, the serial console just prints a couple of characters of garbage and then dies. :( The serial line is probably coming back at the default baud rate and you were setting it higher when you were testing it. That might be, but this happened both when booting with console=ttyS0,115200n8 and with console=ttyS0, which I assumed should set it to the default rate. I altro tried to see if writing to the port would get it working again, e.g. as reported here: http://www.ussg.iu.edu/hypermail/linux/kernel/0502.0/1030.html but that didn't work either. Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: The only way I can think to debug this is to put bunches of printks into drivers/video/aty/radeon_pm.c and then hook a serial console up to the laptop. [...] Hmm. I could try that (though not in the next couple of weeks because I won't have access to another machine), will the serial console will come up before the hang occurs? The serial line is the earliest display the kernel will make. It is active even before secondary CPUs are initialized. I have tried this, but unfortunately my serial console dies on resume. When I first boot it's fine, but when the laptop comes back from S3, even if everything else works, the serial console just prints a couple of characters of garbage and then dies. :( Any other ideas? Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. If I load radeonfb, my laptop hangs on resume from S3. It has been known to cause problems for other people too, see for example the following: http://sourceforge.net/mailarchive/message.php?msg_id=10772046 http://lkml.org/lkml/2005/2/27/170 With a normal text console or vesafb, S3 works like a charm. But as soon as I a modprobe radeonfb, if the laptop goes into S3 it never comes back. I would be happy to test your patch if you think S3 has a hope of working with radeonfb loaded, but if not I think this will be a showstopper for me. Cheers, Lorenzo --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: My patch will do nothing for the S3 resume problem. There must be some bug in the radeonfb power management code. The only way I can think to debug this is to put bunches of printks into drivers/video/aty/radeon_pm.c and then hook a serial console up to the laptop. [...] Hmm. I could try that (though not in the next couple of weeks because I won't have access to another machine), will the serial console will come up before the hang occurs? Furthermore, real kernel hackers (as opposed to me) have been working on this for a while, which leads me to believe that it's not so simple as that. I can try of course... Cheers, Lorenzo --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 mergedfb+mouse lockups back
Hi,
I recently updated my x.org, mesa and r300 trees to current code, but
the machine would lock up if I moved the mouse when a 3d app was
running. This used to happen a while ago too, but then Vladimir fixed it
by calling RADEONWaitForIdleMMIO() in RADEONChooseCursorCRTC():
http://marc.theaimsgroup.com/?l=dri-develm=110877531523881
I reapplied Vladimir's fix and the machine doesn't lock up any more.
Maybe the fix should be checked in to CVS again?
(Patch against current x.org cvs attached for convenience)
Cheers,
Lorenzo
Index: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c
===
RCS file:
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c,v
retrieving revision 1.9
diff -u -r1.9 radeon_mergedfb.c
--- xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c20 Apr
2005 12:25:22 - 1.9
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c16 May
2005 19:41:05 -
@@ -1444,6 +1444,14 @@
((RADEONMergedDisplayModePtr)info-CurrentLayout.mode-Private)-CRT2Position;
ScrnInfoPtr pScrn2 = info-CRT2pScrn;
+/*
+ Note: we need WaitForIdle here because OUTREGP() involves an INREG() to
obtain a previous
+ value. This fix is needed for RV350 + 3d driver (or we get a lockup
otherwise).
+
+ It is also indicated by documentation (we should not be doing INREG if
CP engine is active)
+*/
+RADEONWaitForIdleMMIO(pScrn1);
+
if (srel == radeonClone) {
/* show cursor 2 */
OUTREGP(RADEON_CRTC2_GEN_CNTL, RADEON_CRTC2_CUR_EN,
Re: r300 mergedfb+mouse lockups back
Dave Airlie wrote: I reapplied Vladimir's fix and the machine doesn't lock up any more. Maybe the fix should be checked in to CVS again? http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c?rev=1.9view=log v 1.7 backs it out because it is buggy... I know, I read the checkin comment. However, is buggy better than locked up hard? Cheers, Lorenzo --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] [patch] r300_driver DRM doesn't compile on linux 2.6.11-rc4
Hi,
due to kernel interface changes between 2.6.10 and 2.6.11, the version
of DRM included in the r300_driver CVS tree won't compile on my
2.6.11-rc4 kernel.
The attached patch fixes the problem for me (it compiles and seems to
work too). Could it be merged into CVS so r300_driver users/hackers
upgrade to 2.6.11 and later?
Cheers,
Lorenzo
Index: r300_driver/drm/linux-core/drm_compat.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_compat.h,v
retrieving revision 1.1
diff -u -r1.1 drm_compat.h
--- r300_driver/drm/linux-core/drm_compat.h 23 Oct 2004 12:43:44 -
1.1
+++ r300_driver/drm/linux-core/drm_compat.h 2 Mar 2005 17:59:47 -
@@ -191,6 +191,31 @@
}
#endif
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,10)
+typedef struct {
+ void(*free_memory)(struct agp_memory *);
+ struct agp_memory * (*allocate_memory)(size_t, u32);
+ int (*bind_memory)(struct agp_memory *, off_t);
+ int (*unbind_memory)(struct agp_memory *);
+ void(*enable)(u32);
+ int (*acquire)(void);
+ void(*release)(void);
+ int (*copy_info)(struct agp_kern_info *);
+} drm_agp_t;
+
+static const drm_agp_t drm_agp_stub = {
+ agp_free_memory,
+ agp_allocate_memory,
+ agp_bind_memory,
+ agp_unbind_memory,
+ agp_enable,
+ agp_backend_acquire,
+ agp_backend_release,
+ agp_copy_info
+};
+
+#endif
+
extern const drm_agp_t drm_agp_entry;
/* old architectures */
Index: r300_driver/drm/linux-core/drm_memory.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_memory.h,v
retrieving revision 1.1
diff -u -r1.1 drm_memory.h
--- r300_driver/drm/linux-core/drm_memory.h 23 Oct 2004 12:43:44 -
1.1
+++ r300_driver/drm/linux-core/drm_memory.h 2 Mar 2005 17:59:47 -
@@ -137,7 +137,12 @@
static inline unsigned long drm_follow_page(void *vaddr)
{
pgd_t *pgd = pgd_offset_k((unsigned long)vaddr);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,11)
pmd_t *pmd = pmd_offset(pgd, (unsigned long)vaddr);
+#else
+ pud_t *pud = pud_offset(pgd, (unsigned long)vaddr);
+ pmd_t *pmd = pmd_offset(pud, (unsigned long)vaddr);
+#endif
pte_t *ptep = pte_offset_kernel(pmd, (unsigned long)vaddr);
return pte_pfn(*ptep) PAGE_SHIFT;
}
