Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 03-09-15 19:36, Ilia Mirkin wrote:
> On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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 ?
>
> Those messages get printed by libdrm when the kernel rejects
> something. You should also see what the kernel is rejecting and why in
> dmesg... this should be instructional.

Here is what dmesg says:

[ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
[ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.989441] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.989447] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.989454] nouveau E[soffice.bin[3785]] validate: -12
[ 1202.231688] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1202.231694] nouveau E[soffice.bin[3785]] validating bo list
[ 1202.231701] nouveau E[soffice.bin[3785]] validate: -12


> Could easily be that some
> mt->ms_x/y shifts are missing.

I think that the above dmesg rules that out and that instead
I should be looking into buffer management, right ? Any clues
on how to debug this, are there some kernel parameters to
log the alloc / free of bo-s and to make ttm_validate print
a reason why things are failing ?

I'm currently using dri2, shall I retry with dri3 ?

Regards,

Hans


p.s.

I've a feeling that I can only reproduce after ending an
Xorg session and starting Xorg a second time. At least in my
first session I could not reproduce with a gazillion tries
and in my second session it reproduced pretty quickly ...

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev