[Intel-gfx] [PATCH 0/2] I915 GEM context updates

[David Weinehall]

On Wed, Jul 01, 2015 at 05:23:51PM +0200, Daniel Vetter wrote:
> On Wed, Jul 1, 2015 at 2:21 PM, David Weinehall
> <david.weinehall at linux.intel.com> wrote:
> > On Tue, Jun 30, 2015 at 03:01:06PM +0100, Chris Wilson wrote:
> >> On Tue, Jun 30, 2015 at 04:36:55PM +0300, David Weinehall wrote:
> >> > On Tue, Jun 30, 2015 at 02:32:19PM +0100, Chris Wilson wrote:
> >> > > On Tue, Jun 30, 2015 at 04:01:23PM +0300, David Weinehall wrote:
> >> > > > On Tue, Jun 30, 2015 at 01:49:27PM +0100, Chris Wilson wrote:
> >> > > > > On Tue, Jun 30, 2015 at 03:24:51PM +0300, David Weinehall wrote:
> >> > > > > > This patch contains a few minor updates related to
> >> > > > > > I915 GEM context.
> >> > > > >
> >> > > > > As a kernel API, this is absolutely awful. Can we please correct it before
> >> > > > > it is released?
> >> > > >
> >> > > > Daniel has already merged it and didn't have any objections, so you'll
> >> > > > have to convince him, not me.
> >> > > >
> >> > > > If you believe it's awful, feel free to provide a better implementation.
> >> > >
> >> > > As I recall, I did.
> >> >
> >> > Hmmm, I must've missed your patch -- if so I apologise.  What was the
> >> > title of the post, and how come Daniel hasn't merged that one instead?
> >>
> >> I gave details on a comment to your patch, where I thought the api could
> >> be improved.
> >
> > Yeah, I got the bits about you not liking the approach, but the things
> > you write in this e-mail are the first suggestions that I find concrete
> > enough for me to actually know what you want instead.
> 
> Imo NONZEROMAP is still good to go, and good enough for
> opencl/beignet. Allowing more fancy placement constraints might be
> useful eventually, but thus far I haven't seen a compelling reason
> really. Or not compelling enough at least.
> 
> And I don't think there's a point in blocking beignet for something
> too fancy. Hence this still has my Ack. It gets the (really specific)
> job done for beignet, which seems good enough.

OK, so where do we stand on this?  Daniel is OK with the patch (and has
merged the kernel side).  The last post regarding this on the libdrm
list is that Chris objects, meaning that no one is likely to pick up
that patch and merge it to libdrm, meaning it's dead in the water until
a follow-up comment.


Regards, David