Am Freitag, den 09.02.2018, 19:26 +0100 schrieb Carlos Rafael Giani:
> Hi Daniel,
> thanks, I got it to work - almost. I am running this on the i.MX6
> etnaviv. I do get some flickering, however.
> To test if something is wrong with the page flipping, I call
> 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
> not implemented yet for the i.MX6? And why does drmModePageFlip()
> work with DRM_MODE_PAGE_FLIP_EVENT ?
Beware of confusing terminology here: all regular page flips are async
in that they wait for the next vblank for the actual execution.
Now ASYNC_PAGE_FLIP again make them async in the sense that they are
not synchronized to vblank, but execute as soon as possible. So more
synchronous to you actual page flip request, but with the associated
consequences of tearing, etc. This is something that won't ever be
supported on i.MX6, as the hardware doesn't allow for that.
> On 2018-02-09 17:05, Daniel Stone wrote:
> > Hi Carlos,
> > On 9 February 2018 at 08:33, Carlos Rafael Giani <dv@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
> mesa-dev mailing list
mesa-dev mailing list