[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

[Keith Packard]

Daniel Vetter <daniel at ffwll.ch> writes:

> Yeah, it unfortunately took a few rounds of kernel fixes and other
> haggling to get the semantics right on this one. The kernel atm promises
> to userspace (minus one big in a racy corner case no one should care
> about, still need to fix that one) that it'll return the same gem handle
> if userspace already has one for the underlying object.

That's definitely something we want it to do -- returning different
handles to the same object would result in madness. We just need to deal with the
userspace consequences.

> We need that to make sure userspace doesn't submit the same bo in execbuf
> multiple times and then upsets the kernel - we'll reject such batches as
> userspace bugs.

Oh, I'm well aware of that; you can imagine the adventures I had trying
to debug this...

>> -	DRMINITLISTHEAD(&bo_gem->name_list);
>>  	DRMINITLISTHEAD(&bo_gem->vma_list);
>> +	DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime);
>
> Won't this result in us having fun when a buffer is both imported from a
> prime buffer and then also used with legacy flink? Or is this something
> the X server won't support?

Well, the whole point of prime-based FD buffer passing is to *not* use
flink, of course. However, you could use both DRI2 and DRI3 on
the same pixmap (presumably through different APIs).

Ok, I just tried to create a completely separate prime list for this,
and I think that's wrong. If the question is whether the kernel might
return the same object from two calls, then we'd best actually keep a
single list and look things up for both APIs there. *and*, I think we
need to do the flink->gem handle conversion and then look in the list
again to see if that gem handle was already returned from another flink
or prime fd.

> The second one is about exporting: With flink names we also add the name
> to the lookup list in drm_intel_gem_bo_flink. I think we should do the
> same for exported prime buffers just as a precaution - the kernel will
> return the (existing) gem name also for a prime buffer that has been
> exported by yourself. I guess that would imply insane userspace, but
> better safe than sorry.

yeah, that would seem like crazy user-space behaviour, but user space
often seems insane.

Thanks for your review; replacement patch to follow shortly.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131125/8da762d1/attachment.pgp>