Confira !!
A Microsoft está trabalhando em seu próprio compositor Wayland, derivado da base de código Weston.
Após o anúncio de ontem da conferência virtual BUILD 2020 sobre aceleração de GPU e o suporte a aplicativos de GUI chegando ao WSL2 , a Microsoft foi rápida em detalhar seus planos de aceleração de GPU / DirectX para WSL2 e até publicar o seu driver de kernel DirectX . Mas eles não estavam tão claros até agora sobre como planejam lidar com o manuseio de aplicativos da GUI no WSL2.
O suporte ao aplicativo WSL2 GUI ainda contará com o driver do kernel DXGKRNL para se comunicar com o host via Hyper-V, mas eles não detalharam imediatamente como a apresentação do aplicativo seria tratada principalmente no lado Linux, como se eles estivessem escrevendo seu próprio X Server, como a Apple fazia anteriormente para o macOS ou alguma outra abordagem. Acontece que, graças aos comentários dos desenvolvedores, agora sabemos que eles estão realmente trabalhando em seu próprio compositor Wayland como parte da pilha de apresentações.
A explicação rápida é que a Microsoft usará seu próprio compositor Wayland com uma configuração RDP (Remote Desktop Protocol) glorificada para mostrar os aplicativos na área de trabalho do Windows. O engenheiro da Microsoft, Steve Pronovost, ofereceu as primeiras informações sobre seus planos de apresentação em Wayland via a discussão nesta lista de discussão :
Em termos de apresentação, preciso esclarecer algumas coisas. Anunciamos hoje que também estamos adicionando suporte para aplicativos GUI do Linux. A maneira como isso funcionará é aproximadamente a seguinte. Estamos escrevendo um compositor de Wayland que fará a ponte sobre o RDP-RAIL (RAIL = Aplicativo Remoto Integrado Localmente). Estamos começando a partir de uma base de Weston. Weston já possui um RDP Backend, mas isso é para um esquema completo de comunicação remota na área de trabalho. Weston desenha uma área de trabalho e a remota através de RDP ... e então você pode espreitar essa área de trabalho usando um cliente rdp no lado do Windows. RAIL funciona de maneira diferente. Nesse caso, nosso compositor wayland não pinta mais uma área de trabalho ... em vez disso, simplesmente encaminha o visual / wl_surface individual pelo canal RDP RAIL, para que esse visual possa ser exibido na área de trabalho do Windows. O cliente RDP cria uma janela proxy para cada um desses visuais de nível superior e seu conteúdo é preenchido com os dados provenientes do canal RDP. Todos os pixels pertencem ao servidor RDP / WSL ... portanto, essas janelas parecem diferentes da janela nativa, pois são pintadas e temáticas pelo WSL. A janela do proxy no host coleta entradas e injeta novamente no RDP ... É basicamente assim que o sistema de comunicação remota de aplicativos funciona no Windows e tudo isso é documentado publicamente como parte das várias especificações do protocolo RDP. Por uma questão de fato, para o servidor RDP no lado Weston, estamos analisando continuar utilizando o FreeRDP (e fornecendo correções / aprimoramentos conforme necessário ao projeto público). Além disso, estamos buscando melhorias adicionais nesse caminho para evitar a necessidade de copiar o conteúdo pelo canal RAIL e, em vez disso, apenas compartilhar / trocar buffer entre o convidado e o host. Temos extensão para o protocolo RDP, chamado VAIL (aplicativo virtualizado integrado localmente), que faz isso hoje. Hoje, isso é usado apenas no Windows no Windows para cenários muito específicos. Estamos pensando em estender o protocolo RDP público com essa extensão VAIL para torná-lo um protocolo oficial suportado pela Microsoft, o que nos permitiria segmentar isso na WSL. Terminamos de projetar esta peça em detalhes. Nosso objetivo seria alavancar algo na linha de wl_drm, dma-buf, dma-fence, etc ... Esse compositor e toda a nossa contribuição para o FreeRDP serão totalmente de código aberto, incluindo o nosso documento de design. Ainda não sabemos ao certo se isso será oferecido como um projeto separado, completamente diferente da raiz de Weston ... ou se proporemos uma extensão ao Weston para operar nesse modo.
Além dos detalhes de Wayland, Steve mencionou que pelo menos internamente eles discutiam a possibilidade de oferecer suporte ao DirectX no Linux fora do escopo do Windows / WSL2:
Consideramos a possibilidade de levar o DX ao Linux sem um cabo Windows conectado. Não estou pronto para discutir isso no momento ... mas, na hipótese de fazer isso, o DX estaria em execução no DRI / DRM no Linux nativo. Provavelmente estaríamos contribuindo com algumas alterações no DRM para tratar da área de divergência e obter um mapeamento melhor para o driver do modo de usuário, mas não tentaríamos colocar o sapato / dev / dxg na imagem. Nesse mundo hipotético, teríamos essencialmente o DX de destino do DRM no Linux nativo e o DX continuaria no DXG no WSL para compartilhar a GPU com o host.
Tempos interessantes pela frente ...
Fonte
Até a próxima !!
Nenhum comentário:
Postar um comentário