Re: [PATCH 5/8] drm/i915/context: context validation for execbuffer2

[Ben Widawsky <bwidawsk@gmail.com>]

On Mon, Feb 14, 2011 at 09:21:22PM +0100, Daniel Vetter wrote:
> On Wed, Feb 02, 2011 at 03:00:17PM -0800, Ben Widawsky wrote:
> > Adds the support for actually doing something with buffer validation for
> > the context when submitted via execbuffer2. When a set of context flags
> > are submitted in the execbuffer call, the code is able to handle the
> > commands. It will also go through the existing buffers associated with
> > the context and make sure they are still present. The big thing missing
> > is if the client wants to change the domains of buffers which have
> > already been associated. In this case, the client must disassociate and
> > then re-associate with the proper domains.
> 
> Hm, this remark got me thinking (because currently with read/write domains
> per reloc domain changes on the fly are super-simple): Why not drop the
> whole associate/disassociate idea and require userspace to always submit a
> full list of bos still used by this context (and their required
> offsets)?
> 
The code has changed quite a bit since these patches:
http://cgit.freedesktop.org/~bwidawsk/drm-intel/

I have no problem with this. The complex part of the code has become
tracking when I can retire the context's backing object. As I see it,
your proposal is essentially an implicit associate (if it has an
offset), with no disassociate. In terms of the driver code to handle it,
it would just read through the flags instead of slots.

I had, and still have very little clue as to what clients of the
interface would like. I'm very scared of digging into mesa. A fear which
I am trying to get over presently. So if people think this is at least
as good, or better - then great!

I think what I'll do is fix the couple of outstanding bugs I'm aware
of, get a couple of better unit tests, do some kind of code review on
the result of that, start tinkering with mesa - and then decide which
one seems better. Unless others chime in and say they like one over the
other...

Your argument is pretty convincing. It seems the only advantage of slots
is you can save on the number of flags submitted per execbuffer call,
which is probably negligible since multiple people have said there are
relatively few buffers which we actually need to be tied to a context
anyway.

>   expecting to get this right on the first try is probably wishful
>   thinking.

This is my opinion as well, but I'm not sure everyone agrees.

> 
> Yours, Daniel

Thanks Daniel.
Ben