[Mesa-dev] [PATCH 1/3] vl/dri3: use external texture as back buffers

[Andy Furniss]

Michel Dänzer wrote:
> On 28/10/16 08:19 PM, Andy Furniss wrote:
>> Michel Dänzer wrote:
>>> On 27/10/16 07:52 PM, Andy Furniss wrote:
>>>> Andy Furniss wrote:
>>>>> Michel Dänzer wrote:
>>>>>> On 26/10/16 08:07 PM, Andy Furniss wrote:
>>>>>>>
>>>>>>> The bad = Starting with DRI3 (which is default) I still get trashed
>>>>>>> rendering full screen. Windowed including re-sizing seems OK.
>>>>>>>
>>>>>>> I use Fluxbox window manager, which does not use compositing -
>>>>>>> IIRC this has historically shown some ddx DRI2/3 issue that wasn't
>>>>>>> visible to those testing with compositing (but then the full screen
>>>>>>> case may avoid compositing anyway depending on settings).
>>>>>>
>>>>>> You may be running into a DDX driver issue fixed by
>>>>>> https://patchwork.freedesktop.org/patch/118514/ .
>>>>>
>>>>> Yes, that was it, OK with that patch.
>>>>
>>>> Though "OK", sub-optimal loosing pageflip on tonga, as a vsync test
>>>> fails top 5% of screen unless I force GPU perf high.
>>>>
>>>> Not related to this patch directly of course, but I am a bit surprised
>>>> that on auto powerplay the tonga is too slow to make 60Hz.
>>>
>>> It's not too slow for 60 Hz (or you'd get dropped frames), the blit just
>>> doesn't finish within the vertical blank period.
>>
>> Yea, I didn't word that very well, and also didn't say res (1080p)
>> making it even less useful.
>>
>> Naive question = does the blit have to be "backwards", seems I wouldn't
>> notice if it were the same way as scanout?
>
> It's not backwards. The problem is that OpenGL doesn't provide a
> rectangle primitive, so glamor's blits end up being rendered as two
> triangles. In order to avoid tearing, at least the first triangle needs
> to finish rendering within the vertical blank period.

OK, so with a meaner test like doing -

xrandr --output DVI-D-0  --fb 3840x2160 --panning 3840x2160

and scrolling top left I can get a larger tear area and can see that
the triangles are split top left to bottom right. Possibly misleading
trying to judge what's happening visually, but it looks like the lower
/left triangle is rendered first with the one that covers most of the
top of the screen being the "late" one. If that's correct and assuming
they are copied top to bottom, then maybe there would be much less
visible disturbance if it were the other way round.

>> I guess I am being far too simplistic here, not knowing even the most
>> basic detail, like what format is the actual framebuffer that gets
>> scanned out really kept in?
>>
>> I know it ends up as BGR0 if grabbed by ffmpeg/gstreamer via X, which
>> leads to another thought/question. Currently to record screen with VCE
>> is quite bottle necked by copy to ram/convert to nv12 and copy back.
>>
>> Are there any show stopping issues that would preclude avoiding the
>> copy and doing the CSC/subsample/nv12 layout all in vram/by GPU?
>
> Not that I know of. E.g. something like this could work:
>
> With a GLX context using the X root window as the readable, use
> glReadPixels to store the screen contents in a PBO, then continue
> processing as necessary from there.

Thanks, that's good to know.

>>> Longer term I have an idea how to make the DDX driver support page
>>> flipping in this case as well, but in the meantime making the buffers
>>> sent for presentation tiled instead of linear should allow page flipping
>>> to be used. https://patchwork.freedesktop.org/patch/110569/ might be
>>> enough, which seems to be the best candidate to resolve the nouveau
>>> VDPAU issues as well.
>>
>> Doesn't help (one quick test with ddx patch).
>
> Weird, not sure why the buffer tiling doesn't match that of the X screen
> pixmap then.

I re-tested just in case I messed up, but still can't get it to
work/help.