http://bugs.freedesktop.org/show_bug.cgi?id=23198
--- Comment #5 from Matthias Schiffer 2010-02-01
17:10:53 PST ---
The first patch doesn't make any difference, the second one works well.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #7 from Matthew Garrett 2010-02-01 15:30:56
PST ---
Created an attachment (id=32984)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32984)
Fix nouveau state detection
Can you try this patch?
--
Configure bugmail: http://
If there are no objections, please share them as soon as possible.
On Mon, Feb 1, 2010 at 7:40 PM, Maarten Maathuis wrote:
> Someone should probably check this out on earlier cards as well.
>
> On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis wrote:
>> - We need to disable pgraph fifo access bef
I'm wondering if the write to 0x400824 should be outside the loop,
since it's a flag blocking a ctxprog from continuing.
Anyone know why this one wasn't looping but the pre-nv50 one is?
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis wrote:
> Signed-off-by: Maarten Maathuis
> ---
> drivers/gpu
- We need to disable pgraph fifo access before checking the current channel,
otherwise we could still hit a running ctxprog.
- The writes to 0x400500 are already handled by pgraph->fifo_access and are
therefore redundant, moreover pgraph fifo access should not be reenabled before
current context is
Signed-off-by: Maarten Maathuis
---
drivers/gpu/drm/nouveau/nouveau_irq.c | 140 ++---
1 files changed, 76 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index baa9b3e..475d0f2 100644
--- a/d
Someone should probably check this out on earlier cards as well.
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis wrote:
> - We need to disable pgraph fifo access before checking the current channel,
> otherwise we could still hit a running ctxprog.
> - The writes to 0x400500 are already handled
- ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: Maarten Maathuis
---
drivers/gpu/drm/nouveau/nv50_fifo.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_fifo.c
b/drivers/gpu/drm/nouv
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouve
On Mon, Feb 01, 2010 at 10:50:09AM +0100, Luca Barbieri wrote:
> This patch adds code to allocate semaphores in a dynamic way using
> an algorithm with a lockless fast path.
some minor comments below
>
> 1. Semaphore BOs
>
> Semaphore BOs are BOs containing semaphores. Each is 4KB large and
> c
Luca Barbieri writes:
>> Sounds like premature optimization to me. I'm just stating my personal
>> view here, but I have a feeling a patch with 60% of lines could do very
>> well the same for most realistic cases.
>
> Perhaps, but really, the only thing you would probably save by using
> spinlock
> Sounds like premature optimization to me. I'm just stating my personal
> view here, but I have a feeling a patch with 60% of lines could do very
> well the same for most realistic cases.
Perhaps, but really, the only thing you would probably save by using
spinlocks in the fast path is retrying i
Luca Barbieri writes:
>> How often do we expect cross-channel sync to kick in? Maybe 2-3 times
>> per frame? I suspect contentions will be rare enough to make spinlocks
>> as fast as atomics for all real-life cases, and they don't have such a
>> high maintainability cost. What do you guys think?
http://bugs.freedesktop.org/show_bug.cgi?id=26349
Pavel S. changed:
What|Removed |Added
Attachment #32966|0 |1
is obsolete|
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #6 from Pavel S. 2010-02-01 06:03:55 PST ---
Created an attachment (id=32969)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32969)
acpidump
I screwed my BIOS configuration with VT-d (and did no notice it), so the fist
dump
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #5 from Pavel S. 2010-02-01 05:30:26 PST ---
Created an attachment (id=32967)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32967)
lspci before loading nouveau
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.c
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #4 from Pavel S. 2010-02-01 05:28:22 PST ---
Created an attachment (id=32966)
--> (http://bugs.freedesktop.org/attachment.cgi?id=32966)
acpidump
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
---
> How often do we expect cross-channel sync to kick in? Maybe 2-3 times
> per frame? I suspect contentions will be rare enough to make spinlocks
> as fast as atomics for all real-life cases, and they don't have such a
> high maintainability cost. What do you guys think?
For the case of a single (o
Luca Barbieri writes:
> This patch adds code to allocate semaphores in a dynamic way using
> an algorithm with a lockless fast path.
>
> 1. Semaphore BOs
>
> Semaphore BOs are BOs containing semaphores. Each is 4KB large and
> contains 1024 4-byte semaphores. They are pinned.
>
> Semaphore BOs ar
Luca Barbieri writes:
> nouveau_bo_wait will make the GPU channel wait for fence if possible,
> otherwise falling back to waiting with the CPU using ttm_bo_wait.
>
> The nouveau_fence_sync function currently returns -ENOSYS, and is
> the focus of the next patch.
>
> Signed-off-by: Luca Barbieri
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #3 from Matthew Garrett 2010-02-01 04:52:44
PST ---
Ok - can you install the pmtools package and run the acpidump command as root,
then attach the output?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=ema
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #2 from Pavel S. 2010-02-01 03:49:37 PST ---
(In reply to comment #1)
> Is this a hybrid graphics system?
>
Im' sorry, I forgot that last part of my post...
As far as I know it is something in between a real hybrid an just the
This patch implements the nouveau_fence_sync interface introduced
in the first patch using dynamically allocated semaphores,
introduced in the second patch.
This is tested on NV40, but should work on NV17-NV50 (previous cards
will just fallback to CPU waiting).
Make sure you are using the latest N
This patch adds code to allocate semaphores in a dynamic way using
an algorithm with a lockless fast path.
1. Semaphore BOs
Semaphore BOs are BOs containing semaphores. Each is 4KB large and
contains 1024 4-byte semaphores. They are pinned.
Semaphore BOs are allocated on-demand and freed at devi
nouveau_bo_wait will make the GPU channel wait for fence if possible,
otherwise falling back to waiting with the CPU using ttm_bo_wait.
The nouveau_fence_sync function currently returns -ENOSYS, and is
the focus of the next patch.
Signed-off-by: Luca Barbieri
---
drivers/gpu/drm/nouveau/nouveau
Switching focus to a previously idle firefox and starting to type in the
google bar, the screen locked up (and the display went black and showed 'no
signal').
Ssh'ing into the machine, I found this in dmesg:
[drm] nouveau :01:00.0: Allocating FIFO number 1
[drm] nouveau :01:00.0: nouve
26 matches
Mail list logo
