[PATCH 0/3] [RFC] DRM Render Nodes

Daniel Vetter daniel.vetter at ffwll.ch
Fri Sep 28 11:16:48 PDT 2012


On Fri, Sep 28, 2012 at 7:59 PM, Ilija Hadzic
<ihadzic at research.bell-labs.com> wrote:
>
>
> On Fri, 28 Sep 2012, Alex Deucher wrote:
>>
>>
>> I haven't read through your patches yet, but Dave and Ilija already
>> did something similar a while back:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html
>>
>
> Actually, there is a, a newer series of patches here (applied few comments I
> got after first series)
>
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html
>
> I have the v3 series (applied more comments I got after v2 series, plus some
> more cleanup) that I have never sent out, because my perception was that
> there was low interest in this work. I can send the v3 out, if there is a
> revived interest in this work.
>
> The original work is by Dave and I did some major cleanup and built more on
> the top of it.
>
> Kristian's patches at the first glance (I have not looked them in detail)
> appear more like prep. work (like which ioctl can a render node use and
> which can't, etc.), but my impression is that they still require the work
> cited above (Dave's original work and/or my followup work) to actually be
> able to create and use the render node.
>
> BTW, the third patch in Kristian's series is for Intel only and we'll
> probably need equivalent patches for radeon and nouveau.

On a quick look the rendernode Kristian propose and your work seem to
attack slightly different issues. Your/Dave's patch series seems to
put large efforts into (dynamically) splitting up the resources of a
drm device, including the modeset stuff. Kristians proposal here is
much more modest, with just enabling a way for to do the same for
render clients. All the modeset (and flink open stuff) would still be
only done through the legacy drm node.

One thing though that Kristians patches miss is properly splitting out
mmap support such that each open file of the rendernode only has
access to it's file-private gem object and not all of them. Since
linux has the mmap interface at the struct file level, that shouldn't
be a big hassle to get off the ground: We just need to add an
mmap_offset table to file_prive and then add the offset lookup at the
right place (and do the lookup with the right table), depending upon
whether it's a legacy or a new render node doing the offset create (or
mmap syscall).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list