Vulkan: Buffers uniformes versus constantes push para dados estáticos


8

Estou meio que lutando para entender a diferença conceitual entre buffers uniformes e constantes push. Pelo que consigo entender lendo as especificações, as principais diferenças são:

  1. Buffers uniformes podem ser muito maiores que constantes push.
  2. UBOs usam std140, PCs usam std430.
  3. Os UBOs podem ser atualizados a qualquer momento com vkCmdUpdateBuffer (ou mapeamento de host) e mantêm seus valores, caso contrário, os PCs precisam ser pressionados novamente para cada passagem de renderização. (O que me surpreendeu - com base no nome. Pensei em literalmente atualizar constantes no pipeline no local e fazer com que essas alterações persistissem)

No meu cenário, tenho cerca de ~ 200 bytes de dados que espero que sejam constantes . Ou seja, vou alterá-los com pouca frequência. Seria melhor (assumindo o tamanho permitido) usar constantes push, mesmo que eu tenha que reenviá-las em todos os buffers de comando? Ou seria melhor usar um UBO de 200 bytes e atualizá-lo apenas com frequência com vkCmdUpdatebuffer?

Além disso. e se eu tiver, por exemplo, um float random_seedque atualizarei toda vez que o shader for executado? Supondo que eu já possua uma UBO, seria melhor agrupá-la com a UBO, mesmo que o restante da UBO seja constante, ou eu obteria um benefício ao usar constantes push para especificamente essa variável, para evitar evitar vkCmdUpdateBuffer antes de cada passagem de renderização?


Bem-vindo ao site do Computer Graphics Stack Exchange! Não estou familiarizado com o Vulkan, mas parece que usar um UBO seria mais eficiente no seu caso (você pode tentar comparar o desempenho de ambas as abordagens em um programa de amostra). Com quais APIs gráficas você está familiarizado? Você também pode se interessar por esta apresentação do GDC 2012: Não jogue tudo fora: Gerenciamento eficiente de buffer
wip

Da documentação da Vulkan : enquanto um UBO aloca um bloco de memória de vídeo na GPU (que pode ser atualizada posteriormente), o Push Constant não usa memória de vídeo (é por isso que deve ser fornecida durante cada chamada de empate / cálculo, caso contrário, o sombreador não saberia qual valor usar). Eu acho que ele é armazenado em outra área de armazenamento rápido e de curto prazo na GPU, embora os detalhes possam depender do fornecedor da GPU.
wip

Respostas:


8

Os UBOs podem ser atualizados a qualquer momento com vkCmdUpdateBuffer

Na especificação: "vkCmdUpdateBuffer é permitido apenas fora de um passe de renderização". Portanto, "a qualquer momento" não é o caso.

Mesmo que tenha sido permitido dentro de um passe de renderização, ainda é uma operação de transferência. O que significa que você precisa sincronizar a transferência de memória com os comandos que a utilizam. O que diminui o desempenho.

Para o geral Push Constant vs. Uniform, use seu julgamento. Por "julgamento", quero dizer, apenas observe como eles funcionam. As constantes push permitem que você altere seus dados a qualquer momento sem realizar processos pesados, como operações de memória, sincronização ou alteração do estado do descritor. Claramente, eles servem para alterar dados com frequência. Com que frequência é "frequentemente"? Bem, isso é um julgamento.

Caso contrário, analise a diferença de desempenho.


2

Eu tenho cerca de ~ 200 bytes de dados que eu espero que sejam principalmente constantes. Ou seja, vou alterá-los com pouca frequência.

Se os dados não forem alterados com frequência, você poderá usar constantes de especialização . Eles são definidos quando o pipeline é criado, e um novo pipeline deve ser criado se você precisar alterar os valores. Para um evento não frequente, como o redimensionamento de uma janela, esse pode ser um custo aceitável.

e se eu tiver, por exemplo, um float random_seed que atualizarei toda vez que o shader for executado?

Esse é um caso de uso perfeito para constantes de envio. Você pode manter todos os outros dados na UBO (ou nas constantes de especialização) e alterar esse valor com VkCmdPushConstants.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.