[Mesa-dev] nv3x libreoffice impress opengl animations not working

[Ilia Mirkin]

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