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

[Hans de Goede]

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.

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