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

[Michel Dänzer]

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.


> 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.


>> 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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer