[Mesa-dev] DRM EGL swapbuffers?

[Chia-I Wu]

On Wed, Feb 23, 2011 at 5:22 PM, Thomas Hellstrom <thomas at shipmail.org> wrote:
> On 02/22/2011 07:44 PM, Chia-I Wu wrote:
>>
>> On Tue, Feb 22, 2011 at 1:56 AM, Thomas Hellstrom<thomas at shipmail.org>
>>  wrote:
>>
>>>
>>> Hi, Chia-I,
>>>
>>> Looking at the EGL DRM implementation of swapbuffers, it looks like we're
>>> sort of ad-hoc attaching the backbuffer as a new scanout surface, using
>>> drmModeSetCrtc.
>>>
>>> I don't think this works very well on all hardware. In particular, I
>>> think
>>> drmModeSetCrtc may return before the swap actually takes place, which
>>> will
>>> cause rendering to the old front buffer while it is still displaying.
>>>
>>> Could you fill me in why the pageflip ioctl isn't used here, and a
>>> surface
>>> copy in situations where the pageflip ioctl can't be used? IIRC, the
>>> pageflip ioctl is required to block rendering to the old frontbuffer
>>> until
>>> the new frontbuffer is flipped in.
>>>
>>
>> Yes, pageflip should be used when available.  I did not use it simply
>> because it was not available on my machine when the code was written,
>> and I haven't had the motivation to revisit the code yet..
>>
>>
>
> OK. I'd like to update the code to use pageflip when available and otherwise
> fall back to a gallium blit. The current implementation really has no way to
> sync with ongoing rendering, and even if a synchronization method were
> implemented, draining the pipeline is generally a bad idea.
>
> So what would the appropriate place be to implement an exported gallium blit
> utility function, callable from the platform drivers?
The design is that the platform driver is in charge of turning a
native window to pipe resource(s) and presenting them to the user.  In
the X11 case, for example, the operations are mapped to
X_DRI2GetBuffers and X_DRI2CopyRegion (or X_DRI2SwapBuffers).

In this sense, the DRM platform driver is on its own.  It should
create a pipe context for blitting when that can not be avoided..

> Thanks,
> Thomas
>
>
>>> Thanks,
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>



-- 
olv at LunarG.com