[Bug 27729] [r300g, mesa] gallium compressed texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=27729 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Fabio Pedretti 2010-05-19 00:40:21 PDT --- This appears to be fixed, the game is however still crashing later, see bug #28169. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] [RFC] fair-lru eviction
On Tue, 18 May 2010 23:11:42 +0200, Daniel Vetter wrote: > Hi all, > > This patch series implements the fair-lru eviction Chris Wilson already > posted with a twist. It's essentially the same idea & algorithm. > Differnences versus his patch: > - Doesn't do any allocations while scanning. > - Implemented in drm_mm.c > > In other words, this should also be usable by ttm. The idea is simple: > Scan through the lru, marking objects as evictable until there is a > large area of memory free/free-able. Then walk through all the scanned > objects in reverse, checking which ones fall into this hole. Finally > evicting them. > > Comments, ideas highly welcome. The next adaptation I did was to clean up evict_something to add objects from the inactive, active&&!pinned&&!write, flushing&&!pinned, active&&!pinned&&write lists. This reduces the logic in evict_something to a single scan over the available objects in LRU order. We still need the move-to-inactive-tail upon access by the CPU, and I think it is acceptable to maintain our preference of the GPU over the CPU. Recovering memory from the CPU is comparatively cheap. Comparing 'while :; do yes > /tmp/yes; done & cairo-perf-trace', there is no significant delta between the fair LRU and current. I'll rebase my evict_something() on top of your drm_mm, and rerun the tests. -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: kill drm_mm_node->private
On Tue, May 18, 2010 at 11:11:45PM +0200, Daniel Vetter wrote: > Only ever assigned, never used. > > Signed-off-by: Daniel Vetter NAK private was to be use when doing range restricted allocation somehow the patch that use it was drop/forgot/lost along the was i will try to see i have it and redo it if not. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 23122] mipmap_comp_tests will cause radeon_validate_texture error
https://bugs.freedesktop.org/show_bug.cgi?id=23122 --- Comment #3 from Andrew Randrianasulu 2010-05-19 03:29:43 PDT --- I can't see any error with mipmap_comp_tests on rv280 and mesa up to commit 4cd259ca59128ff2712c42ff2d2340b01a3b74a8 Author: Kristian Høgsberg Date: Tue May 18 14:45:10 2010 -0400 dri2_glx: Put the invalidate b/c code back in -- BUT I see somewhat strange image in this test .. let me open new bug . -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28173] New: mipmap_comp_tests show strange image, green bar at left side
https://bugs.freedesktop.org/show_bug.cgi?id=28173 Summary: mipmap_comp_tests show strange image, green bar at left side Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: rand...@mail.ru using mesa git master up to commit 4cd259ca59128ff2712c42ff2d2340b01a3b74a8 Author: Kristian Høgsberg Date: Tue May 18 14:45:10 2010 -0400 dri2_glx: Put the invalidate b/c code back in and up-to-date ddx/xserver master branches + drm-radeon-testing up to commit debb980f1a333f335ccc33c5a5102af038d59fed Merge: 26481fb e40152e Author: Dave Airlie Date: Wed May 19 06:30:36 2010 +1000 Merge tag 'v2.6.34' into drm-radeon-testing i see strange picture with mipmap_comp_tests, different from software rasterizer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28173] mipmap_comp_tests show strange image, green bar at left side
https://bugs.freedesktop.org/show_bug.cgi?id=28173 --- Comment #1 from Andrew Randrianasulu 2010-05-19 03:34:40 PDT --- Created an attachment (id=35756) --> (https://bugs.freedesktop.org/attachment.cgi?id=35756) screenshot showing bug -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info V2
On Mit, 2010-05-12 at 18:01 +0200, Jerome Glisse wrote: > Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm > crtc id. Bump the minor version so userspace can enable conditionaly > features depend on this. > > V2 use num_crtc and avoid DRM_ERROR > > Signed-off-by: Jerome Glisse Running compiz with this and the corresponding X changes kills my kernel rather quickly (a matter of minutes if not seconds), see below. [ 824.232844] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:192! [ 824.232864] Oops: Exception in kernel mode, sig: 5 [#1] [ 824.232876] PowerMac [ 824.232886] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 824.232898] Modules linked in: netconsole configfs cpufreq_stats sco bnep rfcomm l2cap binfmt_misc fuse ipv6 hfs therm_adt746x pmu_battery snd_aoa_codec_onyx snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm snd_page_alloc snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq ecb b43 mac80211 snd_timer snd_seq_device btusb cfg80211 snd bluetooth sg joydev rfkill rtc_generic soundcore rtc_core firewire_ohci sungem pmac_zilog sr_mod serial_core snd_aoa_soundbus rtc_lib appletouch evdev firewire_core sungem_phy ssb cdrom crc_itu_t [ 824.233302] NIP: c0228ae4 LR: c0228ad4 CTR: c025e618 [ 824.233318] REGS: ebda9d00 TRAP: 0700 Tainted: GW (2.6.34) [ 824.233328] MSR: 00029032 CR: 24084844 XER: [ 824.233389] TASK = ee55be70[3200] 'compiz' THREAD: ebda8000 [ 824.233402] GPR00: 0001 ebda9db0 ee55be70 ef9bc138 c0646420 [ 824.233462] GPR08: c08c40c0 dead4ead ef8fc400 000c 24084848 10052ddc 0001 [ 824.233523] GPR16: 1004ae50 1004ae54 1004af24 10037248 1004ae04 1004ae00 deadbeef 108e8020 [ 824.233586] GPR24: c0272bd8 c05e80ec ebda9e00 ebdff480 ee760720 ebdff430 ef9bc138 [ 824.233851] NIP [c0228ae4] ttm_bo_unreserve+0x3c/0x110 [ 824.233864] LR [c0228ad4] ttm_bo_unreserve+0x2c/0x110 [ 824.233875] Call Trace: [ 824.233889] [ebda9db0] [c0228ad4] ttm_bo_unreserve+0x2c/0x110 (unreliable) [ 824.233923] [ebda9dd0] [c0272cb4] radeon_gem_wait_idle_ioctl+0xdc/0x134 [ 824.233951] [ebda9df0] [c02146f8] drm_ioctl+0x26c/0x3a4 [ 824.233975] [ebda9ea0] [c00f4bf8] vfs_ioctl+0x34/0x80 [ 824.233995] [ebda9eb0] [c00f53ec] do_vfs_ioctl+0x670/0x714 [ 824.234015] [ebda9f10] [c00f54f8] sys_ioctl+0x68/0xa8 [ 824.234035] [ebda9f40] [c0014698] ret_from_syscall+0x0/0x38 [ 824.234065] --- Exception: c01 at 0xfa52ef8 [ 824.234069] LR = 0xfa52e5c [ 824.234082] Instruction dump: [ 824.234097] 7c7e1b78 90010024 93a10014 93e1001c 83e3 3bff0078 7fe3fb78 481d0045 [ 824.234153] 815e0004 801e00c8 7c34 5400d97e <0f00> 801e0080 74080020 40a20088 [ 824.234215] ---[ end trace 48e9af4ed874743b ]--- [ 825.257906] BUG: spinlock lockup on CPU#0, Xorg/1611, ef9bc138 [ 825.257934] Call Trace: [ 825.257977] [ee5b5d20] [c0009884] show_stack+0x7c/0x194 (unreliable) [ 825.258020] [ee5b5d60] [c01c2348] do_raw_spin_lock+0x128/0x170 [ 825.258053] [ee5b5d90] [c03f8b50] _raw_spin_lock+0x3c/0x50 [ 825.258084] [ee5b5da0] [c0229e84] ttm_bo_reserve+0x40/0x114 [ 825.258120] [ee5b5dd0] [c0272d6c] radeon_gem_busy_ioctl+0x60/0x150 [ 825.258155] [ee5b5df0] [c02146f8] drm_ioctl+0x26c/0x3a4 [ 825.258187] [ee5b5ea0] [c00f4bf8] vfs_ioctl+0x34/0x80 [ 825.258214] [ee5b5eb0] [c00f53ec] do_vfs_ioctl+0x670/0x714 [ 825.258243] [ee5b5f10] [c00f54f8] sys_ioctl+0x68/0xa8 [ 825.258271] [ee5b5f40] [c0014698] ret_from_syscall+0x0/0x38 [ 825.258324] --- Exception: c01 at 0xfaccef8 [ 825.258327] LR = 0xfacce5c [ 889.061172] BUG: soft lockup - CPU#0 stuck for 61s! [Xorg:1611] [ 889.061188] Modules linked in: netconsole configfs cpufreq_stats sco bnep rfcomm l2cap binfmt_misc fuse ipv6 hfs therm_adt746x pmu_battery snd_aoa_codec_onyx snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm snd_page_alloc snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq ecb b43 mac80211 snd_timer snd_seq_device btusb cfg80211 snd bluetooth sg joydev rfkill rtc_generic soundcore rtc_core firewire_ohci sungem pmac_zilog sr_mod serial_core snd_aoa_soundbus rtc_lib appletouch evdev firewire_core sungem_phy ssb cdrom crc_itu_t [ 889.061571] irq event stamp: 6080374 [ 889.061580] hardirqs last enabled at (6080373): [] rcu_qsctr_help+0x84/0xa4 [ 889.061605] hardirqs last disabled at (6080374): [] _raw_spin_lock_irq+0x2c/0x68 [ 889.061628] softirqs last enabled at (6080082): [] call_do_softirq+0x14/0x24 [ 889.061659] softirqs last disabled at (6080075): [] call_do_softirq+0x14/0x24 [ 889.061683] NIP: c0010578 LR: c01c2308 CTR: c03f9428 [ 889.061696] REGS: ee5b5cb0 TRAP: 0901 Tainted: G D W (2.6.34) [ 889.061707] MSR: 9032 CR: 44242828 XER: [ 889.061763] TASK = eee75340[1611] 'Xorg' THREAD: ee5b4000 [ 889.061773] GPR00: cc31eee0 ee5b5d60 eee75340 0001 eee75340 0010 0002 [ 889.061836] GPR08: cc31eee0
[PATCH] drm/radeon: AGP memory is only I/O if the aperture can be mapped by the CPU.
From: Michel Dänzer Fixes AGP initialization failure with Apple UniNorth bridges due to trying to ioremap() normal RAM. Signed-off-by: Michel Dänzer --- Nouveau probably needs something similar. drivers/gpu/drm/radeon/radeon_ttm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 1fdf340..b9cbba1 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -451,7 +451,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_ /* RADEON_IS_AGP is set only if AGP is active */ mem->bus.offset = mem->mm_node->start << PAGE_SHIFT; mem->bus.base = rdev->mc.agp_base; - mem->bus.is_iomem = true; + mem->bus.is_iomem = !rdev->ddev->agp->cant_use_aperture; } #endif break; -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: record object that have been list reserved
list reservation was too optimistic about ttm object reservation
and could think that an object reserved by some other process
as reserved by the list reservation which was false. Thus when
unreserving the list it might unreserve object that it didn't
reserved in the list. Sorry if it's hard to follow but this
kind of things are just causing headheck.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_object.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5c9ce2b..66a37fb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -261,6 +261,7 @@ struct radeon_bo_list {
unsignedrdomain;
unsignedwdomain;
u32 tiling_flags;
+ boolreserved;
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index a8d18bc..d5b9373 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -301,6 +301,7 @@ int radeon_bo_list_reserve(struct list_head *head)
r = radeon_bo_reserve(lobj->bo, false);
if (unlikely(r != 0))
return r;
+ lobj->reserved = true;
}
return 0;
}
@@ -311,7 +312,7 @@ void radeon_bo_list_unreserve(struct list_head *head)
list_for_each_entry(lobj, head, list) {
/* only unreserve object we successfully reserved */
- if (radeon_bo_is_reserved(lobj->bo))
+ if (lobj->reserved && radeon_bo_is_reserved(lobj->bo))
radeon_bo_unreserve(lobj->bo);
}
}
@@ -322,6 +323,9 @@ int radeon_bo_list_validate(struct list_head *head)
struct radeon_bo *bo;
int r;
+ list_for_each_entry(lobj, head, list) {
+ lobj->reserved = false;
+ }
r = radeon_bo_list_reserve(head);
if (unlikely(r != 0)) {
return r;
--
1.7.0.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28165] TV-out issues
https://bugs.freedesktop.org/show_bug.cgi?id=28165 --- Comment #1 from pe...@peter-server.homelinux.net 2010-05-19 07:42:51 PDT --- > But I could also pulg in the dvd player. I can see the bios messages and grub > menu on both screens. I might even see (part of) usplash. Then the dvd player > turns blue, like it is recieving no signal. The main monitor displays the > login > screen at a distorted 1024*768. > When I login my monitor switches to 1440*900, but it shows an out-of-range > error. The image looks a bit noisy, and the refresh rate looks low, like 25Hz. > Especially mouse movement is not fluid. That's with the dvd player connected, but still disabled. xrands shows http://pastebin.com/5vD3TLEu It is properly detected, so I can enable it. The out-of-range thing stops, and things work great on my main monitor. GNOME expands the desktop to the dvd-player, but there's still no signal. Blue, with nothing on it. xrandr now shows http://pastebin.com/tm5TPgFB The funniest thing is it detects an "tv" when I connect the composite wire to the ground wire, (using a screwdriver). So it doesn't really detect anything... But that's a limitation of the composite signal. I booted the system with drm.debug=14, and these are the results: without dvd player: http://pastebin.com/f4ftQBDN with dvd player: http://pastebin.com/AwzLGwcx I ran dmesg at the gdm login screen over ssh. My setup looks like this: http://www.youtube.com/watch?v=NfZvJ-WTTXg Ignore the laptop. I shot the video with fglrx in a good mood. That's very rare... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: fix typo in 1600x1...@75 mode
Spotted by Scott Bertilson.
Fixes fdo bug 28146.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7188674..54d749d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -587,7 +587,7 @@ static struct drm_display_mode drm_dmt_modes[] = {
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1600x1...@75hz */
- { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 2025000, 1600, 1664,
+ { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 202500, 1600, 1664,
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1600x1...@85hz */
--
1.5.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28146] typo in drm_edid.c drm_dmt_modes table
https://bugs.freedesktop.org/show_bug.cgi?id=28146 --- Comment #2 from Alex Deucher 2010-05-19 08:51:05 PDT --- Created an attachment (id=35762) View: https://bugs.freedesktop.org/attachment.cgi?id=35762 Review: https://bugs.freedesktop.org/review?bug=28146&attachment=35762 fix the clock Here's the patch I've sent upstream. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28146] typo in drm_edid.c drm_dmt_modes table
https://bugs.freedesktop.org/show_bug.cgi?id=28146 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Alex Deucher 2010-05-19 08:52:31 PDT --- thanks for spotting this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: fix typo in 1600x1...@75 mode
Alex Deucher wrote:
Spotted by Scott Bertilson.
Fixes fdo bug 28146.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7188674..54d749d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -587,7 +587,7 @@ static struct drm_display_mode drm_dmt_modes[] = {
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1600x1...@75hz */
- { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 2025000, 1600, 1664,
+ { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 202500, 1600, 1664,
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1600x1...@85hz */
Looks good.
Reviewed-by: Mark Marshall
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] [RFC] fair-lru eviction
On Wed, May 19, 2010 at 09:06:52AM +0100, Chris Wilson wrote: > On Tue, 18 May 2010 23:11:42 +0200, Daniel Vetter > wrote: > > Hi all, > > > > This patch series implements the fair-lru eviction Chris Wilson already > > posted with a twist. It's essentially the same idea & algorithm. > > Differnences versus his patch: > > - Doesn't do any allocations while scanning. > > - Implemented in drm_mm.c > > > > In other words, this should also be usable by ttm. The idea is simple: > > Scan through the lru, marking objects as evictable until there is a > > large area of memory free/free-able. Then walk through all the scanned > > objects in reverse, checking which ones fall into this hole. Finally > > evicting them. > > > > Comments, ideas highly welcome. > > The next adaptation I did was to clean up evict_something to add objects > from the inactive, active&&!pinned&&!write, flushing&&!pinned, > active&&!pinned&&write lists. This reduces the logic in evict_something to > a single scan over the available objects in LRU order. Is this really worth it? I've worried about the rescanning in case there's no suitable hole in the inactive list, too. But we're doing that also in the current code. And the new code doesn't change the algorithmic complexity (still O(number_of_inactive_objects)) so we're not gonna hit an ugly corner case. Furthermore some printk instrumentation showed that for a full cairo-perf-traces run on my i855 only three times (over the hole run, including rescans when new stuff arrived on the inactive list) there was no suitable hole in the inactive list. So I've stopped worrying. > We still need the move-to-inactive-tail upon access by the CPU, and I > think it is acceptable to maintain our preference of the GPU over the CPU. > Recovering memory from the CPU is comparatively cheap. Argh, I've totally forgotten to put that list_move_tail into gem_fault (and probably gtt_(write|read)_fast, too). > Comparing 'while :; do yes > /tmp/yes; done & cairo-perf-trace', there is > no significant delta between the fair LRU and current. I'll rebase my > evict_something() on top of your drm_mm, and rerun the tests. I'm still crunching the numbers, but preliminary benchmarks on my i855 show that there are _no_ regressions in cairo-traces (poppler is the only one to take a hit of 1% which is decently below it's noise floor of 2%;). Speedups are comparable to what you've posted on the list for your patches Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: kill drm_mm_node->private
On Wed, May 19, 2010 at 11:25:07AM +0200, Jerome Glisse wrote: > On Tue, May 18, 2010 at 11:11:45PM +0200, Daniel Vetter wrote: > > Only ever assigned, never used. > > > > Signed-off-by: Daniel Vetter > > NAK > > private was to be use when doing range restricted allocation > somehow the patch that use it was drop/forgot/lost along the > was i will try to see i have it and redo it if not. I don't agree for the following reasons: 1) drm_mm _does_ implement range-restricted allocations. And it does not use the private pointer to do so. My new scanning algorithm doesn't implement this (i915 doesn't use range restricted allocations), but it's damn trivial to add. 2) The private pointer was used as a back-pointer to the object. If something like this is needed, making struct drm_mm_node embedable looks like the right approach (perhaps with some driver-private bitfields to distinguish different case). I'm still in the process of shooting down the driver_private gem_object pointer and I don't like doing this right away again ... Can you please point me to the code that needs this private pointer? Then I can see in which way I'm wrong ... ;) > Cheers, > Jerome Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] [RFC] fair-lru eviction
On Wed, 19 May 2010 18:57:52 +0200, Daniel Vetter wrote: > On Wed, May 19, 2010 at 09:06:52AM +0100, Chris Wilson wrote: > > The next adaptation I did was to clean up evict_something to add objects > > from the inactive, active&&!pinned&&!write, flushing&&!pinned, > > active&&!pinned&&write lists. This reduces the logic in evict_something to > > a single scan over the available objects in LRU order. > > Is this really worth it? I've worried about the rescanning in case there's > no suitable hole in the inactive list, too. But we're doing that also in > the current code. And the new code doesn't change the algorithmic > complexity (still O(number_of_inactive_objects)) so we're not gonna hit an > ugly corner case. I actually thought it simplified the code and really clarified the rescan logic - which is not at all obvious as it depends upon the caller as well. > Furthermore some printk instrumentation showed that for > a full cairo-perf-traces run on my i855 only three times (over the hole > run, including rescans when new stuff arrived on the inactive list) there > was no suitable hole in the inactive list. So I've stopped worrying. I can generate more... But yes, I don't think cairo-perf-trace is a sufficiently aggressive test. That was why I was trying to apply artificial memory pressure, something I am going to try and refine in future. I guess we will have to look at the games for scenarios that thrash the aperture. > I'm still crunching the numbers, but preliminary benchmarks on my i855 > show that there are _no_ regressions in cairo-traces (poppler is the only > one to take a hit of 1% which is decently below it's noise floor of 2%;). > Speedups are comparable to what you've posted on the list for your patches Excellent! -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] fbmem: fix printk format warnings
From: Randy Dunlap
Fix printk formats:
drivers/video/fbmem.c: In function 'fb_do_apertures_overlap':
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 2 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 3 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 4 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 5 has type 'resource_size_t'
Signed-off-by: Randy Dunlap
---
drivers/video/fbmem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- linux-next-20100519.orig/drivers/video/fbmem.c
+++ linux-next-20100519/drivers/video/fbmem.c
@@ -1491,7 +1491,10 @@ static bool fb_do_apertures_overlap(stru
for (j = 0; j < gena->count; ++j) {
struct aperture *g = &gena->ranges[j];
printk(KERN_DEBUG "checking generic (%llx %llx) vs hw
(%llx %llx)\n",
- g->base, g->size, h->base, h->size);
+ (unsigned long long)g->base,
+ (unsigned long long)g->size,
+ (unsigned long long)h->base,
+ (unsigned long long)h->size);
if (apertures_overlap(g, h))
return true;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28163] Static on right part of screen when 3D happens on rv350 using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=28163 --- Comment #2 from Scott Moreau 2010-05-19 12:01:28 PDT --- (In reply to comment #1) > This is already fixed in 2.6.34: > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=commit;h=f46c01208da1881591e3f55ca77d37f54469f8e4 Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28165] TV-out issues
https://bugs.freedesktop.org/show_bug.cgi?id=28165 --- Comment #2 from pe...@peter-server.homelinux.net 2010-05-19 12:29:59 PDT --- I just compiled a fresh kernel from git, as decribed here: http://wiki.x.org/wiki/radeonBuildHowTo#Bleedingedgecodefromdevelopmentbranch Same results as before... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] [RFC] fair-lru eviction
Daniel, Daniel Vetter wrote: Hi all, This patch series implements the fair-lru eviction Chris Wilson already posted with a twist. It's essentially the same idea & algorithm. Differnences versus his patch: - Doesn't do any allocations while scanning. - Implemented in drm_mm.c In other words, this should also be usable by ttm. The idea is simple: Scan through the lru, marking objects as evictable until there is a large area of memory free/free-able. Then walk through all the scanned objects in reverse, checking which ones fall into this hole. Finally evicting them. Comments, ideas highly welcome. As per usual, I couldn't resist and had to clean up the code in drm_mm.c a little. Yours, Daniel While the cleanup of drm_mm.c looks fine to me, I'm not sure the fair eviction is easy to implement with TTM. TTM releases the spinlock protecting the drm_mm manager in between evictions to be able to wait (without holding locks) for bo idle. That means that the lru list may have changed between the first eviction and the next. In practice, drivers either don't allow simultaneous bo validation or should disallow it if thrashing is likely to occur, so the likelyhood of the lru list changing in between evictions should be small but it needs to be taken into account. Nevertheless, the drm_mm.c cleanup is Acked-by: Thomas Hellstrom I'll leave it to the Intel guys to comment on the fair eviction stuff. /Thomas Daniel Vetter (9): list.h: add list_for_each_entry_safe_from_reverse drm: use list_for_each_entry in drm_mm.c drm: kill drm_mm_node->private drm: kill dead code in drm_mm.c drm: sane naming for drm_mm.c drm_mm: extract check_free_mm_node drm: implement helper functions for scanning lru list drm/i915: prepare for fair lru eviction drm/i915: implement fair lru eviction drivers/gpu/drm/drm_mm.c | 359 - drivers/gpu/drm/i915/i915_gem.c | 122 - drivers/gpu/drm/ttm/ttm_bo.c |6 - drivers/gpu/drm/ttm/ttm_bo_util.c |2 - include/drm/drm_mm.h | 27 +++- include/linux/list.h | 15 ++ 6 files changed, 347 insertions(+), 184 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] [RFC] fair-lru eviction
On Wed, May 19, 2010 at 09:51:33PM +0200, Thomas Hellström wrote: > Daniel, > TTM releases the spinlock protecting the drm_mm manager in between > evictions to be able to wait (without holding locks) for bo idle. > That means that the lru list may have changed between the first > eviction and the next. In practice, drivers either don't allow > simultaneous bo validation or should disallow it if thrashing is > likely to occur, so the likelyhood of the lru list changing in > between evictions should be small but it needs to be taken into > account. Well, in my opinion ttm locking optimize for the wrong case: Usually there should be a little bit of room free to fully pipeline everything. And if it there is no room free anymore, performance is gonna dip anyway, so we might as well block. I think the linux vm with the split between asynchronous background writeback and synchronous writeback in case of low amounts of free memory could be used as inspiration. Whatever, I think ttm could use this fair eviction stuff even with the current locking scheme: Do all the accounting under the spinlock, i.e. - scanning the lru - building up the eviction list - mark the memory blocks as free (with drm_mm_put_block) - reserve the complete free hole (needs a new function in drm_mm, but range-restricted allocations are not yet implemented yet, anyway) with a temporary object. Then do the effective eviction outside the spinlock. iirc ttm already uses such shadow (dunno what they're really called) objects for buffer moves. > Nevertheless, the drm_mm.c cleanup is > Acked-by: Thomas Hellstrom Does that include the drm_mm_node->private pointer removal? Jerome naked that one (but I've objected). Just to clarify. > I'll leave it to the Intel guys to comment on the fair eviction stuff. > > /Thomas Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] [RFC] fair-lru eviction
On 05/19/2010 10:13 PM, Daniel Vetter wrote: On Wed, May 19, 2010 at 09:51:33PM +0200, Thomas Hellström wrote: Daniel, TTM releases the spinlock protecting the drm_mm manager in between evictions to be able to wait (without holding locks) for bo idle. That means that the lru list may have changed between the first eviction and the next. In practice, drivers either don't allow simultaneous bo validation or should disallow it if thrashing is likely to occur, so the likelyhood of the lru list changing in between evictions should be small but it needs to be taken into account. Well, in my opinion ttm locking optimize for the wrong case: Usually there should be a little bit of room free to fully pipeline everything. And if it there is no room free anymore, performance is gonna dip anyway, so we might as well block. Yes, the driver is free to block in such cases if it wants to. It's a matter of taking a command submission rwsem in either read- or write mode. However, a validation sequence of one DRI client shouldn't unnecessarily block other renderers whose render targets / sources are already in memory, but that's only a special case. TTM tries to make sure and encourage driver writers make sure no CPU locks are held while waiting for a GPU, which may turn out to be optimizing for the wrong case in a single-client-single-gpu environment, but turn out to be a good choice in other situations. In any case, the code must take into account that the lru may be modified when the spinlock is released, which I believe you have addressed below. I think the linux vm with the split between asynchronous background writeback and synchronous writeback in case of low amounts of free memory could be used as inspiration. Whatever, I think ttm could use this fair eviction stuff even with the current locking scheme: Do all the accounting under the spinlock, i.e. - scanning the lru - building up the eviction list - mark the memory blocks as free (with drm_mm_put_block) - reserve the complete free hole (needs a new function in drm_mm, but range-restricted allocations are not yet implemented yet, anyway) with a temporary object. Then do the effective eviction outside the spinlock. iirc ttm already uses such shadow (dunno what they're really called) objects for buffer moves. Nevertheless, the drm_mm.c cleanup is Acked-by: Thomas Hellstrom Does that include the drm_mm_node->private pointer removal? Jerome naked that one (but I've objected). Just to clarify. IIRC, Jerome's range validation patches was using that member at some stage. I think if Jerome needs the pointer it should stay. Thanks, Thomas I'll leave it to the Intel guys to comment on the fair eviction stuff. /Thomas Thanks, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm: kill drm_mm_node->private
On Wed, May 19, 2010 at 07:03:32PM +0200, Daniel Vetter wrote: > On Wed, May 19, 2010 at 11:25:07AM +0200, Jerome Glisse wrote: > > On Tue, May 18, 2010 at 11:11:45PM +0200, Daniel Vetter wrote: > > > Only ever assigned, never used. > > > > > > Signed-off-by: Daniel Vetter > > > > NAK > > > > private was to be use when doing range restricted allocation > > somehow the patch that use it was drop/forgot/lost along the > > was i will try to see i have it and redo it if not. > > I don't agree for the following reasons: > 1) drm_mm _does_ implement range-restricted allocations. And it does not >use the private pointer to do so. My new scanning algorithm doesn't >implement this (i915 doesn't use range restricted allocations), but >it's damn trivial to add. > 2) The private pointer was used as a back-pointer to the object. If >something like this is needed, making struct drm_mm_node embedable >looks like the right approach (perhaps with some driver-private >bitfields to distinguish different case). I'm still in the process of >shooting down the driver_private gem_object pointer and I don't like >doing this right away again ... > > Can you please point me to the code that needs this private pointer? Then I > can see in which way I'm wrong ... ;) > Ok fine, nuck it, i will readd it if needed once i have time to get back to this. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=27901 --- Comment #4 from Alain Perrot 2010-05-19 15:58:12 PDT --- (In reply to comment #3) > Alain, > > Okay, The patch I just posted might fix this bug. It doesn't cause any > additional errors in piglit either. I think its working right with > http://github.com/jckarter/hello-gl-ch3 too. Of course I have only tested it > on > my RadeonHD 3100 and its my first attempt at r600 assembly so let me know if > it > works for you. > > Note: it could probably be done so its faster but I'm still not to sure on how > everything works yet in the software > > Conn Thanks for your help. Unfortunately, your patch does not fix the cos/sin functions (at least on my Radeon HD 3870 / RV670). The hello-gl-ch3 example works better but still not as expected, you can compare with Mesa software rendering. I tried to play with your patch to make it work without success for now. A note is that there may be a mistake on the last operand to the CNDGT instruction : +setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); +pAsm->S[1].src.rtype = DST_REG_TEMPORARY; +pAsm->S[1].src.reg = tmp2; +setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); should probably be : +setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); +pAsm->S[2].src.rtype = DST_REG_TEMPORARY; +pAsm->S[2].src.reg = tmp2; +setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); But this update does not make the cos/sin functions work. I will try again tomorrow. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
On Wed, May 19, 2010 at 3:58 PM, wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=27901 > > --- Comment #4 from Alain Perrot 2010-05-19 15:58:12 > PDT --- > (In reply to comment #3) >> Alain, >> >> Okay, The patch I just posted might fix this bug. It doesn't cause any >> additional errors in piglit either. I think its working right with >> http://github.com/jckarter/hello-gl-ch3 too. Of course I have only tested it >> on >> my RadeonHD 3100 and its my first attempt at r600 assembly so let me know if >> it >> works for you. >> >> Note: it could probably be done so its faster but I'm still not to sure on >> how >> everything works yet in the software >> >> Conn > > Thanks for your help. > > Unfortunately, your patch does not fix the cos/sin functions (at least on my > Radeon HD 3870 / RV670). The hello-gl-ch3 example works better but still not > as > expected, you can compare with Mesa software rendering. > > I tried to play with your patch to make it work without success for now. A > note > is that there may be a mistake on the last operand to the CNDGT instruction : > > + setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + pAsm->S[1].src.rtype = DST_REG_TEMPORARY; > + pAsm->S[1].src.reg = tmp2; > + setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > should probably be : > > + setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + pAsm->S[2].src.rtype = DST_REG_TEMPORARY; > + pAsm->S[2].src.reg = tmp2; > + setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > But this update does not make the cos/sin functions work. > > I will try again tomorrow. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Alain, Okay I'll look at it some more tonight. At least I know I'm on the right track. Thanks for testing. Conn -- Conn O. Clark Observation: In formal computer science advances are made by standing on the shoulders of giants. Linux has proved that if there are enough of you, you can advance just as far by stepping on each others toes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=27901 --- Comment #5 from Conn Clark 2010-05-19 16:46:22 PDT --- On Wed, May 19, 2010 at 3:58 PM, wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=27901 > > --- Comment #4 from Alain Perrot 2010-05-19 15:58:12 > PDT --- > (In reply to comment #3) >> Alain, >> >> Okay, The patch I just posted might fix this bug. It doesn't cause any >> additional errors in piglit either. I think its working right with >> http://github.com/jckarter/hello-gl-ch3 too. Of course I have only tested it >> on >> my RadeonHD 3100 and its my first attempt at r600 assembly so let me know if >> it >> works for you. >> >> Note: it could probably be done so its faster but I'm still not to sure on >> how >> everything works yet in the software >> >> Conn > > Thanks for your help. > > Unfortunately, your patch does not fix the cos/sin functions (at least on my > Radeon HD 3870 / RV670). The hello-gl-ch3 example works better but still not > as > expected, you can compare with Mesa software rendering. > > I tried to play with your patch to make it work without success for now. A > note > is that there may be a mistake on the last operand to the CNDGT instruction : > > + setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + pAsm->S[1].src.rtype = DST_REG_TEMPORARY; > + pAsm->S[1].src.reg = tmp2; > + setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > should probably be : > > + setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + pAsm->S[2].src.rtype = DST_REG_TEMPORARY; > + pAsm->S[2].src.reg = tmp2; > + setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > But this update does not make the cos/sin functions work. > > I will try again tomorrow. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Alain, Okay I'll look at it some more tonight. At least I know I'm on the right track. Thanks for testing. Conn -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Try a bit harder to get output on the screen at panic time
On Fri, 9 Apr 2010 15:10:50 -0700 Jesse Barnes wrote: > This set of 3 patches makes it a little more likely we'll get panic > output onto the screen even when X is running, assuming a KMS enabled > stack anyway. > > It gets me from a blank or very sparsely populated black screen at > panic time, to one including the full backtrace and panic output at > panic time (tested with "echo c > /proc/sysrq-trigger" from an X > session). > > It doesn't cover every case; for instance I think it'll fail when X has > disabled the display, but those cases need to be handled with separate > patches anyway (need to add atomic DPMS paths for instance). > > Anyway, please test these out and let me know if they work for you. Ping Linus & Dave again. Have you guys tried these? Really, it's cool. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Try a bit harder to get output on the screen at panic time
On Wed, 2010-05-19 at 17:34 -0700, Jesse Barnes wrote: > On Fri, 9 Apr 2010 15:10:50 -0700 > Jesse Barnes wrote: > > > This set of 3 patches makes it a little more likely we'll get panic > > output onto the screen even when X is running, assuming a KMS enabled > > stack anyway. > > > > It gets me from a blank or very sparsely populated black screen at > > panic time, to one including the full backtrace and panic output at > > panic time (tested with "echo c > /proc/sysrq-trigger" from an X > > session). > > > > It doesn't cover every case; for instance I think it'll fail when X has > > disabled the display, but those cases need to be handled with separate > > patches anyway (need to add atomic DPMS paths for instance). > > > > Anyway, please test these out and let me know if they work for you. > > Ping Linus & Dave again. Have you guys tried these? Really, it's cool. > Second that, just tested these patches, and these work perfectly. One more reason for me to dump nvidia driver for nouveau. Best regards, Maxim Levitsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Try a bit harder to get output on the screen at panic time
On Thu, 2010-05-20 at 04:13 +0300, Maxim Levitsky wrote: > On Wed, 2010-05-19 at 17:34 -0700, Jesse Barnes wrote: > > On Fri, 9 Apr 2010 15:10:50 -0700 > > Jesse Barnes wrote: > > > > > This set of 3 patches makes it a little more likely we'll get panic > > > output onto the screen even when X is running, assuming a KMS enabled > > > stack anyway. > > > > > > It gets me from a blank or very sparsely populated black screen at > > > panic time, to one including the full backtrace and panic output at > > > panic time (tested with "echo c > /proc/sysrq-trigger" from an X > > > session). > > > > > > It doesn't cover every case; for instance I think it'll fail when X has > > > disabled the display, but those cases need to be handled with separate > > > patches anyway (need to add atomic DPMS paths for instance). > > > > > > Anyway, please test these out and let me know if they work for you. > > > > Ping Linus & Dave again. Have you guys tried these? Really, it's cool. > > > Second that, just tested these patches, and these work perfectly. > One more reason for me to dump nvidia driver for nouveau. Unfortunately I spoke too soon. After suspend to ram, system doesn't properly resume now. My system is based on nvidia G86, I use latest nouveau drivers, and suspend with compiz running. I also patched kernel not to do vt switch on suspend/resume: diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 062b7f6..b3ef08b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -31,6 +31,7 @@ #include "drm_crtc_helper.h" #include #include +#include #include "nouveau_drv.h" #include "nouveau_drm.h" @@ -771,6 +772,8 @@ int nouveau_load(struct drm_device *dev, unsigned long flags) int ret = nouveau_card_init(dev); if (ret) return ret; + + pm_set_vt_switch(0); } return 0; Best regards, Maxim Levitsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm tree for 2.6.35-rc1
This is a combined drm/agp tree. Highlights: core: initial dev docs, agp scratch page support kms: framebuffer cleanup + improved disconnected monitor at boot handling, lots of edid parser updates to bring us in line with the X.org code, improved fbdev handover mechanism. ttm: add AGP page pool support to increase AGP speed. radeon kms: initial powermanagement support - for all radeon GPU families, this needs more work but it really needs to be upstream so we can get some feedback now. PM on GPUs is a very complex task. There are two modes of operation a profile driven mode and a dynamic mode, the dynamic mode can potentially save more power but is also more likely to glitch on screen. evergreen irq/basic accel hw setup code. full access to VRAM beyond PCI BAR Intel kms: split intel agp driver into two drivers, one for AGP, one for GTT. move intel sdvo to proper encoder/connector organisation Intel Cougarpoint support This merge has one patch in x86 land which is acked on the list by the proper people. Dave. The following changes since commit 722154e4cacf015161efe60009ae9be23d492296: Linus Torvalds (1): Merge branch 'zerolen' of git://git.kernel.org/.../jgarzik/misc-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next Adam Jackson (25): drm/edid: Fix secondary block fetch. drm/edid: Remove some misleading comments drm/edid: Remove a redundant check drm/edid: Reshuffle mode list construction to closer match the spec drm/edid: Add modes for Established Timings III section drm/edid: Remove arbitrary EDID extension limit drm/edid: Remove some silly comments drm/edid: Fix preferred mode parse for EDID 1.4 drm/edid: Add test for monitor reduced blanking support. drm/edid: Extend range-based mode addition for EDID 1.4 drm/edid: Fix the HDTV hack. drm/edid: Strengthen the algorithm for standard mode codes drm/edid: Add secondary GTF curve support drm/modes: Fix interlaced mode names drm/edid: Fix sync polarity for secondary GTF curve drm/edid: When checking duplicate standard modes, walked the probed list drm/i915: Allow LVDS on pipe A on gen4+ drm/i915: Un-magic a DPCD register write drm/i915: Set sync polarity correctly on DisplayPort drm/i915/pch: Use minimal number of FDI lanes (v2) drm/i915: Use spatio-temporal dithering on PCH drm/i915: Make fbc control wrapper functions drm/i915: Fix DDC bus selection for multifunction SDVO drm/i915: Be extra careful about A/D matching for multifunction SDVO drm/edid: Fix 1024x768 at 85Hz Alex Deucher (39): drm/radeon/kms: update atombios.h power tables for evergreen drm/radeon/kms: add support for evergreen power tables drm/radeon/kms/evergreen: add gart support drm/radeon/kms/evergreen: add soft reset function drm/radeon/kms/evergreen: implement gfx init drm/radeon/kms/evergreen: setup and enable the CP drm/radeon/kms/evergreen: implement irq support drm/radeon/kms/evergreen: add hpd support drm/radeon/kms/atom: disable the encoders in encoder_disable drm/radeon/kms: fix copy pasto in disable encoders patch drm/radeon/kms/atom: fix typo in LVDS panel info parsing drm/radeon/kms/combios: match lvds panel info parsing to ddx drm/radeon/kms: add gui_idle callback drm/radeon/kms: add support for gui idle interrupts (v4) drm/radeon/kms: wait for gpu idle before changing power mode drm/radeon/kms/atom/pm: rework power mode parsing drm/radeon/kms/pm: interate across crtcs for vblank drm/radeon/kms/pm: move pm state update to crtc functions drm/radeon/kms/pm: add asic specific callbacks for setting power state (v2) drm/radeon/kms/pm: add asic specific callbacks for getting power state (v2) drm/radeon/kms/pm: update display watermarks with power state changes drm/radeon/kms/atom: load hwmon drivers drm/radeon/kms/pm: don't enable pm if there is only on power state drm/radeon/kms/pm: clean power state printing drm/radeon/kms: minor pm cleanups drm/radeon/kms/pm: restore default power state on exit drm/radeon/kms/pm: add additional asic callbacks drm/radeon/kms/pm: rework power management drm/radeon/kms: more pm fixes drm/radeon/kms: re-enable gui idle interrupts on r6xx+ drm/radeon/kms: enable misc pm power state features on r5xx, rs6xx drm/radeon/kms: enable misc pm power state features on r1xx-r4xx drm/radeon/kms: fix lock ordering in ring, ib handling drm/radeon/kms/pm: add support for no display power states drm/radeon/kms/pm: rework power management drm/radeon/kms/pm: make pm spam debug only drm/radeon/kms/pm: fix r6xx+ profile setup drm/radeon/kms: reset ddc_bus in object header parsing drm/radeon/k
[PATCH 1/2] drm/radeon/kms: reset ddc_bus in object header parsing
2010/5/19 Alex Deucher : > Some LVDS connectors don't have a ddc bus, so reset the > ddc bus to invalid before parsing the next connector > to avoid using stale ddc bus data. ?Should fix > fdo bug 28164. It does, thanks :) Tested-by: Rafa? Mi?ecki -- Rafa?
[Bug 27729] [r300g, mesa] gallium compressed texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=27729 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Fabio Pedretti 2010-05-19 00:40:21 PDT --- This appears to be fixed, the game is however still crashing later, see bug #28169. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/9] [RFC] fair-lru eviction
On Tue, 18 May 2010 23:11:42 +0200, Daniel Vetter wrote: > Hi all, > > This patch series implements the fair-lru eviction Chris Wilson already > posted with a twist. It's essentially the same idea & algorithm. > Differnences versus his patch: > - Doesn't do any allocations while scanning. > - Implemented in drm_mm.c > > In other words, this should also be usable by ttm. The idea is simple: > Scan through the lru, marking objects as evictable until there is a > large area of memory free/free-able. Then walk through all the scanned > objects in reverse, checking which ones fall into this hole. Finally > evicting them. > > Comments, ideas highly welcome. The next adaptation I did was to clean up evict_something to add objects from the inactive, active&&!pinned&&!write, flushing&&!pinned, active&&!pinned&&write lists. This reduces the logic in evict_something to a single scan over the available objects in LRU order. We still need the move-to-inactive-tail upon access by the CPU, and I think it is acceptable to maintain our preference of the GPU over the CPU. Recovering memory from the CPU is comparatively cheap. Comparing 'while :; do yes > /tmp/yes; done & cairo-perf-trace', there is no significant delta between the fair LRU and current. I'll rebase my evict_something() on top of your drm_mm, and rerun the tests. -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 3/9] drm: kill drm_mm_node->private
On Tue, May 18, 2010 at 11:11:45PM +0200, Daniel Vetter wrote: > Only ever assigned, never used. > > Signed-off-by: Daniel Vetter NAK private was to be use when doing range restricted allocation somehow the patch that use it was drop/forgot/lost along the was i will try to see i have it and redo it if not. Cheers, Jerome
[Bug 23122] mipmap_comp_tests will cause radeon_validate_texture error
https://bugs.freedesktop.org/show_bug.cgi?id=23122 --- Comment #3 from Andrew Randrianasulu 2010-05-19 03:29:43 PDT --- I can't see any error with mipmap_comp_tests on rv280 and mesa up to commit 4cd259ca59128ff2712c42ff2d2340b01a3b74a8 Author: Kristian H??gsberg Date: Tue May 18 14:45:10 2010 -0400 dri2_glx: Put the invalidate b/c code back in -- BUT I see somewhat strange image in this test .. let me open new bug . -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28173] New: mipmap_comp_tests show strange image, green bar at left side
https://bugs.freedesktop.org/show_bug.cgi?id=28173 Summary: mipmap_comp_tests show strange image, green bar at left side Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: randrik at mail.ru using mesa git master up to commit 4cd259ca59128ff2712c42ff2d2340b01a3b74a8 Author: Kristian H??gsberg Date: Tue May 18 14:45:10 2010 -0400 dri2_glx: Put the invalidate b/c code back in and up-to-date ddx/xserver master branches + drm-radeon-testing up to commit debb980f1a333f335ccc33c5a5102af038d59fed Merge: 26481fb e40152e Author: Dave Airlie Date: Wed May 19 06:30:36 2010 +1000 Merge tag 'v2.6.34' into drm-radeon-testing i see strange picture with mipmap_comp_tests, different from software rasterizer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28173] mipmap_comp_tests show strange image, green bar at left side
https://bugs.freedesktop.org/show_bug.cgi?id=28173 --- Comment #1 from Andrew Randrianasulu 2010-05-19 03:34:40 PDT --- Created an attachment (id=35756) --> (https://bugs.freedesktop.org/attachment.cgi?id=35756) screenshot showing bug -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: add query for crtc hw id from crtc id to get info V2
On Mit, 2010-05-12 at 18:01 +0200, Jerome Glisse wrote: > Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm > crtc id. Bump the minor version so userspace can enable conditionaly > features depend on this. > > V2 use num_crtc and avoid DRM_ERROR > > Signed-off-by: Jerome Glisse Running compiz with this and the corresponding X changes kills my kernel rather quickly (a matter of minutes if not seconds), see below. [ 824.232844] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:192! [ 824.232864] Oops: Exception in kernel mode, sig: 5 [#1] [ 824.232876] PowerMac [ 824.232886] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed [ 824.232898] Modules linked in: netconsole configfs cpufreq_stats sco bnep rfcomm l2cap binfmt_misc fuse ipv6 hfs therm_adt746x pmu_battery snd_aoa_codec_onyx snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm snd_page_alloc snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq ecb b43 mac80211 snd_timer snd_seq_device btusb cfg80211 snd bluetooth sg joydev rfkill rtc_generic soundcore rtc_core firewire_ohci sungem pmac_zilog sr_mod serial_core snd_aoa_soundbus rtc_lib appletouch evdev firewire_core sungem_phy ssb cdrom crc_itu_t [ 824.233302] NIP: c0228ae4 LR: c0228ad4 CTR: c025e618 [ 824.233318] REGS: ebda9d00 TRAP: 0700 Tainted: GW (2.6.34) [ 824.233328] MSR: 00029032 CR: 24084844 XER: [ 824.233389] TASK = ee55be70[3200] 'compiz' THREAD: ebda8000 [ 824.233402] GPR00: 0001 ebda9db0 ee55be70 ef9bc138 c0646420 [ 824.233462] GPR08: c08c40c0 dead4ead ef8fc400 000c 24084848 10052ddc 0001 [ 824.233523] GPR16: 1004ae50 1004ae54 1004af24 10037248 1004ae04 1004ae00 deadbeef 108e8020 [ 824.233586] GPR24: c0272bd8 c05e80ec ebda9e00 ebdff480 ee760720 ebdff430 ef9bc138 [ 824.233851] NIP [c0228ae4] ttm_bo_unreserve+0x3c/0x110 [ 824.233864] LR [c0228ad4] ttm_bo_unreserve+0x2c/0x110 [ 824.233875] Call Trace: [ 824.233889] [ebda9db0] [c0228ad4] ttm_bo_unreserve+0x2c/0x110 (unreliable) [ 824.233923] [ebda9dd0] [c0272cb4] radeon_gem_wait_idle_ioctl+0xdc/0x134 [ 824.233951] [ebda9df0] [c02146f8] drm_ioctl+0x26c/0x3a4 [ 824.233975] [ebda9ea0] [c00f4bf8] vfs_ioctl+0x34/0x80 [ 824.233995] [ebda9eb0] [c00f53ec] do_vfs_ioctl+0x670/0x714 [ 824.234015] [ebda9f10] [c00f54f8] sys_ioctl+0x68/0xa8 [ 824.234035] [ebda9f40] [c0014698] ret_from_syscall+0x0/0x38 [ 824.234065] --- Exception: c01 at 0xfa52ef8 [ 824.234069] LR = 0xfa52e5c [ 824.234082] Instruction dump: [ 824.234097] 7c7e1b78 90010024 93a10014 93e1001c 83e3 3bff0078 7fe3fb78 481d0045 [ 824.234153] 815e0004 801e00c8 7c34 5400d97e <0f00> 801e0080 74080020 40a20088 [ 824.234215] ---[ end trace 48e9af4ed874743b ]--- [ 825.257906] BUG: spinlock lockup on CPU#0, Xorg/1611, ef9bc138 [ 825.257934] Call Trace: [ 825.257977] [ee5b5d20] [c0009884] show_stack+0x7c/0x194 (unreliable) [ 825.258020] [ee5b5d60] [c01c2348] do_raw_spin_lock+0x128/0x170 [ 825.258053] [ee5b5d90] [c03f8b50] _raw_spin_lock+0x3c/0x50 [ 825.258084] [ee5b5da0] [c0229e84] ttm_bo_reserve+0x40/0x114 [ 825.258120] [ee5b5dd0] [c0272d6c] radeon_gem_busy_ioctl+0x60/0x150 [ 825.258155] [ee5b5df0] [c02146f8] drm_ioctl+0x26c/0x3a4 [ 825.258187] [ee5b5ea0] [c00f4bf8] vfs_ioctl+0x34/0x80 [ 825.258214] [ee5b5eb0] [c00f53ec] do_vfs_ioctl+0x670/0x714 [ 825.258243] [ee5b5f10] [c00f54f8] sys_ioctl+0x68/0xa8 [ 825.258271] [ee5b5f40] [c0014698] ret_from_syscall+0x0/0x38 [ 825.258324] --- Exception: c01 at 0xfaccef8 [ 825.258327] LR = 0xfacce5c [ 889.061172] BUG: soft lockup - CPU#0 stuck for 61s! [Xorg:1611] [ 889.061188] Modules linked in: netconsole configfs cpufreq_stats sco bnep rfcomm l2cap binfmt_misc fuse ipv6 hfs therm_adt746x pmu_battery snd_aoa_codec_onyx snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm snd_page_alloc snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event arc4 snd_seq ecb b43 mac80211 snd_timer snd_seq_device btusb cfg80211 snd bluetooth sg joydev rfkill rtc_generic soundcore rtc_core firewire_ohci sungem pmac_zilog sr_mod serial_core snd_aoa_soundbus rtc_lib appletouch evdev firewire_core sungem_phy ssb cdrom crc_itu_t [ 889.061571] irq event stamp: 6080374 [ 889.061580] hardirqs last enabled at (6080373): [] rcu_qsctr_help+0x84/0xa4 [ 889.061605] hardirqs last disabled at (6080374): [] _raw_spin_lock_irq+0x2c/0x68 [ 889.061628] softirqs last enabled at (6080082): [] call_do_softirq+0x14/0x24 [ 889.061659] softirqs last disabled at (6080075): [] call_do_softirq+0x14/0x24 [ 889.061683] NIP: c0010578 LR: c01c2308 CTR: c03f9428 [ 889.061696] REGS: ee5b5cb0 TRAP: 0901 Tainted: G D W (2.6.34) [ 889.061707] MSR: 9032 CR: 44242828 XER: [ 889.061763] TASK = eee75340[1611] 'Xorg' THREAD: ee5b4000 [ 889.061773] GPR00: cc31eee0 ee5b5d60 eee75340 0001 eee75340 0010 0002 [ 889.061836] GPR08: cc31eee0
[PATCH] drm/radeon: AGP memory is only I/O if the aperture can be mapped by the CPU.
From: Michel D?nzer Fixes AGP initialization failure with Apple UniNorth bridges due to trying to ioremap() normal RAM. Signed-off-by: Michel D?nzer --- Nouveau probably needs something similar. drivers/gpu/drm/radeon/radeon_ttm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 1fdf340..b9cbba1 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -451,7 +451,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_ /* RADEON_IS_AGP is set only if AGP is active */ mem->bus.offset = mem->mm_node->start << PAGE_SHIFT; mem->bus.base = rdev->mc.agp_base; - mem->bus.is_iomem = true; + mem->bus.is_iomem = !rdev->ddev->agp->cant_use_aperture; } #endif break; -- 1.7.1
[PATCH] drm/radeon/kms: record object that have been list reserved
list reservation was too optimistic about ttm object reservation
and could think that an object reserved by some other process
as reserved by the list reservation which was false. Thus when
unreserving the list it might unreserve object that it didn't
reserved in the list. Sorry if it's hard to follow but this
kind of things are just causing headheck.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_object.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5c9ce2b..66a37fb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -261,6 +261,7 @@ struct radeon_bo_list {
unsignedrdomain;
unsignedwdomain;
u32 tiling_flags;
+ boolreserved;
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index a8d18bc..d5b9373 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -301,6 +301,7 @@ int radeon_bo_list_reserve(struct list_head *head)
r = radeon_bo_reserve(lobj->bo, false);
if (unlikely(r != 0))
return r;
+ lobj->reserved = true;
}
return 0;
}
@@ -311,7 +312,7 @@ void radeon_bo_list_unreserve(struct list_head *head)
list_for_each_entry(lobj, head, list) {
/* only unreserve object we successfully reserved */
- if (radeon_bo_is_reserved(lobj->bo))
+ if (lobj->reserved && radeon_bo_is_reserved(lobj->bo))
radeon_bo_unreserve(lobj->bo);
}
}
@@ -322,6 +323,9 @@ int radeon_bo_list_validate(struct list_head *head)
struct radeon_bo *bo;
int r;
+ list_for_each_entry(lobj, head, list) {
+ lobj->reserved = false;
+ }
r = radeon_bo_list_reserve(head);
if (unlikely(r != 0)) {
return r;
--
1.7.0.1
[Bug 28165] TV-out issues
https://bugs.freedesktop.org/show_bug.cgi?id=28165 --- Comment #1 from peter at peter-server.homelinux.net 2010-05-19 07:42:51 PDT --- > But I could also pulg in the dvd player. I can see the bios messages and grub > menu on both screens. I might even see (part of) usplash. Then the dvd player > turns blue, like it is recieving no signal. The main monitor displays the > login > screen at a distorted 1024*768. > When I login my monitor switches to 1440*900, but it shows an out-of-range > error. The image looks a bit noisy, and the refresh rate looks low, like 25Hz. > Especially mouse movement is not fluid. That's with the dvd player connected, but still disabled. xrands shows http://pastebin.com/5vD3TLEu It is properly detected, so I can enable it. The out-of-range thing stops, and things work great on my main monitor. GNOME expands the desktop to the dvd-player, but there's still no signal. Blue, with nothing on it. xrandr now shows http://pastebin.com/tm5TPgFB The funniest thing is it detects an "tv" when I connect the composite wire to the ground wire, (using a screwdriver). So it doesn't really detect anything... But that's a limitation of the composite signal. I booted the system with drm.debug=14, and these are the results: without dvd player: http://pastebin.com/f4ftQBDN with dvd player: http://pastebin.com/AwzLGwcx I ran dmesg at the gdm login screen over ssh. My setup looks like this: http://www.youtube.com/watch?v=NfZvJ-WTTXg Ignore the laptop. I shot the video with fglrx in a good mood. That's very rare... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/edid: fix typo in 1600x1200@75 mode
Spotted by Scott Bertilson.
Fixes fdo bug 28146.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7188674..54d749d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -587,7 +587,7 @@ static struct drm_display_mode drm_dmt_modes[] = {
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1600x1200 at 75Hz */
- { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 2025000, 1600, 1664,
+ { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 202500, 1600, 1664,
1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1600x1200 at 85Hz */
--
1.5.6.3
[Bug 28146] typo in drm_edid.c drm_dmt_modes table
https://bugs.freedesktop.org/show_bug.cgi?id=28146 --- Comment #2 from Alex Deucher 2010-05-19 08:51:05 PDT --- Created an attachment (id=35762) View: https://bugs.freedesktop.org/attachment.cgi?id=35762 Review: https://bugs.freedesktop.org/review?bug=28146&attachment=35762 fix the clock Here's the patch I've sent upstream. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28146] typo in drm_edid.c drm_dmt_modes table
https://bugs.freedesktop.org/show_bug.cgi?id=28146 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Alex Deucher 2010-05-19 08:52:31 PDT --- thanks for spotting this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/edid: fix typo in 1600x1200@75 mode
Alex Deucher wrote:
> Spotted by Scott Bertilson.
> Fixes fdo bug 28146.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7188674..54d749d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -587,7 +587,7 @@ static struct drm_display_mode drm_dmt_modes[] = {
> 1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> /* 1600x1200 at 75Hz */
> - { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 2025000, 1600, 1664,
> + { DRM_MODE("1600x1200", DRM_MODE_TYPE_DRIVER, 202500, 1600, 1664,
> 1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
> /* 1600x1200 at 85Hz */
Looks good.
Reviewed-by: Mark Marshall
[PATCH 0/9] [RFC] fair-lru eviction
On Wed, May 19, 2010 at 09:06:52AM +0100, Chris Wilson wrote: > On Tue, 18 May 2010 23:11:42 +0200, Daniel Vetter > wrote: > > Hi all, > > > > This patch series implements the fair-lru eviction Chris Wilson already > > posted with a twist. It's essentially the same idea & algorithm. > > Differnences versus his patch: > > - Doesn't do any allocations while scanning. > > - Implemented in drm_mm.c > > > > In other words, this should also be usable by ttm. The idea is simple: > > Scan through the lru, marking objects as evictable until there is a > > large area of memory free/free-able. Then walk through all the scanned > > objects in reverse, checking which ones fall into this hole. Finally > > evicting them. > > > > Comments, ideas highly welcome. > > The next adaptation I did was to clean up evict_something to add objects > from the inactive, active&&!pinned&&!write, flushing&&!pinned, > active&&!pinned&&write lists. This reduces the logic in evict_something to > a single scan over the available objects in LRU order. Is this really worth it? I've worried about the rescanning in case there's no suitable hole in the inactive list, too. But we're doing that also in the current code. And the new code doesn't change the algorithmic complexity (still O(number_of_inactive_objects)) so we're not gonna hit an ugly corner case. Furthermore some printk instrumentation showed that for a full cairo-perf-traces run on my i855 only three times (over the hole run, including rescans when new stuff arrived on the inactive list) there was no suitable hole in the inactive list. So I've stopped worrying. > We still need the move-to-inactive-tail upon access by the CPU, and I > think it is acceptable to maintain our preference of the GPU over the CPU. > Recovering memory from the CPU is comparatively cheap. Argh, I've totally forgotten to put that list_move_tail into gem_fault (and probably gtt_(write|read)_fast, too). > Comparing 'while :; do yes > /tmp/yes; done & cairo-perf-trace', there is > no significant delta between the fair LRU and current. I'll rebase my > evict_something() on top of your drm_mm, and rerun the tests. I'm still crunching the numbers, but preliminary benchmarks on my i855 show that there are _no_ regressions in cairo-traces (poppler is the only one to take a hit of 1% which is decently below it's noise floor of 2%;). Speedups are comparable to what you've posted on the list for your patches Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH 3/9] drm: kill drm_mm_node->private
On Wed, May 19, 2010 at 11:25:07AM +0200, Jerome Glisse wrote: > On Tue, May 18, 2010 at 11:11:45PM +0200, Daniel Vetter wrote: > > Only ever assigned, never used. > > > > Signed-off-by: Daniel Vetter > > NAK > > private was to be use when doing range restricted allocation > somehow the patch that use it was drop/forgot/lost along the > was i will try to see i have it and redo it if not. I don't agree for the following reasons: 1) drm_mm _does_ implement range-restricted allocations. And it does not use the private pointer to do so. My new scanning algorithm doesn't implement this (i915 doesn't use range restricted allocations), but it's damn trivial to add. 2) The private pointer was used as a back-pointer to the object. If something like this is needed, making struct drm_mm_node embedable looks like the right approach (perhaps with some driver-private bitfields to distinguish different case). I'm still in the process of shooting down the driver_private gem_object pointer and I don't like doing this right away again ... Can you please point me to the code that needs this private pointer? Then I can see in which way I'm wrong ... ;) > Cheers, > Jerome Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH 0/9] [RFC] fair-lru eviction
On Wed, 19 May 2010 18:57:52 +0200, Daniel Vetter wrote: > On Wed, May 19, 2010 at 09:06:52AM +0100, Chris Wilson wrote: > > The next adaptation I did was to clean up evict_something to add objects > > from the inactive, active&&!pinned&&!write, flushing&&!pinned, > > active&&!pinned&&write lists. This reduces the logic in evict_something to > > a single scan over the available objects in LRU order. > > Is this really worth it? I've worried about the rescanning in case there's > no suitable hole in the inactive list, too. But we're doing that also in > the current code. And the new code doesn't change the algorithmic > complexity (still O(number_of_inactive_objects)) so we're not gonna hit an > ugly corner case. I actually thought it simplified the code and really clarified the rescan logic - which is not at all obvious as it depends upon the caller as well. > Furthermore some printk instrumentation showed that for > a full cairo-perf-traces run on my i855 only three times (over the hole > run, including rescans when new stuff arrived on the inactive list) there > was no suitable hole in the inactive list. So I've stopped worrying. I can generate more... But yes, I don't think cairo-perf-trace is a sufficiently aggressive test. That was why I was trying to apply artificial memory pressure, something I am going to try and refine in future. I guess we will have to look at the games for scenarios that thrash the aperture. > I'm still crunching the numbers, but preliminary benchmarks on my i855 > show that there are _no_ regressions in cairo-traces (poppler is the only > one to take a hit of 1% which is decently below it's noise floor of 2%;). > Speedups are comparable to what you've posted on the list for your patches Excellent! -- Chris Wilson, Intel Open Source Technology Centre
[PATCH -next] fbmem: fix printk format warnings
From: Randy Dunlap
Fix printk formats:
drivers/video/fbmem.c: In function 'fb_do_apertures_overlap':
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 2 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 3 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 4 has type 'resource_size_t'
drivers/video/fbmem.c:1494: warning: format '%llx' expects type 'long long
unsigned int', but argument 5 has type 'resource_size_t'
Signed-off-by: Randy Dunlap
---
drivers/video/fbmem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- linux-next-20100519.orig/drivers/video/fbmem.c
+++ linux-next-20100519/drivers/video/fbmem.c
@@ -1491,7 +1491,10 @@ static bool fb_do_apertures_overlap(stru
for (j = 0; j < gena->count; ++j) {
struct aperture *g = &gena->ranges[j];
printk(KERN_DEBUG "checking generic (%llx %llx) vs hw
(%llx %llx)\n",
- g->base, g->size, h->base, h->size);
+ (unsigned long long)g->base,
+ (unsigned long long)g->size,
+ (unsigned long long)h->base,
+ (unsigned long long)h->size);
if (apertures_overlap(g, h))
return true;
}
[Bug 28163] Static on right part of screen when 3D happens on rv350 using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=28163 --- Comment #2 from Scott Moreau 2010-05-19 12:01:28 PDT --- (In reply to comment #1) > This is already fixed in 2.6.34: > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=commit;h=f46c01208da1881591e3f55ca77d37f54469f8e4 Thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28165] TV-out issues
https://bugs.freedesktop.org/show_bug.cgi?id=28165 --- Comment #2 from peter at peter-server.homelinux.net 2010-05-19 12:29:59 PDT --- I just compiled a fresh kernel from git, as decribed here: http://wiki.x.org/wiki/radeonBuildHowTo#Bleedingedgecodefromdevelopmentbranch Same results as before... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/9] [RFC] fair-lru eviction
Daniel, Daniel Vetter wrote: > Hi all, > > This patch series implements the fair-lru eviction Chris Wilson already > posted with a twist. It's essentially the same idea & algorithm. > Differnences versus his patch: > - Doesn't do any allocations while scanning. > - Implemented in drm_mm.c > > In other words, this should also be usable by ttm. The idea is simple: > Scan through the lru, marking objects as evictable until there is a > large area of memory free/free-able. Then walk through all the scanned > objects in reverse, checking which ones fall into this hole. Finally > evicting them. > > Comments, ideas highly welcome. > > As per usual, I couldn't resist and had to clean up the code in drm_mm.c a > little. > > Yours, Daniel > > While the cleanup of drm_mm.c looks fine to me, I'm not sure the fair eviction is easy to implement with TTM. TTM releases the spinlock protecting the drm_mm manager in between evictions to be able to wait (without holding locks) for bo idle. That means that the lru list may have changed between the first eviction and the next. In practice, drivers either don't allow simultaneous bo validation or should disallow it if thrashing is likely to occur, so the likelyhood of the lru list changing in between evictions should be small but it needs to be taken into account. Nevertheless, the drm_mm.c cleanup is Acked-by: Thomas Hellstrom I'll leave it to the Intel guys to comment on the fair eviction stuff. /Thomas > Daniel Vetter (9): > list.h: add list_for_each_entry_safe_from_reverse > drm: use list_for_each_entry in drm_mm.c > drm: kill drm_mm_node->private > drm: kill dead code in drm_mm.c > drm: sane naming for drm_mm.c > drm_mm: extract check_free_mm_node > drm: implement helper functions for scanning lru list > drm/i915: prepare for fair lru eviction > drm/i915: implement fair lru eviction > > drivers/gpu/drm/drm_mm.c | 359 > - > drivers/gpu/drm/i915/i915_gem.c | 122 - > drivers/gpu/drm/ttm/ttm_bo.c |6 - > drivers/gpu/drm/ttm/ttm_bo_util.c |2 - > include/drm/drm_mm.h | 27 +++- > include/linux/list.h | 15 ++ > 6 files changed, 347 insertions(+), 184 deletions(-) > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 0/9] [RFC] fair-lru eviction
On Wed, May 19, 2010 at 09:51:33PM +0200, Thomas Hellstr?m wrote: > Daniel, > TTM releases the spinlock protecting the drm_mm manager in between > evictions to be able to wait (without holding locks) for bo idle. > That means that the lru list may have changed between the first > eviction and the next. In practice, drivers either don't allow > simultaneous bo validation or should disallow it if thrashing is > likely to occur, so the likelyhood of the lru list changing in > between evictions should be small but it needs to be taken into > account. Well, in my opinion ttm locking optimize for the wrong case: Usually there should be a little bit of room free to fully pipeline everything. And if it there is no room free anymore, performance is gonna dip anyway, so we might as well block. I think the linux vm with the split between asynchronous background writeback and synchronous writeback in case of low amounts of free memory could be used as inspiration. Whatever, I think ttm could use this fair eviction stuff even with the current locking scheme: Do all the accounting under the spinlock, i.e. - scanning the lru - building up the eviction list - mark the memory blocks as free (with drm_mm_put_block) - reserve the complete free hole (needs a new function in drm_mm, but range-restricted allocations are not yet implemented yet, anyway) with a temporary object. Then do the effective eviction outside the spinlock. iirc ttm already uses such shadow (dunno what they're really called) objects for buffer moves. > Nevertheless, the drm_mm.c cleanup is > Acked-by: Thomas Hellstrom Does that include the drm_mm_node->private pointer removal? Jerome naked that one (but I've objected). Just to clarify. > I'll leave it to the Intel guys to comment on the fair eviction stuff. > > /Thomas Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH 0/9] [RFC] fair-lru eviction
On 05/19/2010 10:13 PM, Daniel Vetter wrote: > On Wed, May 19, 2010 at 09:51:33PM +0200, Thomas Hellstr?m wrote: > >> Daniel, >> TTM releases the spinlock protecting the drm_mm manager in between >> evictions to be able to wait (without holding locks) for bo idle. >> That means that the lru list may have changed between the first >> eviction and the next. In practice, drivers either don't allow >> simultaneous bo validation or should disallow it if thrashing is >> likely to occur, so the likelyhood of the lru list changing in >> between evictions should be small but it needs to be taken into >> account. >> > Well, in my opinion ttm locking optimize for the wrong case: Usually there > should be a little bit of room free to fully pipeline everything. And if > it there is no room free anymore, performance is gonna dip anyway, so we > might as well block. Yes, the driver is free to block in such cases if it wants to. It's a matter of taking a command submission rwsem in either read- or write mode. However, a validation sequence of one DRI client shouldn't unnecessarily block other renderers whose render targets / sources are already in memory, but that's only a special case. TTM tries to make sure and encourage driver writers make sure no CPU locks are held while waiting for a GPU, which may turn out to be optimizing for the wrong case in a single-client-single-gpu environment, but turn out to be a good choice in other situations. In any case, the code must take into account that the lru may be modified when the spinlock is released, which I believe you have addressed below. > I think the linux vm with the split between > asynchronous background writeback and synchronous writeback in case of low > amounts of free memory could be used as inspiration. > > Whatever, I think ttm could use this fair eviction stuff even with the > current locking scheme: Do all the accounting under the spinlock, i.e. > - scanning the lru > - building up the eviction list > - mark the memory blocks as free (with drm_mm_put_block) > - reserve the complete free hole (needs a new function in drm_mm, but >range-restricted allocations are not yet implemented yet, anyway) with a >temporary object. > > Then do the effective eviction outside the spinlock. iirc ttm already uses > such shadow (dunno what they're really called) objects for buffer moves. > > >> Nevertheless, the drm_mm.c cleanup is >> Acked-by: Thomas Hellstrom >> > Does that include the drm_mm_node->private pointer removal? Jerome naked > that one (but I've objected). Just to clarify. > > IIRC, Jerome's range validation patches was using that member at some stage. I think if Jerome needs the pointer it should stay. Thanks, Thomas >> I'll leave it to the Intel guys to comment on the fair eviction stuff. >> >> /Thomas >> > Thanks, Daniel >
[Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=27901 --- Comment #4 from Alain Perrot 2010-05-19 15:58:12 PDT --- (In reply to comment #3) > Alain, > > Okay, The patch I just posted might fix this bug. It doesn't cause any > additional errors in piglit either. I think its working right with > http://github.com/jckarter/hello-gl-ch3 too. Of course I have only tested it > on > my RadeonHD 3100 and its my first attempt at r600 assembly so let me know if > it > works for you. > > Note: it could probably be done so its faster but I'm still not to sure on how > everything works yet in the software > > Conn Thanks for your help. Unfortunately, your patch does not fix the cos/sin functions (at least on my Radeon HD 3870 / RV670). The hello-gl-ch3 example works better but still not as expected, you can compare with Mesa software rendering. I tried to play with your patch to make it work without success for now. A note is that there may be a mistake on the last operand to the CNDGT instruction : +setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); +pAsm->S[1].src.rtype = DST_REG_TEMPORARY; +pAsm->S[1].src.reg = tmp2; +setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); should probably be : +setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); +pAsm->S[2].src.rtype = DST_REG_TEMPORARY; +pAsm->S[2].src.reg = tmp2; +setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); But this update does not make the cos/sin functions work. I will try again tomorrow. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
On Wed, May 19, 2010 at 3:58 PM, wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=27901 > > --- Comment #4 from Alain Perrot 2010-05-19 > 15:58:12 PDT --- > (In reply to comment #3) >> Alain, >> >> Okay, The patch I just posted might fix this bug. It doesn't cause any >> additional errors in piglit either. ?I think its working right with >> http://github.com/jckarter/hello-gl-ch3 too. Of course I have only tested it >> on >> my RadeonHD 3100 and its my first attempt at r600 assembly so let me know if >> it >> works for you. >> >> Note: it could probably be done so its faster but I'm still not to sure on >> how >> everything works yet in the software >> >> Conn > > Thanks for your help. > > Unfortunately, your patch does not fix the cos/sin functions (at least on my > Radeon HD 3870 / RV670). The hello-gl-ch3 example works better but still not > as > expected, you can compare with Mesa software rendering. > > I tried to play with your patch to make it work without success for now. A > note > is that there may be a mistake on the last operand to the CNDGT instruction : > > + ? ?setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + ? ?pAsm->S[1].src.rtype = DST_REG_TEMPORARY; > + ? ?pAsm->S[1].src.reg ? = tmp2; > + ? ?setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > should probably be : > > + ? ?setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + ? ?pAsm->S[2].src.rtype = DST_REG_TEMPORARY; > + ? ?pAsm->S[2].src.reg ? = tmp2; > + ? ?setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > But this update does not make the cos/sin functions work. > > I will try again tomorrow. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Alain, Okay I'll look at it some more tonight. At least I know I'm on the right track. Thanks for testing. Conn -- Conn O. Clark Observation: In formal computer science advances are made by standing on the shoulders of giants. Linux has proved that if there are enough of you, you can advance just as far by stepping on each others toes.
[Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=27901 --- Comment #5 from Conn Clark 2010-05-19 16:46:22 PDT --- On Wed, May 19, 2010 at 3:58 PM, wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=27901 > > --- Comment #4 from Alain Perrot 2010-05-19 > 15:58:12 PDT --- > (In reply to comment #3) >> Alain, >> >> Okay, The patch I just posted might fix this bug. It doesn't cause any >> additional errors in piglit either. ?I think its working right with >> http://github.com/jckarter/hello-gl-ch3 too. Of course I have only tested it >> on >> my RadeonHD 3100 and its my first attempt at r600 assembly so let me know if >> it >> works for you. >> >> Note: it could probably be done so its faster but I'm still not to sure on >> how >> everything works yet in the software >> >> Conn > > Thanks for your help. > > Unfortunately, your patch does not fix the cos/sin functions (at least on my > Radeon HD 3870 / RV670). The hello-gl-ch3 example works better but still not > as > expected, you can compare with Mesa software rendering. > > I tried to play with your patch to make it work without success for now. A > note > is that there may be a mistake on the last operand to the CNDGT instruction : > > + ? ?setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + ? ?pAsm->S[1].src.rtype = DST_REG_TEMPORARY; > + ? ?pAsm->S[1].src.reg ? = tmp2; > + ? ?setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > should probably be : > > + ? ?setaddrmode_PVSSRC(&(pAsm->S[2].src), ADDR_ABSOLUTE); > + ? ?pAsm->S[2].src.rtype = DST_REG_TEMPORARY; > + ? ?pAsm->S[2].src.reg ? = tmp2; > + ? ?setswizzle_PVSSRC(&(pAsm->S[2].src), SQ_SEL_X); > > But this update does not make the cos/sin functions work. > > I will try again tomorrow. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Alain, Okay I'll look at it some more tonight. At least I know I'm on the right track. Thanks for testing. Conn -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Try a bit harder to get output on the screen at panic time
On Fri, 9 Apr 2010 15:10:50 -0700 Jesse Barnes wrote: > This set of 3 patches makes it a little more likely we'll get panic > output onto the screen even when X is running, assuming a KMS enabled > stack anyway. > > It gets me from a blank or very sparsely populated black screen at > panic time, to one including the full backtrace and panic output at > panic time (tested with "echo c > /proc/sysrq-trigger" from an X > session). > > It doesn't cover every case; for instance I think it'll fail when X has > disabled the display, but those cases need to be handled with separate > patches anyway (need to add atomic DPMS paths for instance). > > Anyway, please test these out and let me know if they work for you. Ping Linus & Dave again. Have you guys tried these? Really, it's cool. -- Jesse Barnes, Intel Open Source Technology Center
