[RFC] clients: add simple-dmabuf
dh.herrmann at gmail.com
Mon Oct 28 10:14:39 CET 2013
On Mon, Oct 28, 2013 at 12:34 AM, Axel Davy <davy at clipper.ens.fr> wrote:
> On 22/10/2013 17:23, David Herrmann wrote :
> Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on
> the render-node. So if someone else tests this, you might need the
> same hacks. I will try to find the code in mesa that requires this.
> This comes from 'intel_region_alloc_for_handle', which is called in
> I've just talked with Christopher James Halse Rogers, and he already made
> patches that should solve that.
> The patches to support driImage version 7 were posted recently on Mesa,
> And his older patches (probably need rebasing):
> Combined with setting the name field to null (instead of generating a name)
> and setting the fd field to a prime dma-buf when creating a buffer (in
> it should avoid using names at all, and use dma-buf in Mesa, thus enabling
> using render-nodes with Mesa.
Yepp, exactly these patches are needed! I don't know who it was I
talked to in #intel-gfx, but some-one said he's working on it. Note
that for dma-buf we're still missing allocation negotiation and sync
fences. But these are also being worked on.
With these patches (and your name=0; init thing) it works great.
There're visible sync issues (really awful tearing, need to look into
that), but apart from that it's fine.
Regarding your earlier mail: We tried to _not_ support flink and
friends on render-nodes. Yes, we could have provided some dummy ioctls
to trick user-space, and yes, it would probably have worked well. But
we intentionally tried to break the API to maybe some day be able to
drop it. If we keep dummies, we never know who's still using it. If we
don't, we simply say render-nodes are DRM-2.0 and be done with it.
Thanks for your investigations!
More information about the wayland-devel