Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Direct Rendering Manager
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Render nodes === In the original DRM API, the DRM device <code>/dev/dri/card''X''</code> is used for both privileged (modesetting, other display control) and non-privileged (rendering, [[GPGPU]] compute) operations.{{r|Herrmann 2013 DRM split}} For security reasons, opening the associated DRM device file requires special privileges "equivalent to root-privileges".{{r|Herrmann 2013 rendernodes}} This leads to an architecture where only some reliable user space programs (the X server, a graphical compositor, ...) have full access to the DRM API, including the privileged parts like the modeset API. Other user space applications that want to render or make GPGPU computations should be granted by the owner of the DRM device ("DRM Master") through the use of a special authentication interface.{{r|drmbook-rendernodes}} Then the authenticated applications can render or make computations using a restricted version of the DRM API without privileged operations. This design imposes a severe constraint: there must always be a running graphics server (the X Server, a Wayland compositor, ...) acting as DRM-Master of a DRM device so that other user space programs can be granted the use of the device, even in cases not involving any graphics display like GPGPU computations.{{r|Herrmann 2013 rendernodes}}{{r|drmbook-rendernodes}} The "render nodes" concept tries to solve these scenarios by splitting the DRM user space API into two interfaces β one privileged and one non-privileged β and using separate device files (or "nodes") for each one.{{r|Herrmann 2013 DRM split}} For every GPU found, its corresponding DRM driver—if it supports the render nodes feature—creates a device file <code>/dev/dri/renderD''X''</code>, called the ''render node'', in addition to the primary node <code>/dev/dri/card''X''</code>.{{r|drmbook-rendernodes}}{{r|Herrmann 2013 DRM split}} Clients that use a direct rendering model and applications that want to take advantage of the computing facilities of a GPU, can do it without requiring additional privileges by simply opening any existing render node and dispatching GPU operations using the limited subset of the DRM API supported by those nodes—provided they have [[file system permissions]] to open the device file. Display servers, compositors and any other program that requires the modeset API or any other privileged operation must open the standard primary node that grants access to the full DRM API and use it as usual. Render nodes explicitly disallow the GEM ''flink'' operation to prevent buffer sharing using insecure GEM global names; only PRIME (DMA-BUF) [[file descriptor]]s can be used to share buffers with another client, including the graphics server.{{r|Herrmann 2013 DRM split}}{{r|drmbook-rendernodes}}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)