On Tue, Feb 09, 2016 at 02:08:23PM +0200, Martin Peres wrote: > On 26/01/16 19:00, Daniel Vetter wrote: > >On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote: > >>On 01/22/2016 09:00 AM, Daniel Vetter wrote: > >>>On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orourke@xxxxxxxxx wrote: > >>>>From: Tom O'Rourke <Tom.O'Rourke@xxxxxxxxx> > > > >I'd say we need to keep the boost-deboost stuff alive, e.g. by manually > >telling guc that the we want different limits, then resetting those limits > >again after the boost is done. Same for fast idling - kernel simply has a > >better idea if anyone is about to submit more work (we have execbuf hints > >for specific workloads like libva). > > Since there is soon to be a GPU scheduler, the GuC could get this > information already, right? Unless you are talking about having mesa signal > when it starts creating a new batchbuffer and you would like the GPU to > prepare to ramp-up. We don't tell the guc when we're stalling for a batch, so no it doesn't know. The entire desing seems to center around the idea of just aiming for some average fps, which is silly for spikey workloads. I assuming that without some other magic we'll still need explicit boosting and deboosting. -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
