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

[Hans de Goede]

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 ?

Regards,

Hans