[git pull] drm merge
Hi Linus, The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains a few patches outside the DRM/AGP trees, (a) Initial hybrid graphics support in drivers/gpu/vga/ - called the vga_switcheroo this is for dual-gpu laptops with a multiplexer on the outputs to swap LVDS/VGA between the two GPUs and the ability to powerdown the discrete GPU. This implements the ATI variant and starts the groundwork for the nvidia variant. It touches fb code also to add a call to move all consoles to the other fb device. (b) minor fb patch to fix an offb handover issue. Major drm highlights: core: switch to unlocked ioctls for KMS ioctls radeon-non-kms: fix ability to trash memory on r100/r200 fix problem trying to dynamically allocate 64k buffers at runtime radeon: AMD evergreen (R5xxx) modesetting support - no accel yet, unlocked KMS ioctls hw i2c engine support initial dynamic power management support r600 command stream checker + fixes. intel: Sandybridge GPU support unlocked KMS ioctls nouveau: new API - breaks userspace compatiblity - must upgrade libdrm_nouveau nv50 context program generator - gets rid of reliance on nvidia firmware *NOTE* in case you missed it: this will *break* your nvidia machine, its purely intentional. Rawhide should have the libdrm and driver updates necessary. Dave. Alex Deucher (33): drm/radeon/kms: add radeon i2c algo drm/radeon/kms: add support for hw i2c on r1xx-r5xx drm/radeon/kms: add workaround for rn50/rv100 servers drm/radeon/kms: add support for hardcoded edids in rom (v2) drm/radeon/kms: clean up some low-hanging magic numbers drm/radeon/kms: rework pll algo selection drm/radeon/kms: add pll quirk for toshiba laptop panel drm/radeon/kms/atom: clean up spread spectrum code drm/radeon/kms/atom: add a helper function to get the radeon connector priv drm/radeon/kms/r600: reduce gpu cache flushing drm/radeon/kms: consolidate crtc count in rdev drm/radeon/kms: add functions to get current pcie lanes drm/radeon/kms: pull power mode info from bios tables (v3) drm/radeon/kms: add a power state type based on power state flags drm/radeon/kms: add code to select power state drm/radeon/kms: use power states for dynamic reclocking drm/radeon/kms: dynclks fixes drm/radeon/kms: take the pm mutex when using hw i2c drm/radeon/kms: update atombios.h to latest upstream. drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx) drm/radeon/kms: fix prescale calculations drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE drm/radeon/kms/evergreen: fix multi-head drm/radeon/kms/evergreen: adapt to i2c changes drm/radeon/r600: fix warnings in CS checker drm/radeon/kms: add LVDS pll quirk for Dell Studio 15 drm/radeon/kms: remove HDP flushes from fence emit (v2) drm/radeon/kms: remove unused r600_gart_clear_page drm/radeon/rv740: fix backend setup drm/radeon: fixes for r6xx/r7xx gfx init drm/radeon/kms/evergreen: fix typo in cursor code drm/radeon/kms: update new pll algo drm/radeon/kms/atom: fix shr/shl ops Andy Shevchenko (1): drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi() Ben Skeggs (17): drm/nv50: switch to indirect push buffer controls drm/nouveau: remove PUSHBUF_CAL macro drm/nv50: make pushbuf dma object cover entire vm drm/nouveau: new gem pushbuf interface, bump to 0.0.16 drm/nouveau: allow retrieval of vbios image from debugfs drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table drm/nouveau: merge nvbios and nouveau_bios_info drm/nouveau: reorganise bios header, add dcb connector type enums drm/nouveau: parse dcb gpio/connector tables after encoders drm/nouveau: check for known dcb connector types drm/nouveau: construct a connector table for cards that lack a real one drm/nouveau: use dcb connector table for creating drm connectors drm/nv50: enable hpd on any connector we know the gpio line for drm/nouveau: use dcb connector types throughout the driver drm/nouveau: support version 0x20 displayport tables drm/nouveau: report unknown connector state if lid closed Chris Wilson (2): drm/i915: Replace open-coded eviction in i915_gem_idle() drm/i915: Record batch buffer following GPU error Daniel Vetter (11): drm/i915: overlay: nuke readback to flush wc caches drm/i915: overlay: drop superflous gpu flushes drm/i915: move a gtt flush to the correct place drm/i915: blow away
Re: [PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection
On Mon, Mar 1, 2010 at 2:47 AM, Jerome Glisse wrote: > On Sun, Feb 28, 2010 at 12:22:52PM +, Alan Swanson wrote: >> 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 run only when userspace call bo wait thus it only happen when userspace > is waiting for something. Why not just test when the old timeout code used to test? every second or so? I'm not sure why with the old code instead of assuming a fence timeout implied a lockup you didn't just change it to test if it was a real lockup and continue waiting if the GPU was making progress. This seems simpler, though maybe the cleanups are worth it. Dave. -- Download Intel® 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: Convert DRM_INFO/DRM_ERROR to dev_info/dev_err
On Fri, Feb 26, 2010 at 4:56 AM, Jerome Glisse wrote: > Attached is conversion from DRM_INFO/DRM_ERROR to dev_info/dev_err > to apply it copy all doconv* file into the radeon subfolder of the > kernel run ./doconv.sh and then apply the 0001 patch which fix > compilation after conversion (place where struct radeon_device is > missing) then thing should compile > > I think it's worthwhile cleanup especialy on multi GPU configuration. Does this not remove the drm log levels? so we end up with everything in dmesg the whole time? that seems wrong, I'd rather pass a dev to DRM_ERROR/DRM_INFO or maybe defined DRM_DEV_ERROR, DRM_DEV_INFO. Dave. -- Download Intel® 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: Unmappable VRAM patchset V4
On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse wrote: > Updated patchset, to apply cleanly on top of TTM split no_wait argument. > Compile tested for nouveau+vmwgfx, test in progress for radeon. > > So with the new change radeon won't wait for bo reserving other bo > in fault path but will wait the GPU (hoping it doesn't lockup ;)) > This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. -- Download Intel® 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
[Bug 26809] KMS/R200: Bad shading in NWN since Mesa rewrite
http://bugs.freedesktop.org/show_bug.cgi?id=26809 --- Comment #1 from Alan Swanson 2010-02-28 14:21:47 PST --- Created an attachment (id=33656) --> (http://bugs.freedesktop.org/attachment.cgi?id=33656) r200-nwn-indoor.jpg Bit harder to see as shading is more coloured in this scene but R200 still has flickering on floor tiles. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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
[Bug 26809] New: KMS/R200: Bad shading in NWN since Mesa rewrite
http://bugs.freedesktop.org/show_bug.cgi?id=26809 Summary: KMS/R200: Bad shading in NWN since Mesa rewrite Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: swan...@ukfsn.org Created an attachment (id=33655) --> (http://bugs.freedesktop.org/attachment.cgi?id=33655) r200-nwn-plaza.jpg Neverwinter Nights with KMS has rendering problems possibly related to other R200 KMS shading issues reported while before the Radeon rewrite was merged, Mesa 7.5.2 is fine. On rv250; characters are almost black except when highlighted with a mouse over, general scenery appears darker than old reference whilst objects flip to black as a scene view is rotated. On R200; characters are very dark but do have some shading compared to rv250, general scenery tends to flicker madly inverting shading on each tile and even borders of interface flicker. Note though that am using patch from bug 25544 to disable texture checking to allow R200 to run but don't think it should be relevant. (UMS on both tends to die quickly for other reasons but concentrating on KMS as the future.) Attached are comparative screenshots of two scenes with current Mesa git, libdrm 2.4.18 and Linux 2.6.33. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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
[RFC] drm/ttm: add pool wc/uc page allocator
On AGP system we might allocate/free routinely uncached or wc memory, changing page from cached (wb) to uc or wc is very expensive and involves a lot of flushing. To improve performance this allocator use a pool of uc,wc pages. Pools are linked lists of pages. Ordered so that first is the latest adition to the pool and last is the oldest page. Old pages are periodicaly freed from pools to keep memory use at minimum. Pools are protected with spinlocks to allow multiple threads to allocate pages simultanously. Expensive operations must not hold the spinlock to maximise performance for multiple threads. Based on Jerome Glisse's and Dave Airlie's pool allocator. Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Pauli Nieminen --- drivers/gpu/drm/ttm/Makefile |2 +- drivers/gpu/drm/ttm/ttm_memory.c |5 +- drivers/gpu/drm/ttm/ttm_page_alloc.c | 514 ++ drivers/gpu/drm/ttm/ttm_page_alloc.h | 38 +++ drivers/gpu/drm/ttm/ttm_tt.c | 47 ++-- 5 files changed, 580 insertions(+), 26 deletions(-) create mode 100644 drivers/gpu/drm/ttm/ttm_page_alloc.c create mode 100644 drivers/gpu/drm/ttm/ttm_page_alloc.h diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile index 1e138f5..4256e20 100644 --- a/drivers/gpu/drm/ttm/Makefile +++ b/drivers/gpu/drm/ttm/Makefile @@ -4,6 +4,6 @@ ccflags-y := -Iinclude/drm ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \ ttm_bo_util.o ttm_bo_vm.o ttm_module.o ttm_global.o \ - ttm_object.o ttm_lock.o ttm_execbuf_util.o + ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o obj-$(CONFIG_DRM_TTM) += ttm.o diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c index f5245c0..d587fbe 100644 --- a/drivers/gpu/drm/ttm/ttm_memory.c +++ b/drivers/gpu/drm/ttm/ttm_memory.c @@ -32,6 +32,7 @@ #include #include #include +#include "ttm_page_alloc.h" #define TTM_MEMORY_ALLOC_RETRIES 4 @@ -394,6 +395,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob) "Zone %7s: Available graphics memory: %llu kiB.\n", zone->name, (unsigned long long) zone->max_mem >> 10); } + ttm_page_alloc_init(); return 0; out_no_zone: ttm_mem_global_release(glob); @@ -413,9 +415,10 @@ void ttm_mem_global_release(struct ttm_mem_global *glob) zone = glob->zones[i]; kobject_del(&zone->kobj); kobject_put(&zone->kobj); - } + } kobject_del(&glob->kobj); kobject_put(&glob->kobj); + ttm_page_alloc_fini(); } EXPORT_SYMBOL(ttm_mem_global_release); diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c new file mode 100644 index 000..de6576c --- /dev/null +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -0,0 +1,514 @@ +/* + * Copyright (c) Red Hat Inc. + + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sub license, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the + * next paragraph) shall be included in all copies or substantial portions + * of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Authors: Dave Airlie + * Jerome Glisse + * Pauli Nienmien + */ + +/* simple list based uncached page pool + * - Pool collects resently freed pages for reuse + * - Use page->lru to keep a free list + * - doesn't track currently in use pages + */ +#include +#include +#include +#include +#include +#include + +#include +#include "ttm/ttm_bo_driver.h" +#include "ttm_page_alloc.h" + +/* Number of 4k pages to add at once */ +#define NUM_PAGES_TO_ADD 64 +/* times are in msecs */ +#define TIME_TO_KEEP_PAGE_IN_POOL 15000 +#define PAGE_FREE_INTERVAL 1000 + +/** + * list is a FILO stack. + * All pages pushed into it must go to begin while end of list must hold the + * least recently used pages. When pages in end of the list are not recently + * use they are freed. + * + * All expensive operations must be done outside of pool lock to
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #32 from Anonymous Emailer 2010-02-28 19:50:01 --- Reply-To: andy...@ukfsn.org bugzilla-dae...@bugzilla.kernel.org wrote: > --- Comment #30 from Rafał Miłecki 2010-02-28 19:01:21 --- > > That's weird because we don't have problems with YouTube. It's about Vimeo. Most youtube works for me, but some larger ones don't. I also see the effect of working/not working depending on uts with the kbluetooth vid above using seamonkey 2.02. But I fear you may be correct and despite comment #24 I am seeing a separate issue and am derailing this bug, I will file a new one - I can now recreate my problem without flash. > (In reply to comment #26) >> Reply-To: andy...@ukfsn.org >> >> To possibly answer my own question for my case - AGP cards have accel >> UTS/DFS disabled in UMS. > > I use PCI-E card and I believe it has acceleration in both: UMS and KMS... Yea, it would be interesting to know if mplayer -vo x11 Cpu usage is much different between the two for you. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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 15293] Flash video laggy inside Firefox only with KMS
bugzilla-dae...@bugzilla.kernel.org wrote: > --- Comment #30 from Rafał Miłecki 2010-02-28 19:01:21 --- > > That's weird because we don't have problems with YouTube. It's about Vimeo. Most youtube works for me, but some larger ones don't. I also see the effect of working/not working depending on uts with the kbluetooth vid above using seamonkey 2.02. But I fear you may be correct and despite comment #24 I am seeing a separate issue and am derailing this bug, I will file a new one - I can now recreate my problem without flash. > (In reply to comment #26) >> Reply-To: andy...@ukfsn.org >> >> To possibly answer my own question for my case - AGP cards have accel >> UTS/DFS disabled in UMS. > > I use PCI-E card and I believe it has acceleration in both: UMS and KMS... Yea, it would be interesting to know if mplayer -vo x11 Cpu usage is much different between the two for you. -- Download Intel® 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
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #31 from Pauli 2010-02-28 19:41:26 --- Why NOTOURBUG? Because Linux flash player is buggy. It is trying to do something that is never going to have good performance. Uploading data to VRAM and reading it back late is always going to be slow. Flash player knows that is is going to download back the video frames anyway soon so it shouldn't upload them. It is a lot faster to do everything in software than trying to do partial hardware acceleration. I agree that r600 driver is not doing everything perfectly for what flash wants to do. But the way flash tries to play the video is always going to take at least 3 times more hw resources than standard alone players would take. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #30 from Rafał Miłecki 2010-02-28 19:01:21 --- (In reply to comment #28) > Reply-To: andy...@ukfsn.org > > Andy Furniss wrote: > > Andy Furniss wrote: > > > >> Out of curiosity, why does it work OK with UMS? > > > > To possibly answer my own question for my case - AGP cards have accel > > UTS/DFS disabled in UMS. > > This does seem to be the case, if I enable uts/dfs in UMS (with > BusTypePCIE) I run out of CPU while playing a youtube vid. That's weird because we don't have problems with YouTube. It's about Vimeo. (In reply to comment #26) > Reply-To: andy...@ukfsn.org > > To possibly answer my own question for my case - AGP cards have accel > UTS/DFS disabled in UMS. I use PCI-E card and I believe it has acceleration in both: UMS and KMS... -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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
[Bug 24340] BUG: unable to handle kernel NULL pointer dereference, radeon_object_list_unreserve+0x13/0x34
http://bugs.freedesktop.org/show_bug.cgi?id=24340 --- Comment #3 from Tieum 2010-02-28 09:06:52 PST --- Created an attachment (id=33644) --> (http://bugs.freedesktop.org/attachment.cgi?id=33644) Log for when a similar issue happened -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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
[Bug 24340] BUG: unable to handle kernel NULL pointer dereference, radeon_object_list_unreserve+0x13/0x34
http://bugs.freedesktop.org/show_bug.cgi?id=24340 --- Comment #2 from Tieum 2010-02-28 09:05:06 PST --- I have had my machine completely freezing with the same sort of message showing up in the logs. Attached is an example of it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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: [PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection
On Sun, Feb 28, 2010 at 12:22:52PM +, Alan Swanson wrote: > 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 run only when userspace call bo wait thus it only happen when userspace is waiting for something. Cheers, Jerome -- Download Intel® 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
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #29 from Michał Witkowski 2010-02-28 16:24:11 --- (In reply to comment #25) > I vote for NOTOURBUG too. > > Maybe ddx could be a bit better optimized for XGetSubImage that flash is using > but in end we can't get it perform well enough anyway without modifying the > blob. > > So what exactly is happening to slow down here: > > -Flash is playing the video to vram. > -Flash calls XGetSubImage multiple times per frame to read back the whole > video. > -XGetSubImage tries to copy data from VRAM to system memory but there seems to > be huge latency for CPU to read the data that was just written by GPU. > > Hack patch: http://www.youtube.com/watch?v=JLkGGNbBJeI ;) Right. And what about the problem with in-Firefox videos that don't use flash? I.e. comment #22? That also is miserably slow in KMS. Also, if this bug gets NOTOURBUGged it would mean that flash video will be terribly slow for all radeon KMS users, right? http://xkcd.com/619/ comes to mind ;) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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
[Bug 25544] KMS/R200: CS section size missmatch start at (r200_state_init.c,tex_emit_mm,703) 5 vs 9
http://bugs.freedesktop.org/show_bug.cgi?id=25544 --- Comment #6 from Alan Swanson 2010-02-28 08:01:51 PST --- Created an attachment (id=33643) --> (http://bugs.freedesktop.org/attachment.cgi?id=33643) drm_r200_disable_texture_check.patch Until R200 fake texture enable is supported by CS checker, R200 users can just disable texture checking with attached patch to actually have working 3D. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #28 from Anonymous Emailer 2010-02-28 15:57:51 --- Reply-To: andy...@ukfsn.org Andy Furniss wrote: > Andy Furniss wrote: > >> Out of curiosity, why does it work OK with UMS? > > To possibly answer my own question for my case - AGP cards have accel > UTS/DFS disabled in UMS. This does seem to be the case, if I enable uts/dfs in UMS (with BusTypePCIE) I run out of CPU while playing a youtube vid. One possibly interesting thing I found is that disabling dfs when using KMS has no effect - but Option "EXANoUploadToScreen" cures the problem. It still eats more CPU than UMS - but then so does xv and x11. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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 15293] Flash video laggy inside Firefox only with KMS
Andy Furniss wrote: > Andy Furniss wrote: > >> Out of curiosity, why does it work OK with UMS? > > To possibly answer my own question for my case - AGP cards have accel > UTS/DFS disabled in UMS. This does seem to be the case, if I enable uts/dfs in UMS (with BusTypePCIE) I run out of CPU while playing a youtube vid. One possibly interesting thing I found is that disabling dfs when using KMS has no effect - but Option "EXANoUploadToScreen" cures the problem. It still eats more CPU than UMS - but then so does xv and x11. -- Download Intel® 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: [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 -- Alan. "One must never be purposelessnessnesslessness." -- Download Intel® 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
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #27 from Anonymous Emailer 2010-02-28 13:59:04 --- Reply-To: andy...@ukfsn.org bugzilla-dae...@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15293 > > > > > > --- Comment #25 from Pauli 2010-02-27 06:39:33 --- > I vote for NOTOURBUG too. > > Maybe ddx could be a bit better optimized for XGetSubImage that flash is using > but in end we can't get it perform well enough anyway without modifying the > blob. > > So what exactly is happening to slow down here: > > -Flash is playing the video to vram. > -Flash calls XGetSubImage multiple times per frame to read back the whole > video. > -XGetSubImage tries to copy data from VRAM to system memory but there seems to > be huge latency for CPU to read the data that was just written by GPU. > > Hack patch: http://www.youtube.com/watch?v=JLkGGNbBJeI ;) > Out of curiosity, why does it work OK with UMS? I can't see people being too pleased when their distros switch to KMS and they the can't play some youtube vids that they could previously. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #26 from Anonymous Emailer 2010-02-28 12:52:24 --- Reply-To: andy...@ukfsn.org Andy Furniss wrote: > Out of curiosity, why does it work OK with UMS? To possibly answer my own question for my case - AGP cards have accel UTS/DFS disabled in UMS. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel® 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 15293] Flash video laggy inside Firefox only with KMS
Andy Furniss wrote: > Out of curiosity, why does it work OK with UMS? To possibly answer my own question for my case - AGP cards have accel UTS/DFS disabled in UMS. -- Download Intel® 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 15293] Flash video laggy inside Firefox only with KMS
bugzilla-dae...@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15293 > > > > > > --- Comment #25 from Pauli 2010-02-27 06:39:33 --- > I vote for NOTOURBUG too. > > Maybe ddx could be a bit better optimized for XGetSubImage that flash is using > but in end we can't get it perform well enough anyway without modifying the > blob. > > So what exactly is happening to slow down here: > > -Flash is playing the video to vram. > -Flash calls XGetSubImage multiple times per frame to read back the whole > video. > -XGetSubImage tries to copy data from VRAM to system memory but there seems to > be huge latency for CPU to read the data that was just written by GPU. > > Hack patch: http://www.youtube.com/watch?v=JLkGGNbBJeI ;) > Out of curiosity, why does it work OK with UMS? I can't see people being too pleased when their distros switch to KMS and they the can't play some youtube vids that they could previously. -- Download Intel® 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
