[Intel-gfx] [i-g-t PATCH v1 07/14] lib: Map dumb buffers
chris at chris-wilson.co.uk
Wed Mar 2 14:54:20 UTC 2016
On Wed, Mar 02, 2016 at 02:40:44PM +0000, Daniel Stone wrote:
> On Wed, 2016-03-02 at 14:39 +0000, Chris Wilson wrote:
> > On Wed, Mar 02, 2016 at 02:22:58PM +0000, Daniel Stone wrote:
> > > On Wed, 2016-03-02 at 14:21 +0000, Chris Wilson wrote:
> > > > On Wed, Mar 02, 2016 at 03:00:14PM +0100, Tomeu Vizoso wrote:
> > > > > - gem_set_domain(fd, fb->gem_handle,
> > > > > - I915_GEM_DOMAIN_CPU,
> > > > > I915_GEM_DOMAIN_CPU);
> > > > > + if (!fb->is_dumb)
> > > > > + gem_set_domain(fd, fb->gem_handle,
> > > > > I915_GEM_DOMAIN_CPU,
> > > > > + I915_GEM_DOMAIN_CPU);
> > > > At the risk of opening a can-of-worms, what is the
> > > > synchronisation
> > > > protocol for dumb buffers? Even CPU access to a dumb needs set-
> > > > domain
> > > > on
> > > > Intel.
> > > Then Intel is broken, because the literal entire point of dumb
> > > buffers
> > > is that you do not require driver-specific calls to operate them.
> > >
> > > Map, populate, unmap, display.
> > Don't forget to call dirtyfb then.
> Are you talking about frontbuffer rendering, or pageflipping between
> two dumb buffers?
Afaik, no one yet tracks damage on a backbuffer before a flip. But we
don't constrain the tests to backbuffer as we do need to exercise
frontbuffer rendering and iirc those tests all use set-domain. I don't
see any PSR/FBC testing using the dumb framebuffers... Or is the dumb
framebuffer purely a backbuffer + flip model?
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx