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

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?
>
> I believe this is a clue to the root cause of the problem, but after this
> I'm sorta stuck. Anyone got any hints on how to debug this further /
where
> to look ?
>
> Thanks & Regards,
>
> Hans

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.

Regards,

Hans

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