[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