Otimizar conteúdo compactado com DirectStorage e XBTC

Use este tópico para entender cenários selecionados de descompactação da nova API DirectStorage no Microsoft Game Development Kit, bem como a XBOX Texture Compression Tool (XBTC) usada para ingerir conteúdo para esses cenários. O objetivo é fornecer orientações para ajudar você a obter resultados ideais com base nos requisitos de cada título.

Conteúdo

Aviso de isenção de responsabilidade
Introdução
Arquitetura
Memory Decompression Unit
Empacotamento de dados para a MDU
Tiling de texturas e Sampler Feedback Streaming (SFS)
Limites do pool de memória das operações do DirectStorage
XBOX Texture Compression Tool (XBTC.exe)
Considerações para obter o desempenho ideal

Aviso de isenção de responsabilidade

As medições de desempenho neste tópico foram feitas com o GDK de junho de 2020 e a recuperação correspondente, usando Development Kits fornecidos como parte da atualização de hardware iniciada em julho de 2020. Todas as medições foram feitas a partir de XVCs empacotados instalados no console no modo de unidade de varejo. Espera-se que medições feitas com implantações de arquivos soltos (Loose file) sejam um pouco menores, porque a unidade de desenvolvimento pode ter fragmentação de dados e não pode usar algumas das otimizações de desempenho existentes para XVCs somente leitura. Medições de consoles que não estão definidos para o modo de unidade de varejo têm características de desempenho diferentes. Todos os números fornecidos neste tópico usam a notação padrão do setor para diferenciar números de Base 10 e Base 2. Números de Base 2 usam a notação kibibyte (KiB) ou mebibyte (MiB). Números de Base 10 usam o prefixo SI, kilobyte (KB) ou megabyte (MB), conforme mostrado nos exemplos a seguir.

1 MB == 1.000.000 bytes
1 MiB == 1.048.576 bytes

Introdução

Este tópico aborda como usar a XBOX Texture Compression Tool (XBTC) e a Memory Decompression Unit (MDU) por meio da API DirectStorage, incluindo práticas recomendadas para obter o máximo desempenho. Como pré-requisito para este tópico, você deve primeiro ler o tópico Uso e detalhes internos do DirectStorage, que aborda as características subjacentes de taxa de transferência de E/S do SSD NVMe. A MDU nos consoles XBOX Series tem vários estágios e dá suporte a várias operações sobre os mesmos dados. Ela pode ser usada isoladamente para fazer descompactação em memória ou, mais comumente, dentro do pipeline de E/S do DirectStorage para descompactar o conteúdo de forma transparente à medida que ele é carregado do armazenamento. A MDU foi projetada para que sua taxa de transferência exceda a taxa total de E/S do NVMe de 2 GB/s de bytes compactados provenientes do armazenamento.

Arquitetura

O DirectStorage foi arquitetado para obter a maior largura de banda com a menor sobrecarga de CPU. Ele opera em lotes de solicitações em um modelo de pipeline, conforme mostrado na figura 1 da seção Memory Decompression Unit deste tópico. Para obter mais informações sobre a arquitetura subjacente de todo o sistema, confira Uso e detalhes internos do DirectStorage. O DirectStorage está diretamente vinculado à Memory Decompression Unit (MDU), de modo que você também pode transferir todas as tarefas de descompactação da CPU com o mínimo de esforço. A MDU opera usando um pool intermediário de memória compartilhado por todos os cenários do DirectStorage, gravando os resultados diretamente no buffer de destino fornecido pelo título. Cada solicitação do DirectStorage é enfileirada com metadados sobre como o fluxo de dados deve ser tratado ao passar pela MDU. Para usar essa funcionalidade, os recursos devem ser empacotados de modo que fluxos de dados individuais, e os metadados que os descrevem, possam ser carregados em solicitações discretas do DirectStorage. Depois que os metadados de fluxo de um ativo são carregados, os fluxos de dados individuais são descompactados de forma transparente como parte das solicitações de E/S ao SSD NVMe, com base nas opções associadas a cada solicitação. Em situações em que um fluxo de dados foi carregado por um método alternativo, como uma solicitação de rede, a descompactação pode ocorrer entre buffers especificados por um título usando um tipo alternativo de fila e de solicitação do DirectStorage. Para o cenário principal de texturas, que compõem a maior parte dos ativos de um título, a ferramenta XBTC facilita a compactação e o empacotamento de ativos para descompactação em tempo de execução.

Memory Decompression Unit

A Memory Decompression Unit (MDU) é composta por dois módulos de hardware individuais, cada um com três estágios de operação, conforme mostrado na figura 1. Cada módulo de hardware tem uma velocidade máxima de leitura de 1,6 GB/s e uma taxa de saída de 4 GB/s, de modo que a taxa de transferência combinada (3,2 GB/s de entrada e 8 GB/s de saída) excede a taxa de 2 GB/s que o NVMe consegue sustentar. Isso significa que, em cenários típicos, a MDU também pode atender solicitações de descompactação em memória, mesmo que já esteja saturando a E/S do SSD NVMe. A taxa de transferência real que um título pode atingir depende da taxa de compactação do conteúdo, de como ele é empacotado, do padrão de acesso e do uso específico da API DirectStorage. Os números de taxa de transferência anteriores (3,2 GB/s de entrada e 8 GB/s de saída) representam os limites práticos para conteúdo real, na presença de outras operações de E/S. Ao usar a MDU para descompactar páginas perfeitamente compactáveis como uma forma de memset, o limite absoluto é de 12 GB/s de saída para a memória. O exemplo SimpleMDU demonstra os comportamentos de taxa de transferência. Figura 1. Mostra os três estágios de operação da MDU, incluindo descompactação zlib, BCPack e Swizzle block; eles são compartilhados entre todas as filas do DirectStorage

Captura de tela da divisão dos três estágios da MDU

As três operações podem ser feitas em sequência sem redução de velocidade, e os resultados são armazenados diretamente na memória do título especificada no objeto de solicitação enfileirado. Qualquer estágio pode ser ignorado, dependendo de DSTORAGE_REQUEST_OPTIONS. Recursos que não são texturas normalmente consomem apenas o primeiro estágio zlib e são gravados diretamente na memória do título. Recursos de textura podem usar qualquer combinação dos três estágios, com os resultados gravados na memória do título. Leituras não compactadas ignoram todos os estágios, mas ainda são movidas para a memória do título pela MDU.

Estágio zlib da MDU

Você pode descompactar fluxos de dados em conformidade com IETF RFC 1950 usando o primeiro estágio da MDU, também conhecido como compactação zlib ou Deflate. Os consoles XBOX Series dão suporte ao tamanho completo de janela de 32 KiB previsto na especificação e não têm a limitação de 4 KiB que existia na família de consoles XBOX One. Existem duas variações em relação à especificação. Primeiro, há um requisito de que o tamanho compactado seja menor que o tamanho descompactado. Se você tiver um fluxo de dados que se expande para um tamanho igual ou maior por causa da compactação aplicada, ele deverá ser empacotado como dados não compactados. As ferramentas e os caminhos de carregamento do título devem ser capazes de identificar segmentos de dados compactados e não compactados. Segundo, há um limite superior para o tamanho do fluxo de dados descompactado, baseado nos tamanhos de reserva de memória feitos em nome do título (32 MiB). Para habilitar este estágio da MDU para um determinado fluxo de dados, o sinalizador a seguir deve ser definido em DSTORAGE_REQUEST::Options. UINT64 DSTORAGE_REQUEST_OPTIONS::ZlibDecompress:1 Além disso, se zlib for aplicado sobre BCPack em um fluxo de dados, DSTORAGE_REQUEST::IntermediateSize deverá ser definido como o tamanho esperado do fluxo de dados após a descompactação zlib e antes da descompactação BCPack. Caso contrário, IntermediateSize deve ser deixado como zero. Ao analisar e carregar arquivos XBTC, a presença de compactação zlib em um fluxo é indicada quando seu XBTC_STREAM_INFO tem um InflatedSize diferente de seu CompressedSize. O código a seguir do arquivo TiledTexture.cpp no exemplo SimpleSFS demonstra isso.

for (UINT x = 0; x < TilingInfo[mip].WidthInTiles; x++)
{
    auto tileInfo = xbtcFile.GetStreamInfo(tileIndex);
    Tiles[tileIndex].LoadSize = tileInfo->CompressedSize;
    Tiles[tileIndex].OffsetInFile = baseOffset + tileInfo->RelativeOffset;
    Tiles[tileIndex].Coord = { x, y, 0, mip };
    Tiles[tileIndex].ZlibCompressed = (tileInfo->CompressedSize != tileInfo->InflatedSize);   //  <<---
    Tiles[tileIndex].BCPacked = (tileInfo->UncompressedSize != tileInfo->InflatedSize);

    auto parentTileX = x >> 1;
    auto parentTileY = y >> 1;
    Tiles[tileIndex].pParentTile = GetTile(parentTileX, parentTileY, mip + 1);

    tileIndex++;

    // Tiles are required to be 64 KB.
    assert(tileInfo->UncompressedSize == D3D12_TILED_RESOURCE_TILE_SIZE_IN_BYTES);
}

Estágio BCPack da MDU

BCPack é um novo algoritmo de compactação de texturas da Microsoft que tem como alvo específico os formatos de textura de GPU compactados em blocos (BC1-7) e entende os padrões nativos de swizzle de textura dos consoles XBOX Series. Há um conjunto de caminhos de codificação e decodificação específicos para cada formato compactado em blocos. Para cada fluxo compactado, o tipo ou a ausência de um codificador deve ser conhecido e especificado no momento da solicitação de descompactação. O BCPack é habilitado, e o decodificador específico é selecionado para uma determinada DSTORAGE_REQUEST, por meio da definição da opção a seguir.

Ao combinar com a compactação zlib, IntermediateSize deve ser definido. Caso contrário, ele é deixado como zero.

DSTORAGE_BCPACK_MODE DSTORAGE_REQUEST_OPTIONS::BcpackMode: 4  
enum DSTORAGE_BCPACK_MODE : UINT64 {  
    DSTORAGE_BCPACK_MODE_NONE = 0,
    DSTORAGE_BCPACK_MODE_BC1  = 1,  
    DSTORAGE_BCPACK_MODE_BC2  = 2,  
    DSTORAGE_BCPACK_MODE_BC3  = 3,  
    DSTORAGE_BCPACK_MODE_BC4  = 4,  
    DSTORAGE_BCPACK_MODE_BC5  = 5,  
    DSTORAGE_BCPACK_MODE_BC6H = 6,  
    DSTORAGE_BCPACK_MODE_BC7  = 7,  
};

Ao analisar e carregar arquivos XBTC, a presença de compactação zlib em um fluxo é indicada quando seu XBTC_STREAM_INFO tem um InflatedSize diferente de seu UncompressedSize. Isso também é demonstrado no exemplo de código SimpleSFS anterior.

Estágio Swizzle Block da MDU

O estágio Swizzle Block pode fornecer transformações adicionais aos dados descompactados à medida que são gravados na memória do título. A partir do GDK de março de 2024, há vários modos disponíveis projetados para permitir reduções adicionais no tamanho compactado de BC1, BC3, BC4 e BC5 quando usados em conjunto com Deflate ou BCPack. Confira Formatos de embaralhamento do DirectStorage para obter informações sobre esses formatos. O swizzle é controlado pelo código a seguir. Ele deve ser definido como DSTORAGE_SWIZZLE_MODE_NONE (0) se os formatos de embaralhamento especializados não forem usados. DSTORAGE_SWIZZLE_MODE DSTORAGE_REQUEST_OPTIONS::SwizzleMode: 16 Se você tiver um cenário que acredita se beneficiar de transformações adicionais de swizzle de texels após a descompactação e que não seja coberto pelas opções atuais, entre em contato com seu gerente de conta da Microsoft.

Empacotamento de dados para a MDU

Ao criar fluxos de dados para descompactação pelo hardware da MDU, há dois caminhos principais: compactação somente Deflate, destinada principalmente a recursos que não são texturas, e compactação Deflate mais BCPack, destinada a recursos de textura. No primeiro cenário, você é livre para escolher os tamanhos de fluxo de dados que melhor atendem às suas necessidades, enquanto o segundo cenário predefine os tamanhos dos fluxos compactados. Em ambos os cenários, existem os mesmos requisitos básicos. Assim como em outras solicitações ao SSD NVMe, os fluxos de dados devem estar alinhados a 16 bytes. A MDU também dá suporte a um conjunto limitado de opções de swizzle ou embaralhamento que funcionam em conjunto com Deflate e BCPack. Confira Formatos de embaralhamento do DirectStorage para obter informações sobre esses formatos.

Tiling de texturas e Sampler Feedback Streaming (SFS)

O tiling de texturas é um método de dividir texturas grandes em pequenas subseções que podem ser carregadas individualmente. Às vezes, isso também é chamado de Partially Resident Textures (PRT), Virtual Textures ou Tiled Resources. Somente as partes das texturas necessárias são carregadas com o tiling de texturas e, assim, os títulos podem usar a memória disponível com mais eficiência, tendo um número maior de recursos de textura em uso a qualquer momento. Os consoles XBOX Series têm extensões de hardware na GPU para tornar a implementação desse sistema mais fácil e eficiente em tempo de execução. Esse sistema combinado é conhecido como Sampler Feedback Streaming (SFS). Os consoles XBOX Series usam tamanhos de página de 64 KiB para recursos gráficos, que é o tamanho dos padrões nativos de swizzle de textura mais comuns ao otimizar o conteúdo para o layout nativo da GPU. O principal objetivo do SFS é garantir que seu título receba a maior quantidade de recursos gráficos usados ativamente, não mantendo as partes não utilizadas desses recursos na memória residente. Portanto, 64 KiB foi selecionado como o tamanho base do SFS, porque cada página de 64 KiB em uma textura é independente e pode ser carregada e descartada isoladamente. Esse é o uso de memória mais granular e eficiente. Para obter mais informações sobre layouts de textura, confira Sampler Feedback Streaming e Layouts de textura do XBOX Series X|S (novo). Para ilustrar a relação entre tiles de textura e SFS, considere uma textura BC7 quadrada de 2048 × 2048. Ela é composta pelos 86 tiles a seguir (64 KiB cada). BC7 requer 16 bytes por bloco de 4 × 4 texels e, portanto, mip0 requer (2048 × 2048) = 4.194.304 bytes = 4.096 KiB = 64 páginas de 64 KiB cada. Cada mip além de mip0 tem um quarto do tamanho, ou faz parte da cauda de mips (mip tail), conforme mostrado na figura 2. Figura 2. Mostra uma textura BC7 de 2048 × 2048, composta por 86 páginas de 64 KiB cada; quando empacotada para SFS, cada página é um tile separado que pode ser transmitido

Captura de tela do layout de textura BC7 de 2K

Qualquer implementação de texturas parcialmente residentes pode trabalhar com qualquer múltiplo inteiro do tamanho base de tile de 64 KiB como a menor ação de carregamento e descarte. Para o SFS, o tamanho base de 64 KiB é usado e, portanto, a textura mencionada anteriormente é processada em 86 fluxos compactados usados para recuperação individual em tempo de execução. Ao decidir como empacotar os ativos do jogo, a compressibilidade varia dependendo da codificação desses recursos, do tamanho do fluxo e do conteúdo de cada recurso. Há dois pools de conteúdo de exemplo, conforme mostrado na figura 3 e na figura 4. Esses gráficos representam o pool de texturas de 4096 × 4096 originalmente fornecido como parte da demonstração HDR e 4K “Insects” do XBOX One X. Cada gráfico mostra esse pool de conteúdo com uma codificação específica (BC1 ou BC7) e, em seguida, empacotado por meio dos cenários a seguir.

Compactação somente Deflate que divide os dados em tamanhos predefinidos e compacta cada um individualmente (zlib ou zopfli)
Compactação Deflate mais BCPack usando XBTC
- Tiling SFS de 64 KB compactado com zlib, ou zopfli mais BCPack
Compactação de mip inteiro para streaming de Level of Detail (LOD) sem SFS, zlib ou zopfli mais BCPack

Figura 3. Mostra o tamanho compactado usando a opção de empacotamento do pool de conteúdo BC7 do Insects HDR 4K

Captura de tela do tamanho compactado usando a opção de empacotamento do pool de conteúdo BC7 do Insects HDR 4K

Figura 4. Mostra o tamanho compactado usando a opção de empacotamento do pool de conteúdo BC1 do Insects HDR 4K

Captura de tela do tamanho compactado usando a opção de empacotamento do pool de conteúdo BC1 do Insects HDR 4K

Ambas as implementações de Deflate (zlib e zopfli) obtêm melhores taxas de compactação à medida que o tamanho dos tiles e blocos compactados individualmente aumenta, mas com retornos decrescentes (tiles maiores são preferíveis). Ambas as opções de Deflate atingem suas taxas máximas de compactação para fluxos de aproximadamente 1.024 KiB, sendo que tamanhos maiores não oferecem nenhuma vantagem nesse aspecto. O zopfli produz taxas de compactação melhores (1 a 2 por cento) que o zlib, mas com um custo computacional de tempo de compactação muito maior (aproximadamente 10 vezes). As opções BCPack mais Deflate disponíveis por meio do XBTC produzem taxas de compactação significativamente maiores do que qualquer opção somente Deflate. Recomendamos fortemente as opções BCPack mais Deflate para recursos de textura.

O empacotamento xbtc-mip é um único fluxo de dados por mip e, portanto, tem um tamanho de fluxo de dados variável. Ele é colocado no tamanho de tile de 4 MiB para comparação, a fim de ajudar a ilustrar que, embora abra mão da vantagem de um tamanho de tile menor e de um uso de memória mais granular, ele não produz melhorias de compactação em relação ao cenário SFS principal.

Requisitos do pool de memória para operações do DirectStorage

Quando o título inicializa o DirectStorage pela primeira vez chamando DStorageGetFactory, 32 MiB de memória são reservados para o Staging Buffer, que contém as operações atualmente em andamento. Esse tamanho padrão pode ser alterado após a inicialização do DirectStorage usando o método SetStagingBuffer, economizando assim memória para o seu título. Essa memória é compartilhada com outros estágios da pilha do DirectStorage. O último estágio em uso para uma solicitação grava a saída final diretamente na memória do título. Veja a seguir as limitações do sistema.

Para solicitações de descompactação, os tamanhos compactados devem ser menores que os tamanhos descompactados.
O limite superior de tamanho para qualquer solicitação individual do DirectStorage é de 1 GiB. Para solicitações de descompactação, essa é a soma dos tamanhos de origem e destino.

Os limites são impostos no momento em que as solicitações são enfileiradas, e comportamentos adicionais de depuração estão disponíveis para essas condições de erro por meio do método SetDebugFlags.

XBOX Texture Compression Tool (XBTC.exe)

Para consoles XBOX Series, você pode importar, exportar e codificar texturas usando a ferramenta XBTC no GDK. Isso é feito por meio de uma interface de linha de comando em XBTC.exe, como uma biblioteca XBTC.dll ou na forma de código-fonte, depois que requisitos adicionais de NDA forem atendidos. O conjunto de ferramentas pode ser encontrado em uma instalação padrão do GDK em *C:\Program Files (x86)\Microsoft GDK[version]\GXDK\bin\Scarlett*. Se você precisar de acesso ao código-fonte do conjunto de ferramentas, entre em contato com seu gerente de conta da Microsoft.

Importação de conteúdo

O XBTC dá suporte à importação direta de uma ampla variedade de formatos, que incluem .png, .tiff e .jpg, e também pode exportar para esses tipos de arquivo. O XBTC contém um codificador para os formatos de GPU BC1-BC7 e pode aplicar swizzle ao conteúdo de ou para os layouts nativos de textura da GPU do XBOX Series X|S. Sempre que o XBTC executa uma operação com perdas, como converter um ativo bruto em um formato compactado em blocos, ele produz métricas de qualidade de imagem para essa conversão. Ao exportar para um arquivo .dds, somente as partes do importador e do codificador BC do XBTC são usadas. A compactação não é aplicada.

Compactação

O XBTC trabalha com uma região de textura selecionada e compacta essa região em um subfluxo dentro de um arquivo maior. Por padrão, ele compactará cada região de três maneiras diferentes (somente Deflate, somente BCPack, BCPack e depois Deflate). O melhor resultado dos três é salvo, junto com os metadados dessa região, e os outros dois são descartados. A forma como uma textura é dividida em regiões depende de como essa textura deve ser usada e das opções --tilemode e --mipstreams passadas ao XBTC.

Seleção de região do SFS

No exemplo de uma textura BC7 quadrada de 2K, o layout de textura subjacente tinha 86 páginas de 64 KiB cada. Há dois métodos de seleção de região, conforme mostrado na figura 5. À esquerda está o modo de tiling SFS, em que cada página é processada separadamente, com a suposição padrão de que todos os mips devem ser transmitidos separadamente. O resultado são 86 regiões separadas. À direita está a mesma textura, mas especificando ao XBTC que apenas um único mip deve poder ser transmitido. Nesse caso, existem 65 fluxos: 64 para mip0 e um fluxo adicional. O fluxo adicional combina todos os outros mips, entendendo-se que os mips não transmissíveis estão sempre residentes na memória. Figura 5. Mostra (à esquerda) texturas BC7 de 2K com tiling SFS de 64 KiB e todos os mips transmissíveis (86 fluxos de tiles) e mostra (à direita) a mesma textura SFS com um mip transmissível (65 fluxos de dados)

Captura de tela de uma textura SFS com todos os mips transmissíveis e com apenas um mip transmissível

Seleção de região sem SFS

Para qualquer conteúdo que não se destina a ser usado em uma configuração de textura virtual SFS, ou que carrega LODs apenas por mip inteiro, os mesmos princípios se aplicam, embora haja menos regiões. Para essa mesma textura BC7 de 2K, usar o modo de tile padrão de 64 KB sem SFS resulta nas cinco regiões mostradas na figura 6 sendo compactadas individualmente. Se você quisesse especificar que apenas dois mips fossem transmissíveis, as três regiões seriam processadas individualmente, com mip2-11 combinados no fluxo sempre residente. Figura 6. Mostra (à esquerda) uma textura BC7 de 2K com tiling de 64 KiB sem SFS e todos os mips transmissíveis (cinco fluxos de dados) e mostra (à direita) a mesma textura com dois mips transmissíveis e um fluxo de dados sempre residente que contém mips2-11

Captura de tela de uma textura sem SFS com todos os mips transmissíveis e com apenas um mip transmissível

Para texturas extremamente grandes, maiores ou iguais a 8K, é possível ter mips que excedem o tamanho máximo (32 MiB) permitido pelo hardware da MDU. Para resolver esse problema, uma versão futura terá opções para dividir mips de textura sem SFS em tiles com tamanho ideal para carregamento sequencial.

Aplicação

Depois de determinar quais regiões da textura são compactadas individualmente e de selecionar uma das implementações de Deflate (pela presença ou ausência da opção --usezopfli), cada região é compactada três vezes. Elas são compactadas uma vez com a implementação de Deflate, uma vez com BCPack e uma vez aplicando ambos. A MDU pode processar qualquer uma dessas combinações (ou conteúdo não compactado) na velocidade total de E/S, de modo que você pode selecionar a melhor codificação para uma determinada região de dados. A estrutura de dados resultante é empacotada em um arquivo XBTC, que é o conjunto de fluxos compactados, junto com um cabeçalho que os descreve. Você pode usar o arquivo como está e usar o código dos exemplos do GDK como base para carregá-lo, ou é possível extrair os fluxos compactados e os metadados para reempacotá-los no contêiner que funcionar melhor. Em tempo de execução, os dados do cabeçalho alimentam diretamente as solicitações do DirectStorage para esse ativo.

Rate Distortion Optimization (RDO)

Você pode trocar qualidade de compactação por uma taxa de compactação adicional usando RDO. No que diz respeito aos formatos compactados em blocos (BC1-7), isso pode ser tão simples quanto recodificar os blocos de uma maneira diferente. Ao recodificar, você pode reduzir o número de pontos de cor discretos existentes, ou forçar pontos de cor a corresponderem aos vizinhos, para que a compactação adicional aplicada à textura alcance taxas maiores. A versão 2006 QFE1 do GDK adicionou opções de RDO ao XBTC para BC1-5, com outros modos chegando em versões futuras. A implementação de RDO no XBTC existe somente no estágio do codificador BC e pode ser usada ao exportar de volta para um arquivo .dds. No entanto, ela foi projetada tendo em mente o compactador BCPack. A aplicação de RDO é mais complexa do que apenas selecionar uma configuração de compactação ou qualidade. Diferentes tipos e codificações de ativos podem ter diferentes configurações ideais de qualidade. As configurações corretas geralmente exigem iterar em um sistema de regras, com verificações pontuais e ajustes, quando necessário. Para facilitar isso, o XBTC tem os subcomandos adicionais compare, view e export. Você pode executar uma análise de qualidade de imagem usando o subcomando compare. Esse subcomando compara o ativo com RDO ao original ou ao ativo BC anterior ao RDO. Você pode usar esses subcomandos para criar várias regras. Por exemplo, uma regra para um determinado título poderia ser que, para normal maps BC1, uma perda de 2 decibéis (dB) de Peak Signal-to-noise Ratio (PSNR) seria permitida. Quando um ativo fosse adicionado ou alterado, uma passagem única precisaria ser concluída para determinar qual nível de qualidade corresponderia a essa perda de qualidade permitida. Você pode carregar o ativo para inspeção usando o subcomando view. Isso facilita a verificação pontual dos ativos processados e a determinação de se são necessárias alterações ou exceções nas regras. Você também pode manter essas informações para builds futuros. Você também pode usar export para exportar a imagem de volta para outro formato para processamento com outras ferramentas.

O RDO altera a taxa de compactação e pode ter outras implicações para o carregamento ideal.

O conteúdo BC1 normalmente é mais compactável que o BC7 (2:1, contra 1,6:1) e, portanto, o tamanho compactado de tiles BC1 de 64 KiB é de aproximadamente 32 KiB, em média. Reduzir o tamanho compactado em mais 25 por cento usando RDO não equivale diretamente a 25 por cento a mais de taxa de transferência para a memória, por causa da sobrecarga de um grande número de pequenas solicitações de E/S. Se você estiver fazendo tiling para tamanhos maiores, a taxa de transferência da MDU escala diretamente com a taxa de compactação. No entanto, o efeito diminui para conteúdo altamente compactável que começa a se aproximar dos limites de saída de 8 GiB/s da MDU. A figura 7 é um exemplo dessa combinação de efeitos, usando as texturas de resolução 4K da demonstração Insects HDR e 4K. Nesse caso, uma configuração de RDO (qualidade e compactação) foi selecionada de modo que os arquivos XBTC resultantes fossem cerca de 14 por cento menores do que as versões padrão sem RDO. Ou mais 7 por cento, se comparados ao tamanho original não compactado. Deve-se observar que o codificador RDO no XBTC organiza preferencialmente os dados para a melhor compactação com BCPack como parte da cadeia de compactação do XBTC. Assim, o cenário SFS apresenta um ganho relativo maior do que ao usar Deflate em um cenário sem SFS, conforme mostrado na figura 7. Figura 7. Mostra o pool de conteúdo Insects HDR 4K, tamanho BC1, comparado com uma opção de RDO

Captura de tela do pool de conteúdo Insects HDR 4K, tamanho BC1, comparado com uma opção de RDO

Em tempo de execução, a combinação desses efeitos resulta nas características de taxa de transferência a seguir. Ao usar o XBTC para o codificador RDO e, em seguida, empacotar em uma forma sem SFS usando tamanhos de fluxo variáveis, observa-se aproximadamente 13 por cento a mais de taxa de transferência para tamanhos maiores (maiores ou iguais a 128 KiB). Essa diferença quase espelha a vantagem de compactação. Tamanhos menores de fluxo de dados (menores ou iguais a 64 KiB) resultam em melhorias decrescentes, conforme mostrado na figura 8. Figura 8. Mostra o pool de conteúdo Insects HDR 4K, BC1, usando a taxa de transferência da MDU comparada com uma opção de RDO

Captura de tela do pool de conteúdo Insects HDR 4K, BC1, usando a taxa de transferência da MDU comparada com uma opção de RDO

Restrições de modo do codificador BC7

O BC7 permite que cada grupo de 4 × 4 texels seja codificado por qualquer um dos 8 modos, dependendo de qual modo preserva a maior fidelidade para esse grupo. Com isso, os codificadores produzem texturas nativas de GPU com qualidade muito alta, mas isso também significa que há um grau maior de entropia nos bits codificados da textura resultante, porque o padrão de codificação muda com frequência entre os modos. Texturas BC7 são inerentemente menos compactáveis do que muitos outros formatos compactados em blocos. O codificador BC7 no XBTC contém opções para limitar os modos disponíveis usados, o que troca diretamente parte da fidelidade mais alta do formato para unificar o padrão codificado e, assim, torná-lo mais compactável. O uso dessas opções pode alterar drasticamente a compressibilidade da textura resultante, embora seja recomendável fazer verificações pontuais e iterar nessas configurações para confirmar que a textura resultante tenha pouca ou nenhuma perda de qualidade perceptível. O pool de dados de texturas 4K da demonstração Insects HDR do XBOX One é mostrado na figura 9. A codificação BC7 normal, com todos os modos habilitados, resulta em um pool de texturas que o Zopfli consegue compactar para 64 por cento de seu tamanho original, ou 61,5 por cento, se combinado com o BCPack usando o XBTC. No entanto, se apenas o Modo 7 for permitido (--bc7modes 0x80), as texturas resultantes serão muito mais compactáveis, excedendo uma taxa de 2:1, enquanto as texturas mantidas terão uma vantagem de 3 a 5 dB de PSNR em relação às mesmas texturas codificadas com BC1 em uma fidelidade menor. Figura 9. Mostra a compressibilidade do pool de conteúdo Insects HDR 4K, BC7 em todos os modos versus somente o Modo 7

Captura de tela da compressibilidade do pool de conteúdo Insects HDR 4K, BC7 em todos os modos versus somente o Modo 7

Essa taxa de compactação adicional se traduz diretamente em maior taxa de transferência para a memória no momento do carregamento. As características de taxa de transferência desse conteúdo BC7 codificado com o padrão (modos 0-7) e com apenas o Modo 7 habilitado são mostradas na figura 10.

A velocidade de leitura do NVMe é praticamente idêntica, com o conteúdo somente Modo 7 apresentando uma vantagem de aproximadamente 20 a 40 por cento na taxa de transferência, medida na saída da MDU.

Figura 10. Mostra a taxa de transferência da MDU do pool de conteúdo Insects HDR 4K, BC7, taxa de transferência da MDU, usando todos os modos versus somente o Modo 7

Captura de tela da taxa de transferência da MDU do pool de conteúdo Insects HDR 4K, BC7, taxa de transferência da MDU, usando todos os modos versus somente o Modo 7

Considerações para obter o desempenho ideal

As diretrizes do tópico Uso e detalhes internos do DirectStorage se aplicam ao usar a MDU para descompactação.

Mantenha solicitações suficientes em andamento para manter o pipeline cheio. Por exemplo, se você estiver adicionando às filas a cada 16,7 ms, 33,4 MB de dados compactados podem ser carregados durante esse intervalo.

Para manter o pipeline cheio entre os intervalos de adição, mantenha 33,4 MB mais 32 MiB de solicitações em andamento. Isso totaliza aproximadamente 64 MiB. No entanto, como a taxa de transferência real do SSD NVMe pode variar ao longo do tempo, e a garantia de 2000 MB/s vale para qualquer período de 250 ms, os títulos devem manter mais do que esse mínimo de 64 MiB em andamento para ajudar a maximizar a taxa de transferência. Veja a seguir outros fatores específicos da natureza da implementação de hardware da MDU.

Para cada trabalho enviado ao hardware da MDU, há um pequeno custo de inicialização e configuração. Evite grandes quantidades de trabalhos pequenos. Na prática, se você estiver tentando se aproximar da taxa de transferência do SSD NVMe, o limite inferior de tamanho para as solicitações é de 32 KiB compactados (64 KiB descompactados).
- No entanto, a taxa de transferência máxima só é alcançada com tamanhos de fluxo de duas a quatro vezes esse tamanho. A taxa de transferência de leitura do conteúdo 4K da demonstração Insects HDR, usando a opção de empacotamento, tem um declínio acentuado para um tamanho não compactado abaixo de 64 KiB, conforme mostrado na figura 11 e na figura 12. Figura 11. Mostra a taxa de transferência de carregamento do pool de conteúdo Insects HDR 4K, BC1, usando a opção de empacotamento Figura 12. Mostra a taxa de transferência de carregamento do conteúdo Insects HDR 4K, BC7, usando a opção de empacotamento
Solicitações grandes, maiores que 512 KiB de dados compactados, são separadas em várias solicitações de E/S e, em seguida, enviadas à MDU como várias solicitações depois que os dados são recuperados do SSD NVMe. Isso tem um efeito pequeno, mas mensurável, na taxa de transferência de solicitações grandes, afetando principalmente os tamanhos de fluxo de dados que, compactados, ficam logo acima desse tamanho limite.
A taxa de compactação escala diretamente a taxa de transferência final de bytes descompactados para a memória do título. O RDO, ou as restrições de modo do BC7, produzem um efeito duplo: tamanho compactado menor e tempos de carregamento mais rápidos. Para obter mais informações e exemplos, confira as seções Restrições de modo do codificador BC7 e RDO deste tópico.
Para dados de textura, usar o tiling SFS de 64 KiB do XBTC em conjunto com BCPack e Deflate por tile produz a melhor compactação com suporte de hardware, combinada com a maior taxa de transferência (ou comparável) em relação às outras opções.

Confira também

DirectStorage Uso e detalhes internos do DirectStorage Análise do desempenho do DirectStorage Lista de exemplos do GDK

Porting

Build Paths

Conteúdo

Aviso de isenção de responsabilidade

Introdução

Arquitetura