Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Hi,

On 02-09-15 16:44, Ilia Mirkin wrote:
> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi Ilia

<snip>

>>> Of course I don't really see how MS can work at all with nv30 since it
>>> doesn't support a resolve step:
>>>
>>>      if (info.src.resource->nr_samples > 1 &&
>>>          info.dst.resource->nr_samples <= 1 &&
>>>          !util_format_is_depth_or_stencil(info.src.resource->format) &&
>>>          !util_format_is_pure_integer(info.src.resource->format)) {
>>>         debug_printf("nv30: color resolve unimplemented\n");
>>>         return;
>>>      }
>>>
>>> Perhaps there's (supposed to be) some magic with the MSAA visual? Do
>>> you see that print happening?
>>
>>
>> Yes I see that print happening and that explains the misrendering I'm
>> seeing pretty well, it is not misrendering at all, it is just random
>> data from the video mem.
>>
>> I've had a quick talk about this with Ben, he suggested using
>> the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
>> is doing.
>>
>> I've done some digging through the code and this translates to the
>> "sfim" object in the gallium nv30 code. I was wondering if I cannot
>> just simple call nv30_transfer_rect with the right parameters and
>> let it sort the blit out ?
>
> That seems fine to me. BTW, it's sifm == scaled image from memory, not
> sfim. You'll either have to fudge the width/height, or teach the
> transfer methods to look at mt->ms_x/y (and make sure to treat it as a
> scaled xfer if the nr_samples don't line up).

Ok, I've gotten this to work, yeah :) I'll send out patches for this
shortly.

But even with this fixed, there still are problems with msaa:

1) On nv3x (vs nv4x) we end up using the cpu for the blit, this is
no good so I've added a patch to my patch-set to disable msaa
visuals on nv3x

2) On nv4x things mostly work, but sometimes / after a while
the gpu locks up. Attaching gdb to impress shows it is hanging waiting
for a fence which never comes.

Killing ooimpress at this point works exactly once, trying to do any
3d operations after killing impress will lockup the entire system.

When I kill impress at this point it prints a lot of messages
like these to stdout:

nouveau:        0x45070000
nouveau:        0x00000000
nouveau:        0x0004f900
nouveau:        0x04380780
nouveau:        0x000cf580
nouveau:        0x00000000
nouveau:        0x45070000
nouveau:        0x00000000
nouveau:        0x0004f900
nouveau:        0x04380000
nouveau:        0x0004f808
nouveau:        0x00000000
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x000000a9
nouveau:        0x00020000
nouveau:        0x00000000

I've not yet seen the beginning of this list since my scroll-back
buffer is not large enough, I guess I need to reproduce this and
redirect the output to a file to get all messages.

So any hints on how to debug this ?  Could this have something
to do with the destination buffer for the msaa rendering
(so the buffer which has the image rendered at twice the
desired resolution) not having enough padding on its pitch ?

Thanks & Regards,

Hans
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau