[RFC] Using DC in amdgpu for upcoming GPU
Jan Ziak
0xe2.0x9a.0x9b at gmail.com
Fri Dec 9 16:32:54 UTC 2016
Hello Dave
Let's cool down the discussion a bit and try to work out a solution.
To summarize the facts, your decision implies that the probability of
merging DAL/DC into the mainline Linux kernel the next year (2017) has
become extremely low.
In essence, the strategy you are implicitly proposing is to move away from
a software architecture which looks like this:
APPLICATION
USERSPACE DRIVERS (OPENGL, XSERVER)
----
HAL/DC IN AMDGPU.KO (FREESYNC, etc)
LINUX KERNEL SERVICES
HARDWARE
towards a software architecture looking like this:
APPLICATION
USERSPACE DRIVERS (OPENGL, XSERVER)
USERSPACE HAL/DC IMPLEMENTATION (FREESYNC, etc)
----
AMDGPU.KO
LINUX KERNEL SERVICES
HARDWARE
For the future of Linux the latter basically means that the Linux kernel
won't be initializing display resolution (modesetting) when the machine is
booting. The initial modesetting will be performed by a user-space
executable launched by openrc/systemd/etc as soon as possible. Launching
the userspace modesetting executable will be among the first actions of
openrc/systemd/etc.
Note that during the 90-ties Linux-based systems _already_ had the xserver
responsible for modesetting. Linux gradually moved away from the 90-ties
software architecture towards an in-kernel modesetting architecture.
A citation from https://en.wikipedia.org/wiki/X.Org_Server is in order
here: "In ancient times, the mode-setting was done by some x-server
graphics device drivers specific to some video controller/graphics card. To
this mode-setting functionality, additional support for 2D acceleration was
added when such became available with various GPUs. The mode-setting
functionality was moved into the DRM and is being exposed through an DRM
mode-setting interface, the new approach being called "kernel mode-setting"
(KMS)."
The underlying simple hard fact behind the transition from 90-ties
user-modesetting to kernel-modesetting is that most Linux users prefer to
see a single display mode initialization which persists from machine boot
to machine shutdown. In the near future, the combination of the following
four factors:
1. General availability of 144Hz displays
2. Up/down-scaling of fullscreen OpenGL/Vulkan apps (virtual display
resolution)
3. Per-frame monitor refresh rate adjustment (freesync, g-sync)
4. Competition of innovations
will render non-native monitor resolutions and non-native physical
framerates completely obsolete. (3) is a transient phenomenon which will be
later superseded by further developments in the field of (1) towards
emergence of virtual refresh rates.
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161209/fb292101/attachment-0001.html>
More information about the dri-devel
mailing list