blob: 671d67e9aebed47ac3e5f5bd022393b570d1b5e5 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
This is an explanation of where I think the DRM needs to go for modesetting + TTM to provide a flexible interface for users.
[[!img http://people.freedesktop.org/~airlied/drm_new_design.png]
# DRM Device:
This is the central DRM device. There is one instance of this per GPU and consists of the GPU driver alog with drm core code. The DRM device exposes an interface to userspace via device minors. There will be 3 types of minors exposed.
## Legacy Minor:
Old style DRM interface for older drivers to use also if this is opened for a card it will block newer uses of the card until closed. Vice-versa if the control node has been used to setup other nodes then this node will not be openable. The X server by default will use this node to try and enable DRI for all devices.
## Control Minor:
The control node will act like a pts master. This node can be used by a system user manager to create a render node, that can be assigned modesetting resources such as a crtc/outputs. If no rendering resources are assigned to this node then it will be used for GPGPU type applications. The system user manager can then pass the render node to the render leader (i.e. the X server) via a command line option or env variable. The X server will then run as the user and open the correct render minor to gain access to the modesetting resources and rendering functionality. The control node can also be used to switch render nodes in and out of focus. Output resources can only be assigned to one render leader at a time. While the render leader isn't focused it can be suspended or can keep consuming resources in the background with no output displaying. This is under the control of the user manager.
## Render Minor:
The render node is what the user render leader connects to. The system can be configured with either a single render node with all crtcs/outputs available to a single user, or a render node per crtc with a set of configured outputs for multiple users to use. Also render nodes with no output resources can exist.
# Locking and SAREA:
The current DRM design has one large single lock and a single sarea. With this new scheme the actual access to hw is locked within the kernel, clients must prepare buffers and submit them to the drm kernel driver for scheduling. Each render leader has its own private sarea based on DRI2 work, which is used to store cliprects and the lock protecting the cliprects.
# Interrupt handling:
The main area under DRI2 is if we have in-kernel cliprect users we need to make sure the correct sarea is being accessed for the swap buffers. This could be two sareas as we may have a different render leader on each crtc.
|
