DRM中render-node编号的分配
DRM系统
DRM是direct rendering manager的简称。DRM是linux kernel中与负责video cards功能的GPU打交道的子系统。DRM给出了一组API，可以供用户程序来发送命令和数据给GPU设备从而来控制比如display、render等功能。
render-node由来
在以前，DRM子系统中给每个DRM device注册的device-node就是：/dev/dri/cardX ，通过该节点来作mode-setting和rendering的控制。后来发现这么做有问题：
-
mode-setting和rendering是通过同一个文件节点node来控制的
-
单卡的mode-setting资源不能在多个graphics-servers之间切分使用
-
在多cards之间共享display-controller实现过于复杂
然后就有了一些改进来解决这些问题。最终是mode-setting 和 render节点分家。
render node
render-node架构大概是2009年左右提出来的。站在用户程序角度来看，render node的作用是用来加速computing和rendering，render node可以通过 /dev/dri/renderDX 被访问，并且提供了基本的DRM rendering interface。与 /dev/dri/cardX 节点相比，/dev/dri/renderDX 少了一些特性：
-
没有mode-setting（KMS）ioctls功能
-
用dma-buf替换掉gem-flink（非安全的）
-
不再需要DRM-auth认证
-
不再支持pre-KMS DRM-API
这样一来，当应用程序需要hardware-acclerated rendering、访问GPGPU、offscreen rendering等时，就不需要通过DRI或者wl_drm来访问graphics-server，而是直接打开某个render node就开始使用即可。对于render node的访问权限控制则通过标注的file-system modes来控制了。
render-node并没有提供新的API，它们只是将原有的DRM-API分出了一部分到一个新的device-node，原来的node也保留了下来用于如mode-setting等控制。
render-node也没有和任何一个card进行绑定，它是由原有node的同一个driver创建的，所以尝试在原有node和render-node之间进行connect连接通信没有意义。当应用程序需要和graphics-server进行通信时，可以通过dma-buf。
mode-setting node
虽然从原有的node中分离出一个render-node，简化了应用程序的访问，但对于mode-setting程序的访问没有简化。当一个graphics-server想要编程一个display-controller时，它需要是给定card的DRM-Master，可以通过drmSetMaster()接口来获得身份，但同时只能有一个DRM-Master，而且必须是由CAP_SYS_ADMIN特权的程序才能成为DRM-Master，这会带来问题：
-
不能以非root权限运行XServer
-
不能在同一个card上使用两个不同的XServer来控制两个不同的独立的显示器
首先想到的解决办法就是分离出mode-setting node，类似render-node的方式，/dev/dri/modesetD1 和 /dev/dri/modesetD2 节点，来分割KMS CRTC和Connector资源。
另一种方法是将所有的mode-setting资源绑定到一个DRM-Master对象，然后谁要访问mode-setting资源就可以通过访问该DRM-Master对象来实现。
DRM infrastructure
不管是render-node还是mode-setting-node，在kernel角度是如何体现的？
如果hardware没有display-controller，则可以不设置DRIVER_MODESET flag只设置DRIVER_RENDER flag，这样内核DRM只会创建render-node。如果一个hardware只有display-controller而没有rendering hardware，可以设置DRIVER_MODESET而不设置DRIVER_RENDER。
大概回顾了下render node的由来。那么render node由kernel来负责创建，其编号为何从128开始，答案估计还要到kernel中寻找。
drm_dev_init
linux kernel中 drivers/gpu/drm/drm_drv.c中定义了drm_dev_init()函数，其中创建drm设备编号的代码如下
if (drm_core_check_feature(dev, DRIVER_COMPUTE_ACCEL)) {
ret = drm_minor_alloc(dev, DRM_MINOR_ACCEL);
if (ret)
goto err;
} else {
if (drm_core_check_feature(dev, DRIVER_RENDER)) {
ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
if (ret)
goto err;
}
ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
if (ret)
goto err;
}
涉及到两个枚举类型结构体
enum drm_driver_feature {
DRIVER_GEM = BIT(0),
DRIVER_MODESET = BIT(1),
DRIVER_RENDER = BIT(3),
DRIVER_ATOMIC = BIT(4),
DRIVER_SYNCOBJ = BIT(5),
DRIVER_SYNCOBJ_TIMELINE = BIT(6),
DRIVER_COMPUTE_ACCEL = BIT(7),
DRIVER_USE_AGP = BIT(25),
DRIVER_LEGACY = BIT(26),
DRIVER_PCI_DMA = BIT(27),
DRIVER_SG = BIT(28),
DRIVER_HAVE_DMA = BIT(29),
DRIVER_HAVE_IRQ = BIT(30),
};
enum drm_minor_type {
DRM_MINOR_PRIMARY,
DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
DRM_MINOR_ACCEL = 32,
};
当drm core检查到device设置了DRIVER_RENDER标签时，就通过drm_minor_alloc(dev, DRM_MINOR_RENDER)来分配ID，而drm_minor_alloc()函数中最终分配ID是通过idr_alloc()函数来实现，这里的type传入的就是DRM_MINOR_RENDER，也就是2。
r = idr_alloc(&drm_minors_idr,
NULL,
64 * type,
64 * (type + 1),
GFP_NOWAIT);
//idr_alloc又是调用idr_alloc_u32来实现
int idr_alloc(struct idr *idr, void *ptr, int start, int end, gfp_t gfp)
{
u32 id = start;
int ret;
if (WARN_ON_ONCE(start < 0))
return -EINVAL;
ret = idr_alloc_u32(idr, ptr, &id, end > 0 ? end - 1 : INT_MAX, gfp);
if (ret)
return ret;
return id;
}
EXPORT_SYMBOL_GPL(idr_alloc);
* idr_alloc() - Allocate an ID.
* @idr: IDR handle.
* @ptr: Pointer to be associated with the new ID.
* @start: The minimum ID (inclusive).
* @end: The maximum ID (exclusive).
* @gfp: Memory allocation flags.
idr_alloc()的底3个参数就是ID的start，第4个参数是ID范围的end。所以，对于DRIVER_RENDER属性的device来说，其ID范围是
DRM_MINOR_RENDER * 64 = 128 至 （DRM_MINOR_RENDER + 1) * 64 = 192 之间。
所以才有renderD128、renderD129。
内核如何管理render-node的编号
问题：DRM中如何做到一个已经分配了的ID比如128，下一个device来分配时就不使用128而是129呢？换句话说kernel中如何记忆ID的分配结果的？
int idr_alloc_u32(struct idr *idr, void *ptr, u32 *nextid,
unsigned long max, gfp_t gfp)
{
struct radix_tree_iter iter;
void __rcu **slot;
unsigned int base = idr->idr_base;
unsigned int id = *nextid;
if (WARN_ON_ONCE(!(idr->idr_rt.xa_flags & ROOT_IS_IDR)))
idr->idr_rt.xa_flags |= IDR_RT_MARKER;
id = (id < base) ? 0 : id - base;
radix_tree_iter_init(&iter, id);
slot = idr_get_free(&idr->idr_rt, &iter, gfp, max - base);
if (IS_ERR(slot))
return PTR_ERR(slot);
*nextid = iter.index + base;
/* there is a memory barrier inside radix_tree_iter_replace() */
radix_tree_iter_replace(&idr->idr_rt, &iter, slot, ptr);
radix_tree_iter_tag_clear(&idr->idr_rt, &iter, IDR_FREE);
return 0;
}
EXPORT_SYMBOL_GPL(idr_alloc_u32);
这里使用了基数树（radix-tree）。
两个显卡其分配render-node的顺序
比如我这个pc上有两个显卡intel UHD Graphics 630和Nvidia GTX 1050 Ti，然后/dev/dri/下也有两个render-node，renderD128和renderD129，内核分配它们的顺序是如何确定的？
应该是扫描PCI设备的时候就确定顺序了。
ubuntu上查看哪个card和哪个GPU绑定：
drm_info #该命令可以查看/dev/dri/card0对应的GPU驱动
比如我这里两个显卡，card0对应intel 630， card1对应nvidia GTX 1050Ti。
那么如何确定render node和GPU对应关系？
ls /sys/class/drm/card0/device/drm/
#可以看到card0中有card0, controlD64, renderD128
ls /sys/class/drm/card1/device/drm/
#可以看到card1中有card1, controlD65, renderD129
参考：
DRM render node number