- Este artigo se concentra no desenvolvimento do driver de GPU de kernel para Linux mais moderno, Tyr, desenvolvido em Rust, e no princípio de funcionamento de drivers de GPU
- Na criação de drivers de GPU, explica-se a distinção de papéis e a interação entre UMD (User Mode Driver) e KMD (Kernel Mode Driver) por meio do exemplo VkCube
- A UMD converte APIs de alto nível em comandos de baixo nível compreensíveis pela GPU, enquanto o KMD é responsável por funções centrais, como alocação de memória, escalonamento de trabalhos e inicialização do dispositivo
- A API fornecida pelo driver Tyr é a mesma do Panthor e inclui consulta de dispositivo, gerenciamento de memória, gerenciamento de grupos, submissão de trabalhos e gerenciamento do heap de Tiler, entre outros
- No próximo texto, serão tratados a arquitetura de hardware Arm CSF e seus componentes principais (como a MCU), além do processo de inicialização
Introdução: desenvolvimento de driver de kernel GPU moderno baseado em Rust
- Este artigo é o segundo da série de desenvolvimento do driver de kernel GPU Tyr, de ponta para GPUs Arm Mali baseadas em CSF no Linux
- Como exemplo prático, escolheu-se o VkCube, um programa simples de 3D que renderiza um cubo giratório usando a Vulkan API, para explicar como funciona o interior de um driver de GPU
- A estrutura simples do VkCube é adequada para estudar os princípios de funcionamento de drivers de GPU
Fundamentos de driver de GPU: função e estrutura de UMD e KMD
- É composto por User Mode Driver (UMD) e Kernel Mode Driver (KMD)
- UMD: implementa APIs de programas comuns, como panvk (driver Vulkan do Mesa)
- KMD: como Tyr, é o driver privilegiado em nível de kernel do hardware e opera como parte do kernel do Linux
- O driver de GPU em modo kernel faz a ponte entre a UMD e a GPU real; a UMD interpreta comandos de API e os converte em conjuntos de comandos entendíveis pelo hardware
- A UMD prepara dados necessários para montar a cena, como geometria, textura e shaders, e solicita ao KMD a alocação desses dados na memória da GPU antes da execução
- Shader é um programa independente que roda na GPU; no VkCube, ele é responsável por posicionar o cubo, aplicar cores e implementar a rotação. A execução do shader depende de dados externos (geometria, cor, matriz de rotação etc.)
- A UMD envia os comandos preparados (por exemplo, VkCommandBuffers) ao KMD para execução e, ao concluir, recebe a notificação para gravar o resultado na memória
Principais responsabilidades do KMD (Kernel Mode Driver)
- Alocação e mapeamento da memória da GPU (fornecendo isolamento por aplicação)
- Submissão de tarefas para as filas de hardware e notificação ao usuário no momento de conclusão
- Em ambientes de hardware assíncrono e paralelo, o gerenciamento de dependências é essencial, e para garantir resultados corretos o KMD desempenha o papel de escalonamento e validação de dependências
- Também inclui inicialização do dispositivo, operação de reguladores de clock/tensão, execução de código de inicialização e gerenciamento da rotação de acesso para que múltiplos clientes compartilhem o hardware de forma justa
Onde está a complexidade: divisão de trabalho entre UMD e KMD
- A complexidade do driver de GPU está concentrada principalmente na UMD
- UMD: converte comandos de API de alto nível em comandos de hardware
- KMD: oferece funcionalidades essenciais para a UMD operar corretamente, como isolamento de memória, compartilhamento e acesso justo
Estrutura da interface de driver (API) fornecida pelo Tyr
- A API do driver Tyr (= igual ao Panthor) pode ser dividida em 5 grupos principais
- Consulta de informações do dispositivo: DEV_QUERY (consulta de informações de hardware da GPU via IOCTL, uso da área ROM)
- Alocação e isolamento de memória: VM_CREATE, VM_BIND, VM_DESTROY, VM_GET_STATE, BO_CREATE, BO_MMAP_OFFSET
- Gerenciamento de grupos de escalonamento: GROUP_CREATE, GROUP_DESTROY, GROUP_GET_STATE (detalhes serão abordados em artigo futuro)
- Submissão de trabalhos: GROUP_SUBMIT (pedido de execução da GPU por meio de command buffers do dispositivo)
- Gerenciamento de heap de Tiler: TILER_HEAP_CREATE, TILER_HEAP_DESTROY (atende requisitos de memória para GPUs de renderização por tiling)
- Essas APIs ficam distantes das operações de desenho de imagem em si; a UMD é quem executa os comandos reais, enquanto o KMD disponibiliza apenas esta interface para acesso ao hardware
Conclusão e próximos passos
- Neste texto, examinamos a estrutura e o fluxo interno geral de drivers de GPU e as principais APIs fornecidas pelo Tyr
- Com base nesse conteúdo, nos próximos textos da série serão tratados a arquitetura de hardware Arm CSF, o microcontrolador (MCU) e demais componentes centrais, além do processo de inicialização do driver
Ainda não há comentários.