Início / unix / Perguntas / 725954
Accepted
Bram
Asked: 2022-11-23 12:35:56 +0800 CST

Numeração de nó de renderização DRM

  • 772

Por que os nós de renderização DRM começam /dev/dri/renderD<X>sua numeração a partir de 128 enquanto as interfaces privilegiadas /dev/dri/card<X>começam em zero?

$ ls -al /dev/dri/
total 0
drwxr-xr-x   3 root root        100 Nov 21 07:46 .
drwxr-xr-x  23 root root       6040 Nov 22 11:09 ..
drwxr-xr-x   2 root root         80 Nov 21 07:46 by-path
crw-rw----+  1 root video  226,   0 Nov 21 07:46 card0
crw-rw----+  1 root render 226, 128 Nov 21 07:46 renderD128
linux

1 respostas

  1. Best Answer

    A interface DRI privilegiada veio primeiro, e um número de dispositivo principal fixo 226 foi inicialmente alocado exclusivamente para eles .

    Como os dispositivos ARM e o desenvolvimento de dispositivos de computação GPGPU provaram que a configuração do modo de exibição e a renderização precisam ser acessíveis como dispositivos separados, nós de renderização foram desenvolvidos . Parece que os números de dispositivos menores de 128 para cima foram atribuídos a eles, embora eu não tenha encontrado rapidamente nenhuma documentação afirmando isso explicitamente.

    O código que atribui os números dos dispositivos começa na drm_dev_init()função in drivers/gpu/drm/drm_drv.cno código-fonte do kernel. A partir da linha 631 ele chama a drm_minor_allocfunção no mesmo arquivo:

    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;

    Ele chama o idr_alloc()in lib/idr.c:

    r = idr_alloc(&drm_minors_idr,
          NULL,
          64 * type,
          64 * (type + 1),
          GFP_NOWAIT);

    Os parâmetros para idr_alloc()são:

    * 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.

    Se o driver oferecer suporte ao DRIVER_RENDERrecurso e, portanto, nós de renderização, idr_allocserá chamado duas vezes para alocar primeiro o nó de renderização e, em seguida, o nó primário. Caso contrário, apenas o nó primário é alocado.

    As DRM_MINOR_*constantes são definidas em include/drm/drm_file.h:

    /* Note that the order of this enum is ABI (it determines
 * /dev/dri/renderD* numbers).
 */
enum drm_minor_type {
    DRM_MINOR_PRIMARY,
    DRM_MINOR_CONTROL,
    DRM_MINOR_RENDER,
};

    Como este é um enum, DRM_MINOR_PRIMARYobtém um valor de 0, DRM_MINOR_CONTROLtem um valor de 1 e DRM_MINOR_RENDER2, respectivamente.

    Isso funciona para alocar números de dispositivos secundários no intervalo 0 <= x < 64 para nós de interface primários, 64 <= x < 128 para nós DRM_MINOR_CONTROL (o que quer que eles possam ser... parece atualmente não utilizado em kernels 6.0.x?) e 128 <= x < 192 para nós DRM_MINOR_RENDER.

    O nome sysfs para o dispositivo é atribuído na drivers/gpu/drm/drm_sysfs.cfunção drm_sysfs_minor_alloc(), simplesmente usando o número do dispositivo secundário como parte do nome:

    if (minor->type == DRM_MINOR_RENDER)
    minor_str = "renderD%d";
else
    minor_str = "card%d";

[...]

r = dev_set_name(kdev, minor_str, minor->index);

    E, a menos que udevregras sejam usadas para modificar o nome do dispositivo padrão, o nome sysfs também se torna o nome do nó do dispositivo.

    Então, basicamente, é porque ninguém até agora se preocupou em adicionar uma cláusula de condição que subtrairia 128 do número do nó do dispositivo secundário ao atribuir o nome do dispositivo padrão se for um nó de renderização.

    Além disso, observe que este artigo de blog de desenvolvimento de DRM de 2013 diz:

    Também é importante saber que os nós de renderização  não estão vinculados a um cartão específico. Embora internamente seja criado pelo mesmo driver do nó legado, o espaço do usuário nunca deve assumir qualquer conexão entre um nó de renderização e um nó legado/de configuração de modo. Em vez disso, se o espaço do usuário exigir aceleração de hardware, ele deve abrir  qualquer  nó e usá-lo.

    [...]

    Perguntas como “como faço para encontrar o nó de renderização de um determinado cartão?” não faz sentido. Sim, o espaço de usuário específico do driver pode descobrir se e qual nó de renderização foi criado por qual driver, mas o espaço de usuário não específico do driver nunca deve fazer isso!

    Dada essa intenção, a escolha de iniciar deliberadamente a numeração dos nós de renderização a partir de 128 (para quebrar a suposição potencialmente falsa de que card0e renderD0sempre se referiria ao mesmo cartão) pode fazer sentido.

    • 1

relate perguntas