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

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com>
wrote:
> Hi,
>
>
> On 28-08-15 11:02, Ilia Mirkin wrote:
>>
>> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede at
redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On 27-08-15 20:19, Ilia Mirkin wrote:
>>>>
>>>>
>>>> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeucher
at gmail.com>
>>>> wrote:
>>>
>>>
>>>
>>> <snip>
>>>
>>>>>>>> 2) Since the glretrace does work outside of
libreoffice impress, I
>>>>>>>> think
>>>>>>>> it may have something to do with the visual
chosen by libreoffice
>>>>>>>> impress,
>>>>>>>> is there an easy way to find out what visual lo
is choosing?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No, it's not because of the visual. It seems to
me that libreoffice
>>>>>>> changed the behavior of malloc and calloc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm pretty sure that this is not libreoffice
changing malloc / calloc,
>>>>>> it links normally to libc, and the same slide
transition works fine
>>>>>> with an nv84 card which also has a gallium based mesa
driver.
>>>>>>
>>>>>> I really believe this is due to libreoffice doing
something opengl
>>>>>> related differently then glretrace, be it the visual or
something else
>>>>>> back buffer related ...
>>>>>>
>>>>>
>>>>> Does libreoffice use llvm?  I have vague recollections of
there being
>>>>> issues with llvm and libreoffice in the past because
radeonsi uses
>>>>> llvm as well.
>>>>
>>>>
>>>>
>>>> FWIW the nv30 gallium driver will only use llvm as part of
'draw' when
>>>> falling back to the swtnl path. This should be extremely rare.
But
>>>> easy enough to build mesa with --disable-gallium-llvm to
double-check
>>>> (or what was the env var? DRAW_USE_LLVM=0 or something along
those
>>>> lines).
>>>
>>>
>>>
>>> I've tried building with --disable-gallium-llvm, this does not
help,
>>> this is not really surprising since on Fedora both libreoffice and
>>> mesa use the system llvm, so there should be no problems with them
>>> expecting different llvm versions.
>>>
>>> I've done some further debugging adding some debug printf-s to
the
>>> texture creation paths for nv3x, this bit is interesting, glretrace
>>> does:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags
0
>>> nv30_miptree_create 1350x863 uniform_pitch 5440 usage 0 flags 0
bind 1
>>> target 2
>>>
>>> So it gets a texture from a handle, which I believe is the
child-window
>>> in which the animation will be shown, and then create another
texture
>>> with the same dimensions to serve as back buffer I presume.
>>>
>>> ooimpress however does this:
>>>
>>> nv30_miptree_from_handle 1350x863 uniform_pitch 6144 usage 0 flags
0
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0
bind a
>>> target 2
>>> nv30_miptree_create 2700x1726 uniform_pitch 10816 usage 0 flags 0
bind 1
>>> target 2
>>>
>>> Notice how it is creating 2 (back?) buffers and they are twice the
size
>>> of
>>> the "sheet" area of impress to which the animation gets
rendered.
>>
>>
>> bind a = rt/sampler view, bind 1 = depth/stencil. However nv3x
doesn't
>> do NPOT textures... so those sizes are a bit odd. Perhaps there's
some
>> logic that attempts to round-up-to-nearest-POT size, but instead
>> multiplies width by 2?
>
>
> Ok, some debugging / poking at thing further I now know where the multiply
> by 2 comes from, the pipe_resource *tmpl passed into nv30_miptree_create
> has templ->nr_samples = 4, and nv30_miptree_create has:
>
>    switch (tmpl->nr_samples) {
>    case 4:
>       mt->ms_mode = 0x00004000;
>       mt->ms_x = 1;
>       mt->ms_y = 1;
>       break;
>    case 2:
>       mt->ms_mode = 0x00003000;
>       mt->ms_x = 1;
>       mt->ms_y = 0;
>       break;
>    default:
>       mt->ms_mode = 0x00000000;
>       mt->ms_x = 0;
>       mt->ms_y = 0;
>       break;
>    }
>
> So it seems that glretrace is doing a normal rendering which works,
> where as ooimpress is doing a 4 way msaa rendering which does not work.
>
> 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?

  -ilia

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

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