Hello,
I got a report from an AROS user that his current card (mentioned above)
has problems in 3D with nouveau - very slow rendering. After some
investigation it turned out the problem is usage of nv41_sgdma_backend
for this card. Once changed into nv04_sgdma_backend card works correctly
C. Bergström pisze:
Hi all,
Hi Christopher
nouveau itself should be relatively easy to port, but what information
do others have with regards to the surrounding dependencies.
I can give you some information my work porting the nouveau/drm/ttm to
AROS (http://www.aros.org/). AROS is
Hello,
Could someone briefly describe (or point me to the documentation) what
can be a reason for getting NV_PFIFO_INTR_DMA_PUSHER status
(nouveau_fifo_irq_handler).
This started happening immediately after I set the nouveau_vram_pushbuf
flag to TRUE ,it's 100% repetitive and causes fences
(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
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
Hi,
Any feedback on those patches? If they are ok, please commit them as I
don't have access to either of repositories.
Best regards,
Krzysztof
Krzysztof Smiechowicz pisze:
- unreference state objects so that buffer objects are unreferenced and
eventually destroyed
- free channel
Krzysztof Smiechowicz pisze:
Hi,
I'm trying to find a place where objects held in
nv40_context-state.hw[] and nv40_screen-state[] are being unreferenced
during pipe_context destruction.
Currently I'm observing that these objects are not unreferenced and
since they hold reference
- unreference state objects so that buffer objects are unreferenced and
eventually destroyed
- free channel at screen's destruction
Index: nv50/nv50_screen.c
===
--- nv50/nv50_screen.c (wersja 32083)
+++ nv50/nv50_screen.c (kopia
- unreference pushbuf objects on channel destruction
Index: nouveau/nouveau_pushbuf.c
===
--- nouveau/nouveau_pushbuf.c (wersja 32082)
+++ nouveau/nouveau_pushbuf.c (kopia robocza)
@@ -262,6 +262,12 @@
return 0;
}
Hi,
I'm trying to find a place where objects held in
nv40_context-state.hw[] and nv40_screen-state[] are being unreferenced
during pipe_context destruction.
Currently I'm observing that these objects are not unreferenced and
since they hold reference to buffer objects, the buffer objects
Hi,
My name is Krzysztof and currently I'm working on porting nouveau
(gallium3d driver + libdrm + drm) to AROS Research OS
(http://www.aros.org). I completed a quite successful port of old drm
(one from libdrm git - now removed) and currently I'm working on drm
port from the nouveau kernel
Christoph Bumiller pisze:
Hi.
Hi, thanks for the quick feedback. :)
Most probably the state tracker calls pipe_buffer_map on the vertex
buffer which (if it was not created as a user buffer) causes an mmap
of it to the user's address space (so either GART system memory pages or
VRAM pages
13 matches
Mail list logo
