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

[Hans de Goede]

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