From: Thomas Hellstrom <thellstrom@vmware.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2] drm: enable render-nodes by default
Date: Fri, 21 Mar 2014 09:29:31 +0100 [thread overview]
Message-ID: <532BF86B.7030101@vmware.com> (raw)
In-Reply-To: <CAKMK7uF_FPeYESk-01zUgxZ=bd=2_N_FpvTn4rwOOMeqrxOsug@mail.gmail.com>
On 03/21/2014 08:10 AM, Daniel Vetter wrote:
> On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark <robdclark@gmail.com> wrote:
>>>> Ie. an app that was using the gpu for something secure could
>>>> simply choose not to if the hw/driver could not guarantee that another
>>>> process using the gpu could not get access to the buffers..
>>> IMO that should work fine, but we need to provide a way for user-space
>>> to determine whether
>>> the render node is secure or not. Perhaps a sysfs attribute and / or a
>>> drm getparam() parameter?
>> I'd *assume* that that sort of thing would just be some sort of CL extension?
>>
>> But no objection to exposing it in a more common way.
>>
>> I guess it is also an option to keep the bootarg to override default
>> (with the default being 'enabled' for hw w/ per-context/process vm and
>> 'disabled' otherwise).
> Imo if we expose this through sysfs we should always enable
> rendernodes. The udev scripts can then decide what permissions to set
> on them.
Agreed.
Thomas
> -Daniel
prev parent reply other threads:[~2014-03-21 8:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-16 13:43 [PATCH] drm: enable render-nodes by default David Herrmann
2014-03-16 13:43 ` David Herrmann
2014-03-17 10:07 ` Daniel Vetter
2014-03-17 10:07 ` Daniel Vetter
2014-03-17 16:43 ` [PATCH v2] " David Herrmann
2014-03-20 6:43 ` Thomas Hellstrom
2014-03-20 7:36 ` David Herrmann
2014-03-20 8:48 ` Thomas Hellstrom
2014-03-20 9:05 ` David Herrmann
2014-03-20 9:27 ` Thomas Hellstrom
2014-03-20 9:43 ` David Herrmann
2014-03-20 10:28 ` Thomas Hellstrom
2014-03-20 14:36 ` Jerome Glisse
2014-03-20 14:44 ` Ilia Mirkin
2014-03-20 15:35 ` Jerome Glisse
2014-03-20 17:39 ` Ilia Mirkin
2014-03-20 14:59 ` Thomas Hellstrom
2014-03-20 15:34 ` Jerome Glisse
2014-03-20 15:49 ` Thomas Hellstrom
2014-03-20 17:04 ` Jerome Glisse
2014-03-20 17:34 ` Rob Clark
2014-03-20 20:54 ` Thomas Hellstrom
2014-03-20 21:13 ` Rob Clark
2014-03-21 7:10 ` Daniel Vetter
2014-03-21 8:29 ` Thomas Hellstrom [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=532BF86B.7030101@vmware.com \
--to=thellstrom@vmware.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.