From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: "Zach Reizner" <zachr@google.com>,
dri-devel@lists.freedesktop.org,
"Stéphane Marchesin" <marcheu@chromium.org>
Subject: Re: [PATCH] drm/vgem: drop DRIVER_PRIME
Date: Thu, 21 May 2015 17:24:57 +0200 [thread overview]
Message-ID: <20150521152457.GH15256@phenom.ffwll.local> (raw)
In-Reply-To: <555DF3DE.2010006@vmware.com>
On Thu, May 21, 2015 at 05:03:58PM +0200, Thomas Hellstrom wrote:
> Hi, Rob!
>
> On 05/21/2015 04:53 PM, Rob Clark wrote:
> > For actual sharing of buffers with other drivers (ie. actual hardware)
> > we'll need to pimp things out a bit better to deal w/ caching, multiple
> > memory domains, etc. See thread:
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DMay_083160.html&d=AwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=hZDsGjgypZF71rQfORpnkvT34UoNymdOdW0M3RyIIpQ&s=6QpYr_rF5y3fBjm48gY5zTJp6Fu87bv2HJYGGJ7VX7s&e=
> >
> > But for the llvmpipe use-case this isn't a problem. Nor do we really
> > need prime/dri3 (dri2 is sufficient). So until the other issues are
> > sorted lets remove DRIVER_PRIME.
> >
> > NOTE this ends up leaving some basically dead code for prime import/
> > export (mostly because I was rushing to send this before a meeting).
>
> What worries me a little is what Daniel brought up in his commit
> message, that let's say in the end people add a reasonable interface to
> dma_buf mmap, vgem also needs a corresponding interface... Makes me
> think that the best solution for now
> is perhaps to revert it.
Yeah if we just drop the prime parts vgem is pretty much only for llvmpipe
and other software renderers. And if we add prime it'd be purely
self-import only which rejects any foreign access and reject any foreign
objects. At least I haven't understood yet why we need to import the
dma-bufs first when we could just directly mmap the passed-in fd ...
Anyway I think removing the dead code makes sense - we can easily
resurrect it with git again. Also the current prime code for vgem doesn't
handle self-imports correctly, so isnt' even really useable for
llvmpipe-on-vgem as-is.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2015-05-21 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 14:53 [PATCH] drm/vgem: drop DRIVER_PRIME Rob Clark
2015-05-21 15:03 ` Thomas Hellstrom
2015-05-21 15:24 ` Rob Clark
2015-05-21 15:24 ` Daniel Vetter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150521152457.GH15256@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=marcheu@chromium.org \
--cc=thellstrom@vmware.com \
--cc=zachr@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox