Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
On Friday 21 August 2009, Larry Finger wrote: > Rafael J. Wysocki wrote: > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13960 > > Subject : rtl8187 not connect to wifi > > Submitter : okias > > Date: 2009-08-10 19:16 (10 days old) > > The patch for this one was sent from Linville to DaveM earlier today, > and should be sent to mainline in the near future. > > AFAIK, the OP has not yet tested the patch, but I think I was able to > reproduce the problem, and the patch did fit it for me. Thanks for the update. Can you please close the bug when the patch is merged? Rafael -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Partial updates with glX/DRI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michel Dänzer wrote: > On Fri, 2009-08-21 at 11:45 +0200, Tom Cooksey wrote: >> When using glX, we have no guarantee over what state the back buffer will be >> in >> after swap buffers. So, whenever an application needs to update, it must re- >> render the entire window. This makes things slow (we have to invoke every >> child widget's paint event). To overcome this, we try to use a 3rd buffer as >> a >> back buffer, usually a multi-sampled FBO or PBuffer. We direct rendering to >> the >> FBO/PBuffer, bind it as a texture (after blitting it to a non multi-sampled >> FBO >> if needed), draw the whole buffer to the window's back buffer then call swap >> buffers. Eughhh! But at least the PBuffer/FBO contents aren't destroyed. >> What >> would be really nice is to be able to have an EGL_SWAP_BEHAVIOR == >> EGL_BUFFER_PRESERVED equivalent on glX. > > There's the GLX_OML_swap_method extension, but I'm not sure how well > it's supported by our drivers at this point. Any issues there might not > be hard to fix up though. As far as I'm aware, all the drivers only expose visuals with GLX_SWAP_UNDEFINED_OML. I talked to some of the Blender guys at SIGGRAPH, and they have the same issue. Jesse and I are planning to do some work on this for the Intel drivers pretty soon. Once that gets done it should be pretty easy to migrate the code to other DRI2 based drivers. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqO6E8ACgkQX1gOwKyEAw+K+wCfVl2/cIemJUUkREyDM9wgCTI3 CuEAoIHjq+SYWKIAhAoHw8aYUqpOfFdc =eGlw -END PGP SIGNATURE- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13713] [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
http://bugzilla.kernel.org/show_bug.cgi?id=13713 --- Comment #13 from Michel Dänzer 2009-08-21 16:38:39 --- FWIW, I followed up with some other possible solutions. It actually seems best overall to handle this in the X driver rather than in the Mesa driver. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Partial updates with glX/DRI
On Fri, 2009-08-21 at 11:45 +0200, Tom Cooksey wrote: > > When using glX, we have no guarantee over what state the back buffer will be > in > after swap buffers. So, whenever an application needs to update, it must re- > render the entire window. This makes things slow (we have to invoke every > child widget's paint event). To overcome this, we try to use a 3rd buffer as > a > back buffer, usually a multi-sampled FBO or PBuffer. We direct rendering to > the > FBO/PBuffer, bind it as a texture (after blitting it to a non multi-sampled > FBO > if needed), draw the whole buffer to the window's back buffer then call swap > buffers. Eughhh! But at least the PBuffer/FBO contents aren't destroyed. What > would be really nice is to be able to have an EGL_SWAP_BEHAVIOR == > EGL_BUFFER_PRESERVED equivalent on glX. There's the GLX_OML_swap_method extension, but I'm not sure how well it's supported by our drivers at this point. Any issues there might not be hard to fix up though. > I think I can work around this by making a glx context current on a GLXPixamp > (from a XPixmap). Pixmaps are single buffered and so don't get destroyed on > swap buffers (in fact I don't even call swap buffers). I can then post > updates > using XCopyArea which will also cause the Xserver to generate an appropriate > XDamage region for the compositor. The only down side is that I have to > glFinish before calling XCopyArea. Actually you should only need glXWaitGL(), assuming the implementation of that meets the requirements of the GLX spec. > While I have this working, it seems a little hacky and isn't widely > supported (I have it working on 1 driver build for 1 bit of hardware). If you mean rendering to pixmaps isn't widely supported, that should be getting better with DRI2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Partial updates with glX/DRI
Roland Scheidegger wrote: > On 21.08.2009 11:45, Tom Cooksey wrote: >> Hello, >> >> I'm a Qt developer. >> >> We want all Qt rendering to be done using OpenGL 2. We have this working >> pretty well (a few artifacts still here and there). However, we've found >> some >> fundamental problems using GL for regular widget rendering. Normally I >> wouldn't bother this list, but I've recently seen that someone's writing a >> new >> GL back end to Cairo, so I guess those guys are going to hit the exact same >> issues. >> >> The problem is partial updates. From what we've seen it's typical for >> applications to only update a small region of their top-level-widget at a >> time >> (E.g. a flashing cursor in a text edit). As Qt only creates a single X >> window >> per top-level widget, this means a sub-region of a single X window. >> >> When using glX, we have no guarantee over what state the back buffer will be >> in >> after swap buffers. So, whenever an application needs to update, it must re- >> render the entire window. This makes things slow (we have to invoke every >> child widget's paint event). To overcome this, we try to use a 3rd buffer as >> a >> back buffer, usually a multi-sampled FBO or PBuffer. We direct rendering to >> the >> FBO/PBuffer, bind it as a texture (after blitting it to a non multi-sampled >> FBO >> if needed), draw the whole buffer to the window's back buffer then call swap >> buffers. Eughhh! But at least the PBuffer/FBO contents aren't destroyed. >> What >> would be really nice is to be able to have an EGL_SWAP_BEHAVIOR == >> EGL_BUFFER_PRESERVED equivalent on glX. I notice there's an EGL >> implementation >> being worked on in Mesa trunk so perhaps we should switch to EGL rather than >> glX? >> >> Anyway, lets assume that swap buffers keeps the contents of the back buffer. >> There's another issue, although not as detrimental as the first. When we >> issue >> swap buffers, glX/EGL has to assume the entire window's contents has >> changed. >> That has 2 effects: 1) XDamage regions are generated for the whole window: >> When >> a composition manager is running, this means it has to re-compose the entire >> window, even though only a few pixels may have changed (which it might have >> to >> do anyway, see above :-)). 2) I'm led to believe that DRI2 implements swap >> buffers as a blit and so must blit the entire back buffer to the front. >> >> I think I can work around this by making a glx context current on a >> GLXPixamp >> (from a XPixmap). Pixmaps are single buffered and so don't get destroyed on >> swap buffers (in fact I don't even call swap buffers). I can then post >> updates >> using XCopyArea which will also cause the Xserver to generate an appropriate >> XDamage region for the compositor. The only down side is that I have to >> glFinish before calling XCopyArea. While I have this working, it seems a >> little hacky and isn't widely supported (I have it working on 1 driver build >> for 1 bit of hardware). >> >> It seems like a glXSwapPartialBuffers which takes an array of dirty rects >> would >> be preferable. The implementation could ignore the rects completely if it so >> chooses or only use them to generate the damage region. Or, if it's on DRI2, >> it can choose to only copy the sub-region from the back to the front. >> Eventually it could also use the rects as a metric to figure out if it >> should >> flip or blit (flip if there's >30% region changed, blit otherwise). >> > > Would glx_mesa_copy_sub_buffer help? It only takes one rect though, not > a list. BTW, a region of the back buffer can be copied to the front buffer with glCopyPixels() or glBlitFramebuffer() too. -Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] drm/crtc_helper: replace modeset fail path with something simpler
@Dave: any word yet? On Wed, Aug 19, 2009 at 4:43 PM, Maarten Maathuis wrote: > No complaints with this patch set? > > I just need plausible upstream-ability, when it happens is not a big > issue for me. > > Maarten. > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Partial updates with glX/DRI
On 21.08.2009 11:45, Tom Cooksey wrote: > Hello, > > I'm a Qt developer. > > We want all Qt rendering to be done using OpenGL 2. We have this working > pretty well (a few artifacts still here and there). However, we've found some > fundamental problems using GL for regular widget rendering. Normally I > wouldn't bother this list, but I've recently seen that someone's writing a > new > GL back end to Cairo, so I guess those guys are going to hit the exact same > issues. > > The problem is partial updates. From what we've seen it's typical for > applications to only update a small region of their top-level-widget at a > time > (E.g. a flashing cursor in a text edit). As Qt only creates a single X window > per top-level widget, this means a sub-region of a single X window. > > When using glX, we have no guarantee over what state the back buffer will be > in > after swap buffers. So, whenever an application needs to update, it must re- > render the entire window. This makes things slow (we have to invoke every > child widget's paint event). To overcome this, we try to use a 3rd buffer as > a > back buffer, usually a multi-sampled FBO or PBuffer. We direct rendering to > the > FBO/PBuffer, bind it as a texture (after blitting it to a non multi-sampled > FBO > if needed), draw the whole buffer to the window's back buffer then call swap > buffers. Eughhh! But at least the PBuffer/FBO contents aren't destroyed. What > would be really nice is to be able to have an EGL_SWAP_BEHAVIOR == > EGL_BUFFER_PRESERVED equivalent on glX. I notice there's an EGL > implementation > being worked on in Mesa trunk so perhaps we should switch to EGL rather than > glX? > > Anyway, lets assume that swap buffers keeps the contents of the back buffer. > There's another issue, although not as detrimental as the first. When we > issue > swap buffers, glX/EGL has to assume the entire window's contents has changed. > That has 2 effects: 1) XDamage regions are generated for the whole window: > When > a composition manager is running, this means it has to re-compose the entire > window, even though only a few pixels may have changed (which it might have > to > do anyway, see above :-)). 2) I'm led to believe that DRI2 implements swap > buffers as a blit and so must blit the entire back buffer to the front. > > I think I can work around this by making a glx context current on a GLXPixamp > (from a XPixmap). Pixmaps are single buffered and so don't get destroyed on > swap buffers (in fact I don't even call swap buffers). I can then post > updates > using XCopyArea which will also cause the Xserver to generate an appropriate > XDamage region for the compositor. The only down side is that I have to > glFinish before calling XCopyArea. While I have this working, it seems a > little hacky and isn't widely supported (I have it working on 1 driver build > for 1 bit of hardware). > > It seems like a glXSwapPartialBuffers which takes an array of dirty rects > would > be preferable. The implementation could ignore the rects completely if it so > chooses or only use them to generate the damage region. Or, if it's on DRI2, > it can choose to only copy the sub-region from the back to the front. > Eventually it could also use the rects as a metric to figure out if it should > flip or blit (flip if there's >30% region changed, blit otherwise). > Would glx_mesa_copy_sub_buffer help? It only takes one rect though, not a list. Roland -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23436] RV620 locks up on starting/quiting 3D app
http://bugs.freedesktop.org/show_bug.cgi?id=23436 --- Comment #2 from Rafał Miłecki 2009-08-21 04:54:35 PST --- I feel it's much harder to lock up my RV620 after adding 4 fprintf into radeon_common.c flushing function. Some race with EXA maybe? Also I remember similar problem with Xv when I was using mesa/drm's r6xx-r7xx-support branch. Sometimes starting video caused lock up. That was fixed in mainline (doesn't happen in 2.6.31-rcX anymore). I think the fixing commit was: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4247ca942a16745da3d09c58996b276d02655a72 Can this be the same issue, just about 3D this time? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23436] RV620 locks up on starting/quiting 3D app
http://bugs.freedesktop.org/show_bug.cgi?id=23436 --- Comment #1 from Rafał Miłecki 2009-08-21 04:36:59 PST --- One more lock up and I noticed my dmesg was full of: [drm] wait idle failed status : 0xA0003030 0x0003 [drm] wait idle failed status : 0xA0003030 0x0003 [drm] wait idle failed status : 0xA0003030 0x0003 this time. It was when using original mesa r600 driver with 4 additional fprintf, but I don't think this could cause that messages, right? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23437] New: [regression Glean]glean case pbo fails
http://bugs.freedesktop.org/show_bug.cgi?id=23437 Summary: [regression Glean]glean case pbo fails Product: Mesa Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: xunx.f...@intel.com System Environment: -- Host: x-945gm Arch: i386 Platform:945GM Libdrm: (master)cbb3ae3dab9dc82d95524726135b8d6ef86bcf27 Mesa: (master)525ddb1f56aceee74a08764315dc6420f198ccc2 Xserver:(master)eb031d4013d36f6aef4aba45840762ae8635cc13 Xf86_video_intel: (master)465a4ab416b2e5ad53b96702720331a44fffa2fe Kernel: (drm-intel-next)819e0064634f580ab618189e657ea58341d214b7 Bug detailed description: - glean case pbo fails with recent driver. Reproduce steps: 1. xinit& 2. run glean case/pbo -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23436] New: RV620 locks up on starting/quiting 3D app
http://bugs.freedesktop.org/show_bug.cgi?id=23436 Summary: RV620 locks up on starting/quiting 3D app Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: zaj...@gmail.com I use Mesa master git and agd5f's r6xx-r7xx-3d git. IIRC I didn't experience any lock up while running 3D app. However it happens often while starting (first frame) or quiting. It's hard to reproduce with glxgears (last 20 tries of start&quit didn't hit bug) but really easy to reproduce with morph3d. Starting&quiting morph3d about 3-5 times is usually enought to lock up. When machine locks up I can ssh to it or use SysRq. dmesg | tail doesn't show anything drm related, but I didn't use debug param when modprobing drm. When I try debug=15 every lock up is hard one and I can not ssh to machine nor SysRq anymore. Based on 3 cases, last line of /var/log/Xorg.0.log seems to be: exaCopyDirty: Pending damage region empty! One idea I've got on IRC was: zajec: Sounds like possible gpu hang so best info would be what did the latest cmdbuf include but don't know how to get that cmdbuf. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Partial updates with glX/DRI
Hello, I'm a Qt developer. We want all Qt rendering to be done using OpenGL 2. We have this working pretty well (a few artifacts still here and there). However, we've found some fundamental problems using GL for regular widget rendering. Normally I wouldn't bother this list, but I've recently seen that someone's writing a new GL back end to Cairo, so I guess those guys are going to hit the exact same issues. The problem is partial updates. From what we've seen it's typical for applications to only update a small region of their top-level-widget at a time (E.g. a flashing cursor in a text edit). As Qt only creates a single X window per top-level widget, this means a sub-region of a single X window. When using glX, we have no guarantee over what state the back buffer will be in after swap buffers. So, whenever an application needs to update, it must re- render the entire window. This makes things slow (we have to invoke every child widget's paint event). To overcome this, we try to use a 3rd buffer as a back buffer, usually a multi-sampled FBO or PBuffer. We direct rendering to the FBO/PBuffer, bind it as a texture (after blitting it to a non multi-sampled FBO if needed), draw the whole buffer to the window's back buffer then call swap buffers. Eughhh! But at least the PBuffer/FBO contents aren't destroyed. What would be really nice is to be able to have an EGL_SWAP_BEHAVIOR == EGL_BUFFER_PRESERVED equivalent on glX. I notice there's an EGL implementation being worked on in Mesa trunk so perhaps we should switch to EGL rather than glX? Anyway, lets assume that swap buffers keeps the contents of the back buffer. There's another issue, although not as detrimental as the first. When we issue swap buffers, glX/EGL has to assume the entire window's contents has changed. That has 2 effects: 1) XDamage regions are generated for the whole window: When a composition manager is running, this means it has to re-compose the entire window, even though only a few pixels may have changed (which it might have to do anyway, see above :-)). 2) I'm led to believe that DRI2 implements swap buffers as a blit and so must blit the entire back buffer to the front. I think I can work around this by making a glx context current on a GLXPixamp (from a XPixmap). Pixmaps are single buffered and so don't get destroyed on swap buffers (in fact I don't even call swap buffers). I can then post updates using XCopyArea which will also cause the Xserver to generate an appropriate XDamage region for the compositor. The only down side is that I have to glFinish before calling XCopyArea. While I have this working, it seems a little hacky and isn't widely supported (I have it working on 1 driver build for 1 bit of hardware). It seems like a glXSwapPartialBuffers which takes an array of dirty rects would be preferable. The implementation could ignore the rects completely if it so chooses or only use them to generate the damage region. Or, if it's on DRI2, it can choose to only copy the sub-region from the back to the front. Eventually it could also use the rects as a metric to figure out if it should flip or blit (flip if there's >30% region changed, blit otherwise). Cheers, Tom PS: Scrolling is also an issue... :-/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/mm: add ability to dump mm lists via debugfs (v2)
Dave Airlie wrote:
> 2009/8/21 Thomas Hellström :
>
>> Dave Airlie wrote:
>>
>>> From: Dave Airlie
>>>
>>> This adds code to the drm_mm to talk to debugfs, and adds
>>> support to radeon to add the VRAM and GTT mm lists to debugfs.
>>>
>>> changes since v1:
>>> don't bother with free list just add used/free to main list
>>> add totals in pages
>>>
>>> Signed-off-by: Dave Airlie
>>> ---
>>> drivers/gpu/drm/drm_mm.c| 25 ++
>>> drivers/gpu/drm/radeon/radeon_ttm.c | 39
>>> +++
>>> include/drm/drm_mm.h|4 +++
>>> 3 files changed, 68 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>>> index 3e47869..a454e55 100644
>>> --- a/drivers/gpu/drm/drm_mm.c
>>> +++ b/drivers/gpu/drm/drm_mm.c
>>> @@ -44,6 +44,7 @@
>>> #include "drmP.h"
>>> #include "drm_mm.h"
>>> #include
>>> +#include
>>> #define MM_UNUSED_TARGET 4
>>> @@ -370,3 +371,27 @@ void drm_mm_takedown(struct drm_mm * mm)
>>>BUG_ON(mm->num_unused != 0);
>>> }
>>> EXPORT_SYMBOL(drm_mm_takedown);
>>> +
>>> +#if defined(CONFIG_DEBUG_FS)
>>> +int drm_mm_dump_table(struct seq_file *m, void *data)
>>> +{
>>> + struct drm_info_node *node = (struct drm_info_node *)m->private;
>>> + struct drm_mm *mm = (struct drm_mm *)node->info_ent->data;
>>> + struct drm_mm_node *entry;
>>> + int total_used = 0, total_free = 0, total = 0;
>>> + spin_lock(&mm->unused_lock);
>>>
>>>
>> This is not correct. The mm::unused_lock is there only to protect the list
>> of cached drm_mm_node allocations that we
>> use instead of kmalloc() when atomic.
>>
>> Instead the lock the user uses to protect the mm:s must be taken. In the TTM
>> case IIRC its the bo_glob::lru_lock.
>>
>> Is it safe to use seq_printf() from within a spinlocked region?
>>
>>
>
> Good point, this was one of those quick hacks to have a look at fragmentation
> so I sorta guessed at the lock,
>
> I'd probably be best not locking anything, but I'll try and add a
> driver layer before
> drm_mm to do the correct locking, though as its debugging info even
> inconsistent
> is better than none.
>
Yes, but you might end up traversing the list in the middle of a list
pointer modification, which is bad.
> I'll fix it up next week and send v3, thanks again.
> Dave.
>
/Thomas
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/mm: add ability to dump mm lists via debugfs (v2)
2009/8/21 Thomas Hellström :
> Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> This adds code to the drm_mm to talk to debugfs, and adds
>> support to radeon to add the VRAM and GTT mm lists to debugfs.
>>
>> changes since v1:
>> don't bother with free list just add used/free to main list
>> add totals in pages
>>
>> Signed-off-by: Dave Airlie
>> ---
>> drivers/gpu/drm/drm_mm.c | 25 ++
>> drivers/gpu/drm/radeon/radeon_ttm.c | 39
>> +++
>> include/drm/drm_mm.h | 4 +++
>> 3 files changed, 68 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>> index 3e47869..a454e55 100644
>> --- a/drivers/gpu/drm/drm_mm.c
>> +++ b/drivers/gpu/drm/drm_mm.c
>> @@ -44,6 +44,7 @@
>> #include "drmP.h"
>> #include "drm_mm.h"
>> #include
>> +#include
>> #define MM_UNUSED_TARGET 4
>> @@ -370,3 +371,27 @@ void drm_mm_takedown(struct drm_mm * mm)
>> BUG_ON(mm->num_unused != 0);
>> }
>> EXPORT_SYMBOL(drm_mm_takedown);
>> +
>> +#if defined(CONFIG_DEBUG_FS)
>> +int drm_mm_dump_table(struct seq_file *m, void *data)
>> +{
>> + struct drm_info_node *node = (struct drm_info_node *)m->private;
>> + struct drm_mm *mm = (struct drm_mm *)node->info_ent->data;
>> + struct drm_mm_node *entry;
>> + int total_used = 0, total_free = 0, total = 0;
>> + spin_lock(&mm->unused_lock);
>>
>
> This is not correct. The mm::unused_lock is there only to protect the list
> of cached drm_mm_node allocations that we
> use instead of kmalloc() when atomic.
>
> Instead the lock the user uses to protect the mm:s must be taken. In the TTM
> case IIRC its the bo_glob::lru_lock.
>
> Is it safe to use seq_printf() from within a spinlocked region?
>
Good point, this was one of those quick hacks to have a look at fragmentation
so I sorta guessed at the lock,
I'd probably be best not locking anything, but I'll try and add a
driver layer before
drm_mm to do the correct locking, though as its debugging info even inconsistent
is better than none.
I'll fix it up next week and send v3, thanks again.
Dave.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms/radeon: Add kconfig to specify the default modesetting
At Fri, 21 Aug 2009 10:52:13 +1000, Dave Airlie wrote: > > On Thu, Aug 20, 2009 at 11:26 PM, Takashi Iwai wrote: > > This patch adds a Kconfig item to specify the default radeon modeset > > value. Also fixed the description of CONFIG_DRM_RADEON_KMS. > > > > Since KMS gives problems on some Radeon devices, it's safer to disable > > it as default on distro kernels. But distros would love to include the > > feature itself instead of disabling KMS completely. > > > > Reference: Novell bnc#527910 > > https://bugzilla.novell.com/show_bug.cgi?id=527910 > > I'm sort of torn on this, when radeon KMS moves out of staging it will > be disabled by > default using the current option. It will build everything always and > disable/enable like this patch > does. I'm not willing to do that yet esp now in -rcX time as it might > break builds > on some other arches. Yeah, it's a bit late for this kind of change; I share your concern, too. > So if a distro isn't shipping a compatible userspace, I'd rather they > didn't ship > the kernel support built at all until we move it from staging. > > AFAIK you guys don't use -ati on a lot of cards kms is useful so I'm > not sure when you'll > ever have a compatible userspace. Well, a lack of dynamic switch -- or inconsistent behavior (i915 is built with KMS but not enabled as default) is the problem right now. We can live without radeon KMS, but it would be nice if we can still provide the functionality in any form... thanks, Takashi -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
