[Intel-gfx] [i-g-t PATCH v1 07/14] lib: Map dumb buffers

Daniel Vetter daniel at ffwll.ch
Sat Mar 5 12:24:19 UTC 2016


On Wed, Mar 02, 2016 at 02:54:20PM +0000, Chris Wilson wrote:
> 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?

Yeah, but for those tests we do have explict set_domain calls. Anyway the
dumb model is mmap + either flip (setcrtc, setplane, page_flip, atomic) or
dirtyfb. I think for low level functions like these exposing this
explicitly to tests is ok.

If you mix dumb with rendering you simply need to know what you're doing.
But for rendering that's a requirement anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list