Confira !!
Na terça-feira, foi o grande anúncio da Microsoft trazendo o Direct3D 12 para Linux / WSL2 no contexto de permitir que aplicativos GUI e GPU computassem no Windows Subsystem for Linux . Isso também significa suporte ao OpenCL / OpenGL / Vulkan, convertendo-o em consumo de D3D12 pelo sistema Windows host. Embora a Microsoft tenha postado rapidamente as correções para o driver do kernel "dxgkrnl" para esta implementação do Direct3D, ela já está enfrentando resistência e será uma batalha difícil para ser mantida.
O driver do kernel DXGKRNL para Linux fica entre as bibliotecas proprietárias da Microsoft, a serem publicadas, Direct3D 12, que ficam no espaço de usuário do Linux e o sistema host que receberá as instruções. DXGKRNL se comunica com o sistema host via Microsoft Hyper-V.
Com a Microsoft mantendo suas bibliotecas Direct3D 12 Linux de código-fonte fechado, isso imediatamente criou algum atrito, sem surpresas, enquanto eles tentavam fazer upstream de seu driver de kernel Linux de código-fonte aberto. Da perspectiva do Direct Rendering Manager (DRM), eles normalmente não permitem drivers / recursos no kernel que dependem exclusivamente de um cliente proprietário no espaço do usuário, como é o caso aqui. Portanto, se eles estão tentando jogar bem com o DRM upstream, isso causa imediatamente problemas com as bibliotecas de espaço do usuário do Direct3D 12 que não são de código aberto.
O desenvolvedor de código aberto da Intel Daniel Vetter, que ajuda a supervisionar o subsistema DRM, apontou imediatamente vários problemas, incluindo o espaço do usuário de código fechado. Entre os problemas levantados por Vetter está o fato de o driver do kernel do DirectX "reinventar o mundo" ao mudar a enumeração de dispositivos e muitas outras interfaces / recursos já suportados de maneira comum pelos drivers DRM upstream. Também existem questões sobre o quão bem isso se integra a outros recursos comuns do Linux, como o DMA-BUF.
O mantenedor de DRM David Airlie também foi rápido em caracterizar isso como um driver que conecta uma interface de blob binário no Windows a um blob binário em convidados Linux. Ele, pessoalmente, vê pouco valor em ter esse driver atualizado e levantou preocupações sobre como esse driver finalmente lidará com os bits de apresentação planejados para a exibição de aplicativos da GUI do Linux no WSL2. Ele também levantou a possibilidade desse desembarque no kernel do Linux como parte dos drivers Microsoft Hyper-V, e não na área de drivers DRM.
Airlie também afirmou que ele nem gosta da idéia de revisar esse código DXGKRNL de código aberto, já que a implementação de interfaces proprietárias da Microsoft poderia potencialmente prejudicá-lo legalmente no desenvolvimento de novas interfaces gráficas.
Portanto, veremos para onde isso vai, mas não espere que o driver do kernel do DXGKRNL DirectX seja atualizado no futuro imediato.
Aqueles que desejam acompanhar as discussões podem fazê-lo através deste tópico da lista de discussão do kernel .
Fonte
Até a próxima !!
Nenhum comentário:
Postar um comentário