similar to: [PATCH] drm/gk208/gr: add missing registers to grctx init

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- MMIO32 R 0x17e91c 0x0b040a0b PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb040a0b MMIO32 R 0x17e920 0x00090c03 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90c03 MMIO32 W 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C <= 0xb030a0c MMIO32 W 0x17e920 0x00090d08 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 <= 0x90d08 And then

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 file changed, 1 insertion(+), 1 deletion(-) diff --git

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 file changed, 1 insertion(+), 1 deletion(-) diff --git

https://bugs.freedesktop.org/show_bug.cgi?id=91722 Bug ID: 91722 Summary: [NVE4] PGRAPH - grctx template channel unload timeout, failed to construct context, init failed, -16 Product: Mesa Version: 10.6 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major

https://bugs.freedesktop.org/show_bug.cgi?id=69952 Priority: medium Bug ID: 69952 Assignee: nouveau at lists.freedesktop.org Summary: [NVAA] Xorg crash+restart after glxgears on 3.12-rc2 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter:

On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > So... I was wondering what the impact of splitting up the card compilation by > e.g. generation would be. Depending on the split things would get fairly > intertwined, so I thought I'd start small. This just splits NVC0 from > everything else. I figure that for the people this matters the most to,

Op 14-09-14 om 10:31 schreef poma: > On 13.09.2014 23:45, Roy Spliet wrote: >> Dear Poma, >> >> Don't get anyone wrong, your input is greatly valued. The reason why >> "we" (nouveau developers) generally ask for a git bisection is because >> we don't know or track specific distributions. Although your search has >> narrowed the problem down

On 14.09.2014 11:53, Roy Spliet wrote: > Op 14-09-14 om 10:31 schreef poma: >> On 13.09.2014 23:45, Roy Spliet wrote: >>> Dear Poma, >>> >>> Don't get anyone wrong, your input is greatly valued. The reason why >>> "we" (nouveau developers) generally ask for a git bisection is because >>> we don't know or track specific

This will allow the nouveau module to only include support for nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination). Only compiling one of the card types at a time reduces the size of the nouveau module, from 1.3M to 700-800K, depending on the type (including symbols/etc). It should also yield a reduction in compile time as a lot fewer files are compiled. Here are the sizes

On 13.09.2014 23:45, Roy Spliet wrote: > Dear Poma, > > Don't get anyone wrong, your input is greatly valued. The reason why > "we" (nouveau developers) generally ask for a git bisection is because > we don't know or track specific distributions. Although your search has > narrowed the problem down (thanks for that!), we don't know how big the >

So... I was wondering what the impact of splitting up the card compilation by e.g. generation would be. Depending on the split things would get fairly intertwined, so I thought I'd start small. This just splits NVC0 from everything else. I figure that for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options