Nouveau - Sep 2015 - nv3x libreoffice impress opengl animations not working

On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede at redhat.com>
wrote:
> Hi Ilia
>
> On 31-08-15 18:30, Ilia Mirkin wrote:
>>
>> On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at
redhat.com>
>> wrote:
>
>
> <snip>
>
>
>>> Interestingly enough nv30_screen_get_param returns 0 for
>>> PIPE_CAP_TEXTURE_MULTISAMPLE and for PIPE_CAP_SAMPLER_VIEW_TARGET
>>>
>>> And this hack:
>>>
>>> --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>>> +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
>>> @@ -319,7 +319,7 @@ nv30_screen_is_format_supported(struct
pipe_screen
>>> *pscreen,
>>>                                   unsigned sample_count,
>>>                                   unsigned bindings)
>>>   {
>>> -   if (sample_count > 4)
>>> +   if (sample_count > 0)
>>>         return false;
>>>      if (!(0x00000017 & (1 << sample_count)))
>>>         return false;
>>>
>>> Fixes the slide animation misrendering (and sometimes crashing)
>>> in libreoffice impress.
>>>
>>> As said I think this is a hack, I currently do not understand
things
>>> good enough to come up with a better fix.
>>>
>>> Hints how to further investigate this are appreciated.
>>
>>
>> Not surprising that ms gets somehow messed up.
>> PIPE_CAP_TEXTURE_MULTISAMPLE == ARB_texture_multisample, aka allowing
>> the existence of MS textures (as opposed to just renderbuffers) as
>> well as sampling from those textures. nv30 does not support the
>> latter. The "other" way to do MS is to create a MS visual.
You can run
>> glretrace --samples=4 to get the same effect.
>>
>> 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).

  -ilia

Hi,

On 02-09-15 16:44, Ilia Mirkin wrote:
> On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdegoede at
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

On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdegoede at 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 at
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. Could easily be that some
mt->ms_x/y shifts are missing. Might want to make some traces of the
blob drivers running some of the more basic piglit tests with MS and
seeing what they do. [I assume you're familiar with valgrind-mmt +
demmt. If not, http://nouveau.freedesktop.org/wiki/Valgrind-mmt/ ]

  -ilia