On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede <hdegoede at 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 <hdegoede at 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. Could easily be that some
mt->ms_x/y shifts are missing. Might want to make some traces of the
blob drivers running some of the more basic piglit tests with MS and
seeing what they do. [I assume you're familiar with valgrind-mmt +
demmt. If not, http://nouveau.freedesktop.org/wiki/Valgrind-mmt/ ]
-ilia