[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use
keithp at keithp.com
Mon Nov 25 13:21:42 PST 2013
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
> 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);
>> + 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
Size: 827 bytes
Desc: not available
More information about the mesa-dev