Re: [PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection
On Fri, 2010-02-26 at 15:49 +0100, Jerome Glisse wrote: This patch cleanup the fence code, it drops the timeout field of fence as the time to complete each IB is unpredictable and shouldn't be bound. The fence cleanup lead to GPU lockup detection improvement, this patch introduce a callback, allowing to do asic specific test for lockup detection. In this patch the CP is use as a first indicator of GPU lockup. If CP doesn't make progress during 1second we assume we are facing a GPU lockup. To avoid overhead of testing GPU lockup frequently due to fence taking time to be signaled we query the lockup callback every 100msec. There is plenty code comment explaining the design choise inside the code. Every 100msec? Is this running all the time? If so, that's not very good for CPU power saving to lower C-states in an idle system. We could at least use one of the round_jiffies. This have been tested mostly on R3XX/R5XX hw, in normal running destkop (compiz firefox, quake3 running) the lockup callback wasn't call once (1 hour session). Also tested with forcing GPU lockup and lockup was reported after the 1s CP activity timeout. Signed-off-by: Jerome Glisse jgli...@redhat.com -- Alan. One must never be purposelessnessnesslessness. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: bug in intelfbhw.c
On Wed, 2007-02-21 at 17:10 +0100, Orczykowski, Juergen wrote: Hello, we would like to use your drivers in our software. While debugging we found a bug in calculating the ring_space. This is for the Linux kernel frame buffer driver, not the DRI drivers. You should post this to the [EMAIL PROTECTED] alias as documented in the MAINTAINERS file in the Linux kernel source. If there is less then RING_MIN_FREE available in the ring buffer, dinfo-ring_space is set to a big value forcing wait_ring to return. We have attached a possible solution to solve this bug. intelfbhw.c Also note that changes should be supplied as a patch diff from the original file, not the complete file itself otherwise the changes can't be easily reviewed. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL apps causes frequent system locks
On Mon, 2005-02-07 at 19:24 +0100, Roland Scheidegger wrote: Geller Sandor wrote: I don't intend to start a flame-war, but is there anybody who can use the r200 driver without X crashes? I'm testing X.org CVS regularly (almost on every weekend) with my RV280, with the latest linux 2.6 kernel. I suspect that quite the contrary, almost noone has crashes. This is probably part of the problem, if they happen only for few people with very specific configurations, none of the developers can reproduce it and it will just remain unfixed. For reference, I never get crashes with the r200 driver (on a rv250), at least none which I can't directly reference to my own faults when playing around with the driver... At least since the state submit fixes half a year ago the driver seems quite solid for me. Except the hard lockup I got for some very odd reason when I used a gart size of 64MB, though that was on a r100. I'd have to agree with Roland. I don't have any problems on either my R200 or my rv250 using Mesa/DRM CVS (with X.org 6.8.1 approximately). Hell, I'm finding the R200 driver is just getting better and faster. (Both of which use a GART of 64Mb without problems, though which is slightly pointless currently after recent discussions. ;-) -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
Re: radeon m7 hang with gears...hopefully fixed..
Previously, Alan Swanson wrote: This might affect/cure R100's as well. I was recently trying to help someone with lockups on their Radeon 7200 when using Mesa CVS but without success. Testing with my old Radeon DDR also caused lockups. I'll give this a whirl tomorrow and report back. Aye, its fixed the lockups on original Radeons. Glad I don't play NWN on it though because the problematic swtcl for GL_SPHERE_MAP causes horrible character flickering and there is no patch as for R200. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
Re: radeon m7 hang with gears...hopefully fixed..
On Sun, 2005-01-23 at 20:43 +, Dave Airlie wrote: yes, your patch fixed the glxgears-lockup for me, too. Thanks! It looks like this is only necessary on RV200 based chips, maybe a comment in the source about this behavior might be usefull, otherwise this workaround will get removed in the future again... because other radeons work well without it... If its only RV200 I'll put a check in as I think this may be an expensive workaround I'll get some more time this week to work on it, (I actually got paid hourly to track this down so staring at it for two days wasn't as bad as it could have been :-) I'll cook up a proper patch.. Keith you know why this is needed (sounds like you might know why zbs should be emitted considering none of my rv200 docs mention it) ... is it acting like a nop or does it do something ... This might affect/cure R100's as well. I was recently trying to help someone with lockups on their Radeon 7200 when using Mesa CVS but without success. Testing with my old Radeon DDR also caused lockups. I'll give this a whirl tomorrow and report back. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
DRM Build failure: 4 level page tables != 2.6.10
Jon Smirl wrote:
CVSROOT: /cvs/dri
Module name: drm
Repository: drm/linux-core/
Changes by: [EMAIL PROTECTED] 05/01/06 09:09:22
Log message:
Adjust drm-memory for 4 level page tables in 2.6.10
ifdef'd to use 3 levels in kernels older than 2.6.10
Modified files:
drm/linux-core/:
drm_memory.h
Revision ChangesPath
1.31 +7 -2 drm/linux-core/drm_memory.h
The build of linux-core is failing as 4 level page tables weren't
in 2.6.10, but are going to be in 2.6.11. Simple fix attached.
--
Alan.
One must never be purposelessnessnesslessness.
--- drm/linux-core/drm_memory.h 2005-01-08 15:39:14.0 +
+++ drm/linux-core/drm_memory.h 2005-01-08 16:20:33.678901008 +
@@ -137,7 +137,7 @@
static inline unsigned long drm_follow_page(void *vaddr)
{
pgd_t *pgd = pgd_offset_k((unsigned long) vaddr);
-#if LINUX_VERSION_CODE 0x02060a /* KERNEL_VERSION(2,6,10) */
+#if LINUX_VERSION_CODE 0x02060b /* KERNEL_VERSION(2,6,11) */
pmd_t *pmd = pmd_offset(pgd, (unsigned long)vaddr);
#else
pud_t *pud = pud_offset(pgd, (unsigned long) vaddr);
signature.asc
Description: This is a digitally signed message part
Re: Reverse engineering ati driver
On Thu, 2004-12-02 at 19:54 +0100, Stephane Marchesin wrote: And is HyperZ fully working now? Hmmm. It works, but there is a bit that we'll probably leave aside on the R200 (hierarchical Z) because neither Roland nor me have an R200. I've been meaning to offer this for a while for the sterling work people have put into R200 (and Mesa) development, so who would like a free R200? It's only a 8500LE but is still a full R200 and free includes the PP. Roland or Stephane perhaps? -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
Wiki Spam
Until someone has the time to upgrade the Wiki to a newer version with anti-spam features could we at least block any commits which don't have comments? Just that none of the spam commits ever have comments, plus it would make tracking changes easier. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
[PATCH] DRM: /proc/interrupt entry is NULL
A minor issue which has been bugging me for a while is the radeon kernel module is not setting the dev-devname for display in /proc/interrupts (under Linux). Instead NULL is shown. The dev-devname being passed to request_irq in drm_irq.h is null. With the old DRM interface, the devname was set in DRM(setunique), but with the current DRM interface =1.1 the devname is not being set in DRM(set_busid). Attached is patch to fix. -- Alan. One must never be purposelessnessnesslessness. --- drm/linux/drm_ioctl.h 2003-11-05 08:13:52.0 + +++ drm/linux/drm_ioctl.h 2004-06-06 17:08:48.127284384 +0100 @@ -143,6 +143,13 @@ snprintf(dev-unique, dev-unique_len, pci:%04x:%02x:%02x.%d, dev-pci_domain, dev-pci_bus, dev-pci_slot, dev-pci_func); + dev-devname = DRM(alloc)(strlen(dev-name) + dev-unique_len + 2, + DRM_MEM_DRIVER); + if (dev-devname == NULL) + return ENOMEM; + + sprintf(dev-devname, [EMAIL PROTECTED], dev-name, dev-unique); + return 0; } signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Status of XFree86 4.4.0 integration?
On Mon, 2004-03-01 at 13:37, Dieter Nützel wrote: Someone preparing a merge? To which release? The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo and most other distributions are not touching with a barge pole? Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Status of XFree86 4.4.0 integration?
On Mon, 2004-03-01 at 14:34, Adam K Kirchhoff wrote: On Mon, 1 Mar 2004, Alan Swanson wrote: The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo and most other distributions are not touching with a barge pole? The client libraries are still distributed under the old license, so there is no problem linking GPLed libraries or apps to the 4.4 libraries. Which means there is no longer a reason for those distributions not to include 4.4 any more. Unless there has been a new development, they're still not touching it. The DRI list has been free of any flame bait regarding X licensing, but I'm concerned with what happened and what multitude of projects/forks the DRI may have to support. Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? And, as I understand it, is so significantly different from the XFree86 codebase to make a merge rather, shall we say, pointless? I wasn't referring to the X Server project. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] R9200SE Slowness
On Sat, 2004-02-21 at 09:54, Chris Ison wrote: ok, let me get this in perspective R9200R8500 DRI14.62103716.860273 fglrx39.46159444.228085 I have been trying to hunt down the slowdown in DRI, I even if (0)'s all occurances of sched_yield () which is slower in 2.6 than 2.4 due to 2.6 doing it properly. [SNIP] Thats as far as I've gotten so far. Is there anything else I should be looking at? I believe the patch in this mail still needs to be done to remove the excessive flushing in the R200 driver; http://marc.theaimsgroup.com/?l=dri-develm=106668758605732w=2 This was originally changed by discussions from this thread; http://marc.theaimsgroup.com/?l=dri-develm=105248982530908w=2 Which resulted in this patch which added the extra flushing; http://marc.theaimsgroup.com/?l=dri-develm=105907354428969w=2 Someone else last chased this up in November or December? -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Radeon TMU3, R200 and Mesa-templates TMU6 patch
On Fri, 2004-01-02 at 23:30, Andreas Stenglein wrote: here is what I fiddled together to support the 3rd TMU on radeon and 6TMUs on r200. I tried on R200 with multiarb.c and projtex.c and it works almost as it should. (projtex is broken somehow on r200, even with only 2 TMUs) ut2003_demo works a bit but then hangs the card (R200), sadly. It did work longer on radeon (R100) last time I checked. Possibly needs the Texture cache LRU hang workaround for the extra texture units at the end of r200_texstate.c ? Not sure about the T0 hang workaround though. -- Alan. One must never be purposelessnessnesslessness. signature.asc Description: This is a digitally signed message part
