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 fil
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 fil
---
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 change
---
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/n
---
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
--- a/drivers/gpu/
---
.../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
--- a/drivers
---
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
+++ b/drivers/gpu/
---
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
+++ b/drivers/gpu/drm/nou
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
> suggestion
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_ac
On 30.04.2012 19:16, Lucas Stach wrote:
> Fixes an assertion seen by users.
>
> Signed-off-by: Lucas Stach
> Tested-by: JohnDoe_71Rus on irc
> ---
> src/mesa/drivers/dri/nouveau/nouveau_context.c |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/nouveau/nou
On 04/23/2012 06:32 PM, Marcin Slusarz wrote:
> You can run fs-discard-exit-2 test first - for me it causes instant GPU
> lockup.
>
That's because it's designed (but not supposed) to do that, it also
locks up with the blob, it's a harmless shader infinite loop.
(May be a bug in the MPs or a wro
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
>>
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 | 14 +
drivers/gpu/drm/nouveau/nouveau_drv.h |3 ++
drivers/gpu/drm/nouveau/nv50_crtc.c | 42
---
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 ++
---
src/nouveau_dri2.c|4 +++-
src/nv_accel_common.c |4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index d14443f..b99893f 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -46,6 +46,8 @@ nouveau_dri2_create_buf
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 a/drivers/gpu/drm/nouveau/
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 a/drivers/gpu/drm/nouveau/
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 tra
On 05/31/2010 11:58 AM, Ben Skeggs wrote:
> On Mon, 2010-05-31 at 10:30 +0200, Christoph Bumiller wrote:
>> On 31.05.2010 03:49, Ben Skeggs wrote:
>>> On Mon, 2010-05-31 at 11:44 +1000, Ben Skeggs wrote:
>>>
>>>> From: Ben Skeggs
>>>>
>
On 31.05.2010 03:49, Ben Skeggs wrote:
> On Mon, 2010-05-31 at 11:44 +1000, Ben Skeggs wrote:
>
>> From: Ben Skeggs
>>
> This is the result of some playing around, thought it'd be useful so
> sending to the list for some sanity checking first, particularly in the
> shader setup.
>
> I woul
On 14.03.2010 13:03, Maarten Maathuis wrote:
> On Sun, Mar 14, 2010 at 11:32 AM, Christoph Bumiller
> wrote:
>
>> Hi.
>> There's not much to say here, just replacing the screen_init
>> stateobj with direct pushbuffer emission.
>>
>> We don't
sn't
among them (not an address)) become effective.
Thoughts, ack / nack ?
Thanks,
Christoph
>From f37dea43c705683a89e31da78200872cc00ac967 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Sun, 14 Mar 2010 11:19:27 +0100
Subject: [PATCH] nv50: get rid of the screen_init 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 be
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 emitti
)
Thanks,
Christoph
>From c0a9e6d906c8c6fc2cfa281f8553c1109f46f81a Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Tue, 2 Mar 2010 18:43:11 +0100
Subject: [PATCH] nouveau: adjust texture and nv50 RT formats to names byteswap
Will keep a patch for middle endian format naming ready.
---
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.
> ---
> src/nv
On 21.01.2010 22:33, Marcin Slusarz wrote:
> On Fri, Jan 15, 2010 at 12:02:25AM +0100, Maarten Maathuis wrote:
>
>> Is everyone ok with this api addition (naming ok?)?
>>
> I guess they are...
>
> ... Or is there any issue with this patch I'm not aware of?
>
> Marcin
>
>
In principle I g
On 17.01.2010 23:50, Marcin Slusarz wrote:
> ---
> src/gallium/drivers/nv50/nv50_program.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/drivers/nv50/nv50_program.c
> b/src/gallium/drivers/nv50/nv50_program.c
> index 4111d21..cfe8b48 100644
> --- a/src/
do waiting anymore 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
Date: Tue,
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
>>> wrote:
>>>&g
=%d\n",
>>> ppix->drawable.depth);
>>> -return FALSE;
>>
>> Why did you remove this?
>
> because it's unreachable, NOUVEAU_FALLBACK returns FALSE
>
> _
On 12/28/2009 08:15 AM, Younes Manton wrote:
> On Mon, Dec 28, 2009 at 1:55 AM, Luca Barbieri wrote:
>>> Can you reproduce this with your vertex buffers in VRAM instead of GART?
>>> (to rule out that it's a fencing issue).
>>
>> Putting the vertex buffers in VRAM makes things almost perfect, but
>
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
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c |9 -
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/driver
On 12/20/2009 04:46 PM, Maarten Maathuis wrote:
> - This avoids problematic "reloc'ed while mapped" messages and
> some associated corruption as well.
> - Also add one nouveau_bo_unmap() in the vbo code that wasn't present.
I didn't think nouveau_bo_unmap was necessary if the map failed.
As far as
On 20.12.2009 14:01, Maarten Maathuis wrote:+static int
> +nv50_pre_pipebuffer_map(struct pipe_screen *pscreen, struct pipe_buffer *pb,
> + unsigned usage)
> +{
> + struct nv50_screen *screen = nv50_screen(pscreen);
> + struct nv50_context *ctx = screen->cur_ctx;
> +
> + if (!(pb->u
Maarten Maathuis schrieb:
> Signed-off-by: Maarten Maathuis
> ---
> 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
> b/src/gallium/drivers/nouveau/nouveau_stateob
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
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 wo
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 = ch
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
Date: Thu, 10 Dec 2009 20:50:02 +0100
Subject: [PATCH 1/8] nv50: support vertex program textures
---
src/gall
g to float).
Maybe someone wants to comment on the implementation here, though.
>From 53c844d32f94f62e8c947a744f383eb7b4fb21e7 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Wed, 14 Oct 2009 21:23:29 +0200
Subject: [PATCH 3/7] nv50: submit user vbo data through the fifo
Requesting
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
Date: Sat, 10 Oct 2009 13:13:16 +0200
Subject: [P
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
Date:
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
Date: Sun, 12 Jul 2009 15:39:41 +0200
Subject: [PATCH 1/3] nv50:
e000),
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
Date: Sa
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
Date: Wed, 24 Jun 2009 22:18
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 th
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 to
Hi !
I think src and dst starting positions got mixed up in nv50_transfer_rect_m2mf,
there's a diff at the bottom of this message.
This came up when trying to make the gearbox demo run correctly, but this change
alone doesn't fix it. The mesa state tracker in st_cb_clear.c assumes Y_0_TOP
when clea
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 texture
Hi ! I've been trying to improve NV50 shader generation a bit the last couple
of weeks, so here is
what I've produced. I don't know if it's usable for you or just a pile of
horrible hacks, but at
least it makes some mesa demos render more correcly, p.e. the teapot (aside
from mip-mapping issues
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
57 matches
Mail list logo
