(resending as git patch)
- unreference state objects so that buffer objects are unreferenced and
eventually destroyed
- free channel at screen's destruction
diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
b/src/gallium/drivers/nouveau/nouveau_screen.c
index e4cf91c..be7735b 100644
---
(resending as git patch)
- unreference pushbuf objects on channel destruction
diff --git a/nouveau/nouveau_channel.c b/nouveau/nouveau_channel.c
index 674c5c3..6f71f89 100644
--- a/nouveau/nouveau_channel.c
+++ b/nouveau/nouveau_channel.c
@@ -111,6 +111,8 @@ nouveau_channel_free(struct
- 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 |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
- This is not yet a generic implementation that will work everywhere, but it's
a start.
- This will fix the corruption surrounding pixmap/texture bo moves on nv50.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |7 ++
Hi,
Every time I boot my laptop (Fedora 12) I get the following complint from
lockdep:
[ 703.936365] ===
[ 703.936369] [ INFO: possible circular locking dependency detected ]
[ 703.936372] 2.6.33-rc2 #154
[ 703.936374]
On 12/27/2009 12:41 PM, Maarten Maathuis wrote:
- 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 |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff
On Sun, Dec 27, 2009 at 2:43 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 12/27/2009 12:41 PM, Maarten Maathuis wrote:
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
To avoid any confusion, make sure your buffers are large enough
means you shouldn't go allocating very small depth/stencil buffers,
because that will waste space. Userspace should never have to worry
about the restrictions themselves.
Maarten.
On Sun, Dec 27, 2009 at 3:28 PM, Maarten Maathuis
http://bugs.freedesktop.org/show_bug.cgi?id=25806
Summary: NV40 vertex corruption (kernel BO deletion too early?)
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority:
It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup
message was printed, but HWACCEL_DISBALED flag was not set.
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 15 +++
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 ++
when nStatus == 0, nouveau_graph_dump_trap_info printks
something like this:
PGRAPH_ERROR - nSource: PROTECTION_ERROR DMA_W_PROTECTION, nStatus:\n
without any information about status - printk additional 0
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
http://bugs.freedesktop.org/show_bug.cgi?id=25806
--- Comment #1 from Luca Barbieri luca.barbi...@gmail.com 2009-12-27
14:13:14 PST ---
Upon further examination, the kernel does seem to have the required logic:
sending a pushbuffer creates a fence, which is put in bo-sync_obj, which is
then
http://bugs.freedesktop.org/show_bug.cgi?id=25806
Francisco Jerez curroje...@riseup.net changed:
What|Removed |Added
Status|NEW |RESOLVED
From: Julia Lawall ju...@diku.dk
Test the just-allocated value for NULL rather than some other value.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression x,y;
statement S;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
(
if ((x) == NULL) S
|
It seems that Noveau is assuming that once the FIFO pointer is past a
command, that command has finished executing, and all the buffers it
used are no longer needed.
However, this seems to be false at least on G71.
In particular, the card may not have even finished reading the input
vertex
Hi,
Luca Barbieri l...@luca-barbieri.com writes:
It seems that Noveau is assuming that once the FIFO pointer is past a
command, that command has finished executing, and all the buffers it
used are no longer needed.
However, this seems to be false at least on G71.
In particular, the card
I figured out the registers.
There is a fence/sync mechanism which apparently triggers after
rendering is finished.
There are two ways to use it, but they trigger at the same time
(spinning in a loop on the CPU checking them, they trigger at the same
iteration or in two successive iterations).
Can you reproduce this with your vertex buffers in VRAM instead of GART?
(to rule out that it's a fencing issue).
Putting the vertex buffers in VRAM makes things almost perfect, but
still with rare artifacts.
In particular, the yellow arrow in dinoshade sometimes becames a
yellow polygon on the
On Mon, Dec 28, 2009 at 1:55 AM, Luca Barbieri l...@luca-barbieri.com wrote:
Can you reproduce this with your vertex buffers in VRAM instead of GART?
(to rule out that it's a fencing issue).
Putting the vertex buffers in VRAM makes things almost perfect, but
still with rare artifacts.
In
Luca Barbieri pisze:
I'm not sure why this hasn't been noticed before though.
Is everyone getting randomly misrendered OpenGL or is my machine
somehow more prone to reusing buffers?
I reported a similar problem about 2 weeks ago. It first became apparent
with NV40 but I also confirmed it
20 matches
Mail list logo
