On Fri, Sep 19, 2014 at 03:25:55PM +0100, Damien Lespiau wrote: > Hi Daniel, > > On Mon, Jul 07, 2014 at 11:04:55PM +0200, Daniel Vetter wrote: > > On Thu, Jul 03, 2014 at 08:12:35AM +0100, Damien Lespiau wrote: > > > This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd. > > > > > > The OA buffer can contain global data (in particular, not linked to a > > > context or a single batch execution) about GPU events (eg. hw context > > > switches, rc6 transitions, frequency changes, ...) and needs to be > > > mapped to GGTT. The pin ioctl provided a way to do that. > > > > > > Admittedly, this change broke what seems to be a valid use case of > > > pinning a buffer in GGTT, even when PPGTT is used (which is the reason > > > invoked in the commit message). > > > > Global OA buffers should be handled by the kernel and exposed through > > perf, imo. I think I'll go lalala on this a bit longer ... > > Do you think that we can unblock this now that we have somewhat of path > forward with Rob Bragg's work? I'm still uneasy with a precedent where > we break working applications and it takes a long time for us to revert > the offending change? I still consider pinning stuff behind the kernels back too evil. So if people want that I'd like to see the use-case and why we can't do this differently. And I've never approved of the pin ioctl but really loudly complained about each occasion I've spotted, so I think the internal users just have to keep the pieces for a bit longer. -Daniel -- 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
