How DRI and DRM Work
How DRI and DRM Work
Introduction
This page is intended as an introduction to what DRI and DRM are, how they fit into the overall structure of X, Mesa and so on, and why you should care about it if you're developing applications which make use of graphics acceleration. It's written with the SMedia Glamo chip of the Openmoko Neo FreeRunner in mind, but many of the concepts are generally applicable to all graphics hardware. However, more advanced hardware is generally a lot more complicated than the technology described here...
The Hardware
The graphics processor (GPU) is separate from the main CPU, and has its own memory. The graphics chip can't access the main system memory at all [1], but** the graphics memory ("VRAM") can be mapped into the CPU's address space and then written to or read from**. If we didn't care about accelerated graphics, we would just program the GPU to display a section of its VRAM on the LCD screen, and write what we wanted to display.
But we want to do some slightly more exciting things. To use acceleration features, a sequence of commands has to be written to a circular buffer, in VRAM, of commands. Circular in this sense means that when there is no more space left at the end of the buffer, writing begins again at the start of the buffer. Hopefully the buffer is long enough that the program can write a significant number of commands, then go away and do something else while they execute.
Commands submitted via this buffer (known as the "command queue", "ring buffer" or similar) generally need to refer to other buffers in VRAM. For instance, if we told the GPU to turn the entire screen blue, we would need to send a command sequence which described that a flood fill operation was to be performed, that it was to be done using the colour blue, and that the buffer to be filled with blue was the same buffer we previously told it to display on the LCD.
Historical Situation
Previously, all applications which used hardware acceleration would contain a full implementation of the code required to allocate VRAM for the command queue, program the command queue processor (part of the GPU) to read commands from the newly allocated buffer, and to keep updating its configuration every time new commands were written. There'd also be a lot of error-checking to be done to make sure everything went smoothly. In addition, it'd have to handle memory management if it wanted to allocate more buffers in VRAM - for instance, to hold the contents of offscreen windows ready to be quickly copied onto the screen. This is a lot of programming, but is the situation we currently have with the Glamo chip. The X server (both the old Kdrive-based server (Xglamo) and the more recent X.org driver xf86-video-glamo) contains command queue handling code, as does the accelerated version of mplayer.
It's pretty clear that multiple applications can't simultaneously use the acceleration - they'd both be trying to manage a single command queue and pool of VRAM in their own ways, and the results could range from instability to outright catastrophe. This is one of the things DRI is here to fix.
DRM - Kernel Level Support
The Direct Rendering Manager, DRM, is the kernel part of the wider Direct Rendering Infrastructure (DRI). With DRM, all the command queue and VRAM handling is done by the kernel, and there's an ioctl interface through which userspace programs can ask it to do things. For example, a program might ask to allocate some VRAM, and the DRM will return a unique handle by which the program can refer to the newly allocated VRAM. The kernel, aware of the requests from the multiple programs, can coordinate memory management across them all. If the program needed to read or write its VRAM, it could ask the kernel to map the memory into the program's address space. The subset of the DRM ioctl interface which takes care of memory is called GEM [2].
Command queue handling is similar. If the program wanted to submit a sequence of commands, it could call another ioctl with its commands, and the kernel would add it to the command queue. Part of the beauty of all this is that only the kernel has to know where the objects in VRAM actually reside at any point, and it can move some of them out of VRAM if space becomes tight. Userspace programs just use their unique handles to refer to memory, and let the kernel take care of making sure that the correct buffers are in the right places at the right times.
Finally, there's a library ("libDRM") which exists to make handling DRM's ioctls a little easier.
EXA - X Server Acceleration
I mentioned that the X server used to be one of the programs which wanted to access the hardware to send command sequences. With DRM in place, the X server uses the ioctl interface to pass its commands down to the kernel. The GEM interface is used to allocate VRAM for offscreen pixmaps.
DRI - X Server Support
"DRI" could be taken to mean the overall infrastructure which makes accelerated rendering possible. The DRI interface, which is what this section is about, is specific to X. It consists of a handful of X requests by which X clients can request that the X server allows it to carry out accelerated rendering to a particular window. The client asks for a handle for the window, and uses that handle to tell the kernel to draw things, for instance using the 3D engine of the graphics hardware. When it's finished drawing a frame, the client asks the X server to swap the buffers (assuming, say, a double-buffered OpenGL context) so that the contents are visible on the screen.
DRI is just one way to use the underlying DRM framework. For instance, there are other graphics systems (such as Wayland) which also use DRM to access the hardware.
KMS - Kernel Modesetting
There's just one more piece to the puzzle, which is called KMS. This could be the subject of a whole new article, but here's a short overview. Previously, the X driver would directly program the hardware, just as it had to program the command queue engine itself. With KMS, it can ask the kernel to set a certain display resolution, colour depth, or whatever. At the same time, the X driver can send the kernel its handle for a memory buffer which should be used as the contents of the screen. Since the kernel is in complete control of the actual programming of the hardware, it can switch back in the case of, say, a kernel panic or X server crash.
Conclusion
This mostly isn't as complicated as it sounds...! For examples of what programs which use DRM look like, take a look at the Glamo DRI tests. Despite the name, most of these just test DRM, and are independent of the higher-level DRI interfaces.
From: https://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
How DRI and DRM Work的更多相关文章
- AM335x(TQ335x)学习笔记——LCD驱动移植
TI的LCD控制器驱动是非常完善的,共通的地方已经由驱动封装好了,与按键一样,我们可以通过DTS配置完成LCD的显示.下面,我们来讨论下使用DTS方式配置内核完成LCD驱动的思路. (1)初步分析 由 ...
- 如何理解显示卡的驱动模块(DDX,DRM,DRI,XVMC)
如何理解显示卡的驱动模块(DDX,DRM,DRI,XVMC) 1)DDX是什么 DDX是X服务器的2D驱动模块,例如via_drv.so. 2D的显示加速,包括xvideo也是由它负责. 它会初始化硬 ...
- Linux中的DRM
如果在搜索引擎离搜索 DRM 映入眼帘的尽是Digital Rights Managemen,也就是数字版权加密保护技术.这当然不是我们想要的解释.在类unix世界中还有一个DRM即The Direc ...
- 【原创】Linux环境下的图形系统和AMD R600显卡编程(2)——Framebuffer、DRM、EXA和Mesa简介【转】
转自:http://www.cnblogs.com/shoemaker/p/linux_graphics02.html 1. Framebuffer Framebuffer驱动提供基本的显示,fram ...
- Linux环境下的图形系统和AMD R600显卡编程(2)——Framebuffer、DRM、EXA和Mesa简介
转:https://www.cnblogs.com/shoemaker/p/linux_graphics02.html 1. Framebuffer Framebuffer驱动提供基本的显示,fram ...
- Linux Graphic DRI Wayland 显示子系统
转:https://blog.csdn.net/u013165704/article/details/80709547 1. 前言 上篇文章(Linux graphic subsytem(1)_概述) ...
- 【ARM-Linux开发】DRM学习(一)
http://www.landley.NET/kdocs/htmldocs/drm.html 非常好的一个链接,直接把DRM说的很透.很多API的功能都写全了. Table of Contents 1 ...
- linux DRM/KMS 测试工具 modetest、kmscude、igt-gpu-tools (一)
这里整理几个在学习Linux DRM/KMS中用到的几个工具,modetest.kmscude.igt-gpu-tools. 简介: modetest 是由libdrm提供的测试程序,可以查询显示设备 ...
- linux DRM/KMS 测试工具 modetest、kmscude、igt-gpu-tools (二)
kmscube kmscube is a little demonstration program for how to drive bare metal graphics without a c ...
随机推荐
- Snapshot查询所有快照
今天使用snapshot list这个命令时查询出了所有的表,没注意下面报错: NoMethodError:undefined method '-@' for #<Array:0x54326e9 ...
- Codeforces错题本
为什么我这么菜啊QAQ Codeforces 1364C
- Codeforces Round #633 div2 A~C
A. Filling Diamonds 题意:给你n个菱形方块,问能构成图示形状的有多少种 题解:自己画几个不难发现答案是n 代码: 1 #include <iostream> 2 #in ...
- Codeforces Round #654 (Div. 2) B. Magical Calendar (结论)
题意:你需要在长度从\(1\)~\(k\),宽度无限的网格图中造图形(每个点四周必须连通),问最多能造出多少种不同的图形. 题解:感觉没什么好说的,就是画图找规律,如果\(r\ge n\)的话(即没有 ...
- 002、Python中json字符串与字典转换
1.测试用例文件TestCase.xlsx 2.编写Python文件进行读取 #!/usr/bin/env python # -*- coding:utf-8 -*- import time impo ...
- np.random.randint()的返回值
返回的是数组而非int 比如返回x,y 为[1][2] 而非1,2 容易在只有一维一列时没有意识到 其他函数的返回值也要注意
- Leetcode(26)-删除排序数组中的重复项
给定一个排序数组,你需要在原地删除重复出现的元素,使得每个元素只出现一次,返回移除后数组的新长度. 不要使用额外的数组空间,你必须在原地修改输入数组并在使用 O(1) 额外空间的条件下完成. 我们利用 ...
- _.shuffle、_.debounce中下划线对象的理解
Vue 官方教程中有_.shuffle._.debounce,不明白"_"是怎么来的,有什么意义? Lodash 和 Underscorejs 都有相关解释
- bzoj5312 冒险(吉司机线段树)题解
题意: 已知\(n\)个数字,进行以下操作: \(1.\)区间\([L,R]\) 按位与\(x\) \(2.\)区间\([L,R]\) 按位或\(x\) \(3.\)区间\([L,R]\) 询问最大值 ...
- mssql数据库提权(xp_cmdshell)
1.关于 "xp_cmdshell" "存储过程":其实质就是一个"集合",那么是什么样的结合呢,就是存储在SqlServer中预先定义好的 ...