[Mesa-dev] [Nouveau] [PATCH mesa 3/4] nv30: Do not export msaa capabable visuals on nv3x

[Ilia Mirkin]

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