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

[Hans de Goede]

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