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

[Marek Olšák]

Your first question was about shader translation, but now you're
talking about texture allocations, which are completely unrelated.
Like I said, visuals and textures have NOTHING to do with shader
compilations.

Marek

On Fri, Aug 28, 2015 at 10: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.
>
> 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