Re: [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri wrote: > Currently the nv30 and nv40 Gallium drivers are very similar, and > contain about 5000 lines of essentially duplicate code. > > I prepared a patchset (which can be found at > http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) > which gradually unifies the drivers, one file per the commit. > > A new "nvfx" directory is created, and unified files are put there one by one. > After all patches are applied, the nv30 and nv40 directories are > removed and the only the new nvfx directory remains. > > The first patches unify the engine naming (s/curie/eng3d/g; > s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. > Initial versions of this work changed renouveau.xml to create a new > "NVFXTCL" object, but the current version doesn't need any > renouveau.xml modification at all. > > The "unification+fixes" branch referenced above is the one that should > be tested. > The "unification" branch contains just the unification, with no > behavior changes, while "unification+fixes" also fixes swtnl and quad > rendering, allowing to better test the unification. Some cleanups on > top of the unfication are also included. > > That same repository also contains other branches with significant > improvements on top of the unification, but I'm still not proposing > them for inclusion as they need more testing and some fixes. > > While there are some branches in the Mesa repository that would > conflict with this, such branches seem to be popping up continuously > (and this is good!), so waiting until they are merged probably won't > really work. > > The conflicts are minimal anyway and the driver fixes can be very > easily reconstructed over the unified codebase. > > How about merging this? > Any objections? Any comments? Pushed. Thanks. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 23445] NV46: GPU lockup with gdm prompt AND logged in fbcon
http://bugs.freedesktop.org/show_bug.cgi?id=23445 --- Comment #19 from Alexander Trubitsyn 2010-03-14 16:28:01 PST --- Created an attachment (id=34047) --> (http://bugs.freedesktop.org/attachment.cgi?id=34047) xorg.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 23445] NV46: GPU lockup with gdm prompt AND logged in fbcon
http://bugs.freedesktop.org/show_bug.cgi?id=23445 --- Comment #18 from Alexander Trubitsyn 2010-03-14 16:27:35 PST --- Created an attachment (id=34046) --> (http://bugs.freedesktop.org/attachment.cgi?id=34046) lspci -vv log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 23445] NV46: GPU lockup with gdm prompt AND logged in fbcon
http://bugs.freedesktop.org/show_bug.cgi?id=23445 --- Comment #17 from Alexander Trubitsyn 2010-03-14 16:27:05 PST --- Created an attachment (id=34045) --> (http://bugs.freedesktop.org/attachment.cgi?id=34045) lsmod log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 23445] NV46: GPU lockup with gdm prompt AND logged in fbcon
http://bugs.freedesktop.org/show_bug.cgi?id=23445 --- Comment #16 from Alexander Trubitsyn 2010-03-14 16:26:15 PST --- Created an attachment (id=34044) --> (http://bugs.freedesktop.org/attachment.cgi?id=34044) dmesg log 1. Install Open Suse 11.2 64-bit, 2. download & install latest kernel 2.6.33-31-desktop. On every boot in dmesg see GPU lockup message -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ 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 wrote: > On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell > 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
Re: [Nouveau] [Mesa3d-dev] [PATCH] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 5:35 PM, Keith Whitwell 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... Keith ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27076] New: [C51/6100 GO] Image corruption / broken Xv
http://bugs.freedesktop.org/show_bug.cgi?id=27076 Summary: [C51/6100 GO] Image corruption / broken Xv Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau@lists.freedesktop.org ReportedBy: chalserog...@gmail.com QAContact: xorg-t...@lists.x.org Forwarding from Launchpad bug https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/532756 This is with DDX git up to commit 9b4118d, libdrm 2.6.18 with the 0.0.16 API bump reverted, and 2.6.33 drm + nouveau. The user reports image corruption on the bottom of the desktop wallpaper, but only with a background image or gradient - not a flat colour. Image here: http://www.flickr.com/photos/danielecruciani/4417023969/ The user also reports that Xv produces nothing but scrambled colours. Screenshot here: http://launchpadlibrarian.net/40483459/Schermata-Awakenedvoice-DrupalCCKAndViewsTutorial767.mov.png Dmesg: http://launchpadlibrarian.net/40871533/BootDmesg.txt Xorg.0.log: http://launchpadlibrarian.net/40871601/XorgLog.txt lspci output: http://launchpadlibrarian.net/40871582/Lspci.txt -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27049] fails to start - drm open issue?
http://bugs.freedesktop.org/show_bug.cgi?id=27049 --- Comment #5 from Michal Suchanek 2010-03-14 09:14:47 PST --- With 2.6.34-rc1 the X server starts. The kernel also says in the log that it has version 0.0.16 of the nouveau drm module. Is it possible that when the kernel drm version does not match the driver version it just quietly exits instead of reporting a meaningful error? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] RFC: gallium/nv50: get rid of the screen_init stateobj
BEGIN_RING also does autobind, the rest seems ok. Maarten. On Sun, Mar 14, 2010 at 2:53 PM, Christoph Bumiller wrote: > 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 need to store all the usless state from init, and the >>> constant buffer relocations which currently don't work if the >>> addresses change (because the method CB_DEF_SET isn't >>> among them (not an address)) become effective. >>> >>> Thoughts, ack / nack ? >>> Thanks, >>> Christoph >>> >>> >>> ___ >>> Nouveau mailing list >>> Nouveau@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/nouveau >>> >>> >>> >> Perhaps add a BEGIN_RING_RELOC to libdrm? To make it more obvious. >> >> Maarten. >> > Like the following (attached) ?: > ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] RFC: gallium/nv50: get rid of the screen_init stateobj
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 need to store all the usless state from init, and the
>> constant buffer relocations which currently don't work if the
>> addresses change (because the method CB_DEF_SET isn't
>> among them (not an address)) become effective.
>>
>> Thoughts, ack / nack ?
>> Thanks,
>> Christoph
>>
>>
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>
>>
>>
> Perhaps add a BEGIN_RING_RELOC to libdrm? To make it more obvious.
>
> Maarten.
>
Like the following (attached) ?:
>From 6c5fc819f456b217cb677667e90c1de96ed2ebbb Mon Sep 17 00:00:00 2001
From: root
Date: Sun, 14 Mar 2010 14:36:23 +0100
Subject: [PATCH] nv50: add BGN_RELOC
---
nouveau/nouveau_pushbuf.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/nouveau/nouveau_pushbuf.h b/nouveau/nouveau_pushbuf.h
index 52d13a0..818b713 100644
--- a/nouveau/nouveau_pushbuf.h
+++ b/nouveau/nouveau_pushbuf.h
@@ -197,4 +197,13 @@ OUT_RELOCh(struct nouveau_channel *chan, struct nouveau_bo
*bo,
return OUT_RELOC(chan, bo, delta, flags | NOUVEAU_BO_HIGH, 0, 0);
}
+static __inline__ int
+BGN_RELOC(struct nouveau_channel *chan, struct nouveau_bo *bo,
+ struct nouveau_grobj *gr, unsigned mthd, unsigned size,
+ unsigned flags)
+{
+ OUT_RELOC(chan, bo, (size << 18) | (gr->subc << 13) | mthd,
+ flags, 0, 0);
+}
+
#endif
--
1.6.4.4
>From bcc4ed3ea1af1bebb2713035432f3477ac89f7ad Mon Sep 17 00:00:00 2001
From: Christoph Bumiller
Date: Sun, 14 Mar 2010 14:51:03 +0100
Subject: [PATCH] nv50: use BGN_RELOC
---
src/gallium/drivers/nv50/nv50_screen.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_screen.c
b/src/gallium/drivers/nv50/nv50_screen.c
index 2b0c9fd..effe20b 100644
--- a/src/gallium/drivers/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nv50/nv50_screen.c
@@ -212,37 +212,37 @@ nv50_screen_relocs(struct nv50_screen *screen)
unsigned i;
const unsigned rl = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD | NOUVEAU_BO_DUMMY;
+ MARK_RING (chan, 28, 26);
+
/* cause grobj autobind */
BEGIN_RING(chan, tesla, 0x0100, 1);
OUT_RING (chan, 0);
- OUT_RELOC (chan, screen->tic, (tesla->subc << 13) |
- NV50TCL_TIC_ADDRESS_HIGH | (2 << 18), rl, 0, 0);
+ BGN_RELOC (chan, screen->tic, tesla, NV50TCL_TIC_ADDRESS_HIGH, 2, rl);
OUT_RELOCh(chan, screen->tic, 0, rl);
OUT_RELOCl(chan, screen->tic, 0, rl);
- OUT_RELOC (chan, screen->tsc, (tesla->subc << 13) |
- NV50TCL_TSC_ADDRESS_HIGH | (2 << 18), rl, 0, 0);
+ BGN_RELOC (chan, screen->tsc, tesla, NV50TCL_TSC_ADDRESS_HIGH, 2, rl);
OUT_RELOCh(chan, screen->tsc, 0, rl);
OUT_RELOCl(chan, screen->tsc, 0, rl);
- OUT_RELOC (chan, screen->constbuf_misc[0], (tesla->subc << 13) |
- NV50TCL_CB_DEF_ADDRESS_HIGH | (3 << 18), rl, 0, 0);
+ BGN_RELOC (chan, screen->constbuf_misc[0],
+ tesla, NV50TCL_CB_DEF_ADDRESS_HIGH, 3, rl);
OUT_RELOCh(chan, screen->constbuf_misc[0], 0, rl);
OUT_RELOCl(chan, screen->constbuf_misc[0], 0, rl);
OUT_RELOC (chan, screen->constbuf_misc[0],
(NV50_CB_PMISC << 16) | 0x0200, rl, 0, 0);
- OUT_RELOC (chan, screen->constbuf_misc[0], (tesla->subc << 13) |
- NV50TCL_CB_DEF_ADDRESS_HIGH | (3 << 18), rl, 0, 0);
+ BGN_RELOC (chan, screen->constbuf_misc[0],
+ tesla, NV50TCL_CB_DEF_ADDRESS_HIGH, 3, rl);
OUT_RELOCh(chan, screen->constbuf_misc[0], 0x200, rl);
OUT_RELOCl(chan, screen->constbuf_misc[0], 0x200, rl);
OUT_RELOC (chan, screen->constbuf_misc[0],
(NV50_CB_AUX << 16) | 0x0200, rl, 0, 0);
for (i = 0; i < 3; ++i) {
- OUT_RELOC (chan, screen->constbuf_parm[i], (tesla->subc << 13) |
- NV50TCL_CB_DEF_ADDRESS_HIGH | (3 << 18), rl, 0, 0);
+ BGN_RELOC (chan, screen->constbuf_parm[i],
+ tesla, NV50TCL_CB_DEF_ADDRESS_HIGH, 3, rl);
OUT_RELOCh(chan, screen->constbuf_parm[i], 0, rl);
OUT_RELOCl(chan, screen->constbuf_parm[i], 0, rl);
OUT_RELOC (chan, screen->constbuf_parm[i],
--
1.6.4.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] RFC: gallium/nv50: get rid of the screen_init stateobj
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 need to store all the usless state from init, and the > constant buffer relocations which currently don't work if the > addresses change (because the method CB_DEF_SET isn't > among them (not an address)) become effective. > > Thoughts, ack / nack ? > Thanks, > Christoph > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > > Perhaps add a BEGIN_RING_RELOC to libdrm? To make it more obvious. Maarten. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] RFC: gallium/nv50: get rid of the screen_init stateobj
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 from init, and the
constant buffer relocations which currently don't work if the
addresses change (because the method CB_DEF_SET isn'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 stateobj
Relocations of per-screen buffers are now emitted directly,
and include the necessary method to get changes in constbuf
addresses committed to the hw.
It should also be a bit cheaper than the way stateobjs emit
relocation markers, use a little less pushbuf space.
---
src/gallium/drivers/nv50/nv50_screen.c | 275
src/gallium/drivers/nv50/nv50_screen.h |2 +
src/gallium/drivers/nv50/nv50_state_validate.c |2 +-
3 files changed, 141 insertions(+), 138 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_screen.c
b/src/gallium/drivers/nv50/nv50_screen.c
index adf0d3b..2b0c9fd 100644
--- a/src/gallium/drivers/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nv50/nv50_screen.c
@@ -204,16 +204,62 @@ nv50_screen_destroy(struct pipe_screen *pscreen)
FREE(screen);
}
+void
+nv50_screen_relocs(struct nv50_screen *screen)
+{
+ struct nouveau_channel *chan = screen->base.channel;
+ struct nouveau_grobj *tesla = screen->tesla;
+ unsigned i;
+ const unsigned rl = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD | NOUVEAU_BO_DUMMY;
+
+ /* cause grobj autobind */
+ BEGIN_RING(chan, tesla, 0x0100, 1);
+ OUT_RING (chan, 0);
+
+ OUT_RELOC (chan, screen->tic, (tesla->subc << 13) |
+ NV50TCL_TIC_ADDRESS_HIGH | (2 << 18), rl, 0, 0);
+ OUT_RELOCh(chan, screen->tic, 0, rl);
+ OUT_RELOCl(chan, screen->tic, 0, rl);
+
+ OUT_RELOC (chan, screen->tsc, (tesla->subc << 13) |
+ NV50TCL_TSC_ADDRESS_HIGH | (2 << 18), rl, 0, 0);
+ OUT_RELOCh(chan, screen->tsc, 0, rl);
+ OUT_RELOCl(chan, screen->tsc, 0, rl);
+
+ OUT_RELOC (chan, screen->constbuf_misc[0], (tesla->subc << 13) |
+ NV50TCL_CB_DEF_ADDRESS_HIGH | (3 << 18), rl, 0, 0);
+ OUT_RELOCh(chan, screen->constbuf_misc[0], 0, rl);
+ OUT_RELOCl(chan, screen->constbuf_misc[0], 0, rl);
+ OUT_RELOC (chan, screen->constbuf_misc[0],
+ (NV50_CB_PMISC << 16) | 0x0200, rl, 0, 0);
+
+ OUT_RELOC (chan, screen->constbuf_misc[0], (tesla->subc << 13) |
+ NV50TCL_CB_DEF_ADDRESS_HIGH | (3 << 18), rl, 0, 0);
+ OUT_RELOCh(chan, screen->constbuf_misc[0], 0x200, rl);
+ OUT_RELOCl(chan, screen->constbuf_misc[0], 0x200, rl);
+ OUT_RELOC (chan, screen->constbuf_misc[0],
+ (NV50_CB_AUX << 16) | 0x0200, rl, 0, 0);
+
+ for (i = 0; i < 3; ++i) {
+ OUT_RELOC (chan, screen->constbuf_parm[i], (tesla->subc << 13) |
+ NV50TCL_CB_DEF_ADDRESS_HIGH | (3 << 18), rl, 0, 0);
+ OUT_RELOCh(chan, screen->constbuf_parm[i], 0, rl);
+ OUT_RELOCl(chan, screen->constbuf_parm[i], 0, rl);
+ OUT_RELOC (chan, screen->constbuf_parm[i],
+ ((NV50_CB_PVP + i) << 16) | 0x0800, rl, 0, 0);
+ }
+}
+
struct pipe_screen *
nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev)
{
struct nv50_screen *screen = CALLOC_STRUCT(nv50_screen);
struct nouveau_channel *chan;
struct pipe_screen *pscreen;
- struct nouveau_stateobj *so;
unsigned chipset = dev->chipset;
unsigned tesla_class = 0;
int ret, i;
+ const unsigned rl = NOUVEAU_BO_VRAM | NOUVEAU_BO_RD;
if (!screen)
return NULL;
@@ -296,64 +342,58 @@ nv50_screen_create(struct pipe_winsys *ws, struct
nouveau_device *dev)
}
/* Static M2MF init */
- so = so_new(1, 3, 0);
- so_method(so, screen->m2mf, NV04_MEMORY_TO_MEMORY_FORMAT_DMA_NOTIFY, 3);
- so_data (so, screen->sync->handle);
- so_data (so, chan->vram->handle);
- so_data (so, chan->vram->handle);
- so_emit(chan, so);
- so_ref (NULL, &so);
+ BEGIN_RING(chan, screen->m2mf,
+ NV04_MEMORY_TO_MEMORY_FORMAT_DMA_NOTIFY, 3);
+ OUT_RING (chan, screen->sync->handle);
+ OUT_RING (chan, chan->vram->handle);
+ OUT_RING (chan, chan->vram->handle);
/* Static 2D init */
- so = so_new(4, 7, 0);
- so_method(so, screen->eng2d, NV50_2D_DMA_NOTIFY, 4);
- so_data (so, screen->sync->handle);
- so_data (so, chan->vram->handle);
- so_data (so, chan->vram->handle);
- so_data (so, chan->vram->handle);
- so_method(so, screen->eng2d, NV50_2D_OPERATION, 1);
- so_data
Re: [Nouveau] nv50 mouse cursor disappears hourly
On Thu, Mar 11, 2010 at 9:30 PM, Brian DeRocher 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 > 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
