Confira!!
Com o Vulkan 1.1 , deveria ser tecnicamente possível escrever um compositor do wayland do driver / fornecedor agnóstico usando o Vulkan graças às novas extensões do núcleo.
Voltando dois anos foi pedido de recurso # 294 sobre as extensões do lado do compositor Wayland para Vulkan, basicamente tentando escrever um backend de compositor Vulkan. Esse pedido de recurso foi fechado hoje, como acontece com o Vulkan 1.1, é tecnicamente possível, mas ainda temos que ver alguém tentar esse feito.
James Jones, da equipe de motorista da NVIDIA, que também esteve envolvido na proposta de alocação de memória de dispositivos EGLStreams e Unix da empresa, escreveu o seguinte sobre esse pedido de recurso hoje (:
As extensões de objetos externos Vulkan (memória externa, semáforos externos e cercas externas) agora fazem parte da especificação Vulkan 1.1. Eles permitem a implementação de todos os mecanismos / extensões Vulkan WSI no topo do núcleo do Vulkan + as partes específicas do OS de objetos externos (por exemplo, VK_KHR_external_memory_fd). Em outras palavras, se alguém estivesse tão inclinado, eles poderiam escrever um vendedor completo e agnóstico do país, um compositor de wayland e um cliente WSI vulcânico de wayland, além de APIs Vulkan 1.1. O suporte a VK_KHR_display seria necessário para obter realmente um compositor de wayland para exibir em um monitor / saída. A integração WSI poderia ser implementada como uma camada implícita Vulkan, de modo que sua presença seria invisível para aplicativos e se pareceria com qualquer outra implementação WSI Vulkan wayland. Assim sendo,
Meu trabalho para projetar e protótipo de novos mecanismos de alocação para Linux e outros sistemas POSIX ou POSIX (código hospedado em https://github.com/cubanismo/allocator como mencionado acima) está fora do escopo de Vulkan e esse problema, porém poderia ser útil para um compositor do wayland que faz uso do Vulkan para gráficos e / ou exibição. O trabalho adicional de outros para integrar melhor os mecanismos de memória externa Vulkan com construções nativas do Linux, como dma-bufs e modificadores do formato DRM, está em andamento e grande parte do progresso que pode ser rastreado publicamente nas listas de discussão dri-devel ou mesa-dev em freedesktop.org.
O colaborador de drivers de gráficos de código aberto de longa data eo líder de gráficos Collabora, Daniel Stone, tocaram com algumas adições:
No backend, deve ser possível usar o GBM como alocadores de buffer como alternativa à VK_KHR_display, como um caminho de transição mais fácil para compositores usando EGL / GBM / KMS. (Ou, se você estiver executando aninhado, você pode, naturalmente, continuar a usar as extensões Swapchain Wayland / X11 WSI).
No lado do compositor, você vai querer implementar a interface Wayland zwp_linux_dmabuf_v1, usando esta nova extensão Vulkan para importar os buffers resultantes para fazer a textura deles. Para os drivers baseados em Mesa, isso permitirá que os clientes que usam as extensões da Swapchain Wayland WSI funcionem; Para os drivers proprietários da NVIDIA, você precisaria suportar os caminhos EGLStreams.
O trabalho mais recente sobre modificadores é o VK_EXT_image_drm_format_modifier do @chadversary, que permite a propaganda e a importação de buffers com modificadores, semelhantes aos EGL_EXT_image_dma_buf_import_modifiers.
Existe uma extensão de Wayland zwp_linux_explicit_synchronization_v1 proposta que permite a troca de FDs de dma-fence (que você poderia exportar do semáforo de sinal de renderização do cliente e importar para usar como um semáforo de espera para texturização de compositores), mas a implementação para isso ainda não foi mesclada.
Será interessante ver se / quando alguém tenta escrever um compositor puro do Wayland usando as modernas extensões Vulkan.
Mas para aqueles que esperam que ele esclareça magicamente o estado de confusão do suporte do driver para compositores Wayland com GBM vs. EGLStreams, etc., é improvável que seja corrigido em breve. Escrever este compositor do Wayland Vulkan-powered seria ótimo para as últimas gerações de hardware GPU, mas ainda não funcionaria bem para pré-Broadwell, pré-Kepler, processadores gráficos pré-GCN sem Vulkan ... O significado que você ainda precisaria pelo menos, um caminho de código secundário para o suporte existente do compositor Wayland. Aqueles que estiveram contra o apoio de EGLStreams em seus compositores Wayland basearam seus argumentos contra ele na necessidade de suportar múltiplos caminhos de código: até que as GPUs habilitadas por Vulkan possam ser assumidas em todos os lugares (ainda vários anos fora), eles ainda estarão na situação de ter para suportar vários back-ends. De qualquer forma,
Fonte
Até a próxima!!
Nenhum comentário:
Postar um comentário