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/dri-devel/attachments/20131125/8da762d1/attachment.pgp>
