Re: nv3x libreoffice impress opengl animations not working

[Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Hi,

On 28-08-15 13:01, Marek Olšák wrote:
> 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.

My first mail in this thread had 2 questions, 1 has been answered
the other not. Note I've updated the subject to reflect this.

Regards,

Hans


>
> Marek
>
> On Fri, Aug 28, 2015 at 10:54 AM, Hans de Goede <hdegoede@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@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
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau