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

Ilija Hadzic ihadzic at research.bell-labs.com
Fri Sep 28 11:42:49 PDT 2012



On Fri, 28 Sep 2012, Daniel Vetter wrote:

> 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.

Correct, the goal is to be able to run multiseat while sharing a GPU. 
Actually, with my variant of render nodes, I even got multiple desktops
residing in different LXC containers to share the GPU, which is kind of 
cool.

> 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.
>

OK I see. From what I can tell from the second patch, drm_get_pci_dev will 
create one (and I guess only one, right ?) render node if the underlying 
driver has DRIVER_RENDER node feature. The third patch (among other 
things) adds that feature to Intel driver.

So if I boot up a system with these patches and with Intel GPU, I will 
automagically get one more /dev/dri/renderD128 node, right ? The intent is 
that the render client opens and uses that render node. The 
/dev/dri/controlDNN node still remains an unused "orphan", right ?

So would you entertain the possibility that the render node is created 
from user space on demand using an ioctl into the control node ? If that's 
a possiblity for you, then my set of patches is a superset of what 
Kristian needs. If you just need a render client, you can create a node 
with no display resources and you would get something quite close to what 
these 3 patches try to do..... unless I am missing something.

-- Ilija



More information about the dri-devel mailing list