Hi,
On 03-09-15 19:36, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdego...@redhat.com> wrote:
Hi,
On 02-09-15 16:44, Ilia Mirkin wrote:
On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede <hdego...@redhat.com> wrote:
Hi Ilia
<snip>
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?
Yes I see that print happening and that explains the misrendering I'm
seeing pretty well, it is not misrendering at all, it is just random
data from the video mem.
I've had a quick talk about this with Ben, he suggested using
the SCALED_IMAGE_FROM_MEMORY object class, as that is what the blob
is doing.
I've done some digging through the code and this translates to the
"sfim" object in the gallium nv30 code. I was wondering if I cannot
just simple call nv30_transfer_rect with the right parameters and
let it sort the blit out ?
That seems fine to me. BTW, it's sifm == scaled image from memory, not
sfim. You'll either have to fudge the width/height, or teach the
transfer methods to look at mt->ms_x/y (and make sure to treat it as a
scaled xfer if the nr_samples don't line up).
Ok, I've gotten this to work, yeah :) I'll send out patches for this
shortly.
But even with this fixed, there still are problems with msaa:
1) On nv3x (vs nv4x) we end up using the cpu for the blit, this is
no good so I've added a patch to my patch-set to disable msaa
visuals on nv3x
2) On nv4x things mostly work, but sometimes / after a while
the gpu locks up. Attaching gdb to impress shows it is hanging waiting
for a fence which never comes.
Killing ooimpress at this point works exactly once, trying to do any
3d operations after killing impress will lockup the entire system.
When I kill impress at this point it prints a lot of messages
like these to stdout:
nouveau: 0x45070000
nouveau: 0x00000000
nouveau: 0x0004f900
nouveau: 0x04380780
nouveau: 0x000cf580
nouveau: 0x00000000
nouveau: 0x45070000
nouveau: 0x00000000
nouveau: 0x0004f900
nouveau: 0x04380000
nouveau: 0x0004f808
nouveau: 0x00000000
nouveau: 0x0008fd6c
nouveau: 0x00000000
nouveau: 0x000000a9
nouveau: 0x00020000
nouveau: 0x00000000
I've not yet seen the beginning of this list since my scroll-back
buffer is not large enough, I guess I need to reproduce this and
redirect the output to a file to get all messages.
So any hints on how to debug this ? Could this have something
to do with the destination buffer for the msaa rendering
(so the buffer which has the image rendered at twice the
desired resolution) not having enough padding on its pitch ?
Those messages get printed by libdrm when the kernel rejects
something. You should also see what the kernel is rejecting and why in
dmesg... this should be instructional.
Here is what dmesg says:
[ 1197.850642] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1197.850648] nouveau E[soffice.bin[3785]] validating bo list
[ 1197.850654] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.766955] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.766961] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.766968] nouveau E[soffice.bin[3785]] validate: -12
[ 1201.989441] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1201.989447] nouveau E[soffice.bin[3785]] validating bo list
[ 1201.989454] nouveau E[soffice.bin[3785]] validate: -12
[ 1202.231688] nouveau E[soffice.bin[3785]] fail ttm_validate
[ 1202.231694] nouveau E[soffice.bin[3785]] validating bo list
[ 1202.231701] nouveau E[soffice.bin[3785]] validate: -12
Could easily be that some
mt->ms_x/y shifts are missing.
I think that the above dmesg rules that out and that instead
I should be looking into buffer management, right ? Any clues
on how to debug this, are there some kernel parameters to
log the alloc / free of bo-s and to make ttm_validate print
a reason why things are failing ?
I'm currently using dri2, shall I retry with dri3 ?
Regards,
Hans
p.s.
I've a feeling that I can only reproduce after ending an
Xorg session and starting Xorg a second time. At least in my
first session I could not reproduce with a gazillion tries
and in my second session it reproduced pretty quickly ...
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
