On Thu, Dec 04, 2014 at 12:05:34PM +0100, Daniel Vetter wrote: > On Thu, Dec 04, 2014 at 09:13:21AM +0000, Chris Wilson wrote: > > On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote: > > > This simplifies the sync code quite a bit. I don't think we'll be able > > > to get away with using the core fence code's seqno support, since we'll > > > be moving away from simple seqno comparisions with the scheduler and > > > preemption, but the additional code is pretty minimal anyway, and lets > > > us add additional debugging as needed, so it's probably fine to keep > > > either way. > > > > > > We still need to add support for other rings here; we ought to be able > > > to do that with the timeline field of the ioctl (which will include > > > other "rings" like the display flip queue for example). > > > > I am ambivalent about this. I don't think migrating i915_request over to > > use the heavyweight fence primitives is a good idea, so see little value > > in embedding the struct fence inside i915_request vs a small bookkeeping > > struct referencing i915_request. > > Which part of struct fence is too heavyweight? And I guess we could always > add a slab or some cache if the allocation overhead is too much. I really > like this conceptually so if there's a concern with overhead I want solid > data for it. It uses locked atomic operations, which are unnecessary for the very frequent is-complete checks (due to the nice ordering constraints of x86). You have me confused. You keep applying patches without solid data to back up your claims. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
