Re: [Nouveau] Nouveau won't load with GeForce 6150SE nForce 430 (NV40)
On Sun, Feb 6, 2011 at 1:30 AM, Grant emailgr...@gmail.com wrote: I can't seem to get nouveau to load with my onboard GeForce 6150SE nForce 430 which I believe is an NV40 chip. I enabled DRM and DRM_NOUVEAU in the kernel but lspci -v doesn't show any kernel driver in use and Xorg fails to load the module. It does work with the nvidia driver. I'm using Gentoo. Should nouveau work with my card? If so, any idea what I did wrong? Please attach a full dmesg. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv4c broken after october (approx.)
On Wed, Feb 2, 2011 at 6:28 PM, Dzianis Kahanovich maha...@bspu.unibel.by wrote: After october I got broken image on my integrated nv4c chip (are you need precise model?). I don't know precise time points, but now known: in Gentoo portage still 20101010 - good, 20101130 - bad (but I use git version before problems and now - without acceleration/with shadowfb). If I set 32M VRAM - image is semi-broken. I may to do some testings (like testing git by day or try to trace registers), but in first point IMHO this minimal info may help to developers too. Last actions was: installing current kernel (2.6.38-rc2-git8), known nouveau-firmware and current driver libdrm snapshots. This is my screen: http://mahatma.bspu.unibel.by/IMG0035A.jpg (default it was green MJ leafs on background, terminal window and panel on top) PS Even if you omit support of old chips, this is looks semi-working but memory misorganized and in theory still possible to fix. Or no? This is the third report I see today.. for a patch 3-4 months old. At least according to wilder on IRC. http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=c88f13e25b0040c1dd0f93e0ac40f62a6005ce59 17:44 curro wilder: do you get the same corruption with a 1024x768 framebuffer? So what's your resolution and can you try to force 1024x768, as explained there : http://nouveau.freedesktop.org/wiki/KernelModeSetting ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] nvfx: restore BEGIN_RING usage
There is indeed exactly the same problem with MARK_RING. There is always one MARK_RING guarding each OUT_RELOC, but in several cases there is only one MARK_RING for several OUT_RELOC, and some not completely obvious and transparent size computation. coccinelle does not help to check the sizes are correct, but here is manual review : nv30_fragtex nv40_fragtex nvfx_fragprog nvfx_fragtex : direct 1-1 mapping nv04_2d nvfx_state_fb : not direct, but looks correct to me nvfx_vbo : no idea, this one is awful :P On Sun, Dec 26, 2010 at 12:02 PM, Michel Hermier michel.herm...@gmail.com wrote: After cleaning my tree to match this change, I noticed a small potential issue which is not very likely to happens but still migth exist. The MARK_RING required to check OUT_RELOC calls are not updated. The issue is small since whe most probably will runout off pushbuffer space before runing out of relocs and the relocs is well protected introducing only graphical issues. Since you known how to use coccocinelle could you check that the BEGIN_RING followed by OUT_RELOC are guarded with a MARK_RING? 2010/12/25 Xavier Chantry chantry.xav...@gmail.com: Michel Hermier reported libdrm segfault (and kernel crash) on nv40 using gallium : http://www.mail-archive.com/nouveau@lists.freedesktop.org/msg06563.html It turns out these were caused by some missing WAIT_RING (or wrong computation of the WAIT_RING sizes). Unlike all other libdrm_nouveau users, nvfx gallium tried to use a mininum calls of WAIT_RING, one WAIT_RING could apply to many methods for different code paths and spread across several functions. This made it too tricky to find out what the missing or wrong WAIT_RING was. By restoring BEGIN_RING, we force one WAIT_RING per method, and it's much easier to check if the free size required in the pushbuffer is correct. As curro said, let's keep it simple for the maintainers until the big bottlenecks are gone Benchmarked on nv35 with openarena, nexuiz and ut2004 and no performance regression. The core of this patch was made with Coccinelle, with minor manual fixes made on top. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/2] nvfx: restore BEGIN_RING usage
Michel Hermier reported libdrm segfault (and kernel crash) on nv40 using
gallium :
http://www.mail-archive.com/nouveau@lists.freedesktop.org/msg06563.html
It turns out these were caused by some missing WAIT_RING (or wrong
computation of the WAIT_RING sizes). Unlike all other libdrm_nouveau users,
nvfx gallium tried to use a mininum calls of WAIT_RING, one WAIT_RING could
apply to many methods for different code paths and spread across several
functions. This made it too tricky to find out what the missing or wrong
WAIT_RING was.
By restoring BEGIN_RING, we force one WAIT_RING per method, and it's much
easier to check if the free size required in the pushbuffer is correct. As
curro said, let's keep it simple for the maintainers until the big
bottlenecks are gone
Benchmarked on nv35 with openarena, nexuiz and ut2004 and no performance
regression.
The core of this patch was made with Coccinelle, with minor manual fixes
made on top.
---
src/gallium/drivers/nvfx/nv30_fragtex.c|3 +-
src/gallium/drivers/nvfx/nv40_fragtex.c|5 +-
src/gallium/drivers/nvfx/nvfx_context.c|6 +-
src/gallium/drivers/nvfx/nvfx_context.h| 13 +++--
src/gallium/drivers/nvfx/nvfx_draw.c | 14 +++--
src/gallium/drivers/nvfx/nvfx_fragprog.c | 12 ++--
src/gallium/drivers/nvfx/nvfx_fragtex.c|4 +-
src/gallium/drivers/nvfx/nvfx_push.c | 57 +++
src/gallium/drivers/nvfx/nvfx_query.c | 12 ++--
src/gallium/drivers/nvfx/nvfx_screen.c | 70 ++-
src/gallium/drivers/nvfx/nvfx_state_emit.c | 68 +--
src/gallium/drivers/nvfx/nvfx_state_fb.c | 39
src/gallium/drivers/nvfx/nvfx_surface.c|8 ++--
src/gallium/drivers/nvfx/nvfx_vbo.c| 23 +
src/gallium/drivers/nvfx/nvfx_vertprog.c | 14 ++---
15 files changed, 184 insertions(+), 164 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nv30_fragtex.c
b/src/gallium/drivers/nvfx/nv30_fragtex.c
index 951fb20..b609891 100644
--- a/src/gallium/drivers/nvfx/nv30_fragtex.c
+++ b/src/gallium/drivers/nvfx/nv30_fragtex.c
@@ -71,6 +71,7 @@ nv30_fragtex_set(struct nvfx_context *nvfx, int unit)
struct nvfx_sampler_view* sv = (struct
nvfx_sampler_view*)nvfx-fragment_sampler_views[unit];
struct nouveau_bo *bo = ((struct nvfx_miptree
*)sv-base.texture)-base.bo;
struct nouveau_channel* chan = nvfx-screen-base.channel;
+ struct nouveau_grobj *eng3d = nvfx-screen-eng3d;
unsigned txf;
unsigned tex_flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_GART | NOUVEAU_BO_RD;
unsigned use_rect;
@@ -102,7 +103,7 @@ nv30_fragtex_set(struct nvfx_context *nvfx, int unit)
txf = sv-u.nv30.fmt[ps-compare + (use_rect ? 2 : 0)];
MARK_RING(chan, 9, 2);
- OUT_RING(chan, RING_3D(NV30_3D_TEX_OFFSET(unit), 8));
+ BEGIN_RING(chan, eng3d, NV30_3D_TEX_OFFSET(unit), 8);
OUT_RELOC(chan, bo, sv-offset, tex_flags | NOUVEAU_BO_LOW, 0, 0);
OUT_RELOC(chan, bo, txf,
tex_flags | NOUVEAU_BO_OR,
diff --git a/src/gallium/drivers/nvfx/nv40_fragtex.c
b/src/gallium/drivers/nvfx/nv40_fragtex.c
index e8ab403..563183d 100644
--- a/src/gallium/drivers/nvfx/nv40_fragtex.c
+++ b/src/gallium/drivers/nvfx/nv40_fragtex.c
@@ -76,6 +76,7 @@ void
nv40_fragtex_set(struct nvfx_context *nvfx, int unit)
{
struct nouveau_channel* chan = nvfx-screen-base.channel;
+ struct nouveau_grobj *eng3d = nvfx-screen-eng3d;
struct nvfx_sampler_state *ps = nvfx-tex_sampler[unit];
struct nvfx_sampler_view* sv = (struct
nvfx_sampler_view*)nvfx-fragment_sampler_views[unit];
struct nouveau_bo *bo = ((struct nvfx_miptree
*)sv-base.texture)-base.bo;
@@ -87,7 +88,7 @@ nv40_fragtex_set(struct nvfx_context *nvfx, int unit)
txf = sv-u.nv40.fmt[ps-compare] | ps-fmt;
MARK_RING(chan, 11, 2);
- OUT_RING(chan, RING_3D(NV30_3D_TEX_OFFSET(unit), 8));
+ BEGIN_RING(chan, eng3d, NV30_3D_TEX_OFFSET(unit), 8);
OUT_RELOC(chan, bo, sv-offset, tex_flags | NOUVEAU_BO_LOW, 0, 0);
OUT_RELOC(chan, bo, txf, tex_flags | NOUVEAU_BO_OR,
NV30_3D_TEX_FORMAT_DMA0, NV30_3D_TEX_FORMAT_DMA1);
@@ -97,7 +98,7 @@ nv40_fragtex_set(struct nvfx_context *nvfx, int unit)
OUT_RING(chan, ps-filt | sv-filt);
OUT_RING(chan, sv-npot_size);
OUT_RING(chan, ps-bcol);
- OUT_RING(chan, RING_3D(NV40_3D_TEX_SIZE1(unit), 1));
+ BEGIN_RING(chan, eng3d, NV40_3D_TEX_SIZE1(unit), 1);
OUT_RING(chan, sv-u.nv40.npot_size2);
nvfx-hw_txf[unit] = txf;
diff --git a/src/gallium/drivers/nvfx/nvfx_context.c
b/src/gallium/drivers/nvfx/nvfx_context.c
index 95834d2..6c8934d 100644
--- a/src/gallium/drivers/nvfx/nvfx_context.c
+++ b/src/gallium/drivers/nvfx/nvfx_context.c
@@ -13,13 +13,13 @@ nvfx_flush(struct pipe_context *pipe, unsigned flags,
struct nvfx_context *nvfx = nvfx_context(pipe);
[Nouveau] [PATCH] nvfx: restore BEGIN_RING usage
As curro said, let's keep it simple for the maintainers until the big
bottlenecks are gone
Benchmarked on nv35 with openarena, nexuiz and ut2004 and no performance
regression.
The core of this patch was made with Coccinelle, with minor manual fixes
made on top.
---
src/gallium/drivers/nvfx/nv30_fragtex.c|3 +-
src/gallium/drivers/nvfx/nv40_fragtex.c|5 +-
src/gallium/drivers/nvfx/nvfx_context.c|6 +-
src/gallium/drivers/nvfx/nvfx_context.h| 13 +++--
src/gallium/drivers/nvfx/nvfx_draw.c | 14 +++--
src/gallium/drivers/nvfx/nvfx_fragprog.c | 12 ++--
src/gallium/drivers/nvfx/nvfx_fragtex.c|4 +-
src/gallium/drivers/nvfx/nvfx_push.c | 57 +++
src/gallium/drivers/nvfx/nvfx_query.c | 12 ++--
src/gallium/drivers/nvfx/nvfx_screen.c | 70 ++-
src/gallium/drivers/nvfx/nvfx_state_emit.c | 68 +--
src/gallium/drivers/nvfx/nvfx_state_fb.c | 39
src/gallium/drivers/nvfx/nvfx_surface.c|8 ++--
src/gallium/drivers/nvfx/nvfx_vbo.c| 23 +
src/gallium/drivers/nvfx/nvfx_vertprog.c | 14 ++---
15 files changed, 184 insertions(+), 164 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nv30_fragtex.c
b/src/gallium/drivers/nvfx/nv30_fragtex.c
index 951fb20..b609891 100644
--- a/src/gallium/drivers/nvfx/nv30_fragtex.c
+++ b/src/gallium/drivers/nvfx/nv30_fragtex.c
@@ -71,6 +71,7 @@ nv30_fragtex_set(struct nvfx_context *nvfx, int unit)
struct nvfx_sampler_view* sv = (struct
nvfx_sampler_view*)nvfx-fragment_sampler_views[unit];
struct nouveau_bo *bo = ((struct nvfx_miptree
*)sv-base.texture)-base.bo;
struct nouveau_channel* chan = nvfx-screen-base.channel;
+ struct nouveau_grobj *eng3d = nvfx-screen-eng3d;
unsigned txf;
unsigned tex_flags = NOUVEAU_BO_VRAM | NOUVEAU_BO_GART | NOUVEAU_BO_RD;
unsigned use_rect;
@@ -102,7 +103,7 @@ nv30_fragtex_set(struct nvfx_context *nvfx, int unit)
txf = sv-u.nv30.fmt[ps-compare + (use_rect ? 2 : 0)];
MARK_RING(chan, 9, 2);
- OUT_RING(chan, RING_3D(NV30_3D_TEX_OFFSET(unit), 8));
+ BEGIN_RING(chan, eng3d, NV30_3D_TEX_OFFSET(unit), 8);
OUT_RELOC(chan, bo, sv-offset, tex_flags | NOUVEAU_BO_LOW, 0, 0);
OUT_RELOC(chan, bo, txf,
tex_flags | NOUVEAU_BO_OR,
diff --git a/src/gallium/drivers/nvfx/nv40_fragtex.c
b/src/gallium/drivers/nvfx/nv40_fragtex.c
index e8ab403..563183d 100644
--- a/src/gallium/drivers/nvfx/nv40_fragtex.c
+++ b/src/gallium/drivers/nvfx/nv40_fragtex.c
@@ -76,6 +76,7 @@ void
nv40_fragtex_set(struct nvfx_context *nvfx, int unit)
{
struct nouveau_channel* chan = nvfx-screen-base.channel;
+ struct nouveau_grobj *eng3d = nvfx-screen-eng3d;
struct nvfx_sampler_state *ps = nvfx-tex_sampler[unit];
struct nvfx_sampler_view* sv = (struct
nvfx_sampler_view*)nvfx-fragment_sampler_views[unit];
struct nouveau_bo *bo = ((struct nvfx_miptree
*)sv-base.texture)-base.bo;
@@ -87,7 +88,7 @@ nv40_fragtex_set(struct nvfx_context *nvfx, int unit)
txf = sv-u.nv40.fmt[ps-compare] | ps-fmt;
MARK_RING(chan, 11, 2);
- OUT_RING(chan, RING_3D(NV30_3D_TEX_OFFSET(unit), 8));
+ BEGIN_RING(chan, eng3d, NV30_3D_TEX_OFFSET(unit), 8);
OUT_RELOC(chan, bo, sv-offset, tex_flags | NOUVEAU_BO_LOW, 0, 0);
OUT_RELOC(chan, bo, txf, tex_flags | NOUVEAU_BO_OR,
NV30_3D_TEX_FORMAT_DMA0, NV30_3D_TEX_FORMAT_DMA1);
@@ -97,7 +98,7 @@ nv40_fragtex_set(struct nvfx_context *nvfx, int unit)
OUT_RING(chan, ps-filt | sv-filt);
OUT_RING(chan, sv-npot_size);
OUT_RING(chan, ps-bcol);
- OUT_RING(chan, RING_3D(NV40_3D_TEX_SIZE1(unit), 1));
+ BEGIN_RING(chan, eng3d, NV40_3D_TEX_SIZE1(unit), 1);
OUT_RING(chan, sv-u.nv40.npot_size2);
nvfx-hw_txf[unit] = txf;
diff --git a/src/gallium/drivers/nvfx/nvfx_context.c
b/src/gallium/drivers/nvfx/nvfx_context.c
index 95834d2..6c8934d 100644
--- a/src/gallium/drivers/nvfx/nvfx_context.c
+++ b/src/gallium/drivers/nvfx/nvfx_context.c
@@ -13,13 +13,13 @@ nvfx_flush(struct pipe_context *pipe, unsigned flags,
struct nvfx_context *nvfx = nvfx_context(pipe);
struct nvfx_screen *screen = nvfx-screen;
struct nouveau_channel *chan = screen-base.channel;
+ struct nouveau_grobj *eng3d = screen-eng3d;
/* XXX: we need to actually be intelligent here */
if (flags PIPE_FLUSH_TEXTURE_CACHE) {
- WAIT_RING(chan, 4);
- OUT_RING(chan, RING_3D(0x1fd8, 1));
+ BEGIN_RING(chan, eng3d, 0x1fd8, 1);
OUT_RING(chan, 2);
- OUT_RING(chan, RING_3D(0x1fd8, 1));
+ BEGIN_RING(chan, eng3d, 0x1fd8, 1);
OUT_RING(chan, 1);
}
diff --git a/src/gallium/drivers/nvfx/nvfx_context.h
b/src/gallium/drivers/nvfx/nvfx_context.h
Re: [Nouveau] [PATCH] nvfx: restore BEGIN_RING usage
On Mon, Dec 20, 2010 at 10:46 PM, Michel Hermier michel.herm...@gmail.com wrote: Just for my personnal information, how did you benchmarked ? By juging the fps ? These 3 games have built-in benchmark/demo system so I just used it. 20 dec : no patch 840 frames 6.6 seconds 126.4 fps 3.0/7.9/60.0/2.7 ms 931 frames 15.2444695 seconds 61.0713283 fps, one-second fps min/avg/max: 34 71 135 (44 seconds) 9.655401 / 29.729643 / 113.846779 fps -- Score = 29.773331 rand[149038] 20 dec : begin ring patch 840 frames 6.7 seconds 126.2 fps 4.0/7.9/59.0/2.7 ms 931 frames 15.4498180 seconds 60.2596096 fps, one-second fps min/avg/max: 33 70 133 (44 seconds) 9.668166 / 29.757431 / 117.643478 fps -- Score = 29.799963 rand[149038] I usually see a variation of 0.5 - 1 fps between consecutive runs. I don't know if nvfx is more performant on nv40 / pci express, so anyone with the hardware is also welcome to test. If you have the binaries could you also comparbinary size (for reference/culture) I cannot see a difference, but I don't usually look at binary size so feel free to check. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nvfx: restore BEGIN_RING usage
On Mon, Dec 20, 2010 at 11:24 PM, Lucas Stach d...@lynxeye.de wrote: I would really like to test your patch on nv47, but it doesn't apply to current master. It seems to be fixable manually, as only the line numbers in the diff are wrong, but i wonder what's the reason for this. I just applied the mail patch on another box with a fresh master pull. No problem. git am mail.txt ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] libdrm: Make some kernel structures fully initialized
On Fri, Dec 17, 2010 at 1:37 PM, Michel Hermier
michel.herm...@gmail.com wrote:
Hi,
A patch that initialise kernel structures. In addition to reduce the
noise of valgrind when running piglit tests, it may be also
interesting to have these structures fully initialised for the future
in case of some kernel ioctrl changes.
If you send your patch inline (e.g. with git send-email), we can also
review inline which is practical.
Just one comment :
nouveau_bo.c: In function 'nouveau_bo_kalloc':
nouveau_bo.c:116:9: warning: missing braces around initializer
nouveau_bo.c:116:9: warning: (near initialization for 'req.info')
Thats because the first member of drm_nouveau_gem_new is another
structure : drm_nouveau_gem_info
This seems to work:
struct drm_nouveau_gem_new req = { { 0 }, 0, 0 };
And we could also use memset.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] mesa: Patch that fix/add missing WAIT_RING calls
On Thu, Dec 16, 2010 at 12:22 PM, Michel Hermier michel.herm...@gmail.com wrote: Hi, While trying to run a 3D app I needed to modify/add some WAIT_RING calls so the push buffer is properly checked, before we try to blindly push to it (sine OUT_RING don't perform this checks yet, I have a small patch for that for libdrm). I allready discussed about it with lynxeye and shining on IRC. As calim already said (and I again yesterday evening), it seems you failed to account all the existing WAIT_RING already in place. Either someone wants to revert Luca's change and replace back all the WAIT_RING/OUT_RING by BEGIN_RING (which means having to compute the required size once per method, so the size check would be closer to the OUT_RING calls and easier to follow)... ... or we need to actually figure out where the current code exactly fails and why. IE which WAIT_RING is missing or which size is wrongly computed. I think we should try the second path in any case just to see. So please provide us with a precise test-case (like hardware, libdrm assert patch, backtrace of the triggered assert, game used, ...) Thanks :) 12:19 calim also, you realize that the WAIT_RINGs already in the code are supposed to do all the waiting required, right ? 12:19 hermier calim, yes, but some of them have broken or missing values 12:20 calim but it is likely there are counting mistakes and forgotten waits - I was just wondering which if the changes in your patch actually change something 12:20 calim *of the changes 12:20 hermier yes, it changes things 12:21 hermier I have a patch here in libdrm that check the buffer before OUT_RING is successfull 12:22 hermier and it shows that WAIT_RING don't reserve/wait for enought buffer, leading to buffer corruptions 12:24 calim and in which places ? e.g. emit_vertices_* are supposed to work without WAIT_RINGs because the maximum amount of vertices that can be written with the available space has been calculated in advance 12:25 hermier calim, and it failed 12:25 hermier calim, you can't predict that easily 12:26 hermier unless you have the data in your hands 12:26 calim well, then the calculation should be fixed; also, I'd prefer to reintroduce BEGIN_RING in nvfx instead of calling WAIT_RING for single method packets 12:27 calim hermier: you can predict it, the size of a vertex is known, and thus you can derive how many vertices fit into AVAIL_RING(chan) wors 12:28 calim *words 12:28 curro indeed, all those WAIT_RING+OUT_RING's should really be BEGIN_RING's 12:28 curro hermier: ^ 12:29 calim hm, oh - p_overhead in the vertex count calculation has + 64 with the comment magic fix 12:30 calim highly suspicious ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nv04_exa: kill useless WAIT_RING
--- src/nv04_exa.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/nv04_exa.c b/src/nv04_exa.c index 2760d4b..bc20ca3 100644 --- a/src/nv04_exa.c +++ b/src/nv04_exa.c @@ -148,7 +148,6 @@ NV04EXASolid (PixmapPtr pPixmap, int x1, int y1, int x2, int y2) int width = x2-x1; int height = y2-y1; - WAIT_RING (chan, 3); BEGIN_RING(chan, rect, NV04_GDI_RECTANGLE_TEXT_UNCLIPPED_RECTANGLE_POINT(0), 2); OUT_RING (chan, (x1 16) | y1); @@ -278,7 +277,6 @@ NV04EXACopy(PixmapPtr pDstPixmap, int srcX, int srcY, int dstX, int dstY, dstY = 0; } - WAIT_RING (chan, 4); BEGIN_RING(chan, blit, NV01_IMAGE_BLIT_POINT_IN, 3); OUT_RING (chan, (srcY 16) | srcX); OUT_RING (chan, (dstY 16) | dstX); -- 1.7.3.3 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nv50 channel takedown
I am seeing problems on 2.6.36-rc7 based kernels. The error always happens during a channel destruction (always gallium on channel 3 in my tests), and always looks like this : 3[ 612.115977] [drm] nouveau :01:00.0: AIII, invalid/inactive channel id 128 6[ 612.115987] [drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - Ch -1/3 Class 0x5039 Mthd 0x0184 Data 0x:0x0e02 6[ 612.115990] [drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - INVALID_OBJECT This is associated with screen corruptions, mostly all fonts/icons disappearing. The oldest commit where I could see the error during a full piglit run : commit ea645107d204ebb9c6da494b8fc82e03d74e4513 Author: Ben Skeggs bske...@redhat.com Date: Tue Oct 12 08:01:59 2010 +1000 drm/nouveau: fix thinko in channel locking in semaphore path But I might have seen troubles with older commits (still 2.6.36-rc7 based). And I still don't know if the issue is always triggered by the same piglit tests or not. But with a later commit, the issue became much more frequent, triggered by many piglit tests, so I could easily isolate one (fdo10370) which reproduces the issue almost every time : commit 36a7ebda99e904a66188c7304d033e81780455e2 Author: Francisco Jerez curroje...@riseup.net Date: Mon Oct 18 03:53:39 2010 +0200 drm/nouveau: Refactor context destruction to avoid a lock ordering issue. Reversing pfifo and pgraph destruction order as before, and the issue becomes less frequent again. I would love to know if anyone at all ever managed to reproduce this. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv50 channel takedown
On Sun, Dec 12, 2010 at 2:28 PM, Maarten Maathuis madman2...@gmail.com wrote: For some reason this (http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=114432fd006141fa74fb67b2256b2d1dac617d9f) comes to mind, not that it matches the error exactly, but still, consider trying a kernel that includes this commit. There were many changes after the commits I mentioned, but latest git has the same problem. Very easy to trigger the issue. If no one else has the problem, I am wondering if it could be some hardware issue. It is a laptop with a standard nv84, which never had any exotic behavior before. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Decode videos
On Mon, Dec 6, 2010 at 7:35 PM, Mikhail Ramendik m...@ramendik.ru wrote: Hello, http://nouveau.freedesktop.org/wiki/FeatureMatrix lists Decode videos as WIP for NV30 and NV40 seies. As I have an NV44, I would really like to know - what is this feature going to be? VDPAU support for these cards, or XvMC, or something else? According to http://lists.freedesktop.org/archives/nouveau/2010-August/006142.html and the following mails/patches : XvMC. Not sure what is possible on nv40 but that subject was discussed quickly here: http://lists.freedesktop.org/archives/nouveau/2010-May/005726.html ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/3] init ps-context with util_surfaces_get and do_get
Pass pipe_context rather than pipe_screen to util_surfaces_get and
util_surfaces_do_get so that they can check whether the saved pipe_surface
have the current context, and init properly a new pipe_surface with the
current context.
pipe_context is also passed to pipe_surface_reset and pipe_surface_init so
that context initialization is done in one central place.
---
src/gallium/auxiliary/util/u_inlines.h | 13 -
src/gallium/auxiliary/util/u_surfaces.c |6 +++---
src/gallium/auxiliary/util/u_surfaces.h |8
src/gallium/drivers/nvfx/nvfx_miptree.c |3 +--
4 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_inlines.h
b/src/gallium/auxiliary/util/u_inlines.h
index d5bc114..e55aafe 100644
--- a/src/gallium/auxiliary/util/u_inlines.h
+++ b/src/gallium/auxiliary/util/u_inlines.h
@@ -136,8 +136,9 @@ pipe_sampler_view_reference(struct pipe_sampler_view **ptr,
struct pipe_sampler_
}
static INLINE void
-pipe_surface_reset(struct pipe_surface* ps, struct pipe_resource *pt,
- unsigned level, unsigned layer, unsigned flags)
+pipe_surface_reset(struct pipe_context *ctx, struct pipe_surface* ps,
+ struct pipe_resource *pt, unsigned level, unsigned layer,
+ unsigned flags)
{
pipe_resource_reference(ps-texture, pt);
ps-format = pt-format;
@@ -146,15 +147,17 @@ pipe_surface_reset(struct pipe_surface* ps, struct
pipe_resource *pt,
ps-usage = flags;
ps-u.tex.level = level;
ps-u.tex.first_layer = ps-u.tex.last_layer = layer;
+ ps-context = ctx;
}
static INLINE void
-pipe_surface_init(struct pipe_surface* ps, struct pipe_resource *pt,
- unsigned level, unsigned layer, unsigned flags)
+pipe_surface_init(struct pipe_context *ctx, struct pipe_surface* ps,
+ struct pipe_resource *pt, unsigned level, unsigned layer,
+ unsigned flags)
{
ps-texture = 0;
pipe_reference_init(ps-reference, 1);
- pipe_surface_reset(ps, pt, level, layer, flags);
+ pipe_surface_reset(ctx, ps, pt, level, layer, flags);
}
/*
diff --git a/src/gallium/auxiliary/util/u_surfaces.c
b/src/gallium/auxiliary/util/u_surfaces.c
index fd55bd1..b0cfec2 100644
--- a/src/gallium/auxiliary/util/u_surfaces.c
+++ b/src/gallium/auxiliary/util/u_surfaces.c
@@ -31,7 +31,7 @@
boolean
util_surfaces_do_get(struct util_surfaces *us, unsigned surface_struct_size,
- struct pipe_screen *pscreen, struct pipe_resource *pt,
+ struct pipe_context *ctx, struct pipe_resource *pt,
unsigned level, unsigned layer, unsigned flags,
struct pipe_surface **res)
{
@@ -51,7 +51,7 @@ util_surfaces_do_get(struct util_surfaces *us, unsigned
surface_struct_size,
ps = us-u.array[level];
}
- if(ps)
+ if(ps ps-context == ctx)
{
p_atomic_inc(ps-reference.count);
*res = ps;
@@ -65,7 +65,7 @@ util_surfaces_do_get(struct util_surfaces *us, unsigned
surface_struct_size,
return FALSE;
}
- pipe_surface_init(ps, pt, level, layer, flags);
+ pipe_surface_init(ctx, ps, pt, level, layer, flags);
if(pt-target == PIPE_TEXTURE_3D || pt-target == PIPE_TEXTURE_CUBE)
cso_hash_insert(us-u.hash, (layer 8) | level, ps);
diff --git a/src/gallium/auxiliary/util/u_surfaces.h
b/src/gallium/auxiliary/util/u_surfaces.h
index da4fbbf..9581fed 100644
--- a/src/gallium/auxiliary/util/u_surfaces.h
+++ b/src/gallium/auxiliary/util/u_surfaces.h
@@ -45,21 +45,21 @@ struct util_surfaces
/* Return value indicates if the pipe surface result is new */
boolean
util_surfaces_do_get(struct util_surfaces *us, unsigned surface_struct_size,
- struct pipe_screen *pscreen, struct pipe_resource *pt,
+ struct pipe_context *ctx, struct pipe_resource *pt,
unsigned level, unsigned layer, unsigned flags,
struct pipe_surface **res);
/* fast inline path for the very common case */
static INLINE boolean
util_surfaces_get(struct util_surfaces *us, unsigned surface_struct_size,
- struct pipe_screen *pscreen, struct pipe_resource *pt,
+ struct pipe_context *ctx, struct pipe_resource *pt,
unsigned level, unsigned layer, unsigned flags,
struct pipe_surface **res)
{
if(likely((pt-target == PIPE_TEXTURE_2D || pt-target ==
PIPE_TEXTURE_RECT) us-u.array))
{
struct pipe_surface *ps = us-u.array[level];
- if(ps)
+ if(ps ps-context == ctx)
{
p_atomic_inc(ps-reference.count);
*res = ps;
@@ -67,7 +67,7 @@ util_surfaces_get(struct util_surfaces *us, unsigned
surface_struct_size,
}
}
- return util_surfaces_do_get(us, surface_struct_size, pscreen, pt, level,
layer, flags, res);
+ return util_surfaces_do_get(us, surface_struct_size, ctx, pt, level, layer,
[Nouveau] [PATCH 3/3] gallium/trace: check bind_vertex_sampler_states and set_vertex_sampler_views
cso_cache_delete checks if pipe has bind_vertex_sampler_states and
set_vertex_sampler_views so do the same in tr_context.
This avoids a segfault when tracing nvfx driver on piglit
glx-destroycontext-2
---
src/gallium/drivers/trace/tr_context.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/trace/tr_context.c
b/src/gallium/drivers/trace/tr_context.c
index 2fdb6c9..eaabae8 100644
--- a/src/gallium/drivers/trace/tr_context.c
+++ b/src/gallium/drivers/trace/tr_context.c
@@ -314,6 +314,9 @@ trace_context_bind_vertex_sampler_states(struct
pipe_context *_pipe,
struct trace_context *tr_ctx = trace_context(_pipe);
struct pipe_context *pipe = tr_ctx-pipe;
+ if (!pipe-bind_vertex_sampler_states)
+ return;
+
trace_dump_call_begin(pipe_context, bind_vertex_sampler_states);
trace_dump_arg(ptr, pipe);
@@ -980,6 +983,9 @@ trace_context_set_vertex_sampler_views(struct pipe_context
*_pipe,
struct pipe_sampler_view *unwrapped_views[PIPE_MAX_VERTEX_SAMPLERS];
unsigned i;
+ if (!pipe-set_vertex_sampler_views)
+ return;
+
for(i = 0; i num; ++i) {
tr_view = trace_sampler_view(views[i]);
unwrapped_views[i] = tr_view ? tr_view-sampler_view : NULL;
--
1.7.3.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/2] nvfx: fb-nr_cbufs = 1 on nv30
7e1bf946316ff99feaa3f2e85f70b45bd9a77ade changed PIPE_CAP_MAX_RENDER_TARGETS to 1 on nv30. Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- src/gallium/drivers/nvfx/nvfx_state_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nvfx/nvfx_state_fb.c b/src/gallium/drivers/nvfx/nvfx_state_fb.c index 30e48c8..73885de 100644 --- a/src/gallium/drivers/nvfx/nvfx_state_fb.c +++ b/src/gallium/drivers/nvfx/nvfx_state_fb.c @@ -54,7 +54,7 @@ nvfx_framebuffer_prepare(struct nvfx_context *nvfx) int all_swizzled = 1; if(!nvfx-is_nv4x) - assert(fb-nr_cbufs = 2); + assert(fb-nr_cbufs = 1); else assert(fb-nr_cbufs = 4); -- 1.7.3.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/2] nvfx: reset nvfx-hw_zeta
If nvfx_framebuffer prepare and validate were called successively with
fb-zsbuf not NULL and then NULL, nvfx-hw_zeta would contain garbage and
this would cause failures in nvfx_framebuffer_relocate/OUT_RELOC(hw_zeta).
This was triggered by piglit/texwrap 2D GL_DEPTH_COMPONENT24 and caused
first a 'write to user buffer!!' error in libdrm and then worse things.
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/gallium/drivers/nvfx/nvfx_state_fb.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_state_fb.c
b/src/gallium/drivers/nvfx/nvfx_state_fb.c
index 73885de..90eb110 100644
--- a/src/gallium/drivers/nvfx/nvfx_state_fb.c
+++ b/src/gallium/drivers/nvfx/nvfx_state_fb.c
@@ -113,7 +113,9 @@ nvfx_framebuffer_validate(struct nvfx_context *nvfx,
unsigned prepare_result)
nvfx-state.render_temps |=
nvfx_surface_get_render_target(fb-cbufs[i], prepare_result, nvfx-hw_rt[i])
i;
for(; i 4; ++i)
- nvfx-hw_rt[i].bo = 0;
+ nvfx-hw_rt[i].bo = NULL;
+
+ nvfx-hw_zeta.bo = NULL;
if (fb-zsbuf) {
nvfx-state.render_temps |=
nvfx_surface_get_render_target(fb-zsbuf, prepare_result, nvfx-hw_zeta) 7;
--
1.7.3.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 1/2] nvfx: fb-nr_cbufs = 1 on nv30 now
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- src/gallium/drivers/nvfx/nvfx_state_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nvfx/nvfx_state_fb.c b/src/gallium/drivers/nvfx/nvfx_state_fb.c index 30e48c8..73885de 100644 --- a/src/gallium/drivers/nvfx/nvfx_state_fb.c +++ b/src/gallium/drivers/nvfx/nvfx_state_fb.c @@ -54,7 +54,7 @@ nvfx_framebuffer_prepare(struct nvfx_context *nvfx) int all_swizzled = 1; if(!nvfx-is_nv4x) - assert(fb-nr_cbufs = 2); + assert(fb-nr_cbufs = 1); else assert(fb-nr_cbufs = 4); -- 1.7.3.2 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/2] nvfx: use bo_ref for render targets
If nvfx_framebuffer prepare and validate were called successively with
fb-zsbuf not NULL and then NULL, nvfx-hw_zeta would contain garbage and
this would cause failures in nvfx_framebuffer_relocate/OUT_RELOC(hw_zeta).
This was triggered by piglit/texwrap 2D GL_DEPTH_COMPONENT24 and caused
first a 'write to user buffer!!' error in libdrm and then worse things.
When using bo_ref, the bo referenced by nvfx-hw_zeta is preserved properly.
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/gallium/drivers/nvfx/nvfx_context.c |6 ++
src/gallium/drivers/nvfx/nvfx_state_fb.c | 19 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nvfx/nvfx_context.c
b/src/gallium/drivers/nvfx/nvfx_context.c
index 95834d2..93a00aa 100644
--- a/src/gallium/drivers/nvfx/nvfx_context.c
+++ b/src/gallium/drivers/nvfx/nvfx_context.c
@@ -32,10 +32,16 @@ static void
nvfx_destroy(struct pipe_context *pipe)
{
struct nvfx_context *nvfx = nvfx_context(pipe);
+ struct pipe_framebuffer_state *fb = nvfx-framebuffer;
if(nvfx-dummy_fs)
pipe-delete_fs_state(pipe, nvfx-dummy_fs);
+ for (int i = 0; i 4; i++) {
+ nouveau_bo_ref(NULL, nvfx-hw_rt[i].bo);
+ }
+ nouveau_bo_ref(NULL, nvfx-hw_zeta.bo);
+
for(unsigned i = 0; i nvfx-vtxbuf_nr; ++i)
pipe_resource_reference(nvfx-vtxbuf[i].buffer, 0);
pipe_resource_reference(nvfx-idxbuf.buffer, 0);
diff --git a/src/gallium/drivers/nvfx/nvfx_state_fb.c
b/src/gallium/drivers/nvfx/nvfx_state_fb.c
index 73885de..1064837 100644
--- a/src/gallium/drivers/nvfx/nvfx_state_fb.c
+++ b/src/gallium/drivers/nvfx/nvfx_state_fb.c
@@ -30,7 +30,7 @@ nvfx_surface_get_render_target(struct pipe_surface* surf, int
all_swizzled, stru
struct nvfx_surface* ns = (struct nvfx_surface*)surf;
if(!ns-temp)
{
- target-bo = ((struct nvfx_miptree*)surf-texture)-base.bo;
+ nouveau_bo_ref(((struct nvfx_miptree*)surf-texture)-base.bo,
target-bo);
target-offset = surf-offset;
target-pitch = align(ns-pitch, 64);
assert(target-pitch);
@@ -40,7 +40,7 @@ nvfx_surface_get_render_target(struct pipe_surface* surf, int
all_swizzled, stru
{
target-offset = 0;
target-pitch = ns-temp-linear_pitch;
- target-bo = ns-temp-base.bo;
+ nouveau_bo_ref(ns-temp-base.bo, target-bo);
assert(target-pitch);
return TRUE;
}
@@ -91,6 +91,17 @@ nvfx_framebuffer_prepare(struct nvfx_context *nvfx)
return all_swizzled;
}
+static void
+nvfx_release_render_target(struct nvfx_context *nvfx)
+{
+ struct pipe_framebuffer_state *fb = nvfx-framebuffer;
+ int i;
+ for(i = fb-nr_cbufs; i 4; ++i)
+ nouveau_bo_ref(NULL, nvfx-hw_rt[i].bo);
+ if (!fb-zsbuf)
+ nouveau_bo_ref(NULL, nvfx-hw_zeta.bo);
+}
+
void
nvfx_framebuffer_validate(struct nvfx_context *nvfx, unsigned prepare_result)
{
@@ -102,6 +113,8 @@ nvfx_framebuffer_validate(struct nvfx_context *nvfx,
unsigned prepare_result)
unsigned w = fb-width;
unsigned h = fb-height;
+ nvfx_release_render_target(nvfx);
+
rt_enable = (NV30_3D_RT_ENABLE_COLOR0 fb-nr_cbufs) - 1;
if (rt_enable (NV30_3D_RT_ENABLE_COLOR1 |
NV40_3D_RT_ENABLE_COLOR2 | NV40_3D_RT_ENABLE_COLOR3))
@@ -112,8 +125,6 @@ nvfx_framebuffer_validate(struct nvfx_context *nvfx,
unsigned prepare_result)
for (i = 0; i fb-nr_cbufs; i++)
nvfx-state.render_temps |=
nvfx_surface_get_render_target(fb-cbufs[i], prepare_result, nvfx-hw_rt[i])
i;
- for(; i 4; ++i)
- nvfx-hw_rt[i].bo = 0;
if (fb-zsbuf) {
nvfx-state.render_temps |=
nvfx_surface_get_render_target(fb-zsbuf, prepare_result, nvfx-hw_zeta) 7;
--
1.7.3.2
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Tester wanted: Timing management
On Mon, Oct 11, 2010 at 11:01 AM, Martin Peres martin.pe...@ensi-bourges.fr wrote: Hi, Roy Spliet, Emil Velikov and I are working on getting memory timing support to nouveau (http://en.wikipedia.org/wiki/Memory_timings). We badly need your help as the vbios timing table (that stores the timings that should be set when we up/down-clock the memory clocks) contains a lot of magic. If you want to help us, please follow this link: http://github.com/pathscale/pscnv/wiki/TestingTimings For those who already sent us your info and had a bios table containing timing values, please re-read the page, we now also need the strap register now (sorry). Thanking you by advance. I checked the two regs on my nv84 laptop with nouveau and blob at the 3 perf levels. On blob, I see that perf level $i seems to correspond to bios entry $i with i=0,1,2 On nouveau, I always get same value as with blob on max level (2). So two questions : 1) are you not interested in getting the values for each perf level while running the blob ? 2) does it mean that the timings set on boot are already the best ones, at least for my card ? nouveau perf level 0,1,2 00100220: 09162728 0c01080c 0008080c 1e160909 00100230: 28000808 270c0c09 00320137 04090202 same as blob on level 2 blob level 0 00100220: 02040606 0b010707 00020102 19160404 00100230: 28000808 06020702 00320132 04040202 similar to entry 0 level 1 00100220: 050a1112 0b010709 00040305 1b160606 00100230: 28000808 11050905 00320134 04060202 similar to entry 1 level 2 00100220: 09162728 0c01080c 0008080c 1e160909 00100230: 28000808 270c0c09 00320137 04090202 similar to entry 2 Timing table at c706. Version 10. Header: c706: 10 04 0c 10 12 entries c70a: 09 05 05 06 00 06 00 04 00 02 02 01 02 08 00 00 Entry 0: RP(6), RAS(6), RFC(4), RC(2) Registers: 220: 02040606 0b010704 02020102 230: 0808 06020702 c71a: 09 05 07 12 00 11 00 0a 00 05 05 03 04 08 00 00 Entry 1: RP(18), RAS(17), RFC(10), RC(5) Registers: 220: 050a1112 0b010706 04040305 230: 0808 11050705 c72a: 0a 06 0a 28 00 27 00 16 00 09 0c 08 08 08 02 00 Entry 2: RP(40), RAS(39), RFC(22), RC(9) Registers: 220: 09162728 0c010809 0808080c 230: 0808 270c0709 c73a: 0a 06 0b 28 00 27 00 16 00 0c 0c 08 08 08 02 00 Entry 3: RP(40), RAS(39), RFC(22), RC(12) Registers: 220: 0c162728 0c01080a 0808080c 230: 0808 270c070c c74a: 09 05 07 06 00 06 00 04 00 02 02 01 02 08 00 00 Entry 4: RP(6), RAS(6), RFC(4), RC(2) Registers: 220: 02040606 0b010706 02020102 230: 0808 06020702 c75a: 0c 07 0b 24 00 2d 00 1a 00 0d 0c 08 08 07 02 00 Entry 5: RP(36), RAS(45), RFC(26), RC(13) Registers: 220: 0d1a2d24 0e01090a 0808080c 230: 0707 2d0c070d ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] OT: compilation
2010/10/7 Grzesiek Sójka p...@pfu.pl: I have two problems with the kernel compilation. 1. I have a small rootfs. It is too small to put all the modules there without gzipping it first. So installing it requires lots of sweating. That is why I was wondering if there is a (more/less easy) way to make the make modules_install command gzip the modules on the fly. No idea if you can do that but here are some possible alternatives : 1) increase the size of your rootfs 2) remove modules you don't need and change from modules to builtin for features or drivers that you don't need to unload/reload 3) a quick googling showed me this patch : http://www.mail-archive.com/linux-ker...@vger.kernel.org/msg271865.html However it seems to install first then compress so if that's the case, you will need to adapt it to your need 4) set INSTALL_MOD_PATH to a prefix , compress modules , then move to /lib/modules/ LOCALVERSION_AUTO is found in : make menuconfig General Setup Automatically append version information to the version string ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Canvas in Firefox, corruption
On Mon, Oct 4, 2010 at 6:27 PM, Maarten Maathuis madman2...@gmail.com wrote: On Mon, Oct 4, 2010 at 2:29 PM, Xavier Chantry chantry.xav...@gmail.com wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=587499#c1 Or alternatively PAD repeat can be set on the source images at least in some cases. Everything depends on whether it is preferable (for performance reasons) to have SRC compositing operation instead of OVER for some images which are known to be opaque. Also see bug 568767 for more details. What do you think of this comment, how does nouveau handle that ? nv40+ will be fine, older cards can't repeat NPOT textures. So in that sense switching to ARGB is better than RepeatPad. 3 new comments after I posted your answer there. It would really be awesome if you could just check directly in the bug report what they are saying, and comment if necessary :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Canvas in Firefox, corruption
On Wed, Aug 18, 2010 at 11:51 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Sun, Aug 15, 2010 at 12:48 AM, Maarten Maathuis madman2...@gmail.com wrote: Maybe someone should tell mozilla to use ARGB instead of XRGB, because that will be hardware accelerated (XRender and opengl disagree on what should be sampled when going outside the texture without an alpha channel). You are very welcome to add any corrections or clarifications to the report. https://bugzilla.mozilla.org/show_bug.cgi?id=587499 https://bugzilla.mozilla.org/show_bug.cgi?id=587499#c1 Or alternatively PAD repeat can be set on the source images at least in some cases. Everything depends on whether it is preferable (for performance reasons) to have SRC compositing operation instead of OVER for some images which are known to be opaque. Also see bug 568767 for more details. What do you think of this comment, how does nouveau handle that ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Canvas in Firefox, corruption
On Sun, Aug 15, 2010 at 12:48 AM, Maarten Maathuis madman2...@gmail.com wrote: Maybe someone should tell mozilla to use ARGB instead of XRGB, because that will be hardware accelerated (XRender and opengl disagree on what should be sampled when going outside the texture without an alpha channel). You are very welcome to add any corrections or clarifications to the report. https://bugzilla.mozilla.org/show_bug.cgi?id=587499 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] RFC: gallium-msaa branch merge
Ok, after looking at how some other drivers were updated, I thought nouveau needed bigger changes than that. Jakob just pushed a simple build fix, and now nv50 builds and runs (almost ;)). I just noticed 5 piglit regressions : fbo/fbo-copypix fbo/fbo-copyteximage general/scissor-copypixels texturing/depth-level-clamp texturing/texredefine And I am not sure how important is the TODO mentioned in the commit log below. commit b59b23a51dc17da59ccff0b3f8a73009056746e5 Author: Roland Scheidegger srol...@vmware.com Date: Mon May 17 21:28:14 2010 +0200 nouveau: adapt to interface changes this probably needs further cleanup (just getting a surface for the resource seems quite nonoptimal and potentially cause unnecessary copies I think) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nv50 piglit change between 7.8 and master
7.8 branch (533b7663) : 209/246 master branch (c882c31) : 216/241 In short : 8 fail/warn - pass 5 fail - skip 1 pass - fail So the only regression is glean/clipFlat Output: -- Test clipping with flat shading (provoking vertex). clipFlat: Failure for glBegin/End(GL_QUADS), glFrontFace(GL_CCW) GL_EXT_provoking_vertex test: GL_FIRST_VERTEX_CONVENTION_EXT mode Expected color (0, 1, 0) but found (1, 0, 0) clipFlat: FAIL rgba8, db, z24, s8, win+pmap, id 33 If anyone cares, I can host the detailed html results somewhere. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nv50 : fix too long shader uploads by splitting them
This fixes fp-long-alu test which failed/stopped at depth 3077 with the
following kernel errors :
[drm] nouveau :01:00.0: Allocating FIFO number 3
[drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 3
[drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - Ch 3/3 Class 0x502d
Mthd 0x0838 Data 0x0001:0x0001e0f8
[drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - INVALID_VALUE
[drm] nouveau :01:00.0: PGRAPH_TRAP - Ch 3/7 Class 0x8297 Mthd
0x15e0 Data 0x:0x
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 0:
INVALID_OPCODE at 00 warp 4, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 1:
INVALID_OPCODE at 00 warp 1, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 1 MP 0:
INVALID_OPCODE at 00 warp 3, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 1 MP 1:
INVALID_OPCODE at 00 warp 4, opcode
[drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 3
Just one mystery, fp-long-alu test still fails if I split upload at 65536
(supposed to be the max value), without triggering any pgraph errors.
Any lower value (256 aligned) works.
Thanks to Christoph Bumiller and Marcin Kościelnicki for the help !
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/gallium/drivers/nv50/nv50_program.c | 23 +++
src/gallium/drivers/nv50/nv50_transfer.c |3 ---
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_program.c
b/src/gallium/drivers/nv50/nv50_program.c
index 0156ff9..9a41f44 100644
--- a/src/gallium/drivers/nv50/nv50_program.c
+++ b/src/gallium/drivers/nv50/nv50_program.c
@@ -4207,10 +4207,13 @@ nv50_program_validate_data(struct nv50_context *nv50,
struct nv50_program *p)
static void
nv50_program_validate_code(struct nv50_context *nv50, struct nv50_program *p)
{
+ struct nouveau_grobj *tesla = nv50-screen-tesla;
struct nouveau_channel *chan = nv50-screen-base.channel;
struct nv50_program_exec *e;
uint32_t *up, i;
boolean upload = FALSE;
+ unsigned offset;
+ int width;
if (!p-bo) {
nouveau_bo_new(chan-device, NOUVEAU_BO_VRAM, 0x100,
@@ -4267,10 +4270,22 @@ nv50_program_validate_code(struct nv50_context *nv50,
struct nv50_program *p)
NOUVEAU_ERR(0x%08x\n, e-inst[1]);
}
#endif
- nv50_upload_sifc(nv50, p-bo, 0, NOUVEAU_BO_VRAM,
-NV50_2D_DST_FORMAT_R8_UNORM, 65536, 1, 262144,
-up, NV50_2D_SIFC_FORMAT_R8_UNORM, 0,
-0, 0, p-exec_size * 4, 1, 1);
+
+ /* SIFC_HEIGHT/SIFC_WIDTH of 65536 do not work, and are not reported
+* as data error either. hw bug ? */
+#define SIFC_MAX_WIDTH (65536-256)
+ offset = 0;
+ width = p-exec_size * 4;
+ while(width 0) {
+ nv50_upload_sifc(nv50, p-bo, offset, NOUVEAU_BO_VRAM,
+ NV50_2D_DST_FORMAT_R8_UNORM, 65536, 1, 262144,
+ up[offset / 4], NV50_2D_SIFC_FORMAT_R8_UNORM,
0,
+ 0, 0, MIN2(SIFC_MAX_WIDTH, width), 1, 1);
+ width -= SIFC_MAX_WIDTH;
+ offset += SIFC_MAX_WIDTH;
+ }
+ BEGIN_RING(chan, tesla, NV50TCL_CODE_CB_FLUSH, 1);
+ OUT_RING (chan, 0);
FREE(up);
}
diff --git a/src/gallium/drivers/nv50/nv50_transfer.c
b/src/gallium/drivers/nv50/nv50_transfer.c
index c5581a6..8b66c42 100644
--- a/src/gallium/drivers/nv50/nv50_transfer.c
+++ b/src/gallium/drivers/nv50/nv50_transfer.c
@@ -274,7 +274,6 @@ nv50_upload_sifc(struct nv50_context *nv50,
{
struct nouveau_channel *chan = nv50-screen-base.channel;
struct nouveau_grobj *eng2d = nv50-screen-eng2d;
- struct nouveau_grobj *tesla = nv50-screen-tesla;
unsigned line_dwords = (w * cpp + 3) / 4;
reloc |= NOUVEAU_BO_WR;
@@ -347,6 +346,4 @@ nv50_upload_sifc(struct nv50_context *nv50,
src = (uint8_t *) src + src_pitch;
}
- BEGIN_RING(chan, tesla, NV50TCL_CODE_CB_FLUSH, 1);
- OUT_RING (chan, 0);
}
--
1.7.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nv50 : fix too long shader uploads by splitting them
This fixes fp-long-alu test which failed/stopped at depth 3077 with the
following kernel errors :
[drm] nouveau :01:00.0: Allocating FIFO number 3
[drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 3
[drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - Ch 3/3 Class 0x502d
Mthd 0x0838 Data 0x0001:0x0001e0f8
[drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - INVALID_VALUE
[drm] nouveau :01:00.0: PGRAPH_TRAP - Ch 3/7 Class 0x8297 Mthd
0x15e0 Data 0x:0x
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 0:
INVALID_OPCODE at 00 warp 4, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 1:
INVALID_OPCODE at 00 warp 1, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 1 MP 0:
INVALID_OPCODE at 00 warp 3, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 1 MP 1:
INVALID_OPCODE at 00 warp 4, opcode
[drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 3
Just one mystery, fp-long-alu test still fails if I split upload at 65536
(supposed to be the max value), without triggering any pgraph errors.
Any lower value (256 aligned) works.
Thanks to Christoph Bumiller and Marcin Kościelnicki for the help !
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/gallium/drivers/nv50/nv50_program.c | 24
src/gallium/drivers/nv50/nv50_transfer.c |3 ---
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_program.c
b/src/gallium/drivers/nv50/nv50_program.c
index 0156ff9..33981fa 100644
--- a/src/gallium/drivers/nv50/nv50_program.c
+++ b/src/gallium/drivers/nv50/nv50_program.c
@@ -4207,10 +4207,13 @@ nv50_program_validate_data(struct nv50_context *nv50,
struct nv50_program *p)
static void
nv50_program_validate_code(struct nv50_context *nv50, struct nv50_program *p)
{
+ struct nouveau_grobj *tesla = nv50-screen-tesla;
struct nouveau_channel *chan = nv50-screen-base.channel;
struct nv50_program_exec *e;
uint32_t *up, i;
boolean upload = FALSE;
+ unsigned offset;
+ int width;
if (!p-bo) {
nouveau_bo_new(chan-device, NOUVEAU_BO_VRAM, 0x100,
@@ -4267,10 +4270,23 @@ nv50_program_validate_code(struct nv50_context *nv50,
struct nv50_program *p)
NOUVEAU_ERR(0x%08x\n, e-inst[1]);
}
#endif
- nv50_upload_sifc(nv50, p-bo, 0, NOUVEAU_BO_VRAM,
-NV50_2D_DST_FORMAT_R8_UNORM, 65536, 1, 262144,
-up, NV50_2D_SIFC_FORMAT_R8_UNORM, 0,
-0, 0, p-exec_size * 4, 1, 1);
+
+ /* SIFC_HEIGHT/SIFC_WIDTH of 65536 do not work, and are not reported
+* as data error either. hw bug ? */
+#define SIFC_MAX_WIDTH (65536-256)
+ offset = 0;
+ width = p-exec_size * 4;
+ while(width 0) {
+ nv50_upload_sifc(nv50, p-bo, offset, NOUVEAU_BO_VRAM,
+ NV50_2D_DST_FORMAT_R8_UNORM, 65536, 1, 262144,
+ up[offset / 4], NV50_2D_SIFC_FORMAT_R8_UNORM,
0,
+ 0, 0, MIN2(SIFC_MAX_WIDTH, width), 1, 1);
+ width -= SIFC_MAX_WIDTH;
+ offset += SIFC_MAX_WIDTH;
+ break;
+ }
+ BEGIN_RING(chan, tesla, NV50TCL_CODE_CB_FLUSH, 1);
+ OUT_RING (chan, 0);
FREE(up);
}
diff --git a/src/gallium/drivers/nv50/nv50_transfer.c
b/src/gallium/drivers/nv50/nv50_transfer.c
index c5581a6..8b66c42 100644
--- a/src/gallium/drivers/nv50/nv50_transfer.c
+++ b/src/gallium/drivers/nv50/nv50_transfer.c
@@ -274,7 +274,6 @@ nv50_upload_sifc(struct nv50_context *nv50,
{
struct nouveau_channel *chan = nv50-screen-base.channel;
struct nouveau_grobj *eng2d = nv50-screen-eng2d;
- struct nouveau_grobj *tesla = nv50-screen-tesla;
unsigned line_dwords = (w * cpp + 3) / 4;
reloc |= NOUVEAU_BO_WR;
@@ -347,6 +346,4 @@ nv50_upload_sifc(struct nv50_context *nv50,
src = (uint8_t *) src + src_pitch;
}
- BEGIN_RING(chan, tesla, NV50TCL_CODE_CB_FLUSH, 1);
- OUT_RING (chan, 0);
}
--
1.7.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nv50 : fix too long shader uploads by splitting them
On Sun, May 9, 2010 at 12:41 AM, Xavier Chantry
chantry.xav...@gmail.com wrote:
This fixes fp-long-alu test which failed/stopped at depth 3077 with the
following kernel errors :
[drm] nouveau :01:00.0: Allocating FIFO number 3
[drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 3
[drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - Ch 3/3 Class 0x502d
Mthd 0x0838 Data 0x0001:0x0001e0f8
[drm] nouveau :01:00.0: PGRAPH_DATA_ERROR - INVALID_VALUE
[drm] nouveau :01:00.0: PGRAPH_TRAP - Ch 3/7 Class 0x8297 Mthd
0x15e0 Data 0x:0x
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 0:
INVALID_OPCODE at 00 warp 4, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 1:
INVALID_OPCODE at 00 warp 1, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 1 MP 0:
INVALID_OPCODE at 00 warp 3, opcode
[drm] nouveau :01:00.0: PGRAPH_TRAP_MP_EXEC - TP 1 MP 1:
INVALID_OPCODE at 00 warp 4, opcode
[drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 3
Just one mystery, fp-long-alu test still fails if I split upload at 65536
(supposed to be the max value), without triggering any pgraph errors.
Any lower value (256 aligned) works.
Thanks to Christoph Bumiller and Marcin Kościelnicki for the help !
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/gallium/drivers/nv50/nv50_program.c | 24
src/gallium/drivers/nv50/nv50_transfer.c | 3 ---
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_program.c
b/src/gallium/drivers/nv50/nv50_program.c
index 0156ff9..33981fa 100644
--- a/src/gallium/drivers/nv50/nv50_program.c
+++ b/src/gallium/drivers/nv50/nv50_program.c
@@ -4207,10 +4207,13 @@ nv50_program_validate_data(struct nv50_context *nv50,
struct nv50_program *p)
static void
nv50_program_validate_code(struct nv50_context *nv50, struct nv50_program *p)
{
+ struct nouveau_grobj *tesla = nv50-screen-tesla;
struct nouveau_channel *chan = nv50-screen-base.channel;
struct nv50_program_exec *e;
uint32_t *up, i;
boolean upload = FALSE;
+ unsigned offset;
+ int width;
if (!p-bo) {
nouveau_bo_new(chan-device, NOUVEAU_BO_VRAM, 0x100,
@@ -4267,10 +4270,23 @@ nv50_program_validate_code(struct nv50_context *nv50,
struct nv50_program *p)
NOUVEAU_ERR(0x%08x\n, e-inst[1]);
}
#endif
- nv50_upload_sifc(nv50, p-bo, 0, NOUVEAU_BO_VRAM,
- NV50_2D_DST_FORMAT_R8_UNORM, 65536, 1, 262144,
- up, NV50_2D_SIFC_FORMAT_R8_UNORM, 0,
- 0, 0, p-exec_size * 4, 1, 1);
+
+ /* SIFC_HEIGHT/SIFC_WIDTH of 65536 do not work, and are not reported
+ * as data error either. hw bug ? */
+#define SIFC_MAX_WIDTH (65536-256)
+ offset = 0;
+ width = p-exec_size * 4;
+ while(width 0) {
+ nv50_upload_sifc(nv50, p-bo, offset, NOUVEAU_BO_VRAM,
+ NV50_2D_DST_FORMAT_R8_UNORM, 65536, 1, 262144,
+ up[offset / 4],
NV50_2D_SIFC_FORMAT_R8_UNORM, 0,
+ 0, 0, MIN2(SIFC_MAX_WIDTH, width), 1, 1);
+ width -= SIFC_MAX_WIDTH;
+ offset += SIFC_MAX_WIDTH;
+ break;
damn, the break is a debug leftover, sorry. I will resubmit...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau driver fails to resume
On Wed, May 5, 2010 at 4:12 AM, Gabriele Tozzi gabri...@tozzi.eu wrote: I don't know where to start debugging this issue. I'm attaching my xorg log. Kernel logs usually have more information. Check in /var/log/ something like kern.log or kernel.log (distrib specific), and see if anything got logged during resume or not. Even if nothing got logged on resume, a full kernel log from boot to suspend/resume could still be useful. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] _mesa_init_texture_s3tc() vs util_format_s3tc_init()
I am trying to understand the s3tc init code as nv50 gallium has a problem with that. It looks like some drivers (r300g and llvmpipe) actually inits s3tc in two places : ./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc() ./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init() Here is an extract of the backtrace calls while loading fgfs on llvmpipe : driCreateScreen - llvmpipe_create_screen - util_format_s3tc_init driCreateContext - st_create_context - _mesa_create_context_for_api - init_attrib_groups - _mesa_init_texture_s3tc These two functions seem to do more or less the same job, and apparently, the classic mesa init is unused for a gallium driver. So I suppose that init is not necessary, but it happens because gallium and mesa are tightly tied together, and create context is handled similarly, but it shouldn't hurt ? Additionally r300g and llvmpipe added util_format_s3tc_init to their create_screen functions, and util/u_format_s3tc.c apparently contains all the functions that a gallium driver uses. So I suppose that nvfx and nv50 should do the same ? If that's correct, the patch below might not be completely wrong. On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry chantry.xav...@gmail.com wrote: flightgear now dies with : Mesa warning: external dxt library not available: texstore_rgba_dxt3 util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed. I don't really understand what these stubs are about, they were introduced by following commit : commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 Author: José Fonseca jfons...@vmware.com Date: Wed Apr 7 20:47:38 2010 +0100 util: Use stubs for the dynamically loaded S3TC functions. Loosely based on Luca Barbieri's commit 52e9b990a192a9329006d5f7dd2ac222effea5a5. Looking at llvm and r300 code and trying to guess, I came up with the following patch that allows flightgear to start again. But I don't really understand that stuff so it could be wrong. nvfx is probably affected as well. diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c index 233a91a..a91b00b 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.c +++ b/src/gallium/drivers/nouveau/nouveau_screen.c @@ -5,6 +5,7 @@ #include util/u_memory.h #include util/u_inlines.h #include util/u_format.h +#include util/u_format_s3tc.h #include stdio.h #include errno.h @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) pscreen-fence_signalled = nouveau_screen_fence_signalled; pscreen-fence_finish = nouveau_screen_fence_finish; + util_format_s3tc_init(); + return 0; } diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index 2dd1042..0d74c90 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include util/u_format_s3tc.h #include pipe/p_screen.h #include nv50_context.h @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, case PIPE_FORMAT_A8_UNORM: case PIPE_FORMAT_I8_UNORM: case PIPE_FORMAT_L8A8_UNORM: - case PIPE_FORMAT_DXT1_RGB: - case PIPE_FORMAT_DXT1_RGBA: - case PIPE_FORMAT_DXT3_RGBA: - case PIPE_FORMAT_DXT5_RGBA: case PIPE_FORMAT_S8_USCALED_Z24_UNORM: case PIPE_FORMAT_Z24_UNORM_S8_USCALED: case PIPE_FORMAT_Z32_FLOAT: @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, case PIPE_FORMAT_R16G16_SNORM: case PIPE_FORMAT_R16G16_UNORM: return TRUE; + case PIPE_FORMAT_DXT1_RGB: + case PIPE_FORMAT_DXT1_RGBA: + case PIPE_FORMAT_DXT3_RGBA: + case PIPE_FORMAT_DXT5_RGBA: + return util_format_s3tc_enabled; default: break; } ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nv50 dxt / s3tc
flightgear now dies with : Mesa warning: external dxt library not available: texstore_rgba_dxt3 util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed. I don't really understand what these stubs are about, they were introduced by following commit : commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13 Author: José Fonseca jfons...@vmware.com Date: Wed Apr 7 20:47:38 2010 +0100 util: Use stubs for the dynamically loaded S3TC functions. Loosely based on Luca Barbieri's commit 52e9b990a192a9329006d5f7dd2ac222effea5a5. Looking at llvm and r300 code and trying to guess, I came up with the following patch that allows flightgear to start again. But I don't really understand that stuff so it could be wrong. nvfx is probably affected as well. diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c b/src/gallium/drivers/nouveau/nouveau_screen.c index 233a91a..a91b00b 100644 --- a/src/gallium/drivers/nouveau/nouveau_screen.c +++ b/src/gallium/drivers/nouveau/nouveau_screen.c @@ -5,6 +5,7 @@ #include util/u_memory.h #include util/u_inlines.h #include util/u_format.h +#include util/u_format_s3tc.h #include stdio.h #include errno.h @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen, struct nouveau_device *dev) pscreen-fence_signalled = nouveau_screen_fence_signalled; pscreen-fence_finish = nouveau_screen_fence_finish; + util_format_s3tc_init(); + return 0; } diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c index 2dd1042..0d74c90 100644 --- a/src/gallium/drivers/nv50/nv50_screen.c +++ b/src/gallium/drivers/nv50/nv50_screen.c @@ -20,6 +20,7 @@ * SOFTWARE. */ +#include util/u_format_s3tc.h #include pipe/p_screen.h #include nv50_context.h @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, case PIPE_FORMAT_A8_UNORM: case PIPE_FORMAT_I8_UNORM: case PIPE_FORMAT_L8A8_UNORM: - case PIPE_FORMAT_DXT1_RGB: - case PIPE_FORMAT_DXT1_RGBA: - case PIPE_FORMAT_DXT3_RGBA: - case PIPE_FORMAT_DXT5_RGBA: case PIPE_FORMAT_S8_USCALED_Z24_UNORM: case PIPE_FORMAT_Z24_UNORM_S8_USCALED: case PIPE_FORMAT_Z32_FLOAT: @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen, case PIPE_FORMAT_R16G16_SNORM: case PIPE_FORMAT_R16G16_UNORM: return TRUE; + case PIPE_FORMAT_DXT1_RGB: + case PIPE_FORMAT_DXT1_RGBA: + case PIPE_FORMAT_DXT3_RGBA: + case PIPE_FORMAT_DXT5_RGBA: + return util_format_s3tc_enabled; default: break; } ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv50 piglit regression
On Thu, Apr 29, 2010 at 2:43 PM, Xavier Chantry chantry.xav...@gmail.com wrote: Between mesa-7.8.1-1697-g1820d24 and mesa-7.8.1-1911-g7327a84 , I got 4 new failures : general/texgen glean/polygonOffset shaders/fp-generic/ dph and kil-swizzle If some of these are not already known and expected, I will do a bisect. Sorry it is apparently not a mesa regression. Downgrading mesa does not help. In the same time, I did a distrib upgrade that bumped xorg server from 1.7.6 to 1.8.0.901 Downgrading just xorg-server fixes the 4 tests above. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nv50 piglit regression
Between mesa-7.8.1-1697-g1820d24 and mesa-7.8.1-1911-g7327a84 , I got 4 new failures : general/texgen glean/polygonOffset shaders/fp-generic/ dph and kil-swizzle If some of these are not already known and expected, I will do a bisect. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] drm-nouveau - more gl extensions?
On Thu, Apr 22, 2010 at 12:57 PM, yaiba.kurog...@interia.pl wrote: Hello. I have old nvidia hardware (NV17) and noticed that some extensions are missing.They will be added in near future ? Anyone from nouveau developers actually working on driver for such old hw ??? A few months ago : 15:27 curro_ hmm, or we could expose gl1.3 already, IIRC the only thing left is cube mapping curro is the one that resurrected the nv10-nv20 driver and got it to a nicer state. He seemed less active recently, so probably busy with other things like work and/or life. I guess it depends on what extension / what gl version you are talking about and how complex they are to implement. And I suppose they are all supported by the blob (nvidia proprietary driver) ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa-dev] drm-nouveau - more gl extensions?
On Thu, Apr 22, 2010 at 12:57 PM, yaiba.kurog...@interia.pl wrote: Hello. I have old nvidia hardware (NV17) and noticed that some extensions are missing.They will be added in near future ? Anyone from nouveau developers actually working on driver for such old hw ??? A few months ago : 15:27 curro_ hmm, or we could expose gl1.3 already, IIRC the only thing left is cube mapping curro is the one that resurrected the nv10-nv20 driver and got it to a nicer state. He seemed less active recently, so probably busy with other things like work and/or life. I guess it depends on what extension / what gl version you are talking about and how complex they are to implement. And I suppose they are all supported by the blob (nvidia proprietary driver) ? (kept mesa in CC this time) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] nv20tcl and renouveau questions
First some data errors I get with both nv20 exa and nv20 dri/mesa. 1. RT_FORMAT LINEAR + X8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x0105 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x0105 LINEAR + A8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x0108 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x0108 The only value I found in renouveau dump was 0x0128. Let's look at renouveau.xml nv20 reg32 offset=0x0208 name=RT_FORMAT type=bitfield bitfield name=TYPE high=11 low=8 type=enum enum_name=nv40_rendertarget_type/ bitfield name=COLOR high=4 low=0 type=enum enum_name=nv40_rendertarget_color_format/ /reg32 Nothing for bit 5. Looking at dri/mesa : case MESA_FORMAT_XRGB: return 0x05; case MESA_FORMAT_ARGB: return 0x08; case MESA_FORMAT_RGB565: return 0x03; case MESA_FORMAT_Z16: return 0x10; case MESA_FORMAT_Z24_S8: return 0x20; Does that mean that color only goes from bit 0 to 3, and zeta is bit 4-5. Unlike nv30 where color goes from 0 to 4, and has zeta on 5-6 ? On nv20, 0x10 and 0x20 is valid, but not 0x40. And it seems nv20 dri also cause data errors because it does not always set zeta with 0x10/0x20, it only does that in depth/stencil case. 2. TX_FILTER(0) MIN NEAREST + MAG NEAREST Ch 1/7 Class 0x0597 Mthd 0x1b14 Data 0x0101:0x0101 For that one, I found the 0x2000 value both in nv20 renouveau dump and nv30 exa. nv30 exa documents it as engine lock. Anyway idea what that is, and how to add it to renouveau.xml ? bitfield name=ENGINE_LOCK high=13 low=13 type=boolean/ ? 3. And finally, is this name difference RT_PITCH / COLOR0_PITCH between nv10/nv20 and nv30/nv40 normal ? I saw many naming inconsistencies that were more obvious, the worse part is probably between nv30 and nv40. But not sure about that one, if 0x20c is the same method or a different one. nv10 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=RT_PITCH type=bitfield reg32 offset=0x0210 name=COLOR_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ nv20 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=RT_PITCH type=bitfield reg32 offset=0x0210 name=COLOR_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ nv30 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=COLOR0_PITCH type=bitfield reg32 offset=0x0210 name=COLOR0_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ nv40 reg32 offset=0x0208 name=RT_FORMAT type=bitfield reg32 offset=0x020c name=COLOR0_PITCH type=int/ reg32 offset=0x0210 name=COLOR0_OFFSET type=hexa/ reg32 offset=0x0214 name=ZETA_OFFSET type=hexa/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nv30/exa : cleanup from nv40 exa
This has two purposes :
- cleaner code
- reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ?
The main differences seem to be that nv30 uses rect texture format (and does
not support repeat on that). Then there are some minor changes in TX_FORMAT
RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete
different.
Tested with:
./rendercheck -t
fill,dcoords,scoords,mcoords,tscoords,tmcoords,triangles,bug7366
./rendercheck -f a8r8g8b8,x8r8g8b8,r5g6b5,a8,a8b8g8r8,x8b8g8r8,x1r5g5b5
-o Clear,Src,Dst,Over,OverReverse,In,InReverse,Out,OutReverse,Atop
-t blend
(restricted blend test to supported formats and operation. exluded
composite,cacomposite,gradients,repeat tests which seem to take forever)
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/nv30_exa.c | 393
src/nv40_exa.c |2 +-
2 files changed, 166 insertions(+), 229 deletions(-)
diff --git a/src/nv30_exa.c b/src/nv30_exa.c
index b736fb3..2cd7d32 100644
--- a/src/nv30_exa.c
+++ b/src/nv30_exa.c
@@ -56,26 +56,28 @@ typedef struct nv30_exa_state {
static nv30_exa_state_t exa_state;
#define NV30EXA_STATE nv30_exa_state_t *state = exa_state
+#define NV34TCL_RT_FORMAT_COLOR_X1R5G5B5 0x0002
static nv_pict_surface_format_t
NV30SurfaceFormat[] = {
- { PICT_a8r8g8b8 , 0x148 },
- { PICT_a8b8g8r8 , 0x150 },
- { PICT_x8r8g8b8 , 0x145 },
- { PICT_x8b8g8r8 , 0x14f },
- { PICT_r5g6b5 , 0x143 },
- { PICT_a8 , 0x149 },
- { PICT_x1r5g5b5 , 0x142 },
+ { PICT_a8r8g8b8 , NV34TCL_RT_FORMAT_COLOR_A8R8G8B8 },
+ { PICT_x8r8g8b8 , NV34TCL_RT_FORMAT_COLOR_X8R8G8B8 },
+ { PICT_r5g6b5 , NV34TCL_RT_FORMAT_COLOR_R5G6B5 },
+ { PICT_a8 , NV34TCL_RT_FORMAT_COLOR_B8 },
+ { PICT_a8b8g8r8 , NV34TCL_RT_FORMAT_COLOR_A8B8G8R8 },
+ { PICT_x8b8g8r8 , NV34TCL_RT_FORMAT_COLOR_X8B8G8R8 },
+ { PICT_x1r5g5b5 , NV34TCL_RT_FORMAT_COLOR_X1R5G5B5 },
+ { -1, ~0 }
};
static nv_pict_surface_format_t *
NV30_GetPictSurfaceFormat(int format)
{
- int i;
+ int i = 0;
- for(i=0;isizeof(NV30SurfaceFormat)/sizeof(NV30SurfaceFormat[0]);i++)
- {
+ while (NV30SurfaceFormat[i].pict_fmt != -1) {
if (NV30SurfaceFormat[i].pict_fmt == format)
return NV30SurfaceFormat[i];
+ i++;
}
return NULL;
@@ -123,106 +125,72 @@ NV30EXAHackupA8Shaders(ScrnInfoPtr pScrn)
}
}
-/* should be in nouveau_reg.h at some point.. */
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_ZERO 0
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_ONE1
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_S1 2
-
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_SHIFT 14
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_Y_SHIFT 12
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_Z_SHIFT 10
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_W_SHIFT 8
-
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_X 3
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_Y 2
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_Z 1
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_W 0
-
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_SHIFT 6
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_Y_SHIFT 4
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_Z_SHIFT 2
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_W_SHIFT 0
-
-#define _(r,tf,ts0x,ts0y,ts0z,ts0w,ts1x,ts1y,ts1z,ts1w) \
- { \
- PICT_##r, \
- (tf), \
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0x NV34TCL_TX_SWIZZLE_UNIT_S0_X_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0y NV34TCL_TX_SWIZZLE_UNIT_S0_Y_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0z NV34TCL_TX_SWIZZLE_UNIT_S0_Z_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0w NV34TCL_TX_SWIZZLE_UNIT_S0_W_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1x NV34TCL_TX_SWIZZLE_UNIT_S1_X_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1y NV34TCL_TX_SWIZZLE_UNIT_S1_Y_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1z NV34TCL_TX_SWIZZLE_UNIT_S1_Z_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1w NV34TCL_TX_SWIZZLE_UNIT_S1_W_SHIFT)\
+#define _(r,tf,ts0x,ts0y,ts0z,ts0w,ts1x,ts1y,ts1z,ts1w) \
+ { \
+ PICT_##r, NV34TCL_TX_FORMAT_FORMAT_##tf, \
+ NV34TCL_TX_SWIZZLE_S0_X_##ts0x | NV34TCL_TX_SWIZZLE_S0_Y_##ts0y | \
+ NV34TCL_TX_SWIZZLE_S0_Z_##ts0z | NV34TCL_TX_SWIZZLE_S0_W_##ts0w | \
+ NV34TCL_TX_SWIZZLE_S1_X_##ts1x | NV34TCL_TX_SWIZZLE_S1_Y_##ts1y | \
+ NV34TCL_TX_SWIZZLE_S1_Z_##ts1z | NV34TCL_TX_SWIZZLE_S1_W_##ts1w, \
}
static nv_pict_texture_format_t
NV30TextureFormat[] = {
- _(a8r8g8b8, 0x12, S1, S1, S1, S1, X, Y, Z, W),
- _(a8b8g8r8
[Nouveau] [PATCH] nv10/exa : demagify tex and rt format
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/nv10_exa.c | 35 +++
1 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/src/nv10_exa.c b/src/nv10_exa.c
index 1acb583..23a68e3 100644
--- a/src/nv10_exa.c
+++ b/src/nv10_exa.c
@@ -34,30 +34,33 @@ static struct pict_format {
int exa;
int hw;
} nv10_tex_format_pot[] = {
- { PICT_a8, 0x80 },
- { PICT_r5g6b5, 0x280 },
- { PICT_x8r8g8b8, 0x300 },
- { PICT_a8r8g8b8, 0x300 },
+ { PICT_a8, NV10TCL_TX_FORMAT_FORMAT_A8 },
+ { PICT_r5g6b5, NV10TCL_TX_FORMAT_FORMAT_R5G6B5 },
+ { PICT_x8r8g8b8, NV10TCL_TX_FORMAT_FORMAT_A8R8G8B8 },
+ { PICT_a8r8g8b8, NV10TCL_TX_FORMAT_FORMAT_A8R8G8B8 },
{},
}, nv10_tex_format_rect[] = {
- { PICT_a8, 0x980 },
- { PICT_r5g6b5, 0x880 },
- { PICT_x8r8g8b8, 0x900 },
- { PICT_a8r8g8b8, 0x900 },
+ { PICT_a8, NV10TCL_TX_FORMAT_FORMAT_A8_RECT },
+ { PICT_r5g6b5, NV10TCL_TX_FORMAT_FORMAT_R5G6B5_RECT },
+ { PICT_x8r8g8b8, NV10TCL_TX_FORMAT_FORMAT_A8R8G8B8_RECT },
+ { PICT_a8r8g8b8, NV10TCL_TX_FORMAT_FORMAT_A8R8G8B8_RECT },
{},
+/* That's awesome, we need to use the nv20 rect formats on nv20 for
+ * NV10TCL_TX_FORMAT. Only A8_RECT differs between nv10 and nv20, but with the
+ * great side-effect to cause a DATA error when that is enabled */
}, nv20_tex_format_rect[] = {
- { PICT_a8, 0xd80 },
- { PICT_r5g6b5, 0x880 },
- { PICT_x8r8g8b8, 0x900 },
- { PICT_a8r8g8b8, 0x900 },
+ { PICT_a8, 0x1b NV10TCL_TX_FORMAT_FORMAT_SHIFT },
+ { PICT_r5g6b5, NV10TCL_TX_FORMAT_FORMAT_R5G6B5_RECT },
+ { PICT_x8r8g8b8, NV10TCL_TX_FORMAT_FORMAT_A8R8G8B8_RECT },
+ { PICT_a8r8g8b8, NV10TCL_TX_FORMAT_FORMAT_A8R8G8B8_RECT },
{},
}, nv10_rt_format[] = {
- { PICT_r5g6b5, 0x103 },
- { PICT_x8r8g8b8, 0x108 },
- { PICT_a8r8g8b8, 0x108 },
+ { PICT_r5g6b5, NV10TCL_RT_FORMAT_COLOR_R5G6B5 },
+ { PICT_x8r8g8b8, NV10TCL_RT_FORMAT_COLOR_X8R8G8B8 },
+ { PICT_a8r8g8b8, NV10TCL_RT_FORMAT_COLOR_A8R8G8B8 },
{},
};
@@ -432,7 +435,7 @@ setup_render_target(NVPtr pNv, PicturePtr pict, PixmapPtr
pixmap)
struct nouveau_bo *bo = nouveau_pixmap_bo(pixmap);
BEGIN_RING(chan, celsius, NV10TCL_RT_FORMAT, 2);
- OUT_RING (chan, get_rt_format(pict));
+ OUT_RING (chan, get_rt_format(pict) | NV10TCL_RT_FORMAT_TYPE_LINEAR);
OUT_RING (chan, (exaGetPixmapPitch(pixmap) 16 |
exaGetPixmapPitch(pixmap)));
--
1.7.0.5
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nv30/exa : cleanup from nv40 exa
This has two purposes :
- cleaner code
- reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ?
The main differences seem to be that nv30 uses rect texture format (and does
not support repeat on that). Then there are some minor changes in TX_FORMAT
RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete
different.
Tested with:
./rendercheck -t
fill,dcoords,scoords,mcoords,tscoords,tmcoords,triangles,bug7366
./rendercheck -f a8r8g8b8,x8r8g8b8,r5g6b5,a8,a8b8g8r8,x8b8g8r8,x1r5g5b5
-o Clear,Src,Dst,Over,OverReverse,In,InReverse,Out,OutReverse,Atop
-t blend
(restricted blend test to supported formats and operation. exluded
composite,cacomposite,gradients,repeat tests which seem to take forever)
A few explanations, even though these cleanups were all made to nv40
already, most of them in commit 0d1835d67e :
- (sblend 16) | sblend - sblend is normal, as the new SF and DF
definitions include both ALPHA ( 16) and RGB.
- about PictFilterBilinear, the if was just moved directly around the
OUT_RING
- about RT_FORMAT, zeta_z24s8 and type_linear were previously directly
hardcoded in the rt format values
0x148 = NV34TCL_RT_FORMAT_TYPE_LINEAR (0x100) +
NV34TCL_RT_FORMAT_ZETA_Z24S8 (0x40) +
NV34TCL_RT_FORMAT_COLOR_A8R8G8B8 (0x8)
v2: smaller diff, without strict indent changes and removal of debug code
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
src/nv30_exa.c | 230 +---
src/nv40_exa.c |2 +-
2 files changed, 103 insertions(+), 129 deletions(-)
diff --git a/src/nv30_exa.c b/src/nv30_exa.c
index b736fb3..0031fe7 100644
--- a/src/nv30_exa.c
+++ b/src/nv30_exa.c
@@ -56,26 +56,28 @@ typedef struct nv30_exa_state {
static nv30_exa_state_t exa_state;
#define NV30EXA_STATE nv30_exa_state_t *state = exa_state
+#define NV34TCL_RT_FORMAT_COLOR_X1R5G5B5 0x0002
static nv_pict_surface_format_t
NV30SurfaceFormat[] = {
- { PICT_a8r8g8b8 , 0x148 },
- { PICT_a8b8g8r8 , 0x150 },
- { PICT_x8r8g8b8 , 0x145 },
- { PICT_x8b8g8r8 , 0x14f },
- { PICT_r5g6b5 , 0x143 },
- { PICT_a8 , 0x149 },
- { PICT_x1r5g5b5 , 0x142 },
+ { PICT_a8r8g8b8 , NV34TCL_RT_FORMAT_COLOR_A8R8G8B8 },
+ { PICT_x8r8g8b8 , NV34TCL_RT_FORMAT_COLOR_X8R8G8B8 },
+ { PICT_r5g6b5 , NV34TCL_RT_FORMAT_COLOR_R5G6B5 },
+ { PICT_a8 , NV34TCL_RT_FORMAT_COLOR_B8 },
+ { PICT_a8b8g8r8 , NV34TCL_RT_FORMAT_COLOR_A8B8G8R8 },
+ { PICT_x8b8g8r8 , NV34TCL_RT_FORMAT_COLOR_X8B8G8R8 },
+ { PICT_x1r5g5b5 , NV34TCL_RT_FORMAT_COLOR_X1R5G5B5 },
+ { -1, ~0 }
};
static nv_pict_surface_format_t *
NV30_GetPictSurfaceFormat(int format)
{
- int i;
+ int i = 0;
- for(i=0;isizeof(NV30SurfaceFormat)/sizeof(NV30SurfaceFormat[0]);i++)
- {
+ while (NV30SurfaceFormat[i].pict_fmt != -1) {
if (NV30SurfaceFormat[i].pict_fmt == format)
return NV30SurfaceFormat[i];
+ i++;
}
return NULL;
@@ -123,106 +125,72 @@ NV30EXAHackupA8Shaders(ScrnInfoPtr pScrn)
}
}
-/* should be in nouveau_reg.h at some point.. */
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_ZERO 0
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_ONE1
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_S1 2
-
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_X_SHIFT 14
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_Y_SHIFT 12
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_Z_SHIFT 10
-#define NV34TCL_TX_SWIZZLE_UNIT_S0_W_SHIFT 8
-
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_X 3
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_Y 2
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_Z 1
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_W 0
-
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_X_SHIFT 6
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_Y_SHIFT 4
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_Z_SHIFT 2
-#define NV34TCL_TX_SWIZZLE_UNIT_S1_W_SHIFT 0
-
-#define _(r,tf,ts0x,ts0y,ts0z,ts0w,ts1x,ts1y,ts1z,ts1w) \
- { \
- PICT_##r, \
- (tf), \
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0x NV34TCL_TX_SWIZZLE_UNIT_S0_X_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0y NV34TCL_TX_SWIZZLE_UNIT_S0_Y_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0z NV34TCL_TX_SWIZZLE_UNIT_S0_Z_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S0_X_##ts0w NV34TCL_TX_SWIZZLE_UNIT_S0_W_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1x NV34TCL_TX_SWIZZLE_UNIT_S1_X_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1y NV34TCL_TX_SWIZZLE_UNIT_S1_Y_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1z NV34TCL_TX_SWIZZLE_UNIT_S1_Z_SHIFT)|\
- (NV34TCL_TX_SWIZZLE_UNIT_S1_X_##ts1w NV34TCL_TX_SWIZZLE_UNIT_S1_W_SHIFT)\
+#define _(r
[Nouveau] crash in ttm_bo_cleanup_refs
I got a nice lockup today after running etracer for a few minutes. kernel : Linux 2.6.34-rc3 + recent nouveau code (Apr 7 , de2f7caff0bf) mesa : git master of today , using nvfx gallium Apr 15 11:37:12 myhost kernel: [57533.031358] [drm] nouveau :01:00.0: Allocating FIFO number 2 Apr 15 11:37:12 myhost kernel: [57533.033502] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 2 Apr 15 11:39:57 myhost kernel: [57698.458538] BUG: unable to handle kernel paging request at 0007000d Apr 15 11:39:57 myhost kernel: [57698.458551] IP: [f82cddc4] ttm_bo_cleanup_refs+0x24/0x210 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458565] *pde = Apr 15 11:39:57 myhost kernel: [57698.458569] Oops: [#1] PREEMPT SMP Apr 15 11:39:57 myhost kernel: [57698.458575] last sysfs file: /sys/devices/platform/w83627hf.656/temp2_input Apr 15 11:39:57 myhost kernel: [57698.458581] Modules linked in: w83627hf hwmon_vid nfs lockd nfs_acl auth_rpcgss sunrpc fuse snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq usbhid hid snd_emu10k1 snd_pcm_oss snd_mixer_oss snd_rawmidi nouveau snd_intel8x0 snd_ac97_codec ac97_bus ttm snd_pcm snd_seq_device snd_util_mem snd_timer drm_kms_helper ppdev snd_hwdep parport_pc i82875p_edac snd drm edac_core i2c_algo_bit soundcore snd_page_alloc uhci_hcd firewire_ohci emu10k1_gp i2c_i801 firewire_core crc_itu_t gameport thermal e1000 processor button lp intel_agp ehci_hcd usbcore parport i2c_core evdev agpgart iTCO_wdt iTCO_vendor_support shpchp pci_hotplug rtc_cmos rtc_core rtc_lib dm_mirror dm_region_hash dm_log dm_mod Apr 15 11:39:57 myhost kernel: [57698.458667] Apr 15 11:39:57 myhost kernel: [57698.458673] Pid: 7, comm: events/0 Not tainted 2.6.34-rc3 #16 P4C800-E/To Be Filled By O.E.M. Apr 15 11:39:57 myhost kernel: [57698.458678] EIP: 0060:[f82cddc4] EFLAGS: 00010202 CPU: 0 Apr 15 11:39:57 myhost kernel: [57698.458685] EIP is at ttm_bo_cleanup_refs+0x24/0x210 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458689] EAX: 00070001 EBX: e671cb40 ECX: e671cb50 EDX: Apr 15 11:39:57 myhost kernel: [57698.458693] ESI: e671cb78 EDI: 0001 EBP: f704ff30 ESP: f704ff08 Apr 15 11:39:57 myhost kernel: [57698.458698] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Apr 15 11:39:57 myhost kernel: [57698.458703] Process events/0 (pid: 7, ti=f704e000 task=f7031ce0 task.ti=f704e000) Apr 15 11:39:57 myhost kernel: [57698.458706] Stack: Apr 15 11:39:57 myhost kernel: [57698.458708] f82cf908 f704ff20 f82cd10a e671c1a8 f82cd0a0 e671cb50 00070001 e671c780 Apr 15 11:39:57 myhost kernel: [57698.458719] 0 e671cb40 f704ff54 f82ce028 f1a80334 f653414c Apr 15 11:39:57 myhost kernel: [57698.458731] 0 f1a80344 f1a80344 c2808980 f704ff60 f82ce0a3 c2808980 f704ffbc c10540a3 Apr 15 11:39:57 myhost kernel: [57698.458743] Call Trace: Apr 15 11:39:57 myhost kernel: [57698.458752] [f82cf908] ? ttm_transfered_destroy+0x8/0x10 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458761] [f82cd10a] ? ttm_bo_release_list+0x6a/0xb0 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458768] [f82cd0a0] ? ttm_bo_release_list+0x0/0xb0 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458776] [f82ce028] ? ttm_bo_delayed_delete+0x78/0xe0 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458784] [f82ce0a3] ? ttm_bo_delayed_workqueue+0x13/0x30 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458794] [c10540a3] ? worker_thread+0x113/0x250 Apr 15 11:39:57 myhost kernel: [57698.458803] [c132213c] ? schedule+0x25c/0x700 Apr 15 11:39:57 myhost kernel: [57698.458811] [f82ce090] ? ttm_bo_delayed_workqueue+0x0/0x30 [ttm] Apr 15 11:39:57 myhost kernel: [57698.458817] [c1058310] ? autoremove_wake_function+0x0/0x40 Apr 15 11:39:57 myhost kernel: [57698.458823] [c1053f90] ? worker_thread+0x0/0x250 Apr 15 11:39:57 myhost kernel: [57698.458828] [c1057eec] ? kthread+0x6c/0x80 Apr 15 11:39:57 myhost kernel: [57698.458833] [c1057e80] ? kthread+0x0/0x80 Apr 15 11:39:57 myhost kernel: [57698.458840] [c1003e3e] ? kernel_thread_helper+0x6/0x18 Apr 15 11:39:57 myhost kernel: [57698.458843] Code: c9 eb ac 8d 74 26 00 55 89 e5 57 89 d7 56 83 f7 01 53 89 c3 83 ec 1c 8b 40 04 81 e7 ff 00 00 00 8d 73 38 89 45 f0 8b 0b 89 4d ec 8b 40 0c 89 45 e8 89 f0 e8 4f 62 05 c9 31 c9 31 d2 89 d8 89 3c Apr 15 11:39:57 myhost kernel: [57698.458909] EIP: [f82cddc4] ttm_bo_cleanup_refs+0x24/0x210 [ttm] SS:ESP 0068:f704ff08 Apr 15 11:39:57 myhost kernel: [57698.458920] CR2: 0007000d Apr 15 11:39:57 myhost kernel: [57698.458934] ---[ end trace 66bbdca73e702081 ]--- Apr 15 11:39:57 myhost kernel: [57698.603553] BUG: unable to handle kernel paging request at 0007000d Apr 15 11:39:57 myhost kernel: [57698.603565] IP: [f82cce5b] ttm_bo_wait+0x1b/0x180 [ttm] Apr 15 11:39:57 myhost kernel: [57698.603577] *pde = Apr 15 11:39:57 myhost kernel: [57698.603581] Oops: [#2] PREEMPT SMP Apr 15 11:39:57 myhost kernel: [57698.603585] last sysfs file: /sys/devices/platform/w83627hf.656/temp2_input Apr 15 11:39:57 myhost kernel: [57698.603590]
Re: [Nouveau] [PATCH 2/2] drm/nv20: Enable DATA_ERROR reporting
2010/4/14 Marcin Kościelnicki koria...@0x04.net: Signed-off-by: Marcin Kościelnicki koria...@0x04.net --- drivers/gpu/drm/nouveau/nv20_graph.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv20_graph.c b/drivers/gpu/drm/nouveau/nv20_graph.c index d6fc0a8..bd83971 100644 --- a/drivers/gpu/drm/nouveau/nv20_graph.c +++ b/drivers/gpu/drm/nouveau/nv20_graph.c @@ -570,7 +570,7 @@ nv20_graph_init(struct drm_device *dev) nv_wr32(dev, NV04_PGRAPH_DEBUG_0, 0x); nv_wr32(dev, NV04_PGRAPH_DEBUG_0, 0x); nv_wr32(dev, NV04_PGRAPH_DEBUG_1, 0x00118700); - nv_wr32(dev, NV04_PGRAPH_DEBUG_3, 0xF3CE0475); /* 0x4 = auto ctx switch */ + nv_wr32(dev, NV04_PGRAPH_DEBUG_3, 0xF3DE0475); /* 0x4 = auto ctx switch */ nv_wr32(dev, NV10_PGRAPH_DEBUG_4, 0x); nv_wr32(dev, 0x40009C , 0x0040); -- 1.7.0.2 Relevant IRC discussion : 02:07 curro shining^: hahah, fun, that could explain why someone decided to disable data errors on nv2x 02:07 shining^ lol 02:07 marcheu curro: yes that's the reason 02:07 marcheu we couldn't get A8 to work on nv20 without removing the error check 02:07 marcheu I didn't think anyone would reenable it 02:07 shining^ ok so it was disabled on purpose. fun. and for that exact same reason 02:07 marcheu yeah 02:08 shining^ I got many data errors, I just decided to look into the 2d one first 02:08 shining^ which was the a8 one 02:08 marcheu same on nv40 btw 02:08 darktama hmmm, not the same 02:08 curro marcheu: ahh, good to know, mwk just sent a patch to reenable it 02:08 marcheu curro: yup noticed, wanted to reply but 02:08 darktama nv40 rejected A8+blending at draw time with INVALID_STATE 02:08 darktama we disabled STATE_CHECK to ignore that 02:09 marcheu darktama: I think that's reenabled in the last patch from mwk though? 02:09 marcheu didn't check the bits yet though 02:09 darktama iirc STATE_CHECK was bit 29, i'll double-check though 02:10 marcheu hmm no nv40 is untouched 02:10 darktama nope, mwk turned on DATA_CHECK 02:12 darktama on nv40, A8 is valid, and blending is valid, but combined they're not supposed to work I guess.. they just happen to accidently for us 02:13 marcheu yeah 02:13 marcheu error reporting is overrated :p 02:13 darktama hehe :) 02:13 marcheu maybe we need comments there 02:13 marcheu bit blah is disabled because blah So should we just completely give up because it's a dead end, or is it still worth to investigate further ? I would like to help, so any crazy ideas about how to find what's going on are welcome. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau_class.h
On Fri, Apr 9, 2010 at 8:51 AM, Ben Skeggs skeg...@gmail.com wrote: So, with all the nouveau_class.h changes lately it's become rather difficult to keep libdrm synced up with a particular mesa version. This is much like what happens when we break our kernel ABI, but on a far more regular basis so it has a larger impact. I'm proposing we drop nouveau_class.h from libdrm again, and move it back to the ddx and mesa trees where it can be updated at the same time the code that uses it is. Any objections / other suggestions? I did several times mesa bisection across one or more nouveau_class.h changes , that was a bit painful. So that change would be most welcome. And that would also obsolete the regular build failures from users who forgot to update libdrm. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa3d-dev] makedepend in Mesa
On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson dbn.li...@gmail.com wrote: diff --git a/configure.ac b/configure.ac index 485836a..a582337 100644 --- a/configure.ac +++ b/configure.ac @@ -28,8 +28,11 @@ AC_PROG_CPP AC_PROG_CC AC_PROG_CXX AC_CHECK_PROGS([MAKE], [gmake make]) -AC_PATH_PROG([MKDEP], [makedepend]) AC_PATH_PROG([SED], [sed]) +AC_PATH_PROG([MKDEP], [makedepend], no) +if test x$MKDEP = xno; then + AC_MSG_ERROR([makedepend not found]) +fi Yep, that would do it. In fact, when I wrote configure.ac originally, I wanted it to be a hard requirement and assumed that AC_PATH_PROG would error by default if it didn't find the program. Should I resubmit a proper git patch ? I have been running with makedepend installed on my 3 systems for 1 month, it has worked very well. I don't think I got ONE weird failure in the past month, while I used to get more than once per week. The only thing I need is to sometimes run autogen.sh and/or configure, when there are some structure changes (e.g. nv30-nv40 merge to nvfx). AFAIK this is also handled automatically in other projects. But this is much less annoying, because it fails at build time, instead of segfaulting at runtime. Everyone complains about mesa crappy build system so I thought all the failures I got were expected. Now I see they weren't, just that makedepend is badly required :) I am just worried some people might run into the same troubles as me. But I wonder if there are any since only Dan answered in that thread. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv50 mouse cursor disappears hourly
On Mon, Mar 15, 2010 at 7:51 PM, Brian DeRocher br...@derocher.org wrote: On Sunday 14 March 2010 05:37:59 you wrote: Is this a regression ? Did you build an earlier kernel that worked ? .git/logs/HEAD might help. Here's the whole file. a8072c2a92a13511e28edbec015b58c6b66c35c9 root r...@bregalad.noblis.org 1260291438 -0500 clone: from git://anongit.freedesktop.org/git/nouveau/linux-2.6 a8072c2a92a13511e28edbec015b58c6b66c35c9 a733b93582023fd100c5ce6430f3a0b0f26af86c root r...@bregalad.noblis.org 1266534758 -0500 pull : Fast-forward a733b93582023fd100c5ce6430f3a0b0f26af86c d03ab2d78b6ab62e94f9958da50b4419c27e0f60 root r...@bregalad.noblis.org 1267454502 -0500 pull : Fast-forward I'm trying to remember the history. Here are the dates of those updates. 2009-12-08 Merge remote branch 'korg/drm-radeon-dp' into drm-linus Dave Airlie 24 -323/+2657 2010-02-17 drm/nouveau: fix i2ctable bounds checking Marcin Slusarz 1 -3/+4 2010-03-01 drm/nv50: Improve PGRAPH interrupt handling. Marcin Kościelnicki 7 -56/+622 After the first cloning, the other packages like drm or xf86-video-nouveau didn't compile. So i reverted back to using a stock debian kernel. After the first update. I'm pretty sure it was working correctly. No cursors disappearing. After the second update clearly it's failing. I'd be glad to revert back and test, if someone would help me with the git commands. Should i try git bisect? I suppose i'll need to do the same with drm and xf86-video-nouveau in order to (1) get it to compile and (2) recreate the same conditions. Is that right? Since 2010-02-17 is right after the ABI break, this should not cause any problems, so I would just move back to this older kernel first with git checkout and check for some period that it indeed works. And if it does work, start a bisection between these two dates. Looking back at this commit range, there is the nv50 ctxprog right in the middle. So maybe it would be a good idea to try this nouveau module parameter first : parm: ctxfw:Use external firmware blob for grctx init (NV40) (int) (it seems the param description needs an update for NV50 ;) ) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv50 mouse cursor disappears hourly
2010/3/15 Xavier Chantry chantry.xav...@gmail.com: Since 2010-02-17 is right after the ABI break, this should not cause any problems, so I would just move back to this older kernel first with git checkout and check for some period that it indeed works. And if it does work, start a bisection between these two dates. Looking back at this commit range, there is the nv50 ctxprog right in the middle. So maybe it would be a good idea to try this nouveau module parameter first : parm: ctxfw:Use external firmware blob for grctx init (NV40) (int) (it seems the param description needs an update for NV50 ;) ) I should always ask first people who know better :) 20:19 mwk shining: fwiw, ctxprog generator shouldn't be the one causing cursor screwups 20:19 mwk it deals with entirely different area of card 20:19 mwk ctxprog == PGRAPH, cursor == PDISPLAY 20:19 mwk evoch == PDISPLAY too ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv50 mouse cursor disappears hourly
On Thu, Mar 11, 2010 at 9:30 PM, Brian DeRocher br...@derocher.org wrote: I compiled linux-2.6 from git. I think my last pull/merge? is this one (git show) commit d03ab2d78b6ab62e94f9958da50b4419c27e0f60 Author: Marcin Kościelnicki koria...@0x04.net Date: Mon Mar 1 00:18:39 2010 + drm/nv50: Improve PGRAPH interrupt handling. Is this a regression ? Did you build an earlier kernel that worked ? .git/logs/HEAD might help. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification
On Mon, Mar 15, 2010 at 12:12 AM, Keith Whitwell keith.whitw...@googlemail.com wrote: On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell keith.whitw...@googlemail.com wrote: Sounds good to me - fewer driver directories to fix up after changes... It'd be good to get this merged sooner rather than later as I'll soon be starting on pipe_resources conversion for the nv drivers. Once I do that, there will be heaps of conflicts with your patches, but if I can merge them in before I do the conversion all will be well... I tested unification+fixes branch on nv35 with 11 games that you can see on that page : http://nouveau.freedesktop.org/wiki/XavierChantry No regression to report compared to mesa master. A benefit worth mentioning is the SWTNL support which allows to run the 4 games currently broken with mesa master. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] Remove leftover in man page and nv_const.h
Signed-off-by: Xavier Chantry chantry.xav...@gmail.com
---
man/nouveau.man | 16
src/nv_const.h |1 -
2 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/man/nouveau.man b/man/nouveau.man
index 87f645a..cd66e9a 100644
--- a/man/nouveau.man
+++ b/man/nouveau.man
@@ -70,22 +70,6 @@ Enable or disable the HW cursor. Default: on.
.BI Option \*qNoAccel\*q \*q boolean \*q
Disable or enable acceleration. Default: acceleration is enabled.
.TP
-.BI Option \*qFPDither\*q \*q boolean \*q
-Many digital flat panels (particularly ones on laptops) have only 6 bits
-per component color resolution.
-This option tells the driver to dither from 8 bits per component to 6 before
-the flat panel truncates it.
-Default: off.
-.TP
-.BI Option \*qFPScale\*q \*q boolean \*q
-Supported only on GeForce4 and newer chips, this option
-tells to the driver to scale lower resolutions up to the flat panel's native
-resolution. Default: on.
-.TP
-.BI Option \*qScalingMode\*q \*q string \*q
-Only for the randr-1.2 driver, this allows to set the DFP scaling mode.
-The options are fullscreen, aspect, noscale and panel. Default:
aspect.
-.TP
.BI Option \*qShadowFB\*q \*q boolean \*q
Enable or disable use of the shadow framebuffer layer. Default: off.
.SH SEE ALSO
diff --git a/src/nv_const.h b/src/nv_const.h
index 767344c..09293e0 100644
--- a/src/nv_const.h
+++ b/src/nv_const.h
@@ -23,7 +23,6 @@ static const OptionInfoRec NVOptions[] = {
{ OPTION_NOACCEL, NoAccel, OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_SHADOW_FB, ShadowFB, OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_VIDEO_KEY,VideoKey, OPTV_INTEGER, {0},
FALSE },
-{ OPTION_EXA_PIXMAPS, EXAPixmaps, OPTV_BOOLEAN, {0}, FALSE },
{ -1, NULL, OPTV_NONE, {0}, FALSE }
};
--
1.7.0.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] Remove leftover in man page and nv_const.h
On Fri, Mar 5, 2010 at 12:53 AM, Xavier Chantry chantry.xav...@gmail.com wrote: Signed-off-by: Xavier Chantry chantry.xav...@gmail.com --- man/nouveau.man | 16 src/nv_const.h | 1 - 2 files changed, 0 insertions(+), 17 deletions(-) Other comments about the man page : 1 - SWcursor and VideoKey are not documented 2 - The supported hardware is incomplete, do we even want to maintain a complete list of all codenames ? We already have that on this page : http://nouveau.freedesktop.org/wiki/CodeNames But the man page is organized in a different way, it doesn't even look straightforward to convert the CodeNames page to the manpage organization 3 - are the AUTHORS and COPYRIGHT sections right ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Mesa3d-dev] makedepend in Mesa
On Tue, Feb 23, 2010 at 11:14 PM, Dan Nicholson dbn.li...@gmail.com wrote: We could use gcc directly for depends (I have a patch to do it), but: 1. I don't think it would actually help much in terms of rebuilds since makedepend seems to do a perfectly adequate job of finding the needed headers. 2. gcc expects to output a single make target for a single source file. mesa just tosses all the source files at makedepend which generates a depend file with a bunch of targets. gcc is phenomenally slow doing the same. Changing the build to include one dep file per source file would be a ton of churn. 3. The fast way automake does gcc dep tracking is to do it as a step during the compile. Since gcc fully preprocesses the source file before generating the make target, you can get it for free during the compile. Doing as a separate step like mesa means you're throwing away the preprocessing and then doing it again immediately afterward. The time adds up. I guess what I'm saying is that I wouldn't bother with gcc dep tracking unless it's coming as part of automake. Thanks for all these explanations ! configure checks for makedepend, but doesn't error if it's not found. It probably should. Likewise, the commands running makedepend should probably not be silenced with stderr redirected to /dev/null. That would break builds for people using the static configs without makedepend. Why do we need static configs ? If I understand correctly, we have the choice between 1 autoconf file, and more than 100 static config files ? And autoconf can potentially capture all these static configurations and more ? I think the problem is more that it's not used consistently since it has to be setup manually in the Makefile vs. automatically like automake. My understanding of autotools is still very limited. mesa currently doesn't use automake, does it ? A git grep automake lets me believe that it was dropped in 5.1 So currently makedepend needs to be setup manually in all the Makefiles ? And using automake would give a big advantage on the two sides : 1) automatic makedepend setup 2) efficient use of gcc dep tracking ? I'd be comfortable having makedepend be a hard requirement in configure. Otherwise, I'd rather have this be AC_MSG_WARN([your message]) right after the AC_PATH_PROG for makedepend. Actually I wanted to propose a hard requirement but then thought some people might complain. If I just put a AC_MSG_WARN right after AC_PATH_PROG, I am afraid it won't make a big difference as it won't be very visible. To make a hard requirement, I could just use AC_MSG_ERROR instead ? [I wonder if it wouldn't be easier to make scons work like I want to avoid all these problems. I believe I would just need to add nouveau support, and probably look into this : # TODO: Build several variants at the same time? # http://www.scons.org/wiki/SimultaneousVariantBuilds] diff --git a/configure.ac b/configure.ac index 485836a..a582337 100644 --- a/configure.ac +++ b/configure.ac @@ -28,8 +28,11 @@ AC_PROG_CPP AC_PROG_CC AC_PROG_CXX AC_CHECK_PROGS([MAKE], [gmake make]) -AC_PATH_PROG([MKDEP], [makedepend]) AC_PATH_PROG([SED], [sed]) +AC_PATH_PROG([MKDEP], [makedepend], no) +if test x$MKDEP = xno; then +AC_MSG_ERROR([makedepend not found]) +fi dnl Our fallback install-sh is a symlink to minstall. Use the existing dnl configuration in that case. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] low memory
On Tue, Feb 9, 2010 at 8:49 PM, Xavier Chantry chantry.xav...@gmail.com wrote: 12:08 curro_ shining: hmm, it seems, darktama didn't quite finish the additional reloc checking he started to code 12:11 curro_ shining: that would have solved your problem, poke him when he's back from vacations :) 12:16 shining curro_: hmm I really dont get it, it looks like domain can have both set, and flags can also have both set 12:16 shining I want to look at the reloc checking, what made you say he didnt finish ? 12:23 curro_ shining: when you pin a BO, it can't end up in several locations at the same time :P 12:23 curro_ he implemented the necessary stuff to track available aperture space from userspace 12:23 curro_ but he didn't make the reloc functions check if the buffers would actually fit /me pokes darktama :) Let me remind you my wonderful test case : loading a 3500x2500 pixmap in firefox with 64mb vram. After talking a bit more with curro, I started to write a patch. I don't know how bad and wrong it is, there are still so many things I don't understand. It seems it works somehow, meaning OUT_RELOC - emit_reloc will fail before FIRE_RING - pushbuf_flush. But enomem failures during pushbuf_flush still happen. And worse, what happens after an OUT_RELOC failure is awful : 1) on nv25, the system freezes for 5 seconds, and after the lower part (a rectangle) of the picture seems to have a wrong offset or something. 2) on nv84 (hacked to force 64mb vram) : X crash because of a bug in nouveau_wfb.c . After fixing that, the pixmap is correctly displayed *after* the system freezes between 1min30 and 2min (There are several options for fixing the imprecision bug of fast divide in nouveau_wfb.c but I would like to be able to run this code in a normal situation, without crazy system freezing and extreme slowness, so that I can hopefully do proper benchmarking between the different options :) ) I ran oprofile on nv25 in these two configurations : 1) previous workaround of making nouveau_exa_create_pixmap always fail : performance still acceptable (early fallback) 2) runtime OUT_RELOC failure and fallback : turtle speed (late fallback) The commit that implemented workaround 1 for 32mb vram says : exa: force the use of sysmem pixmaps on low-mem cards Very similar effect to forcing MigrationHeuristic greedy on classic EXA. Far better than the migration ping-pong that'd occur otherwise I suppose that arch/x86/mm/pageattr.c showing up in the profile, and pixman_blt_mmx taking ages are consequences of that migration ping-pong ? But I still don't understand what is going on, what migrations are made and how to limit them. Just to clarify : the problems on nv84 (slowness and nouveau_wfb crashing X) only happen after limiting vram to 64mb. It was just a sidetest to see if I could reproduce the nv25 situation. There are probably not real problems. My goal is just to get nv25 render pixmaps properly at acceptable speed instead of freezing 5 seconds to display a black box. 64mb seems to be the worst amount one can have. Below that, we don't even try and disable accel. And with more memory, it might be less usual to run out of it. To sum up the discussion with curro and stillunknown, the different alternatives seem to be : 1) Fallback on reloc failures, to avoid pushbuf / ttm validation failure, as my libdrm patch attempted. But this seems to cause extreme slowness, which could be explained by the system reading the pixmap in vram. 2) Earlier fallback in nouveau_exa_create_pixmap 2.1) just bump limit from 32 to 64. This causes everything to be done in software but is actually the only way I found which is never extremely slow. 2.2) only fallback for pixmaps which are big compared to the amount of vram. This solution fixed the pixmap rendering, but for example dragging a window on top of the pixmap would kill the system. However I could workaround this using xcompmgr. I am tempted to just go with 2.1 and stop bothering everyone with this. It's the most trivial fix and will cause less surprises to whoever use that machine :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau: [drm] failed to open device
On Thu, Feb 18, 2010 at 12:55 PM, Daniel Mack dan...@caiaq.de wrote: On Thu, Feb 18, 2010 at 12:37:19PM +0100, Xavier Chantry wrote: On Thu, Feb 18, 2010 at 10:38 AM, Daniel Mack dan...@caiaq.de wrote: Hi, I'm trying to get the new nouveau kernel driver (2.6.33-rc8) to work with X.Org 1.7.4 (Debian/unstable, all relevant packages updated). The modules load just fine, and the kernel spits out the following upon probe: [ 8.304602] nouveau :06:00.0: PCI INT A - Link[LNEB] - GSI 18 (level, low) - IRQ 18 [ 8.304779] nouveau :06:00.0: setting latency timer to 64 [ 8.313364] [drm] nouveau :06:00.0: Detected an NV40 generation card (0x044300a2) [ 8.313812] [drm] nouveau :06:00.0: Attempting to load BIOS image from PROM [ 8.521142] [drm] nouveau :06:00.0: ... appears to be valid [ 8.521148] [drm] nouveau :06:00.0: BIT BIOS found [ 8.521151] [drm] nouveau :06:00.0: Bios version 05.44.02.62 [ 8.521156] [drm] nouveau :06:00.0: BIT table 'd' not found [ 8.521159] [drm] nouveau :06:00.0: Found Display Configuration Block version 3.0 ... However, when starting X.Org (installed from the Debian package), I get this: X.Org X Server 1.7.4 Release Date: 2010-01-08 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-trunk-686 i686 Debian Current Operating System: Linux jup 2.6.33-rc8 #20 SMP PREEMPT Wed Feb 17 11:26:28 CET 2010 i686 Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.git root=/dev/sda3 ro quiet Build Date: 20 January 2010 10:52:55PM xorg-server 2:1.7.4-2 (bgog...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Wed Feb 17 17:00:25 2010 (==) Using config file: /etc/X11/xorg.conf (EE) [drm] failed to open device (EE) No devices detected. From the strace output (http://pastebin.com/m12d5b19a) I cannot see what the problem could possibly be, and searching the FAQs and archives didn't help me either. I can't see any errors or warning anywhere except for the one above. The full X log is here: http://pastebin.com/m731c3561 And my xorg.conf is here: http://pastebin.com/m5f143408 Any pointers appreciated - I got the evil feeling to overlook the obvious ;) Did you have a look at the wiki ? Latest news on http://nouveau.freedesktop.org/wiki/ I in fact did, yes. But I couldn't find any explanation to what I'm seeing. Sorry if this is covered by the FAQ - just point me there then. Which libdrm version are you using ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau: [drm] failed to open device
On Thu, Feb 18, 2010 at 2:05 PM, Daniel Mack dan...@caiaq.de wrote: Which libdrm version are you using ? 2.4.0, built from the git sources yesterday. Bump of the userspace interface to 0.0.16. libdrm and nouveau drm have to be updated together for nouveau to keep working. The kernel.org version will not work with the current git user space for some time. See the kernel commit log for more information. This means kernel.org tree does not work with libdrm git. (so you can either use older git userspace or a newer nouveau drm module/kernel) If this is not clear enough, do you have a suggestion for rephrasing the paragraph on the frontpage ? I suppose we could also add an entry in either Faq or Troubleshooting. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Mouse cursor rotated on all screens when rotating a single screen.
On Thu, Feb 18, 2010 at 1:27 PM, Hans Wurst bon3f...@gmail.com wrote: I have two monitors, one landscape and the other portrait. When I rotate the portrait monitor using xrandr (or the xorg.conf option) the mouse cursor on the landscape monitor is also rotated and the click point is no longer below the cursor (this makes the mouse practically unusable). The cursor is correct on the rotated monitor. Setting NoAccel False and HWCursor False in xorg.conf results in a corrupted screen and lockup. I am running an up-to-date i686 Arch Linux with the latest git version of xf86-video-nouveau (I used the AUR package). xorg-server is from the arch core repositories. My card is the GeForce9500GT (two DVI ports on the card). I've got the exact same problem. So: *BUMP* See https://bugs.freedesktop.org/show_bug.cgi?id=26102 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] texture dimension limits in ddx
in nv10_exa.c :
check_texture does :
if (w 2046 || h 2046)
NOUVEAU_FALLBACK(picture too large, %dx%d\n, w, h);
check_render_target does :
if (w 4096 || h 4096)
return FALSE;
So we have different size limits for the source and the destination ?
Another thing is that nv20 uses nv10_exa.c code, and the limit in
check_texture could be increased for nv20 according to curro :
01:03 curro_ shining: btw, about the 2048x2048 fallback, i'm quite
sure it's wrong for nv2x
01:05 curro_ shining: it can do 4096x4096 with no problems, IIRC
And finally I saw that nouveau_exa_init does this :
if (pNv-Architecture = NV_ARCH_50) {
exa-maxX = 8192;
exa-maxY = 8192;
} else
if (pNv-Architecture = NV_ARCH_20) {
exa-maxX = 4096;
exa-maxY = 4096;
} else {
exa-maxX = 2048;
exa-maxY = 2048;
}
But these 3 values are hardcoded everywhere in the code.
It might not be possible to use exa-maxX/Y directly as some functions
like check_texture / check_render_target above don't seem to have
access to them.
Maybe some constants could be defined instead and used everywhere ?
#define NV04_MAX 2048
#define NV20_MAX 4096
#define NV50_MAX 8192
or something.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] low memory
12:08 curro_ shining: hmm, it seems, darktama didn't quite finish
the additional reloc checking he started to code
12:11 curro_ shining: that would have solved your problem, poke him
when he's back from vacations :)
12:16 shining curro_: hmm I really dont get it, it looks like
domain can have both set, and flags can also have both set
12:16 shining I want to look at the reloc checking, what made you
say he didnt finish ?
12:23 curro_ shining: when you pin a BO, it can't end up in several
locations at the same time :P
12:23 curro_ he implemented the necessary stuff to track available
aperture space from userspace
12:23 curro_ but he didn't make the reloc functions check if the
buffers would actually fit
/me pokes darktama :)
Let me remind you my wonderful test case : loading a 3500x2500 pixmap
in firefox with 64mb vram.
After talking a bit more with curro, I started to write a patch. I
don't know how bad and wrong it is, there are still so many things I
don't understand.
It seems it works somehow, meaning OUT_RELOC - emit_reloc will fail
before FIRE_RING - pushbuf_flush.
But enomem failures during pushbuf_flush still happen. And worse, what
happens after an OUT_RELOC failure is awful :
1) on nv25, the system freezes for 5 seconds, and after the lower part
(a rectangle) of the picture seems to have a wrong offset or
something.
2) on nv84 (hacked to force 64mb vram) : X crash because of a bug in
nouveau_wfb.c . After fixing that, the pixmap is correctly displayed
*after* the system freezes between 1min30 and 2min
(There are several options for fixing the imprecision bug of fast
divide in nouveau_wfb.c but I would like to be able to run this code
in a normal situation, without crazy system freezing and extreme
slowness, so that I can hopefully do proper benchmarking between the
different options :) )
I ran oprofile on nv25 in these two configurations :
1) previous workaround of making nouveau_exa_create_pixmap always fail
: performance still acceptable (early fallback)
2) runtime OUT_RELOC failure and fallback : turtle speed (late fallback)
The commit that implemented workaround 1 for 32mb vram says :
exa: force the use of sysmem pixmaps on low-mem cards
Very similar effect to forcing MigrationHeuristic greedy on classic
EXA. Far better than the migration ping-pong that'd occur otherwise
I suppose that arch/x86/mm/pageattr.c showing up in the profile, and
pixman_blt_mmx taking ages are consequences of that migration
ping-pong ?
But I still don't understand what is going on, what migrations are
made and how to limit them.
From 778258e823b4a55d2a4cbfff16230f91d8de3b89 Mon Sep 17 00:00:00 2001
From: Xavier Chantry chantry.xav...@gmail.com
Date: Mon, 1 Feb 2010 17:42:37 +0100
Subject: [PATCH] check memory for relocs
---
nouveau/nouveau_private.h |3 +++
nouveau/nouveau_pushbuf.c | 35 +++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/nouveau/nouveau_private.h b/nouveau/nouveau_private.h
index 39758d1..c04a603 100644
--- a/nouveau/nouveau_private.h
+++ b/nouveau/nouveau_private.h
@@ -59,6 +59,9 @@ struct nouveau_pushbuf_priv {
unsigned nr_buffers;
struct drm_nouveau_gem_pushbuf_reloc *relocs;
unsigned nr_relocs;
+
+ uint64_t relocs_vram_size;
+ uint64_t relocs_gart_size;
};
#define nouveau_pushbuf(n) ((struct nouveau_pushbuf_priv *)(n))
diff --git a/nouveau/nouveau_pushbuf.c b/nouveau/nouveau_pushbuf.c
index 7da3a47..3e7c3b7 100644
--- a/nouveau/nouveau_pushbuf.c
+++ b/nouveau/nouveau_pushbuf.c
@@ -241,6 +241,9 @@ restart_push:
goto restart_push;
}
+ if (ret)
+ fprintf(stderr, validate failed : %d!!\n, ret);
+
/* Update presumed offset/domain for any buffers that moved.
* Dereference all buffers on validate list
@@ -267,6 +270,9 @@ restart_push:
nvpb-nr_buffers = 0;
nvpb-nr_relocs = 0;
+ nvpb-relocs_vram_size = 0;
+ nvpb-relocs_gart_size = 0;
+
/* Allocate space for next push buffer */
assert(!nouveau_pushbuf_space(chan, min));
@@ -314,6 +320,13 @@ nouveau_pushbuf_marker_undo(struct nouveau_channel *chan)
if (--nvbo-pending_refcnt)
continue;
+
+ if (pbbo-presumed_domain NOUVEAU_GEM_DOMAIN_VRAM) {
+ nvpb-relocs_vram_size -= nvbo-size;
+ } else {
+ nvpb-relocs_gart_size -= nvbo-size;
+ }
+
nvbo-pending = NULL;
nouveau_bo_ref(NULL, bo);
nvpb-nr_buffers--;
@@ -355,11 +368,13 @@ nouveau_pushbuf_emit_reloc(struct nouveau_channel *chan, void *ptr,
struct nouveau_bo *bo, uint32_t data, uint32_t data2,
uint32_t flags, uint32_t vor, uint32_t tor)
{
+ struct nouveau_device_priv *nvdev = nouveau_device(chan-device);
struct nouveau_pushbuf_priv *nvpb = nouveau_pushbuf(chan-pushbuf);
struct nouveau_bo_priv *nvbo = nouveau_bo(bo);
struct drm_nouveau_gem_pushbuf_reloc *r;
struct drm_nouveau_gem_pushbuf_bo *pbbo;
uint32_t domains = 0;
+ uint64_t *current_size, max_size;
if (nvpb-nr_relocs = NOUVEAU_GEM_MAX_RELOCS) {
fprintf(stderr, too many relocs!!\n
Re: [Nouveau] [RFC] Merge of a reincarnation of the nouveau classic mesa driver.
On Tue, Feb 2, 2010 at 12:01 PM, Francisco Jerez curroje...@riseup.net wrote: For a long time the gallium pipe drivers for nvidia fixed function cards (nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and godforsaken -- especially nv0x and nv1x had seen almost no progress since their creation. They've recently grown a classic mesa driver which implements many new features: texturing, hardware-accelerated tnl. However the killer feature is it actually draws stuff (and if you're lucky even some simple games at reasonable FPS) so I don't like to consider this a step back. Right now it is located in a git repo here [1], mesa-next is the branch I'm proposing to merge. I'll reply myself with the patches affecting core mesa it depends on, to give them more visibility. Of course driver-related comments are welcome too. [1] http://cgit.freedesktop.org/~currojerez/mesa/ I did some testing of a few opengl games, just for fun and by curiosity. Card is nv25 (64mb vram). - works perfectly openarena tremulous xmoto frozen-bubble hedgewars neverball supertux2 - works with some problems * teeworlds : perfect after a hack to workaround this issue : nv04_surface.c:246: nv04_surface_copy_swizzle: Assertion `!(dst-offset 63)' failed. * foobillard : works but this error shows up : Mesa: User error: GL_STACK_OVERFLOW in glPushMatrix(mode=GL_TEXTURE, unit=0) * etracer : first few seconds are very very slow, then its still very slow compared to all the other games. Also some texture problems after a recent change. * bzflag : full screen mode broken but window mode ok. Fonts look weird (apparently some random corruptions) - fails glest : needs mesa 1.3 I think it's pretty good overall :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] swap control
Is it possible to use sync to vblank / swap control with mesa/gallium (and nouveau) ? I googled it but did not find any clear answers about how it is supposed to be enabled. I also tried to read the code, and I am getting lost. So I didn't find any answers to any of these questions : 1) how are we supposed to enable it ? is there an env var , or ~/.drirc ? is drirc/driconf still valid with dri2 ? 2) is it supported by mesa/gallium ? and nouveau ? It looks like there were some related changes with dri2.2 but that might not concern SGI/MESA swap_control extensions. http://lists.x.org/archives/xorg-devel/2009-October/003209.html Anyway when running progs/xdemos/glxswapcontrol with softpipe, I get the following message : Unable to set swap-interval. Neither GLX_SGI_swap_control nor GLX_MESA_swap_control are supported. And I do not get when using nouveau, so it seems these extensions are announced but not supported. Another mystery : right after the dri2.2 merge, running glxgears showed the following bogus message : Running synchronized to the vertical refresh. The framerate should be approximately 1/12400064 the monitor refresh rate. 4843 frames in 5.0 seconds = 968.573 FPS Again I tried to read the code when it happened but I didn't find anything. And the message went away soon after, but I don't know when and why. Probably during one of the regular mesa update.. but I couldn't find which patch fixed it. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau: add ratelimit to nouveau_graph_dump_trap_info
Often when things get stuck spinning, nouveau_pgraph_intr_error and
nouveau_graph_dump_trap_info gets called many times, flooding logs with
PGRAPH_ERROR and filling up the disk.
Pekka Paalanen pointed me to ratelimit, so I went ahead and added some
ratelimit support. It is much better now :)
I am completely new to the kernel world though so I hope I did not do
something terribly wrong.
Signed-off-by: Xavier Chantry shinin...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_irq.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 597007a..0aae8c2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -462,6 +462,14 @@ nouveau_pgraph_intr_notify(struct drm_device *dev,
uint32_t nsource)
nouveau_graph_dump_trap_info(dev, PGRAPH_NOTIFY, trap);
}
+DEFINE_RATELIMIT_STATE(nouveau_ratelimit_state, 3 * HZ, 20);
+
+int nouveau_ratelimit(void)
+{
+ return __ratelimit(nouveau_ratelimit_state);
+}
+
+
static inline void
nouveau_pgraph_intr_error(struct drm_device *dev, uint32_t nsource)
{
@@ -478,7 +486,7 @@ nouveau_pgraph_intr_error(struct drm_device *dev, uint32_t
nsource)
unhandled = 1;
}
- if (unhandled)
+ if (unhandled nouveau_ratelimit())
nouveau_graph_dump_trap_info(dev, PGRAPH_ERROR, trap);
}
--
1.6.5.3
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] nouveau: add ratelimit to nouveau_graph_dump_trap_info
Often when things get stuck spinning, nouveau_pgraph_intr_error and
nouveau_graph_dump_trap_info gets called many times, flooding logs with
PGRAPH_ERROR and filling up the disk.
Pekka Paalanen pointed me to ratelimit, so I went ahead and added some
ratelimit support. It is much better now :)
I am completely new to the kernel world though so I hope I did not do
something terribly wrong.
Signed-off-by: Xavier Chantry shinin...@gmail.com
---
Addressed a few comments from pq (or is it PP ? :D)
* make the function and global variable static
* fix whitespace damage
drivers/gpu/drm/nouveau/nouveau_irq.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index 597007a..fa3b5d1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_irq.c
+++ b/drivers/gpu/drm/nouveau/nouveau_irq.c
@@ -462,6 +462,14 @@ nouveau_pgraph_intr_notify(struct drm_device *dev,
uint32_t nsource)
nouveau_graph_dump_trap_info(dev, PGRAPH_NOTIFY, trap);
}
+static DEFINE_RATELIMIT_STATE(nouveau_ratelimit_state, 3 * HZ, 20);
+
+static int nouveau_ratelimit(void)
+{
+ return __ratelimit(nouveau_ratelimit_state);
+}
+
+
static inline void
nouveau_pgraph_intr_error(struct drm_device *dev, uint32_t nsource)
{
@@ -478,7 +486,7 @@ nouveau_pgraph_intr_error(struct drm_device *dev, uint32_t
nsource)
unhandled = 1;
}
- if (unhandled)
+ if (unhandled nouveau_ratelimit())
nouveau_graph_dump_trap_info(dev, PGRAPH_ERROR, trap);
}
--
1.6.5.3
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
