- A partir do OBS Studio 32.0.0 para macOS, foi adicionado experimentalmente um backend de renderização baseado em Apple Metal, com o objetivo de melhorar desempenho e eficiência em relação ao OpenGL existente
- Metal é uma API projetada para baixo overhead e para refletir arquiteturas modernas de GPU, e o OBS modificou de forma fundamental sua maneira de interagir com a GPU para oferecer suporte a isso
- Como o renderizador existente do OBS era estruturado em torno do Direct3D, o backend Metal exigiu um grande trabalho de compatibilidade em áreas como conversão de shaders e gerenciamento de recursos
- Em especial, a implementação inclui a complexa lógica de converter shaders HLSL para MSL em tempo real e simular dentro do Metal o comportamento de
map/unmap do Direct3D
- O backend Metal ainda está em fase “experimental”, mas representa um importante ponto de virada para o ambiente de desenvolvimento no macOS, com desempenho superior ao OpenGL, uma estrutura de código mais segura baseada em Swift e suporte a preview EDR
Visão geral da adoção do renderizador Metal
- A partir do OBS Studio 32.0.0, o macOS passa a oferecer experimentalmente um renderizador baseado na API gráfica Metal
- Como alternativa ao backend OpenGL existente, ele busca melhorar desempenho e eficiência
- O Metal é uma API moderna que muda de forma fundamental a interação com a GPU, e o OBS ajustou sua estrutura interna para isso
- O backend Metal aparece marcado como “Experimental”, e há alguns problemas e limitações já conhecidos
- O renderizador OpenGL continua sendo o padrão, e os usuários podem testar manualmente a versão em Metal
- Desenvolvedores com experiência em Metal são incentivados a participar com feedback e Pull Requests
Contexto do Metal e sua filosofia de design
- A Apple apresentou o Metal pela primeira vez em 2014 para iPhone e o expandiu para Mac em 2015
- Na época, o Metal foi uma das primeiras APIs gráficas de nova geração a oferecer suporte a GPUs Intel, AMD e NVIDIA
- O Metal combina conceitos do Mantle da AMD com OpenGL e Direct3D, mas foi redesenhado com remoção de elementos legados
- Com uma API baseada em Objective-C e Swift, oferece uma estrutura familiar para desenvolvedores de iOS e macOS
- Também fornece suporte integrado, dentro do Xcode, para depuração de shaders e análise de GPU
Diferenças de design da API e adaptação do renderizador do OBS
- OpenGL e Direct3D, no modelo antigo, tratavam automaticamente de gerenciamento de recursos e sincronização,
enquanto APIs modernas como Metal exigem que o desenvolvedor gerencie isso diretamente
- As novas APIs tratam a GPU como um dispositivo de processamento baseado em filas paralelas de comandos, com estados de pipeline geridos como objetos imutáveis
- Como o renderizador existente do OBS foi projetado de acordo com a forma de funcionamento do Direct3D,
foi necessário implementar uma camada de compatibilidade no nível do backend para suportar Metal
Estrutura do renderizador do OBS e problemas de compatibilidade com Metal
- O OBS usa backends específicos por plataforma: Direct3D (Windows) e OpenGL (Linux/macOS)
- O núcleo do renderizador é independente da API, mas existem algumas premissas centradas em Direct3D
- Principais limitações
- Os shaders são escritos com base em HLSL, então precisam ser convertidos em tempo de execução
- Há uso de variáveis globais, suposições de execução sequencial e tratamento de texturas no estilo Direct3D
- A renderização de preview depende do modelo de descarte (“discard model”) do DXGI
Conversão de shaders (Transpiling Shaders)
- Os arquivos de efeito do OBS são escritos em HLSL e convertidos conforme cada API
- Para o suporte a Metal, foi adicionado um conversor de HLSL → MSL
- Principais diferenças
- O MSL exige separação das structs de entrada e saída e não oferece suporte a variáveis globais
- Todos os dados uniform devem ser passados por buffers de GPU, exigindo passagem explícita como argumentos de função
- Na chamada de funções, a verificação de tipos e de assinaturas é rigorosa
- O conversor reescreve parcialmente o código dos shaders em tempo de execução para adequá-lo às regras do MSL
- Por exemplo, variáveis
uniform de HLSL são convertidas em constant buffer no MSL
- Também há inserção automática de lógica de conversão de tipos, como
int3 → uint2 + uint
Simulação do comportamento do Direct3D
- O renderizador do OBS foi projetado assumindo o comportamento de
map/unmap do Direct3D
- Como o Metal não oferece essa sincronização automática, foi preciso implementá-la diretamente no backend
- Forma de funcionamento no backend Metal
- Na escrita, cria-se um buffer de GPU compartilhado diretamente com a memória da CPU
- No
unmap, um comando de blit da GPU é agendado para copiar os dados para a textura
- Na leitura, o buffer de GPU também é compartilhado, mas conflitos são evitados com sincronização explícita
- Na prática, isso recria dentro do Metal os recursos de rastreamento de recursos e sincronização do Direct3D
Problema de renderização de preview e solução temporária
- A Metal Layer do macOS, ao contrário do DXGI, não permite que o app exiba frames de forma arbitrária
- O sistema controla a taxa de frames de acordo com ProMotion e modo de baixo consumo
- Como o OBS usa seu próprio loop de renderização, que não coincide com o ciclo de exibição do macOS, ocorre latência no preview
- Solução temporária
- O OBS primeiro renderiza em uma textura virtual, e uma thread separada faz a cópia para a Surface exibida na tela
- Esse processo exige sincronização de GPU e pode gerar discrepâncias entre frames
- A partir do macOS 14, espera-se um desafio adicional por causa dos temporizadores independentes por janela
O custo oculto das APIs gráficas modernas
- O desenvolvimento do backend Metal exigiu meses de pesquisa e iterações de design
- Isso demonstra, na prática, por que transições como OpenGL→Vulkan e D3D11→D3D12 podem causar queda de desempenho
- Em APIs modernas, tarefas antes feitas pelo driver agora precisam ser executadas diretamente pela aplicação
- Isso exige entendimento profundo do funcionamento da GPU e das dependências entre comandos
- Embora o backend Metal reintroduza parte do overhead, ele oferece vantagens como
- Desempenho equivalente ou superior ao OpenGL
- Ferramentas poderosas de análise, como depuração de shaders e texturas
- Uma estrutura de código mais segura baseada em Swift
- Suporte a preview EDR, permitindo processamento de vídeo de alta qualidade
- Com os recursos de análise integrados ao Xcode, a eficiência de manutenção do OBS no macOS melhora,
e os desenvolvedores pedem feedback para uma futura migração do Metal para renderizador padrão
1 comentários
Comentários do Hacker News
Foi um texto realmente muito bom. A explicação de como os shaders são processados foi impressionante
Fiquei me perguntando se, para fazer shaders de plugins de terceiros funcionarem em vários backends, esse processo realmente precisa ser assim, ou se ficou desse jeito por causa da manutenção da retrocompatibilidade
Do ponto de vista da equipe principal, pode até ser fácil dizer para desenvolvedores externos “escrevam em cada linguagem de shader”, mas, na prática, isso não é desejável
Todo mundo acha isso ineficiente, mas, na prática, não há alternativa
O título da matéria esconde o ponto principal
Deveria ser algo como “OBS Studio adota um novo renderizador: o processo de adoção do Metal”
Isso mostra claramente o preço de a Apple ter criado uma API para proteger seu próprio ecossistema, em vez de adotar Vulkan
O OBS Studio adicionou suporte a Vulkan em março de 2020, na versão 25.0. Já se passaram 5 anos e meio
Em ambientes embarcados, o foco ainda continua sendo OpenGL ES
Não sou especialista nesse tema. Entendi só uns 5% do que li, mas gostaria que houvesse mais textos com esse tipo de explicação técnica detalhada
Comunicados simples parecem marketing
Pessoalmente, estou mais animado com o futuro suporte a VST3, mas essa novidade também é bem-vinda
É muito mais fácil do que configurar codificação por hardware em um SoC da Rockchip
Achei interessante a explicação de que o Metal leva adiante a abordagem orientada a objetos do Direct3D, combinando isso com o design de API “verboso” do Objective-C e do Swift
É surpreendente que uma API de gráficos 3D em nível de sistema operacional possa ser feita com essa base em linguagem dinâmica
Imagino que isso seja possível graças às otimizações de
objc_msgSend()Vulkan/Metal/DirectX 12 enviam vários comandos por meio de command buffers, em vez de depender de chamadas individuais
No começo dos anos 2000 havia livros sobre usar Direct3D com C#, e isso mudou a percepção de que gráficos de alto desempenho em linguagens com GC seriam inviáveis
O ponto central é minimizar o overhead de runtime com uma estrutura em lote que referencia buffers pré-alocados
Depois do Cocoa, a maior parte passou a ser escrita em um subconjunto restrito de C++ (por exemplo, IOKit)
Espero que as APIs modernas de GPU sejam uma fase de transição rumo a algo mais simples
Tenho uma relação de amor e ódio com OpenGL, mas, depois de usar as APIs novas, passei até a sentir falta da simplicidade dele
Fiquei curioso se o Metal vai melhorar o desempenho também nos Macs antigos com Intel, ou se é uma otimização exclusiva para a série M
Mas o Metal 3 ainda é suportado em vários Macs com Intel, então fica a dúvida de por que limitaram assim
Eu estava pensando em montar um equipamento de streaming com um Mac Mini
Queria saber se, com esse ganho de desempenho, isso já seria viável o suficiente
Para jogos 2D estilo arcade ou tela de desenvolvimento, não deve haver problema
Para jogos AAA recentes, o melhor é usar uma placa de captura para receber a imagem do PC
Lá por 2017 era difícil fazer streaming com macOS, mas hoje, com a série M, já é suficiente
Com essa melhoria, a expectativa é de ainda mais eficiência
Eu queria que a Apple investisse mais recursos para aumentar os casos de sucesso externos do Metal
Fora do ambiente interno da Apple, o Metal ainda não teve grande sucesso