This fixes write faults from GPCCLIENT 5 in geometry shader tests.
For now this is just a guess from a single mmio trace, it looks
like 8 large pages are being used, i.e. one per TPC.
Can we just ask NV for the correct sizes ?
---
drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c | 2 +-
1
This fixes write faults from GPCCLIENT 5 in geometry shader tests.
For now this is just a guess from a single mmio trace, it looks
like 8 large pages are being used, i.e. one per TPC.
Can we just ask NV for the correct sizes ?
---
drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c | 2 +-
1
---
drivers/gpu/drm/nouveau/nouveau_drm.h | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h
b/drivers/gpu/drm/nouveau/nouveau_drm.h
index b25df37..04cc466 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++
---
.../gpu/drm/nouveau/core/engine/software/nvc0.c| 29
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
index a523eaa..d698e71 100644
---
---
drivers/gpu/drm/nouveau/core/engine/graph/nve0.c | 230 ++
1 files changed, 230 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nve0.c
b/drivers/gpu/drm/nouveau/core/engine/graph/nve0.c
index 4b45afb..e411b18 100644
---
---
drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 10 ++
drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 10 ++
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 15 +++
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h |2 ++
---
drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h |7 +
drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +
drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c| 129 +++-
drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +-
4 files
---
drivers/gpu/drm/nouveau/nvd0_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvd0_display.c
b/drivers/gpu/drm/nouveau/nvd0_display.c
index c486d3c..c50b075 100644
--- a/drivers/gpu/drm/nouveau/nvd0_display.c
+++
On 06.05.2012 20:53, Marcin Slusarz wrote:
Fixes 3 piglit tests:
general/pos-array
shaders/glsl-novertexdata
shaders/glsl-vs-point-size
and makes shaders/vp-ignore-input not trigger PGRAPH DATA_ERROR
---
It's a bit ugly... If there's a way to fix it properly, I'm open to
suggestions.
---
On 05/03/2012 03:08 PM, Marcin Slusarz wrote:
On Sun, Apr 15, 2012 at 01:46:42PM +0200, Marcin Slusarz wrote:
Regression from WIP: port to new libdrm.
---
src/nv50_accel.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/nv50_accel.c b/src/nv50_accel.c
index
On 30.04.2012 19:16, Lucas Stach wrote:
Fixes an assertion seen by users.
Signed-off-by: Lucas Stach d...@lynxeye.de
Tested-by: JohnDoe_71Rus on irc
---
src/mesa/drivers/dri/nouveau/nouveau_context.c |9 +
1 file changed, 9 insertions(+)
diff --git
Contexts in instance memory were not added to PMPEG until nv44.
---
drivers/gpu/drm/nouveau/nv31_mpeg.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv31_mpeg.c
b/drivers/gpu/drm/nouveau/nv31_mpeg.c
index 6f06a07..bd90d51 100644
On 07.02.2012 13:47, Jose Fonseca wrote:
Makes sense.
Very much so ...
http://cgit.freedesktop.org/mesa/mesa/commit/?id=189e6c7e81ce35b89d9b52d4bd0d6271a7e9c10f
(of 26 hours ago).
Jose
- Original Message -
The assertion added in f09910f3 broke nv50 completely by asserting
that
Safety margins checked on GTX470, not verified on other cards with
a different number of memory partitions.
---
drivers/gpu/drm/nouveau/nouveau_state.c | 35 +++---
drivers/gpu/drm/nouveau/nvc0_fb.c | 81 +++
drivers/gpu/drm/nouveau/nvc0_vm.c |
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 23 ++
drivers/gpu/drm/nouveau/nouveau_crtc.h |3 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 12 +++
drivers/gpu/drm/nouveau/nouveau_drv.h |3 ++
drivers/gpu/drm/nouveau/nv50_crtc.c | 42
Without this, they return bytes written since the last update of
the offset, but we want the full offset.
Trace shows setting this on GPC[0]/TP[0] is enough.
---
drivers/gpu/drm/nouveau/nvc0_graph.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
Without this, they return bytes written since the last update of
the offset, but we want the full offset.
Trace shows setting this on GPC[0]/TP[0] is enough.
---
drivers/gpu/drm/nouveau/nvc0_graph.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
On 07/09/2011 05:22 PM, Andrew Randrianasulu wrote:
Hello. I have nv18 card in my machine currently.
It works with kernel 3.0.0.-rc6 (i need to pass nouveau.tv_disable=1
parameter
to module, because uothervise it thinks i have TV connected, while in fact I
have only VGA CRT monitor
On 13.05.2011 13:20, Francesco Marella wrote:
-Francesco
Pushed, thank you.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
On 13.11.2010 11:20, Patrice Mandin wrote:
Hello,
As nv30/nv40 supports primitive restart in hardware, here is a patch.
Thank you, note however that this does not make it work yet in the case
where the driver decides to push vertex data on the FIFO directly, which
is implemented via the
(not an address)) become effective.
Thoughts, ack / nack ?
Thanks,
Christoph
From f37dea43c705683a89e31da78200872cc00ac967 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Sun, 14 Mar 2010 11:19:27 +0100
Subject: [PATCH] nv50: get rid of the screen_init
On 14.03.2010 13:03, Maarten Maathuis wrote:
On Sun, Mar 14, 2010 at 11:32 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
Hi.
There's not much to say here, just replacing the screen_init
stateobj with direct pushbuffer emission.
We don't need to store all the usless state
On 11.03.2010 18:42, Uwe Bugla wrote:
Hi,
I use two nv34 cards and I would like to test / try out / use the
Gallium driver without drawbacks.
Note that you said use, and not own, which is a little
biased towards they're plugged into the same MB.
Unfortunately this has not been working
Just wanted to communicate some thoughts I had while reading the diffs,
even thought I didn't have the time to look at everything in detail yet.
- nv50: use relocs rather than re-uploading TIC all the time
It's nice that we can write relocs to arbitrary buffers, and it's much
less work than
On 02/05/2010 06:01 PM, Marcin Kościelnicki wrote:
Turns out we used a misaligned long instruction near the end, and the
shader was getting killed after writing R, A components. This has gone
unnoticed since the remaining G, B outputs aren't actually used.
Thank you, pushed.
---
by mapping a bo (since I didn't reloc one),
and thus I have to busy wait on the notifier area, which isn't
necessarily optimal ...
Any suggestions ?
Christoph
From 5f08c8ec98e389f69d80b4529a89ebaee3a72a93 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Tue, 5 Jan 2010
c1de285273004f90937e909187db654d789617b7 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Wed, 30 Dec 2009 18:28:25 +0100
Subject: [PATCH] nv50: check drawable.bitsPerPixel instead of depth to get
format
---
src/nv50_exa.c |6 +++---
src/nv50_xv.c |6
On 12/30/2009 06:37 PM, Christoph Bumiller wrote:
On 12/29/2009 06:06 PM, Marcin Slusarz wrote:
On Mon, Dec 28, 2009 at 06:55:23PM +0100, Maarten Maathuis wrote:
On Mon, Dec 28, 2009 at 6:37 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
---
src/nv50_exa.c | 155
On 12/28/2009 08:15 AM, Younes Manton wrote:
On Mon, Dec 28, 2009 at 1:55 AM, Luca Barbieri l...@luca-barbieri.com wrote:
Can you reproduce this with your vertex buffers in VRAM instead of GART?
(to rule out that it's a fencing issue).
Putting the vertex buffers in VRAM makes things almost
On 12/27/2009 12:41 PM, Maarten Maathuis wrote:
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff
Maarten Maathuis schrieb:
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_stateobj.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nouveau_stateobj.h
Krzysztof Smiechowicz schrieb:
Hi,
My name is Krzysztof and currently I'm working on porting nouveau
(gallium3d driver + libdrm + drm) to AROS Research OS
(http://www.aros.org). I completed a quite successful port of old drm
(one from libdrm git - now removed) and currently I'm working
On 17.12.2009 19:11, Krzysztof Smiechowicz wrote:
Christoph Bumiller pisze:
Hi.
Hi, thanks for the quick feedback. :)
Most probably the state tracker calls pipe_buffer_map on the vertex
buffer which (if it was not created as a user buffer) causes an mmap
of it to the user's
On 13.12.2009 16:07, Maarten Maathuis wrote:
- Added flush notify functions for NV30 and NV40.
- NV30 and NV40 need testing (check for regressions).
---
@@ -112,19 +112,29 @@ so_emit(struct nouveau_channel *chan, struct
nouveau_stateobj *so)
{
struct nouveau_pushbuf *pb =
Maybe someone wants to have a look at this ... should work.
Thanks, Christoph
From 7ecd5a88d637a2199103dc321dc649b68e84cbbd Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Thu, 10 Dec 2009 20:50:02 +0100
Subject: [PATCH 1/8] nv50: support vertex program
the
same in the DDX failed. This can provide a good speed boost in some
cases, too.
I'll wait a while for potential comments before pushing this.
From 3a4317961fda080aa23a35e0f22146dd14f738f0 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Sat, 10 Oct 2009 13:13:16
someone wants to comment on the implementation here, though.
From 53c844d32f94f62e8c947a744f383eb7b4fb21e7 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Wed, 14 Oct 2009 21:23:29 +0200
Subject: [PATCH 3/7] nv50: submit user vbo data through the fifo
Half of them I sent previously, now with updated reg names and
corrections, the other half is new. Read them for a description,
I'm too tired now for detailed explanations ...
Christoph
From 4a2fe7e7e3dd3f7dcb1451f6ee74038897c6df7a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425
These patches should fix viewport and scissoring
being y-inverted.
The effect should be visible in the gearbox demo.
Christoph
From 2bd1767340698ff6efb38c1869febdde52c4369d Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Sun, 12 Jul 2009 15:39:41 +0200
),
but that's not yet defined in the pipe formats header,
and I actually don't know if it's even possbible to define
that cleanly the way pipe_format is laid out.
Christoph
From 855ce10f59b1d4623f509f2aa502dd4300cd54e3 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Date: Sat, 4
Ah, obviously I DID introduce a few regressions in those patches,
this should fix what I discovered so far; will be merged into
the respective patches later.
Christoph
From c7feb3ab5aaf6a323e842987d6ea5f7637fac79d Mon Sep 17 00:00:00 2001
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Hi ! Here are some more changes to the shader code to be applied in
addition to the previous ones.
Well, I've though about getting an account so I could commit some (or
all) of this stuff, probably in splitting some patches up a bit more.
But I'd feel much better doing so (if I was even allowed
Hello Kamil,
Nope, nothing's got commited so far, and I'm thinking about creating an
account so I can do so, but I'd really feel better if someone reviewed
my stuff first.
Thanks for your interest, I'd be happy if you tested my patches and told
me if you get any improvements or regressions with
This one maps textures to sampler units (or textures to texture units
or whatever it's called), which wasn't done before. It should make the
mesa demo multiarb work, at least with the shader patches I sent
earlier. Of course, with this functionality one probably wouldn't have
to setup the textures
When trying out the Gallium3D NV50 driver (curiosity) with a small OpenGL
program that renders 2 rotating triangles partially occluding each other
I noticed that depth buffer clearing by rendering a quad
(st_cb_clear.c/clear_with_quad) didn't work properly.
I found this was because the rasterizer
45 matches
Mail list logo
