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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux