Implementando gráficos 2D de alto desempenho na CPU com renderização baseada em sparse strips [pdf]

• Apresenta uma abordagem que utiliza a estrutura de sparse strips para aumentar a eficiência na renderização de gráficos 2D baseada em CPU
• Estudo focado em estruturas de dados e métodos de processamento para viabilizar renderização de alto desempenho na CPU em vez de GPU
• Por meio de uma representação esparsa de dados, reduz o uso de memória e garante alta velocidade de renderização mesmo em cenas complexas
• Projeto que melhora a eficiência do processamento paralelo e o aproveitamento de cache em comparação com métodos tradicionais de renderização em CPU
• Pesquisa que mostra a possibilidade de implementar gráficos 2D de alta qualidade usando apenas a CPU

---

Visão geral da pesquisa

• Este artigo tem como objetivo a renderização de gráficos 2D de alto desempenho na CPU e explora formas de reduzir a dependência de GPU
• O conceito central é uma estrutura de dados chamada sparse strips, que armazena de forma eficiente apenas as partes necessárias em vez de dados contínuos por pixel
• Com essa estrutura, alcança redução do custo de acesso à memória e melhoria da velocidade de renderização

Estrutura de sparse strips

• Um strip representa uma faixa contínua de pixels em uma imagem 2D, e no formato sparse armazena apenas as partes necessárias
• Esse método é especialmente eficiente em imagens com muitos espaços vazios ou gráficos vetoriais complexos
• Em comparação com a renderização tradicional baseada em buffer completo, oferece redução no uso de memória e melhor eficiência de cache

Desempenho e implementação

• Utiliza instruções SIMD e multithreading da CPU para maximizar o desempenho do processamento paralelo
• Os resultados experimentais mostram que é possível processar a mesma cena com desempenho em nível de renderização em tempo real mesmo sem GPU
• A implementação foi escrita em C++ e testada em várias resoluções e níveis de complexidade de cena

Possibilidades de aplicação

• Pode ser usado em ambientes centrados em CPU, como renderização de UI, motores de gráficos vetoriais e pipelines 2D de engines de jogos
• Também pode oferecer suporte a processamento gráfico 2D de alto desempenho em sistemas embarcados ou ambientes de servidor com GPU limitada

Conclusão

• A abordagem baseada em sparse strips comprova a redução de gargalos na renderização por CPU e a melhoria da eficiência de memória
• Apresenta potencial como um modelo alternativo às arquiteturas de processamento gráfico dependentes de GPU
• Para números adicionais ou dados comparativos, é necessário consultar o texto do PDF

[GN⁺]

Comentários no Hacker News

• A estrutura struct Strip definida no artigo parece ter tamanho de 64 bits (8 bytes), mas no texto está escrito que uma strip tem 64 bytes
  Fazendo as contas, o tamanho real parece ser algo como 259×8 + 7296 ≈ 9KB. Parece que há alguma unidade errada

  • Sou o autor. Sim, foi um erro por confundir bits e bytes. Agradeço por apontar isso
  • Não tive tempo de analisar todo o código, mas o artigo tem uma seção sobre multithreading
    Pode ser só um erro de digitação, mas também é possível que cada strip tenha sido alocada em unidades de linha de cache (64 bytes).
    Isso evitaria false sharing, então o renderizador pode ter feito isso de propósito
  • Pensei a mesma coisa. Nesse parágrafo, o uso de memória parece ter sido superestimado.
    O artigo focou principalmente na comparação de tempo de execução e não tratou da comparação de espaço de armazenamento

• Vale a pena ver também Blaze: Parallel Rasterization on CPU

  • Obrigado pela informação. Eu não conhecia esse projeto, e os números de benchmark são bem impressionantes
  • A demo é surpreendentemente rápida

• O projeto é interessante. Pela seção 3.9, a saída é em formato de bitmap, então no fim parece que seria preciso copiar a imagem para a GPU
  Como o Skia está migrando para WebGPU e o WebGPU oferece suporte a compute shaders, a impressão é que gráficos 2D estão cada vez mais perto de serem um problema resolvido em termos de portabilidade e desempenho
  Ainda assim, há casos em que um renderizador em CPU continua útil — por exemplo, na web é preciso compilar shaders em tempo de execução quando a página carrega
  Em teoria, também daria para começar com um renderizador em CPU, como um JIT de JS, e trocar para o shader de GPU quando ele ficasse pronto
  Outra vantagem é o tamanho do binário, que fica menor. O WebGPU (baseado em dawn) é bastante grande
  Link de referência

  • Isso, a saída é bitmap e precisa ser enviada para a GPU.
    Em um projeto maior, também existe uma versão chamada Vello Hybrid, que faz a geometria na CPU e a pintura dos pixels na GPU
    A ideia de usar o renderizador em CPU durante a compilação dos shaders também foi considerada, mas ainda não foi implementada
  • Um caso em que o renderizador em CPU é especialmente útil é em test runners. Quando a saída é uma imagem ou screenshot, não há necessidade de copiar nada para a GPU
    Na verdade, se renderizar na GPU, depois ainda é preciso copiar a imagem de volta, o que é ineficiente
  • Em uma arquitetura de memória unificada (por exemplo, Apple Silicon), não é necessário copiar para a GPU. Como a mesma memória é compartilhada, o custo é quase zero

• Recentemente escrevi código para renderizar trajetórias N-body de alta precisão com milhões de vértices,
  e fiquei curioso se a implementação, na GPU, da representação RLE proposta neste artigo funcionaria bem sem perder a simplicidade
  Vídeo de demonstração

• Interessante. Gostaria de ver o desempenho em um único núcleo dos renderizadores comparados.
  Acho que isso mostraria a eficiência do código. Renderizadores populares podem ser mais lentos, mas usar menos CPU

  • O artigo tem uma seção de comparação de desempenho em núcleo único
    Também dá para ver resultados no benchmark oficial do Blend2D ou
    no vello_chart que eu fiz incluindo renderizadores adicionais

• Será que um dos orientadores, Raph Levien, é o autor da antiga biblioteca Libart?

• Um pouco fora do tópico, mas fiquei curioso sobre desde quando a pré-visualização de PDF no GitHub passou a carregar só algumas páginas
  Acho que era melhor como antes, quando carregava o PDF inteiro de uma vez e o navegador fazia a renderização

• Fiquei curioso se existe algum benchmark para validar a correção (correctness) do renderizador

  • A Cornell box foi criada originalmente para esse tipo de objetivo
    A ideia é medir a radiosidade de uma cena real e comparar com o resultado da simulação
    Em renderização em tempo real, às vezes também se usa renderizadores offline como Arnold ou Octane como referência de comparação
    Cornell box na Wikipédia
  • Depende do que se quer dizer com “correção”
    Não existe renderizador que reproduza a realidade de forma perfeita; todos assumem algum nível de trade-off