Hi Daniel/Chris, > As Chris said, instead of rolling your own code to track when flips are emitted to the ring simply add a real request (with the add_request function) like the execbuf paths.Then add any additional trackin you need to our request structure. We can use the 'add_request' function. But since we already have & can track the seqno of the object (for which we want the rendering to complete), we think there shall be no additional benefit in adding a new request & then tracking the same. > Rather exporting deep magic from i915_gem, just emit the request after the mmio flip and use the normal signalling mechanisms. There are other users who could also use a request after a flip. We had the following point in mind, when implementing the Mmio based Page flips : We wanted to completely avoid locking of the device mutex from the flip path. As we had seen sometimes the flips getting delayed because of concurrent exec buffers processing, while we are waiting for them to release the mutex. Since the public functions (i915_wait_seqno ) require mutex to be taken beforehand, we had no choice but to expose the private __wait_seqno function in order to do so. Also, we couldn't find any other signaling mechanism (other than wait_seqno type of functions) to do so. Can you please provide your feedback on the above points. Regards, Sourab -----Original Message----- From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter Sent: Friday, February 07, 2014 8:17 PM To: Goel, Akash Cc: 'Chris Wilson'; 'intel-gfx@xxxxxxxxxxxxxxxxxxxxx' Subject: Re: [PATCH 2/2] drm/i915/vlv: Replaced Blitter ring based flips with MMIO Flips for VLV. On Fri, Feb 07, 2014 at 11:59:29AM +0000, Goel, Akash wrote: > Please could you kindly elaborate here, it will help us to proceed further with this patch. As Chris said, instead of rolling your own code to track when flips are emitted to the ring, simply add a real request (with the add_request function) like the execbuf paths. Then add any additional trackin you need to our request structure. -Daniel > > Best Regards > Akash > > -----Original Message----- > From: Goel, Akash > Sent: Monday, January 13, 2014 3:17 PM > To: Chris Wilson > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: [PATCH 2/2] drm/i915/vlv: Replaced Blitter ring based flips with MMIO Flips for VLV. > > >> Rather exporting deep magic from i915_gem, just emit the request after the mmio flip and use the normal signalling mechanisms. There are other users who could also use a request after a flip. > > Sorry, couldn't understand your point. > > With Command streamer based flips, we could use the cross ring MBOX mechanism at Hw level, to ensure that buffer is flipped only when the rendering is completed. > > But with MMIO flips, need to ensure that we somehow introduce a wait for the rendering to complete, before updating the Display Surface Address register, to effect the flip. > > Best Regards > Akash > > -----Original Message----- > From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] > Sent: Thursday, January 09, 2014 5:02 PM > To: Goel, Akash > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH 2/2] drm/i915/vlv: Replaced Blitter ring based flips with MMIO Flips for VLV. > > On Thu, Jan 09, 2014 at 04:56:39PM +0530, akash.goel@xxxxxxxxx wrote: > > From: Akash Goel <akash.goel@xxxxxxxxx> > > > > Using MMIO based flips now on VLV for Media power well residency optimization. > > The blitter ring is currently being used just for the command > > streamer based flip calls. For pure 3D workloads, with MMIO flips, > > there will be no use of blitter ring and this will ensure the 100% residency in D0i3 for Media well. > > The other alternative of having Render ring based flip calls is not > > being used, as that option adversly affects the performance (FPS) of > > certain 3D Apps > > Rather exporting deep magic from i915_gem, just emit the request after the mmio flip and use the normal signalling mechanisms. There are other users who could also use a request after a flip. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
