Re: Font selection with i915
On Wed, 20 Jan 2010, Corbin Simpson wrote: > FYI the legacy non-KMS path (nomodeset) is deprecated in kernel and > was recently dropped from the X driver. You should be able to use > fbset to change the resolution of your fbcon though. I tried fbset, and it was distinctly unsuccessful. When I ran "fbset 640x480-60", the general appearance of the screen did not change but all new text got squeezed into the upper-left corner in an unreadable form. It's not clear what mode I should specify. The output from "fbset" is rather unhelpful (I didn't save the exact output but this is close): mode: "1280x1024-0" D: 0 MHz H: 0 kHz V: 0 Hz geometry: 1280 1024 1280 1024 32 timings: -1 0 0 0 0 0 0 rgba: 8/16,8/8,8/0,0/0 Alan Stern -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
> Also note that the delayed delete list is not in fence order but in > deletion-time order, which perhaps gives room for more optimizations. You are right. I think then that ttm_bo_delayed_delete may still need to be changed, because it stops when ttm_bo_cleanup_refs returns -EBUSY, which happens when a fence has not been reached. This means that a buffer will need to wait for all previously deleted buffers to become unused, even if it is unused itself. Is this acceptable? What if we get rid of the delayed destroy list, and instead append buffers to be deleted to their fence object, and delete them when the fence is signaled? This also allows to do it more naturally, since the fence object can just keep a normal reference to the buffers it fences, and unreference them on expiration. Then there needs to be no special "delayed destruction" logic, and it would work as if the GPU were keeping a reference to the buffer itself, using fences as a proxy to have the CPU do that work for the GPU. Then the delayed work is no longer "periodically destroy buffers" but rather "periodically check if fences are expired", naturally stopping at the first unexpired one. Drivers that support IRQs on fences could also do the work in the interrupt handler/tasklet instead, avoid the delay jiffies magic number. This may need a NAPI-like interrupt mitigation middle layer for optimal results though. > But isn't an atomic cmpxchg about as costly as a spinlock? I think it's cheaper on all architectures, as otherwise it would be mostly pointless to have it, since you can emulate it with a spinlock. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
When designing this, we should also keep in mind that some drivers (e.g. nouveau) have multiple FIFO channels, and thus we would like a buffer to be referenced for reading by multiple channels at once (and be destroyed only when all fences are expired, obviously). Also, hardware may support on-GPU inter-channel synchronization, and then multiple references may be for writing too. If we use an external dynamically allocated channel/buffer list node, we can support this (if the kernel allocators aren't fast enough, which they should be, we can just keep released ones linked to the bo to speed allocations). Note that in nouveau there is a small hardware limit to channels (up to 128 on nv50), but future hardware may possibly support unlimited channels. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
> We had to do a similar thing in the > Poulsbo driver and it turned out that we could save a significant amount of > CPU by using a delayed workqueue, collecting objects and destroying them > periodically. Yes, indeed, we don't really care about a fence expiring unless we want to use that buffer or we are out of memory. Processing each fence, especially if there is an interrupt per fence, seems unnecessary, since you can just do that work in the cases mentioned above. So, here is a new proposal that should have the best features of all previously considered methods. Assume first that there is a single FIFO channel. We introduce a list of fence nodes, each containing: - A list of buffers NOT to be destroyed having the fence as their sync object (or possibly one for each memory type) - A delayed-destroy list of buffers having the fence as their sync object Fence nodes are added at the end upon emission. They are removed and freed when the buffer count drops to 0 (meaning all buffers have been moved to later fences). Thus, the number of fence nodes does not grow without bounds, but is bounded by the number of buffers. . The LRU lists are changed to only contain unfenced buffers and buffers are initially put on it. When a buffer is fenced, it is removed from the LRU list or its current fence list, and added to the new fence (possibly destroying the old fence node in the process). The reference count of buffer objects is only increased when they are put in a delayed destruction list. Upon deletion, they are destroyed immediately if they are on the LRU list and moved to the corresponding delayed-delete list if they are in the fenced list. ttm_bo_delayed_delete is no longer called by any workqueue, but only on when we run out of memory, before we try eviction. It processes the list until the first unsignalled fence, destroying all buffers it finds and freeing all the fence nodes. All the buffers in the alive lists are put in the LRU list, in the correct order. We may either keep an alive list per memory type, or sort the buffers by memory type (so they are put in the memory type LRU list) at this point Thus, after ttm_bo_delayed_delete, there is the following scenario: 1. Inactive buffers with no references are destroyed 2. Inactive buffers with references are in the LRU list 3. Fenced buffers with no references are in the delayed-destroy list attached to their fence 4. Fenced buffers with references are in the alive list attached to their fence This should have about the same CPU and memory usage of the current code, but the following advantages: 1. Delayed deletion does not run periodically, but exactly when needed (at allocation time, before eviction) 2. Delayed deletion always deletes all buffers that can be deleted, since it processes them in fence order 3. The LRU list at eviction time contains exactly all evictable buffers 4. Each buffer is always on an LRU _or_ on a delayed destroy list, so only one node is necessary 5. Once buffer deletion determines a fence is signalled, it can destroyed all its to-be-destroyed buffers without any more checking 6. Some fence logic (such as signalling of all fences on channel forced closing) can be moved from drivers to TTM 7. Some channel logic can be moved from drivers to TTM 8. The code should be simpler and more elegant Note that using a buffer with the CPU doesn't change its position in the LRU list. This is good, because evicting a buffer used by the CPU is actually a good thing, since it will move to a region of memory slower for the GPU but possibly faster for the CPU. However, for buffers in system memory, if the LRU list is used for swapping, CPU access should move the buffer to the front of list (using the LRU list for this is probably a bad idea though, since system memory swapping should be at page granularity). For multiple channels, things are slightly more complex. First, we need to built the fence data structure for each channel. Also, we need the fence/buffer nodes to be separate Delayed destruction continues to work, but the reference count needs to be set to the number of channels fencing the buffer on destruction. Putting buffers in the LRU list can be done by doing n-way merging between the channel fence lists, assigning each fence a global sequence number, and using that to merge and put back buffers in the LRU. n-way merging can be done with a small heap on the stack on current hardware where channels are limited. Furthermore, we need to keep a reference count, so that buffers are put in the LRU (or destroyed) only after they are off all the channels. The LRU list semantics are relaxed. If a buffer has both its fence emitted before another buffer, and also signaled before it, then it will be considered as "less recently" used, and the opposite thing happens if both are after. Otherwise, the order is undetermined. This should still guarantee good eviction behavior, and allows to have the LRU list only contain evictable buffers, while n
Re: Font selection with i915
since 2.6.32 you can change the resolution with video=VGA-1:640x480 boot parameter and emulate the old behaviour. On 01/20/2010 05:39 PM, Alan Stern wrote: > On Wed, 20 Jan 2010, Corbin Simpson wrote: > > >> FYI the legacy non-KMS path (nomodeset) is deprecated in kernel and >> was recently dropped from the X driver. You should be able to use >> fbset to change the resolution of your fbcon though. >> > I tried fbset, and it was distinctly unsuccessful. When I ran "fbset > 640x480-60", the general appearance of the screen did not change but > all new text got squeezed into the upper-left corner in an unreadable > form. > > It's not clear what mode I should specify. The output from "fbset" is > rather unhelpful (I didn't save the exact output but this is close): > > mode: "1280x1024-0" > D: 0 MHz H: 0 kHz V: 0 Hz > geometry: 1280 1024 1280 1024 32 > timings: -1 0 0 0 0 0 0 > rgba: 8/16,8/8,8/0,0/0 > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/200: fix bug in CS parser
Both patch looks good. On Wed, Jan 20, 2010 at 6:00 PM, Alex Deucher wrote: > From 8097d73afefaf77132df11feb8b9bfa7e52032fe Mon Sep 17 00:00:00 2001 > From: Andrew Randrianasulu > Date: Wed, 20 Jan 2010 11:56:07 -0500 > Subject: [PATCH] drm/radeon/kms/200: fix bug in CS parser > > Add missing vertex shader regs for r200. > > fixed fdo bug 26061 > > agd5f: use official reg names > > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/radeon/reg_srcs/r200 | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/reg_srcs/r200 > b/drivers/gpu/drm/radeon/reg_srcs/r200 > index 6021c88..c29ac43 100644 > --- a/drivers/gpu/drm/radeon/reg_srcs/r200 > +++ b/drivers/gpu/drm/radeon/reg_srcs/r200 > @@ -91,6 +91,8 @@ r200 0x3294 > 0x22b8 SE_TCL_TEX_CYL_WRAP_CTL > 0x22c0 SE_TCL_UCP_VERT_BLEND_CNTL > 0x22c4 SE_TCL_POINT_SPRITE_CNTL > +0x22d0 SE_PVS_CNTL > +0x22d4 SE_PVS_CONST_CNTL > 0x2648 RE_POINTSIZE > 0x26c0 RE_TOP_LEFT > 0x26c4 RE_MISC > -- > 1.5.6.3 > -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Yes it's fine. I sent your patch to Dave with an expanded commit comment for merging. Here is a possible redesign of the mechanism inspired by this issue. It seems that what we are racing against is buffer eviction, due to delayed deletion buffers being still kept on the LRU list. I'm wondering if the delayed deletion design could be changed as follows: 1. Remove to-be-deleted buffers from the LRU list before putting them on delayed delete 2. Change buffer eviction to first do a delayed deletion pass. This should be cheap (and cheaper than the current code) because delayed deletion stops at the first unsignaled fence. 3. Add a new "delayed deletion" lock/semaphore. Then, have ttm_bo_delayed_delete take it for reading and keep it across the function. 4. Inside the delayed deletion lock, grab the LRU lock, copy the delayed delete list head to a local variable, set it to empty and release the lock. 5. Iterate on the privately held list with list_for_each_safe 6. At the end of ttm_bo_delayed_delete, retake the LRU lock and readd the remaining part of our private list at the head of the global list This would prevent uselessly trying to evict delayed-delete buffers (which should be processed in fence order and not LRU order), and also prevent concurrent delayed deletions, which should be more harmful than useful. Furthermore, it should be possible to get rid of list locking in the following way: 1. BOs to be delayed-deleted are added to the head of the initial delayed deletion single linked list, using atomic cmpxchg 2. ttm_bo_delayed_delete takes the delayed deletion lock and grabs the list with an atomic xchg of the head with zero 3. It reverses the list in place, processes the entries and puts them at the end of a second single linked list, the recurring delayed deletion list 4. It processes the recurring delayed deletion list, cleaning up the BOs 5. Finally, the delayed deletion lock is released This makes adding to the delayed deletion list lockless. The LRU list instead inherently needs to be doubly linked, so only RCU could make it lockless, and it seems that may require using an external list node structure (so readers don't suddenly jump to the most recent node), and that would not be a win (except with *lots* of CPUs). Besides, most DRM drivers (except vmware) are taking the BKL around all ioctls and (except nouveau) use a single pushbuffer, so this is a bit moot anyway. What do you think? Anyway, this, if done, would be for the next merge window, or later, while the current fix ought to be merged now. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete (v3, final)
Resending this with Thomas Hellstrom's signoff for merging into 2.6.33
ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(&nentry->list_kref, ttm_bo_release_list);
we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.
However, we then use the next pointer we stored, which is not guaranteed
to be valid.
This was apparently the cause of some Nouveau oopses I experienced.
This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry->next.
v2 updated by me according to Thomas Hellstrom's feedback.
v3 proposed by Thomas Hellstrom. Commit comment updated by me.
Both updates fixed minor efficiency/style issues only and all three versions
should be correct.
Signed-off-by: Luca Barbieri
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 58 ++
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7733c3..1a3e909 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -524,52 +524,44 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
{
struct ttm_bo_global *glob = bdev->glob;
- struct ttm_buffer_object *entry, *nentry;
- struct list_head *list, *next;
- int ret;
+ struct ttm_buffer_object *entry = NULL;
+ int ret = 0;
spin_lock(&glob->lru_lock);
- list_for_each_safe(list, next, &bdev->ddestroy) {
- entry = list_entry(list, struct ttm_buffer_object, ddestroy);
- nentry = NULL;
+ if (list_empty(&bdev->ddestroy))
+ goto out_unlock;
- /*
-* Protect the next list entry from destruction while we
-* unlock the lru_lock.
-*/
+ entry = list_first_entry(&bdev->ddestroy,
+ struct ttm_buffer_object, ddestroy);
+ kref_get(&entry->list_kref);
+
+ for (;;) {
+ struct ttm_buffer_object *nentry = NULL;
- if (next != &bdev->ddestroy) {
- nentry = list_entry(next, struct ttm_buffer_object,
- ddestroy);
+ if (entry->ddestroy.next != &bdev->ddestroy) {
+ nentry = list_first_entry(&entry->ddestroy,
+ struct ttm_buffer_object, ddestroy);
kref_get(&nentry->list_kref);
}
- kref_get(&entry->list_kref);
spin_unlock(&glob->lru_lock);
ret = ttm_bo_cleanup_refs(entry, remove_all);
kref_put(&entry->list_kref, ttm_bo_release_list);
+ entry = nentry;
+
+ if (ret || !entry)
+ goto out;
spin_lock(&glob->lru_lock);
- if (nentry) {
- bool next_onlist = !list_empty(next);
- spin_unlock(&glob->lru_lock);
- kref_put(&nentry->list_kref, ttm_bo_release_list);
- spin_lock(&glob->lru_lock);
- /*
-* Someone might have raced us and removed the
-* next entry from the list. We don't bother restarting
-* list traversal.
-*/
-
- if (!next_onlist)
- break;
- }
- if (ret)
+ if (list_empty(&entry->ddestroy))
break;
}
- ret = !list_empty(&bdev->ddestroy);
- spin_unlock(&glob->lru_lock);
+out_unlock:
+ spin_unlock(&glob->lru_lock);
+out:
+ if (entry)
+ kref_put(&entry->list_kref, ttm_bo_release_list);
return ret;
}
--
1.6.2.5
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] drm/ttm: remove unnecessary save_flags and ttm_flag_masked in ttm_bo_util.c
On Wed, Jan 20, 2010 at 6:48 PM, Thomas Hellstrom wrote: > Yuan, > This looks like an old leftover from a previous cleanup. > > Although, when I look at the code, it seems save_flags should be removed > completely. > Can you take a look at that and respin the patch? Yes. One declaration wasn't removed. The new patch is attached. > > Thanks, > Thomas > 0001-drm-ttm-remove-unnecessary-save_flags-and-ttm_flag_.patch Description: Binary data -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
On 2010.01.20 13:14:23 +, James Simmons wrote: > > It's just adding the backlight api to the intel driver. In fact it gives > the user the ablity to control the brightness of the backlight which I see > is lacking in the intel driver. Wait, this regression has nothing to do with backlight control. We already have backlight drivers for platform specific or ACPI interface, the reason intel driver doesn't hook up one is because if we provide native interface which would be much possible to have state conflict with platform or ACPI way. This problem is just the wrong DPMS state is used for FB blank request. Dave, does my patch look sane? This regression isn't in 2.6.32, but only for .33-rc kernel. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23992] Skybox corruption in Tremulous with KMS enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=23992 --- Comment #6 from Lukasz Krotowski 2010-01-20 15:23:26 PST --- (In reply to comment #5) > Commit you mentioned is "radeong: Fix EGL driver names." which can not fix > that. Maybe some earlier commit was real fixing one. Yup Rafał, my English is not clear enough. "It seems it was fixed in some commit up to NNN" -- that's what I was trying to say. Wild guess would be that blit work by Maciek. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23992] Skybox corruption in Tremulous with KMS enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=23992 --- Comment #5 from Rafał Miłecki 2010-01-20 15:17:37 PST --- (In reply to comment #4) > Seems fixed in mesa commit: c1334ce23550a8321023c0b8fa58ad266199afa1. I'll > watch it and close in couple of days if everything is ok. Commit you mentioned is "radeong: Fix EGL driver names." which can not fix that. Maybe some earlier commit was real fixing one. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23992] Skybox corruption in Tremulous with KMS enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=23992 --- Comment #4 from Lukasz Krotowski 2010-01-20 15:10:28 PST --- Seems fixed in mesa commit: c1334ce23550a8321023c0b8fa58ad266199afa1. I'll watch it and close in couple of days if everything is ok. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26145] New: [KMS] PM patches: inconsistency between clock set and read
http://bugs.freedesktop.org/show_bug.cgi?id=26145 Summary: [KMS] PM patches: inconsistency between clock set and read Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: bjag...@free.fr Using drm-radeon-testing + PM patches (http://people.freedesktop.org/~agd5f/pm/), PM is working just fine on my RV250 but shows inconsistent debug output: for low frequencies, the value read using debugfs is about half of the value set. I have tried arbitrary frequencies (and not just the ones read from the table), and it looks like this weirdness is only reproducible when setting a frequency around half of the default frequency or below that, so I tend to think the problem is just reading the engine clock. br...@leo:~/git/ubuntu-lucid$ dmesg | grep drm | head -n 20 [1.275752] [drm] Initialized drm 1.1.0 20060810 [1.588338] [drm] radeon defaulting to kernel modesetting. [1.588343] [drm] radeon kernel modesetting enabled. [1.592398] [drm] radeon: Initializing kernel modesetting. [1.592520] [drm] register mmio base: 0xC010 [1.592523] [drm] register mmio size: 65536 [1.592931] [drm] GPU reset succeed (RBBM_STATUS=0x0140) [1.592943] [drm] 2 Power State(s) [1.592946] [drm] State 0 Battery [1.592948] [drm]1 Clock Mode(s) [1.592950] [drm]0 engine/memory: 11/11 [1.592953] [drm] State 1 Default (default) [1.592955] [drm]1 Clock Mode(s) [1.592958] [drm]0 engine/memory: 252000/20 [1.592970] [drm] radeon: dynamic power management enabled [1.592972] [drm] radeon: power management initialized [1.593077] [drm] radeon: VRAM 64M [1.593080] [drm] radeon: VRAM from 0x to 0x03FF [1.593082] [drm] radeon: GTT 256M [1.593085] [drm] radeon: GTT from 0xD000 to 0xDFFF br...@leo:~/git/ubuntu-lucid$ dmesg | tail [9.432030] [drm] Requested: e: 25200 m: 2 p: 16 [9.632030] [drm] Setting: e: 25200 m: 2 p: 16 [ 10.532036] [drm] Requested: e: 11000 m: 11000 p: 0 [ 10.732030] [drm] Setting: e: 11000 m: 11000 p: 0 [ 14.808027] eth1: no IPv6 routers present [ 18.857279] lib80211_crypt: registered algorithm 'TKIP' [ 3142.448034] [drm] Requested: e: 25200 m: 2 p: 16 [ 3142.648138] [drm] Setting: e: 25200 m: 2 p: 16 [ 3143.048056] [drm] Requested: e: 11000 m: 11000 p: 0 [ 3143.248056] [drm] Setting: e: 11000 m: 11000 p: 0 br...@leo:~/git/ubuntu-lucid$ cat /sys/kernel/debug/dri/0/radeon_pm_info state: PM_STATE_ACTIVE default engine clock: 252000 kHz current engine clock: 55120 kHz default memory clock: 20 kHz current memory clock: 200250 kHz -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26103] Planeshift is unplayable, almost everything is gray and white
http://bugs.freedesktop.org/show_bug.cgi?id=26103 --- Comment #9 from darkbasic 2010-01-20 14:30:58 PST --- It's a texture compression related problem. If I disable it (Video.OpenGL.MesaForceS3TCEnable = no in data/config/r3dopengl.cfg) it works. Should I close the bug report? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25597] SIGSEGV in _radeon_bo_unref
http://bugs.freedesktop.org/show_bug.cgi?id=25597 --- Comment #5 from Alex Deucher 2010-01-20 14:07:57 PST --- (In reply to comment #4) > I build drm 1st, so it should be enabled with the configure flag. I assume > that the other modules autotdetect it's presence no? Moreover, if not, it > still should work, albeit without KMS. > correct. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25597] SIGSEGV in _radeon_bo_unref
http://bugs.freedesktop.org/show_bug.cgi?id=25597 --- Comment #4 from David Ronis 2010-01-20 13:35:30 PST --- I build drm 1st, so it should be enabled with the configure flag. I assume that the other modules autotdetect it's presence no? Moreover, if not, it still should work, albeit without KMS. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25597] SIGSEGV in _radeon_bo_unref
http://bugs.freedesktop.org/show_bug.cgi?id=25597 --- Comment #3 from Alex Deucher 2010-01-20 13:29:21 PST --- (In reply to comment #2) > One more thing: I'm running with the ati driver with the ATI Radeon 9000 IGP > chip and kernel 2.6.32.3. I configure drm with > --enable-radeon-experimental-api. Could this be an issue? I added the > configure flag from a suggestion in dealing with bug 25355. > You need mesa and xf86-video-ati built against libdrm built with --enable-radeon-experimental-api in order to use KMS. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/r4xx: cleanup atom path
>From 0a08c5213b2f7e36841928f2e127387319ac363b Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 20 Jan 2010 16:22:53 -0500
Subject: [PATCH] drm/radeon/kms/r4xx: cleanup atom path
most of radeon_legacy_atom_set_surface() is taken care
of in atombios_set_base(), so remove the duplicate
setup and move the remaining bits (DISP_MERGE setup and
FP2 sync) to atombios_crtc.c where they are used.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 26 +++-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 63 ---
drivers/gpu/drm/radeon/radeon_mode.h|1 -
3 files changed, 25 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 4ec931b..4acb85c 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -763,6 +763,30 @@ int atombios_crtc_set_base(struct drm_crtc *crtc,
int x, int y,
return radeon_crtc_set_base(crtc, x, y, old_fb);
}
+/* properly set additional regs when using atombios */
+static void radeon_legacy_atom_fixup(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct radeon_device *rdev = dev->dev_private;
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+ u32 disp_merge_cntl;
+
+ switch (radeon_crtc->crtc_id) {
+ case 0:
+ disp_merge_cntl = RREG32(RADEON_DISP_MERGE_CNTL);
+ disp_merge_cntl &= ~RADEON_DISP_RGB_OFFSET_EN;
+ WREG32(RADEON_DISP_MERGE_CNTL, disp_merge_cntl);
+ break;
+ case 1:
+ disp_merge_cntl = RREG32(RADEON_DISP2_MERGE_CNTL);
+ disp_merge_cntl &= ~RADEON_DISP2_RGB_OFFSET_EN;
+ WREG32(RADEON_DISP2_MERGE_CNTL, disp_merge_cntl);
+ WREG32(RADEON_FP_H2_SYNC_STRT_WID,
RREG32(RADEON_CRTC2_H_SYNC_STRT_WID));
+ WREG32(RADEON_FP_V2_SYNC_STRT_WID,
RREG32(RADEON_CRTC2_V_SYNC_STRT_WID));
+ break;
+ }
+}
+
int atombios_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
@@ -785,7 +809,7 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
if (radeon_crtc->crtc_id == 0)
atombios_set_crtc_dtd_timing(crtc, adjusted_mode);
atombios_crtc_set_base(crtc, x, y, old_fb);
- radeon_legacy_atom_set_surface(crtc);
+ radeon_legacy_atom_fixup(crtc);
}
atombios_overscan_setup(crtc, mode, adjusted_mode);
atombios_scaler_setup(crtc);
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 4abeab2..b6d8081 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -339,69 +339,6 @@ void radeon_crtc_dpms(struct drm_crtc *crtc, int mode)
}
}
-/* properly set crtc bpp when using atombios */
-void radeon_legacy_atom_set_surface(struct drm_crtc *crtc)
-{
- struct drm_device *dev = crtc->dev;
- struct radeon_device *rdev = dev->dev_private;
- struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- int format;
- uint32_t crtc_gen_cntl;
- uint32_t disp_merge_cntl;
- uint32_t crtc_pitch;
-
- switch (crtc->fb->bits_per_pixel) {
- case 8:
- format = 2;
- break;
- case 15: /* 555 */
- format = 3;
- break;
- case 16: /* 565 */
- format = 4;
- break;
- case 24: /* RGB */
- format = 5;
- break;
- case 32: /* xRGB */
- format = 6;
- break;
- default:
- return;
- }
-
- crtc_pitch = crtc->fb->pitch / (crtc->fb->bits_per_pixel / 8))
* crtc->fb->bits_per_pixel) +
- ((crtc->fb->bits_per_pixel * 8) - 1)) /
- (crtc->fb->bits_per_pixel * 8));
- crtc_pitch |= crtc_pitch << 16;
-
- WREG32(RADEON_CRTC_PITCH + radeon_crtc->crtc_offset, crtc_pitch);
-
- switch (radeon_crtc->crtc_id) {
- case 0:
- disp_merge_cntl = RREG32(RADEON_DISP_MERGE_CNTL);
- disp_merge_cntl &= ~RADEON_DISP_RGB_OFFSET_EN;
- WREG32(RADEON_DISP_MERGE_CNTL, disp_merge_cntl);
-
- crtc_gen_cntl = RREG32(RADEON_CRTC_GEN_CNTL) & 0xf0ff;
- crtc_gen_cntl |= (format << 8);
- crtc_gen_cntl |= RADEON_CRTC_EXT_DISP_EN;
- WREG32(RADEON_CRTC_GEN_CNTL, crtc_gen_cntl);
- break;
- case 1:
- disp_merge_cntl = RREG32(RADEON_DISP2_MERGE_CNTL);
- disp_merge_cntl &= ~RADEON_DISP2_RGB_OFFSET_EN;
- WREG32(RADEON_DISP2_MERGE_CNTL, disp_merge_cntl
[Bug 25597] SIGSEGV in _radeon_bo_unref
http://bugs.freedesktop.org/show_bug.cgi?id=25597 --- Comment #2 from David Ronis 2010-01-20 13:11:53 PST --- One more thing: I'm running with the ati driver with the ATI Radeon 9000 IGP chip and kernel 2.6.32.3. I configure drm with --enable-radeon-experimental-api. Could this be an issue? I added the configure flag from a suggestion in dealing with bug 25355. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri wrote: > When designing this, we should also keep in mind that some drivers > (e.g. nouveau) have multiple FIFO channels, and thus we would like a > buffer to be referenced for reading by multiple channels at once (and > be destroyed only when all fences are expired, obviously). > Also, hardware may support on-GPU inter-channel synchronization, and > then multiple references may be for writing too. > In the context of the current code, I've been thinking of having a list of fences on each bo to support multiple readers, and also to try to deal with the problem of simultaneous GPU- and CPU readers. But if the hardware supports on-GPU inter-channel synchronization, I figure the code should be smart enough to only wait on the "last" write fence? /Thomas -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri wrote: >> Also note that the delayed delete list is not in fence order but in >> deletion-time order, which perhaps gives room for more optimizations. >> > You are right. > I think then that ttm_bo_delayed_delete may still need to be changed, > because it stops when ttm_bo_cleanup_refs returns -EBUSY, which > happens when a fence has not been reached. > This means that a buffer will need to wait for all previously deleted > buffers to become unused, even if it is unused itself. > Is this acceptable? > Yes, I think it's acceptable if you view it in the context that the most important buffer resources (GPU memory space and physical system memory) are immediately reclaimable through the eviction- and swapping mechanisms. > What if we get rid of the delayed destroy list, and instead append > buffers to be deleted to their fence object, and delete them when the > fence is signaled? > > This also allows to do it more naturally, since the fence object can > just keep a normal reference to the buffers it fences, and unreference > them on expiration. > > Then there needs to be no special "delayed destruction" logic, and it > would work as if the GPU were keeping a reference to the buffer > itself, using fences as a proxy to have the CPU do that work for the > GPU. > > Then the delayed work is no longer "periodically destroy buffers" but > rather "periodically check if fences are expired", naturally stopping > at the first unexpired one. > Drivers that support IRQs on fences could also do the work in the > interrupt handler/tasklet instead, avoid the delay jiffies magic > number. This may need a NAPI-like interrupt mitigation middle layer > for optimal results though. > > Yes, I think that this way, it should definitely be possible to find a more optimal solution. One should keep in mind, however, that we'll probably not able to destroy buffers from within an atomic context, which means we have to schedule a workqueue to do that task. We had to do a similar thing in the Poulsbo driver and it turned out that we could save a significant amount of CPU by using a delayed workqueue, collecting objects and destroying them periodically. /Thomas -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri wrote: > Yes it's fine. I sent your patch to Dave with an expanded commit > comment for merging. > > Here is a possible redesign of the mechanism inspired by this issue. > It seems that what we are racing against is buffer eviction, due to > delayed deletion buffers being still kept on the LRU list. > > I'm wondering if the delayed deletion design could be changed as follows: > 1. Remove to-be-deleted buffers from the LRU list before putting them > on delayed delete > 2. Change buffer eviction to first do a delayed deletion pass. This > should be cheap (and cheaper than the current code) because delayed > deletion stops at the first unsignaled fence. > 3. Add a new "delayed deletion" lock/semaphore. Then, have > ttm_bo_delayed_delete take it for reading and keep it across the > function. > 4. Inside the delayed deletion lock, grab the LRU lock, copy the > delayed delete list head to a local variable, set it to empty and > release the lock. > 5. Iterate on the privately held list with list_for_each_safe > 6. At the end of ttm_bo_delayed_delete, retake the LRU lock and readd > the remaining part of our private list at the head of the global list > > This would prevent uselessly trying to evict delayed-delete buffers > (which should be processed in fence order and not LRU order), and also > prevent concurrent delayed deletions, which should be more harmful > than useful. > Yes. Note that there is a problem with this. If we need to find space for a buffer, we need to be able to guarantee that we've evicted *all* evictable buffers. Even those on the delayed delete list. Otherwise we have no means of guaranteeing a certain available GPU memory space to user-space, so that user-space can predict when to flush. If we remove delayed-delete buffers from the LRU lists, we'd need to empty the delayed-delete list to guarantee that, and we may end up waiting for buffers that aren't even in the relevant memory region. Also note that the delayed delete list is not in fence order but in deletion-time order, which perhaps gives room for more optimizations. > Furthermore, it should be possible to get rid of list locking in the > following way: > 1. BOs to be delayed-deleted are added to the head of the initial > delayed deletion single linked list, using atomic cmpxchg > 2. ttm_bo_delayed_delete takes the delayed deletion lock and grabs the > list with an atomic xchg of the head with zero > 3. It reverses the list in place, processes the entries and puts them > at the end of a second single linked list, the recurring delayed > deletion list > 4. It processes the recurring delayed deletion list, cleaning up the BOs > 5. Finally, the delayed deletion lock is released > > This makes adding to the delayed deletion list lockless. > But isn't an atomic cmpxchg about as costly as a spinlock? > The LRU list instead inherently needs to be doubly linked, so only RCU > could make it lockless, and it seems that may require using an > external list node structure (so readers don't suddenly jump to the > most recent node), and that would not be a win (except with *lots* of > CPUs). > Besides, most DRM drivers (except vmware) are taking the BKL around > all ioctls and (except nouveau) use a single pushbuffer, so this is a > bit moot anyway. > > What do you think? > In general, the more locks we can get rid of, the better, so I'm for that. Note, however, that reserving a buffer and simultaneously taking it off lru lists need to be an atomic operation. The lru lock is currently used to assure that, and I guess we need to preserve that in some way. /Thomas -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Postal 2 on RadeonProgram wiki page
2010/1/20 Corbin Simpson : > On Wed, Jan 20, 2010 at 2:00 AM, Mark Rosenstand wrote: >> Hey guys, >> >> I recently acquired a couple of R700 class cards and was sort of >> surprised how well 3D seemed to work, so I decided to try out one of the >> (very few) games I liked in the past, Postal 2. >> >> The menu works - including people fighting in 3D in the background - and >> the "Monday" splash shows up, but then it only gets to a black screen. >> >> [m...@mjollnir ~]$ postal2awp >> Postal 2 >> Copyright 2003 Running With Scissors, Inc. >> Unreal Engine >> Copyright 2001 Epic Games, Inc. >> IRQ's not enabled, falling back to busy waits: 2 0 >> < starting game from menu, game loads ... > >> bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. >> invalid bo(0x1aef4a10) [0xE04A8000, 0xE04E7000] >> bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. >> invalid bo(0x1aef4a10) [0xD6E5A000, 0xD6E72000] >> bo(0x1ac88730, 778240) is mapped (-1) can't valide it. >> invalid bo(0x1ac88730) [0xD6E5A000, 0xD6E72000] >> bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. >> invalid bo(0x1aef4a10) [0xE1D51000, 0xE1E0F000] >> >> Anyway, considering the game was banned in a few countries and many >> stores, would it be okay to add it to the RadeonProgram wiki page? I see >> the page has some other titles that are more violent than The Sims, but >> given the number of less known titles and the relative popularity of >> Postal 2, I'd like to be sure if it's okay to add. >> >> If anybody are up to testing on better supported chips, the >> win/mac/linux combo DVD is available for $15 including international >> shipping: >> http://store03.prostores.com/servlet/runningwithscissors/the-4/POSTAL-10th-Anniversary-Collector's/Detail > > Go for it. That page is really by users, for users, at this point. Come on, even if this is banned, it doesn't mean you can not talk about it, does it? ;) Put it :) -- Rafał -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Font selection with i915
FYI the legacy non-KMS path (nomodeset) is deprecated in kernel and was recently dropped from the X driver. You should be able to use fbset to change the resolution of your fbcon though. ~ C. On Tue, Jan 19, 2010 at 10:09 AM, Alan Stern wrote: > On Tue, 19 Jan 2010, James Simmons wrote: > >> >> > When Fedora 12 loads i915 during initramfs probing on my system, the >> > driver automatically installs a tiny 160x64 font. How can I prevent it >> > from doing this, or tell it to use a larger 80x25 font instead? >> > >> > Is this documented anywhere? >> >> Not really. Here is how you enable larger fonts. Configure your kernel. Go >> into the Graphics support menu. This the the menu that has the >> DRI/Framebuffer and backlight options. You will see a "Console display >> driver support" option. Select it and you will have a new menu. You will >> see the option "Select compiled-in fonts". Enable that and select the font >> you want. Most likely it will be the Sun 12x22 font. Build your kernel. >> >> Their might be one more setup to do. Some distros like to load a console >> font at boot up. Depending on the distro if that is the case you will have >> to disable it. > > It turns out that preventing the mode switch is easier. Finding it > took a certain amount of digging, but the "nomodeset" kernel parameter > prevents the console from leaving normal VGA mode. If only it were > documented... > > Alan Stern > > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Postal 2 on RadeonProgram wiki page
Go for it. That page is really by users, for users, at this point. On Wed, Jan 20, 2010 at 2:00 AM, Mark Rosenstand wrote: > Hey guys, > > I recently acquired a couple of R700 class cards and was sort of > surprised how well 3D seemed to work, so I decided to try out one of the > (very few) games I liked in the past, Postal 2. > > The menu works - including people fighting in 3D in the background - and > the "Monday" splash shows up, but then it only gets to a black screen. > > [m...@mjollnir ~]$ postal2awp > Postal 2 > Copyright 2003 Running With Scissors, Inc. > Unreal Engine > Copyright 2001 Epic Games, Inc. > IRQ's not enabled, falling back to busy waits: 2 0 > < starting game from menu, game loads ... > > bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. > invalid bo(0x1aef4a10) [0xE04A8000, 0xE04E7000] > bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. > invalid bo(0x1aef4a10) [0xD6E5A000, 0xD6E72000] > bo(0x1ac88730, 778240) is mapped (-1) can't valide it. > invalid bo(0x1ac88730) [0xD6E5A000, 0xD6E72000] > bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. > invalid bo(0x1aef4a10) [0xE1D51000, 0xE1E0F000] > > Anyway, considering the game was banned in a few countries and many > stores, would it be okay to add it to the RadeonProgram wiki page? I see > the page has some other titles that are more violent than The Sims, but > given the number of less known titles and the relative popularity of > Postal 2, I'd like to be sure if it's okay to add. > > If anybody are up to testing on better supported chips, the > win/mac/linux combo DVD is available for $15 including international > shipping: > http://store03.prostores.com/servlet/runningwithscissors/the-4/POSTAL-10th-Anniversary-Collector's/Detail > > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26061] rv280 in KMS mode triggers "Forbidden register 0x22D0"
http://bugs.freedesktop.org/show_bug.cgi?id=26061 --- Comment #2 from Alex Deucher 2010-01-20 09:00:50 PST --- Created an attachment (id=32744) --> (http://bugs.freedesktop.org/attachment.cgi?id=32744) patch for upstream good catch. patch for upstream. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/200: fix bug in CS parser
>From 8097d73afefaf77132df11feb8b9bfa7e52032fe Mon Sep 17 00:00:00 2001 From: Andrew Randrianasulu Date: Wed, 20 Jan 2010 11:56:07 -0500 Subject: [PATCH] drm/radeon/kms/200: fix bug in CS parser Add missing vertex shader regs for r200. fixed fdo bug 26061 agd5f: use official reg names Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/reg_srcs/r200 |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/reg_srcs/r200 b/drivers/gpu/drm/radeon/reg_srcs/r200 index 6021c88..c29ac43 100644 --- a/drivers/gpu/drm/radeon/reg_srcs/r200 +++ b/drivers/gpu/drm/radeon/reg_srcs/r200 @@ -91,6 +91,8 @@ r200 0x3294 0x22b8 SE_TCL_TEX_CYL_WRAP_CTL 0x22c0 SE_TCL_UCP_VERT_BLEND_CNTL 0x22c4 SE_TCL_POINT_SPRITE_CNTL +0x22d0 SE_PVS_CNTL +0x22d4 SE_PVS_CONST_CNTL 0x2648 RE_POINTSIZE 0x26c0 RE_TOP_LEFT 0x26c4 RE_MISC -- 1.5.6.3 From 95865cd65e02fa9ca31017c806a36ccc0f144939 Mon Sep 17 00:00:00 2001 From: Andrew Randrianasulu Date: Wed, 20 Jan 2010 11:36:30 -0500 Subject: [PATCH] drm/radeon/kms/r200: fix bug in CS parser The checks for CUBE and 3D textures were inverted. fixes fdo bug 24159 agd5f: added comments for clarity. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/r200.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c index 2094212..ff1e0cd 100644 --- a/drivers/gpu/drm/radeon/r200.c +++ b/drivers/gpu/drm/radeon/r200.c @@ -371,13 +371,16 @@ int r200_packet0_check(struct radeon_cs_parser *p, case 5: case 6: case 7: + /* 1D/2D */ track->textures[i].tex_coord_type = 0; break; case 1: - track->textures[i].tex_coord_type = 1; + /* CUBE */ + track->textures[i].tex_coord_type = 2; break; case 2: - track->textures[i].tex_coord_type = 2; + /* 3D */ + track->textures[i].tex_coord_type = 1; break; } break; -- 1.5.6.3 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24159] [KMS] radeon module oops with stex3d and rv280
http://bugs.freedesktop.org/show_bug.cgi?id=24159 --- Comment #4 from Alex Deucher 2010-01-20 08:41:58 PST --- Created an attachment (id=32742) --> (http://bugs.freedesktop.org/attachment.cgi?id=32742) patch for upstream good catch. I'm sending this upstream. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/r200: fix bug in CS parser
>From 95865cd65e02fa9ca31017c806a36ccc0f144939 Mon Sep 17 00:00:00 2001 From: Andrew Randrianasulu Date: Wed, 20 Jan 2010 11:36:30 -0500 Subject: [PATCH] drm/radeon/kms/r200: fix bug in CS parser The checks for CUBE and 3D textures were inverted. fixes fdo bug 24159 agd5f: added comments for clarity. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/r200.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c index 2094212..ff1e0cd 100644 --- a/drivers/gpu/drm/radeon/r200.c +++ b/drivers/gpu/drm/radeon/r200.c @@ -371,13 +371,16 @@ int r200_packet0_check(struct radeon_cs_parser *p, case 5: case 6: case 7: + /* 1D/2D */ track->textures[i].tex_coord_type = 0; break; case 1: - track->textures[i].tex_coord_type = 1; + /* CUBE */ + track->textures[i].tex_coord_type = 2; break; case 2: - track->textures[i].tex_coord_type = 2; + /* 3D */ + track->textures[i].tex_coord_type = 1; break; } break; -- 1.5.6.3 From 95865cd65e02fa9ca31017c806a36ccc0f144939 Mon Sep 17 00:00:00 2001 From: Andrew Randrianasulu Date: Wed, 20 Jan 2010 11:36:30 -0500 Subject: [PATCH] drm/radeon/kms/r200: fix bug in CS parser The checks for CUBE and 3D textures were inverted. fixes fdo bug 24159 agd5f: added comments for clarity. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/r200.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r200.c b/drivers/gpu/drm/radeon/r200.c index 2094212..ff1e0cd 100644 --- a/drivers/gpu/drm/radeon/r200.c +++ b/drivers/gpu/drm/radeon/r200.c @@ -371,13 +371,16 @@ int r200_packet0_check(struct radeon_cs_parser *p, case 5: case 6: case 7: + /* 1D/2D */ track->textures[i].tex_coord_type = 0; break; case 1: - track->textures[i].tex_coord_type = 1; + /* CUBE */ + track->textures[i].tex_coord_type = 2; break; case 2: - track->textures[i].tex_coord_type = 2; + /* 3D */ + track->textures[i].tex_coord_type = 1; break; } break; -- 1.5.6.3 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26103] Planeshift is unplayable, almost everything is gray and white
http://bugs.freedesktop.org/show_bug.cgi?id=26103 --- Comment #8 from darkbasic 2010-01-20 07:25:33 PST --- Full pslaunch.sh log: http://pastebin.com/m2a21af5 In-game planeshift screenshot: http://darkbasic.homelinux.com/images/planeshift_ingame.jpeg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26103] Planeshift is unplayable, almost everything is gray and white
http://bugs.freedesktop.org/show_bug.cgi?id=26103 --- Comment #7 from darkbasic 2010-01-20 06:50:51 PST --- I don't know if it is connected to the planeshift issue but this is nexuiz piece-o-cake first location (effects set to low): http://darkbasic.homelinux.com/images/nexuiz_afterglsl1.jpeg This is nexuiz with effects set to high: http://darkbasic.homelinux.com/images/nexuiz_afterglsl2.jpeg I noticed theese problems after the merging of the glsl patches. This is nexuiz with effects set to low (every map except piece-o-cake): http://darkbasic.homelinux.com/images/nexuiz_low.jpeg Everything seems to be ok in the last screenshot (here I even enabled texture compression to test if it works). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
> On 2010.01.19 16:17:56 +, James Simmons wrote: > > Sorry I meant the backlight power management state seperate from the > > encoder state. > > > > > drm_fb_helper_off() will find fb's crtc and attached encoders, then > > > call encoder_funcs->dpms() and turn off crtc, so for your DRM_MODE_DPMS_ON > > > change, it will actually turn encoder on, but what we need for > > > FB_BLANK_NORMAL is to turn off the display. No? > > > > FB_BLANK_NORMAL is not a full power down. Only CRTC is powerdown in this > > mode. > > So how the encoder could tell the meaning of you passed DRM_MODE_DPMS_ON in > this case? which is really turning on everything, or keep port on but turn > off panel power? So you are saying that certian combos of crtc dpms states and encoder dpms states are not possible. Since this can from a user application I assume the DRI layer has to fix this up. > > FB_BLANK_POWERDOWN turns off everything. You are wondering why this > > is the case. If the console blanks and you go to use it again it comes > > back very fast. In FB_BLANK_POWERDOWN mode it takes awhile to come back > > for certain types of displays. I have a old Sony CRT at home. Once powered > > down it takes about 5 to 10 seconds to come back up. > > Isn't this monitor specific issue instead of display device problem? ;) > I don't think any LCD monitor nowadays could have this issue. Don't forget about embedded devices. They can behave in the same way. > > Besides this the real issue is backlight != part of encoder. > > > > A patch will be coming shortly. > > Panel power sequencing for Intel LVDS is controlled by encoder, and closely > related to port state, although we haven't really taken LVDS port > enable/disable > step before Ironlake, I think this is normal case for encoders having > backlight. For non embedded platforms yes. Actually I worked on a embedded platform that used a SiS graphics chip. That chipset also has a backlight for the encoder but the manufacture instead disabled that backlight and instead used a external backlight powered by a external gpio. > Could we just restore back to origin behavior for fixing this in 2.6.33? > Otherwise I don't know if your patch would be too intrusive... It's just adding the backlight api to the intel driver. In fact it gives the user the ablity to control the brightness of the backlight which I see is lacking in the intel driver. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Thomas Hellstrom wrote:
Yes, it looks correct. Although it seems a little unintuitive to enter
the loop with the spinlock held, and exit it with the spinlock not held.
I've attached yet another patch to have that fixed. Could you take a
look at whether it seems OK with you and, in that case, repost it for Dave?
... And the patch.
/Thomas
>From 68972c220abe3ce19eb046d72fa218646168adc7 Mon Sep 17 00:00:00 2001
From: Luca Barbieri
Date: Mon, 18 Jan 2010 19:34:53 +0100
Subject: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete (v2)
ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(&nentry->list_kref, ttm_bo_release_list);
we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.
However, we then use the next pointer we stored, which is not guaranteed
to be valid.
This was apparently the cause of some Nouveau oopses I experienced.
This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry->next.
It should now be correct and free of races, but please double check this.
Updated according to Thomas Hellstrom's feedback.
Signed-off-by: Luca Barbieri
---
drivers/gpu/drm/ttm/ttm_bo.c | 58 ++---
1 files changed, 26 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2920f9a..5dfa41f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -523,52 +523,46 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo, bool remove_all)
static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
{
struct ttm_bo_global *glob = bdev->glob;
- struct ttm_buffer_object *entry, *nentry;
- struct list_head *list, *next;
- int ret;
+ struct ttm_buffer_object *entry;
+ int ret = 0;
spin_lock(&glob->lru_lock);
- list_for_each_safe(list, next, &bdev->ddestroy) {
- entry = list_entry(list, struct ttm_buffer_object, ddestroy);
- nentry = NULL;
+ if (list_empty(&bdev->ddestroy)) {
+ spin_unlock(&glob->lru_lock);
+ return 0;
+ }
- /*
- * Protect the next list entry from destruction while we
- * unlock the lru_lock.
- */
+ entry = list_first_entry(&bdev->ddestroy,
+ struct ttm_buffer_object, ddestroy);
+ kref_get(&entry->list_kref);
+
+ for (;;) {
+ struct ttm_buffer_object *nentry = NULL;
- if (next != &bdev->ddestroy) {
- nentry = list_entry(next, struct ttm_buffer_object,
- ddestroy);
+ if (entry->ddestroy.next != &bdev->ddestroy) {
+ nentry = list_first_entry(&entry->ddestroy,
+struct ttm_buffer_object, ddestroy);
kref_get(&nentry->list_kref);
}
- kref_get(&entry->list_kref);
spin_unlock(&glob->lru_lock);
ret = ttm_bo_cleanup_refs(entry, remove_all);
kref_put(&entry->list_kref, ttm_bo_release_list);
+ entry = nentry;
+
+ if (ret || !entry)
+ break;
spin_lock(&glob->lru_lock);
- if (nentry) {
- bool next_onlist = !list_empty(next);
+
+ if (list_empty(&entry->ddestroy)) {
spin_unlock(&glob->lru_lock);
- kref_put(&nentry->list_kref, ttm_bo_release_list);
- spin_lock(&glob->lru_lock);
- /*
- * Someone might have raced us and removed the
- * next entry from the list. We don't bother restarting
- * list traversal.
- */
-
- if (!next_onlist)
-break;
- }
- if (ret)
break;
+ }
}
- ret = !list_empty(&bdev->ddestroy);
- spin_unlock(&glob->lru_lock);
+ if (entry)
+ kref_put(&entry->list_kref, ttm_bo_release_list);
return ret;
}
--
1.6.3.3
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Thomas Hellstrom wrote:
Thomas Hellstrom wrote:
Yes, it looks correct. Although it seems a little unintuitive to enter
the loop with the spinlock held, and exit it with the spinlock not held.
I've attached yet another patch to have that fixed. Could you take a
look at whether it seems OK with you and, in that case, repost it for Dave?
... And the patch.
/Thomas
Hmm, It seems I should've stayed in bed today. Hopefully this is the
right one...
/Thomas
>From b3dc72cf74d1b8e0eb5f5423fbb0ac975f147f4c Mon Sep 17 00:00:00 2001
From: Luca Barbieri
Date: Mon, 18 Jan 2010 19:34:53 +0100
Subject: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete (v2)
ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(&nentry->list_kref, ttm_bo_release_list);
we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.
However, we then use the next pointer we stored, which is not guaranteed
to be valid.
This was apparently the cause of some Nouveau oopses I experienced.
This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry->next.
It should now be correct and free of races, but please double check this.
Updated according to Thomas Hellstrom's feedback.
Signed-off-by: Luca Barbieri
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 58 ++
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7733c3..1a3e909 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -524,52 +524,44 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo, bool remove_all)
static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
{
struct ttm_bo_global *glob = bdev->glob;
- struct ttm_buffer_object *entry, *nentry;
- struct list_head *list, *next;
- int ret;
+ struct ttm_buffer_object *entry = NULL;
+ int ret = 0;
spin_lock(&glob->lru_lock);
- list_for_each_safe(list, next, &bdev->ddestroy) {
- entry = list_entry(list, struct ttm_buffer_object, ddestroy);
- nentry = NULL;
+ if (list_empty(&bdev->ddestroy))
+ goto out_unlock;
- /*
- * Protect the next list entry from destruction while we
- * unlock the lru_lock.
- */
+ entry = list_first_entry(&bdev->ddestroy,
+ struct ttm_buffer_object, ddestroy);
+ kref_get(&entry->list_kref);
+
+ for (;;) {
+ struct ttm_buffer_object *nentry = NULL;
- if (next != &bdev->ddestroy) {
- nentry = list_entry(next, struct ttm_buffer_object,
- ddestroy);
+ if (entry->ddestroy.next != &bdev->ddestroy) {
+ nentry = list_first_entry(&entry->ddestroy,
+struct ttm_buffer_object, ddestroy);
kref_get(&nentry->list_kref);
}
- kref_get(&entry->list_kref);
spin_unlock(&glob->lru_lock);
ret = ttm_bo_cleanup_refs(entry, remove_all);
kref_put(&entry->list_kref, ttm_bo_release_list);
+ entry = nentry;
+
+ if (ret || !entry)
+ goto out;
spin_lock(&glob->lru_lock);
- if (nentry) {
- bool next_onlist = !list_empty(next);
- spin_unlock(&glob->lru_lock);
- kref_put(&nentry->list_kref, ttm_bo_release_list);
- spin_lock(&glob->lru_lock);
- /*
- * Someone might have raced us and removed the
- * next entry from the list. We don't bother restarting
- * list traversal.
- */
-
- if (!next_onlist)
-break;
- }
- if (ret)
+ if (list_empty(&entry->ddestroy))
break;
}
- ret = !list_empty(&bdev->ddestroy);
- spin_unlock(&glob->lru_lock);
+out_unlock:
+ spin_unlock(&glob->lru_lock);
+out:
+ if (entry)
+ kref_put(&entry->list_kref, ttm_bo_release_list);
return ret;
}
--
1.6.2.5
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Luca Barbieri wrote: >> Would nentry=list_first_entry(&entry->ddestroy, ) work? >> > Yes, it seems a bit less intuitive, but if that's the accepted > practice, let's do that instead. > > >> Here nentry may have been removed from the list by another process, which >> would trigger the unnecessary call, mentioned above. >> > You are right. > > I attached a revised patch. > It's only compile tested, but the changes are small and it should > hopefully work. > Yes, it looks correct. Although it seems a little unintuitive to enter the loop with the spinlock held, and exit it with the spinlock not held. I've attached yet another patch to have that fixed. Could you take a look at whether it seems OK with you and, in that case, repost it for Dave? > The whole function seems more complicated than needed, but I can't > find a way to do it with less code. If we could keep glob->lru_lock > while calling ttm_bo_cleanup_refs things would be much simpler, but > that would require intrusive changes and may not be possible. > Yes, one of the rules of TTM is to avoid calling any kref_put() function that may free an object with a spinlock or a mutex held, since the free function must be able to take whatever mutex or spinlock it likes, otherwise we'd end up in a complete mess of recursive locks and lock dependency errors. Since therefore ttm_bo_cleanup_refs would need to temporarily release any lock held at call time, we wouldn't be better off. /Thomas -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] drm/ttm: remove unnecessary save_flags and ttm_flag_masked in ttm_bo_util.c
Yuan,
This looks like an old leftover from a previous cleanup.
Although, when I look at the code, it seems save_flags should be removed
completely.
Can you take a look at that and respin the patch?
Thanks,
Thomas
Yuan, Shengquan wrote:
> commit d60326ac977a5e99047b44f9b313ff79cd3a14b4
> Author: Austin Yuan
> Date: Tue Jan 19 11:45:24 2010 +0800
>
> drm/ttm: remove unnecessary save_flags and ttm_flag_masked in
> ttm_bo_util.c
>
> Signed-off-by: Austin Yuan
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index ceae52f..a6fca9e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -77,7 +77,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
>
> *old_mem = *new_mem;
> new_mem->mm_node = NULL;
> - ttm_flag_masked(&save_flags, new_mem->placement, TTM_PL_MASK_MEMTYPE);
> +
> return 0;
> }
> EXPORT_SYMBOL(ttm_bo_move_ttm);
> @@ -219,7 +219,6 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> void *old_iomap;
> void *new_iomap;
> int ret;
> - uint32_t save_flags = old_mem->placement;
> unsigned long i;
> unsigned long page;
> unsigned long add = 0;
> @@ -270,7 +269,6 @@ out2:
>
> *old_mem = *new_mem;
> new_mem->mm_node = NULL;
> - ttm_flag_masked(&save_flags, new_mem->placement, TTM_PL_MASK_MEMTYPE);
>
> if ((man->flags & TTM_MEMTYPE_FLAG_FIXED) && (ttm != NULL)) {
> ttm_tt_unbind(ttm);
> @@ -537,7 +535,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
> *bo,
> struct ttm_mem_type_manager *man = &bdev->man[new_mem->mem_type];
> struct ttm_mem_reg *old_mem = &bo->mem;
> int ret;
> - uint32_t save_flags = old_mem->placement;
> struct ttm_buffer_object *ghost_obj;
> void *tmp_obj = NULL;
>
> @@ -598,7 +595,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
> *bo,
>
> *old_mem = *new_mem;
> new_mem->mm_node = NULL;
> - ttm_flag_masked(&save_flags, new_mem->placement, TTM_PL_MASK_MEMTYPE);
> +
> return 0;
> }
> EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
>
> --
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Postal 2 on RadeonProgram wiki page
Hey guys, I recently acquired a couple of R700 class cards and was sort of surprised how well 3D seemed to work, so I decided to try out one of the (very few) games I liked in the past, Postal 2. The menu works - including people fighting in 3D in the background - and the "Monday" splash shows up, but then it only gets to a black screen. [m...@mjollnir ~]$ postal2awp Postal 2 Copyright 2003 Running With Scissors, Inc. Unreal Engine Copyright 2001 Epic Games, Inc. IRQ's not enabled, falling back to busy waits: 2 0 < starting game from menu, game loads ... > bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. invalid bo(0x1aef4a10) [0xE04A8000, 0xE04E7000] bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. invalid bo(0x1aef4a10) [0xD6E5A000, 0xD6E72000] bo(0x1ac88730, 778240) is mapped (-1) can't valide it. invalid bo(0x1ac88730) [0xD6E5A000, 0xD6E72000] bo(0x1aef4a10, 778240) is mapped (-1) can't valide it. invalid bo(0x1aef4a10) [0xE1D51000, 0xE1E0F000] Anyway, considering the game was banned in a few countries and many stores, would it be okay to add it to the RadeonProgram wiki page? I see the page has some other titles that are more violent than The Sims, but given the number of less known titles and the relative popularity of Postal 2, I'd like to be sure if it's okay to add. If anybody are up to testing on better supported chips, the win/mac/linux combo DVD is available for $15 including international shipping: http://store03.prostores.com/servlet/runningwithscissors/the-4/POSTAL-10th-Anniversary-Collector's/Detail -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RFC: xfree: dri2: libdrm as optional
Some drivers use DRI2 protocol but implement their own kernel rendering
mananger. For these drivers, libdrm becomes useless.
The only inconvenient right now to put libdrm optional to X server is
concerning DRI2Authenticate. Such function uses drm_magic_t and drmAuthMagic
symbols from libdrm. So I thought two alternatives.
1. wrap with some macros and set at compilation time:
#ifndef WITH_DRM
typedef unsigned int drm_magic_t;
#endif
Bool
DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
{
#ifdef WITH_DRM
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
if (ds == NULL || drmAuthMagic(ds->fd, magic))
return FALSE;
return TRUE;
#else
return FALSE;
#endif
}
2. hide all trickery inside xorg driver, adding a new field to DRI2InfoRec:
Bool
DRI2Authenticate(ScreenPtr pScreen, unsigned int magic)
{
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
if (ds == NULL || (*ds->AuthMagic)(ds->fd, magic))
return FALSE;
return TRUE;
}
In the first alternative the implementation is straightforward but should be
adjusted at build time. It's ugly. Also, one would want to implement his own
way of clients authentication, or not (sigh) - note though dri2proto states
that this is not mandatory:
"A kernel rendering manager can choose not to implement any
authentication and just allow access to all buffers."
Alternative 2. seems more complete but requires code changes all over the
drivers. I'm more inclined for this alternative... Moreover, for both
alternatives we need to do something with drm_magic_t type - can we just use
unsigned int instead declare such new type?
So what you guys think about this all?
Thanks,
Tiago
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Font selection with i915
On Tue, 19 Jan 2010, James Simmons wrote: > > > When Fedora 12 loads i915 during initramfs probing on my system, the > > driver automatically installs a tiny 160x64 font. How can I prevent it > > from doing this, or tell it to use a larger 80x25 font instead? > > > > Is this documented anywhere? > > Not really. Here is how you enable larger fonts. Configure your kernel. Go > into the Graphics support menu. This the the menu that has the > DRI/Framebuffer and backlight options. You will see a "Console display > driver support" option. Select it and you will have a new menu. You will > see the option "Select compiled-in fonts". Enable that and select the font > you want. Most likely it will be the Sun 12x22 font. Build your kernel. > > Their might be one more setup to do. Some distros like to load a console > font at boot up. Depending on the distro if that is the case you will have > to disable it. It turns out that preventing the mode switch is easier. Finding it took a certain amount of digging, but the "nomodeset" kernel parameter prevents the console from leaving normal VGA mode. If only it were documented... Alan Stern -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: xfree: dri2: libdrm as optional
On Tue, 2010-01-19 at 20:18 +0100, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.
>
> The only inconvenient right now to put libdrm optional to X server is
> concerning DRI2Authenticate. Such function uses drm_magic_t and drmAuthMagic
> symbols from libdrm. So I thought two alternatives.
>
> 1. wrap with some macros and set at compilation time:
>
> #ifndef WITH_DRM
> typedef unsigned int drm_magic_t;
> #endif
>
> Bool
> DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
> {
> #ifdef WITH_DRM
> DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
>
> if (ds == NULL || drmAuthMagic(ds->fd, magic))
>return FALSE;
>
> return TRUE;
> #else
> return FALSE;
> #endif
> }
>
>
> 2. hide all trickery inside xorg driver, adding a new field to DRI2InfoRec:
>
> Bool
> DRI2Authenticate(ScreenPtr pScreen, unsigned int magic)
> {
> DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
> if (ds == NULL || (*ds->AuthMagic)(ds->fd, magic))
> return FALSE;
>
> return TRUE;
> }
>
>
> In the first alternative the implementation is straightforward but should be
> adjusted at build time. It's ugly. Also, one would want to implement his own
> way of clients authentication, or not (sigh) - note though dri2proto states
> that this is not mandatory:
>
> "A kernel rendering manager can choose not to implement any
> authentication and just allow access to all buffers."
>
> Alternative 2. seems more complete but requires code changes all over the
> drivers. I'm more inclined for this alternative... Moreover, for both
> alternatives we need to do something with drm_magic_t type - can we just use
> unsigned int instead declare such new type?
Does it really matter that we would leave the drm_magic_t typedef
defined? In this case, we would just have one ifdef inside
DRI2Authenticate().
But I agree, moving the auth checking into a function in DRI2InfoRec
might be the nicest solution but harder to get in considering it touches
all the drivers.
> So what you guys think about this all?
>
>
> Thanks,
>
> Tiago
> ___
> xorg-devel mailing list
> xorg-de...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
