[Mesa-dev] GBM, KMS/DRM, triple buffering

[Carlos Rafael Giani]

Hi Daniel,

thanks, I got it to work - almost. I am running this on the i.MX6 with 
etnaviv. I do get some flickering, however.

To test if something is wrong with the page flipping, I call drmGetCap() 
with DRM_CAP_ASYNC_PAGE_FLIP , and it returns me 0, indicating that 
async page flipping is not supported. But this is odd - is this really 
not implemented yet for the i.MX6? And why does drmModePageFlip() still 
work with DRM_MODE_PAGE_FLIP_EVENT ?



On 2018-02-09 17:05, Daniel Stone wrote:
> Hi Carlos,
>
> On 9 February 2018 at 08:33, Carlos Rafael Giani <dv at pseudoterminal.org> wrote:
>> I want to implement triple buffering instead of double buffering for a
>> program that uses EGL on GBM on a KMS-enabled platform. So far, I used
>> kmscube as an example.
>>
>> However, I do not see where I can specify that I want to have 3 buffers
>> allocated instead of 2. From what I saw, I could try to call
>> gbm_dri_surface_lock_front_buffer() to produce 3 BOs over time, but there's
>> a chance that gbm_dri_surface_has_free_buffers() will return 0 after getting
>> 2 BOs already.
> You're correct that there is no explicit control available. On the
> other hand, having three buffers is pretty much guaranteed for GBM:
> since your last buffer won't be released until after vblank, only
> having double buffering is likely to give you very badly reduced
> performance. (In practice, Mesa makes four buffers available.)
>
>> And, does gbm_dri_surface_lock_front_buffer() internally allocate the buffer
>> itself too (not just the BO structure)? Or are the flippable pages
>> preallocated by the implementation?
> This is an implementation detail. Usually buffer allocation is
> deferred to the first draw call of a frame: if there are no buffers
> available, then the implementation will allocate a new one.
>
> Cheers,
> Daniel