Estamos nos aproximando rapidamente do aniversário de dois anos do lançamento do OpenGL 4.6 e parece que os drivers Intel/RadeonSI podem estar perto da última revisão mais importante da API gráfica.
Como já falamos, os drivers do Mesa foram suspensos no suporte do OpenGL 4.6 devido ao suporte de ingestão do SPIR-V exigido por esta versão de julho de 2017 da especificação OpenGL. Embora existam os drivers Intel e Radeon AdVr Vulkan já com o apoio SPIR-V que é central para Vulkan, é levado muito tempo re-instalação dos drivers OpenGL para as necessidades de ARB_gl_spirv. Então, novamente, não há muitos grandes jogos OpenGL exigindo a versão 4.6 da especificação, mesmo com seus benefícios de interoperabilidade graças ao SPIR-V.
Tem havido os patches do OpenGL 4.6/SPIR-V na lista de discussão e o Gitlab para revisão há um bom tempo. No entanto, pouca ação foi dada. Porém, agora um desenvolvedor de código aberto da Valve, Timothy Arceri, fundiu uma versão refinada de um dos patches que faz parte da solicitação de mesclagem ARB_gl_spirv. Este código reestrutura alguns dos códigos de linkers do Mesa GLSL, de modo que é muito limpo, embora não seja ligado em nenhum dos novos bits SPIR-V.
A esperança é que os drivers Intel e RadeonSI possam alcançar o OpenGL 4.6 na mainline Mesa antes do aniversário de dois anos em 31 de julho. Isso colocaria o suporte ao OpenGL 4.6 para o lançamento do Mesa 19.2, que deve sair no final de agosto.
GNU Binutils começa a aterrar no suporte eBPF
O GNU Binutils está finalmente sendo conectado ao BPF Estendido (eBPF) como a moderna máquina virtual no kernel que estende o Berkeley Packet Filter além do subsistema de rede.
Compilar para o eBPF tem sido feito mais comumente pelo backend LLVM eBPF para permitir a compilação de C no bytecode do eBPF, mas parece que os desenvolvedores de ferramentas de GNU estão procurando aumentar seu suporte em torno dos casos de uso cada vez mais comuns do eBPF VM.
Detalhes adicionais podem ser encontrados dentro dos commits do GNU Binutils eBPF aqui, antes do lançamento do Binutils 2.33 no final do ano.
Arm SVE2 para o GCC 10, LLVM Clang 9.0
Dados os benefícios significativos de desempenho para a Scalable Vector Extension 2 (SVE2) da Arm, eles estão trabalhando para garantir que os códigos-fonte do compilador Linux de código aberto suportem essas novas instruções da CPU antes do envio de SoCs que suportam essa grande adição.
A Arm anunciou Scalable Vector Extension 2 (SVE2) como seu mais novo avanço em torno da programação SIMD e aumentando o paralelismo de dados nos programas. O SVE2 foi projetado para oferecer melhor desempenho de SIMD do que suas extensões de Neon de longa data. Além disso, serve para escalar o desempenho com aumentos de comprimento de vetor, além de permitir técnicas de autovetorização. Mais detalhes neste post no SVE2.
Semelhante às Extensões de Memória Transacional que estão sendo inseridas nos compiladores, a Arm também está trabalhando para trazer o suporte da SVE2 dentro dos compiladores de código aberto para garantir sua disponibilidade para os desenvolvedores que trabalham no suporte de hardware da próxima geração da Arm.
A partir desta semana, o código de desenvolvimento do GCC 10 agora tem os sinalizadores SVE2 para habilitar as instruções principais do SVE2. Esse código do GCC também habilita o suporte para a extensão SVE original que foi segmentada apenas para fins do HPC do braço.
Ao mesmo tempo, o LLVM/Clang está tendo muitos commits em torno da habilitação do SVE2.
É bom ver esse código imediatamente. O suporte a SVE2 em LLVM/Clang está lá para a versão 9.0 que deve ser lançado em setembro. O suporte ao GNU Compiler Collection estará no GCC10 que não deve ser lançado até seu tempo normal no final do primeiro trimestre/início do segundo trimestre do próximo ano. Neste ponto ainda não parece haver nenhuma comunicação pública sobre quando os primeiros núcleos/SoCs serão habilitados para SVE2 serão lançados.
