Ilia Mirkin
2015-Sep-03 17:32 UTC
[Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote:> On nv3x we will likely end up using the cpu to do color resolving for msaa > blits. Disable msaa on these cards so that we do not end up using the cpu.Actually the CPU fallback won't do scaled, so it's stuck with SIFM or assert(false). Which isn't great, but... it's what the HW does. I don't see a reason to shut that off. I'd rather disallow allocating MS surfaces that SIFM won't later be able to resolve on nv3x.> Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > src/gallium/drivers/nouveau/nv30/nv30_screen.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c > index 7aad26b..69acc38 100644 > --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c > @@ -319,8 +319,16 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen, > unsigned sample_count, > unsigned bindings) > { > - if (sample_count > 4) > - return false; > + struct nv30_screen *screen = nv30_screen(pscreen); > + > + if (screen->eng3d->oclass >= NV40_3D_CLASS) { > + if (sample_count > 4) > + return false; > + } else { > + if (sample_count > 0) > + return false; > + } > + > if (!(0x00000017 & (1 << sample_count))) > return false; > > -- > 2.4.3 > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau
Hans de Goede
2015-Sep-04 13:10 UTC
[Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x
Hi, On 03-09-15 19:32, Ilia Mirkin wrote:> On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: >> On nv3x we will likely end up using the cpu to do color resolving for msaa >> blits. Disable msaa on these cards so that we do not end up using the cpu. > > Actually the CPU fallback won't do scaled, so it's stuck with SIFM or > assert(false). Which isn't great, but... it's what the HW does.Ok.> I don't see a reason to shut that off. I'd rather disallow allocating MS > surfaces that SIFM won't later be able to resolve on nv3x.Hmm, my first hunch when reading this was: "that is not going to work, apps pick a visual and then alloc surfaces for that visual and only that visual, they will not fall back to another visual if the alloc fails." Still I've given this a try, resulting in this: diff --git a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c index 76bb8b8..172ffc1 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c @@ -325,6 +325,7 @@ nv30_miptree_create(struct pipe_screen *pscreen, const struct pipe_resource *tmpl) { struct nouveau_device *dev = nouveau_screen(pscreen)->device; + struct nv30_screen *screen = nv30_screen(pscreen); struct nv30_miptree *mt = CALLOC_STRUCT(nv30_miptree); struct pipe_resource *pt = &mt->base.base; unsigned blocksz, size; @@ -356,6 +357,15 @@ nv30_miptree_create(struct pipe_screen *pscreen, w = pt->width0 << mt->ms_x; h = pt->height0 << mt->ms_y; + + /* On nv3x ms requires sifm, make sure we meet the sifm constraints */ + if (screen->eng3d->oclass < NV40_3D_CLASS && tmpl->nr_samples > 0 && + ((w | h) > 1024 || w < 2 || h < 2)) { + debug_printf("refusing to create ms buffer with a size of %dx%d\n", w, h); + FREE(mt); + return NULL; + } + d = (pt->target == PIPE_TEXTURE_3D) ? pt->depth0 : 1; blocksz = util_format_get_blocksize(pt->format); But as I guessed already this does not make impress happy, it still tries to use a ms visuals, and then hobbles along showing an uninitialized frontbuffer, as it was doing before the patch to implement color resolve. I've checked and the debug printf I added works, so either I'm doing this at the wrong place, or this is just not a good idea. BTW there are more arguments to disable msaa on nv3x: 1) nv3x is slow enough without it 2) nv3x cards typically only have 64M of memory and msaa takes a significant amount of extra memory. Regards, Hans> >> Signed-off-by: Hans de Goede <hdegoede at redhat.com> >> --- >> src/gallium/drivers/nouveau/nv30/nv30_screen.c | 12 ++++++++++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) >> >> diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> index 7aad26b..69acc38 100644 >> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c >> @@ -319,8 +319,16 @@ nv30_screen_is_format_supported(struct pipe_screen *pscreen, >> unsigned sample_count, >> unsigned bindings) >> { >> - if (sample_count > 4) >> - return false; >> + struct nv30_screen *screen = nv30_screen(pscreen); >> + >> + if (screen->eng3d->oclass >= NV40_3D_CLASS) { >> + if (sample_count > 4) >> + return false; >> + } else { >> + if (sample_count > 0) >> + return false; >> + } >> + >> if (!(0x00000017 & (1 << sample_count))) >> return false; >> >> -- >> 2.4.3 >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau
Ilia Mirkin
2015-Sep-04 17:09 UTC
[Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x
On Fri, Sep 4, 2015 at 9:10 AM, Hans de Goede <hdegoede at redhat.com> wrote:> Hi, > > On 03-09-15 19:32, Ilia Mirkin wrote: >> >> On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: >>> >>> On nv3x we will likely end up using the cpu to do color resolving for >>> msaa >>> blits. Disable msaa on these cards so that we do not end up using the >>> cpu. >> >> >> Actually the CPU fallback won't do scaled, so it's stuck with SIFM or >> assert(false). Which isn't great, but... it's what the HW does. > > > Ok. > >> I don't see a reason to shut that off. I'd rather disallow allocating MS >> surfaces that SIFM won't later be able to resolve on nv3x. > > > Hmm, my first hunch when reading this was: "that is not going to work, > apps pick a visual and then alloc surfaces for that visual and only > that visual, they will not fall back to another visual if the alloc > fails." > > Still I've given this a try, resulting in this: > > diff --git a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c > b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c > index 76bb8b8..172ffc1 100644 > --- a/src/gallium/drivers/nouveau/nv30/nv30_miptree.c > +++ b/src/gallium/drivers/nouveau/nv30/nv30_miptree.c > @@ -325,6 +325,7 @@ nv30_miptree_create(struct pipe_screen *pscreen, > const struct pipe_resource *tmpl) > { > struct nouveau_device *dev = nouveau_screen(pscreen)->device; > + struct nv30_screen *screen = nv30_screen(pscreen); > struct nv30_miptree *mt = CALLOC_STRUCT(nv30_miptree); > struct pipe_resource *pt = &mt->base.base; > unsigned blocksz, size; > @@ -356,6 +357,15 @@ nv30_miptree_create(struct pipe_screen *pscreen, > > w = pt->width0 << mt->ms_x; > h = pt->height0 << mt->ms_y; > + > + /* On nv3x ms requires sifm, make sure we meet the sifm constraints */ > + if (screen->eng3d->oclass < NV40_3D_CLASS && tmpl->nr_samples > 0 && > + ((w | h) > 1024 || w < 2 || h < 2)) { > + debug_printf("refusing to create ms buffer with a size of %dx%d\n", > w, h); > + FREE(mt); > + return NULL; > + } > + > d = (pt->target == PIPE_TEXTURE_3D) ? pt->depth0 : 1; > blocksz = util_format_get_blocksize(pt->format); > > > But as I guessed already this does not make impress happy, it still tries > to use a ms visuals, and then hobbles along showing an uninitialized > frontbuffer, as it was doing before the patch to implement color > resolve. > > I've checked and the debug printf I added works, so either I'm doing this > at the wrong place, or this is just not a good idea. > > BTW there are more arguments to disable msaa on nv3x: > > 1) nv3x is slow enough without it > 2) nv3x cards typically only have 64M of memory and msaa > takes a significant amount of extra memory.Well, I don't think anyone's expecting it to do 4K resolution at 32x msaa... The fact that it'll die even with 640x480 is a bit unfortunate though. MSAA doesn't take a "significant" amount of extra memory, just 2x or 4x for the RB. Textures/everything else are unaffected. Really we should be using sifm for the whole thing irrespective of the size and just tiling. That'll introduce seams if we're not careful about it, but it should be fine for a resolve, since it's very direct pixel mappings (i.e. 2:1 or 4:1, no 2.5:1 type of thing). Unless it uses surrounding samples, then there might be very minor seams... not sure. Should be easy to rig up sifm to ignore the w/h restrictions for MS textures, and just do it in 1024x1024 blocks. What do you think? You should also double-check whether the 1024 restriction is real, and what it's actually restricting? [Note that MS miptrees are allocated linear, not swizzled. Not sure why... probably not a bad thing since sifm only deals with linear sources.] -ilia