On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 27-08-15 20:19, Ilia Mirkin wrote: >> >> On Thu, Aug 27, 2015 at 1:59 PM, Alex Deucher <alexdeuc...@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? > > 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
