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 l...@luca-barbieri.com
---
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
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #2 from Pavel S. pa...@freenet.de 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
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #3 from Matthew Garrett mj...@srcf.ucam.org 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:
Luca Barbieri l...@luca-barbieri.com 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 l...@luca-barbieri.com 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.
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 (or a
http://bugs.freedesktop.org/show_bug.cgi?id=26349
Pavel S. pa...@freenet.de changed:
What|Removed |Added
Attachment #32966|0 |1
is obsolete|
Luca Barbieri l...@luca-barbieri.com 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
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 in
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
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
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
- ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
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
Someone should probably check this out on earlier cards as well.
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis madman2...@gmail.com 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
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
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
- 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
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 madman2...@gmail.com wrote:
Signed-off-by: Maarten Maathuis
If there are no objections, please share them as soon as possible.
On Mon, Feb 1, 2010 at 7:40 PM, Maarten Maathuis madman2...@gmail.com wrote:
Someone should probably check this out on earlier cards as well.
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis madman2...@gmail.com wrote:
- We
http://bugs.freedesktop.org/show_bug.cgi?id=26349
--- Comment #7 from Matthew Garrett mj...@srcf.ucam.org 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?
--
http://bugs.freedesktop.org/show_bug.cgi?id=23198
--- Comment #5 from Matthias Schiffer matth...@gamezock.de 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
20 matches
Mail list logo
