Hi,
On 28-08-15 11:02, Ilia Mirkin wrote:
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?
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.
Regards,
Hans
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
