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

[Ilia Mirkin]

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