On Sat, Mar 05, 2016 at 01:24:19PM +0100, Daniel Vetter wrote: > 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.
Ok, maybe I should read the patch, it's a high-level function ;-) In that case, yes please add a dirtyfb ioctl call _after_ the rendering to make it all just work. Since we don't know how callers use it. But for library completeness I think it'd be good to have kmstest_ wrappers for both dumb mmap and dirtyfb (maybe just defer to the libdrm one) like with the dumb create one. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
