Método ID3D11DeviceContext2::ResizeTilePool (d3d11_2.h)

Redimensiona um pool de blocos.

Sintaxe

HRESULT ResizeTilePool(
  [in] ID3D11Buffer *pTilePool,
  [in] UINT64       NewSizeInBytes
);

Parâmetros

[in] pTilePool

Tipo: ID3D11Buffer*

Um ponteiro para um ID3D11Buffer para o pool de blocos redimensionar.

[in] NewSizeInBytes

Tipo: UINT64

O novo tamanho em bytes do pool de blocos. O tamanho deve ser um múltiplo de 64 KB ou 0.

Retornar valor

Tipo: HRESULT

Retorna S_OK se tiver êxito; caso contrário, retorna um dos seguintes:

• Retorna E_INVALIDARG se o novo tamanho do pool de blocos não for um múltiplo de 64 KB ou 0.
• Retorna E_OUTOFMEMORY se a chamada resultar na necessidade de alocar espaço para novos mapeamentos de tabela de página, mas ficando sem memória.
• Retorna DXGI_ERROR_DEVICE_REMOVED se o cartão de vídeo foi fisicamente removido do sistema ou se ocorreu uma atualização de driver para o cartão de vídeo.

Comentários

ResizeTilePool aumenta ou diminui o tamanho do pool de blocos, dependendo se o aplicativo precisa de mais ou menos conjunto de trabalho para os recursos lado a lado mapeados nele. Um aplicativo pode alocar pools de blocos adicionais para novos recursos lado a lado, mas se qualquer recurso lado a lado precisar de mais espaço do que o disponível inicialmente em seu pool de blocos, o aplicativo poderá aumentar o tamanho do pool de blocos do recurso. Um recurso lado a lado não pode ter mapeamentos em vários pools de blocos simultaneamente.

Quando você aumenta o tamanho de um pool de blocos, blocos adicionais são adicionados ao final do pool de blocos por meio de uma ou mais novas alocações pelo driver; seu aplicativo não pode detectar a divisão nas novas alocações. A memória existente no pool de blocos é deixada intocada e os mapeamentos de recursos lado a lado existentes nessa memória permanecem intactos.

Quando você diminui o tamanho de um pool de blocos, os blocos são removidos do final (isso é permitido mesmo abaixo do tamanho de alocação inicial, até 0). Isso significa que novos mapeamentos não podem ser feitos além do novo tamanho. Porém, os mapeamentos existentes após o final do novo tamanho permanecem intactos e utilizáveis. A memória é mantida ativa, desde que os mapeamentos para qualquer parte das alocações que estão sendo usadas para a memória do pool de blocos permaneçam. Se, após a diminuição, alguma memória tiver sido mantida ativa porque os mapeamentos de bloco estão apontando para ela e o pool de blocos será aumentado novamente (por qualquer quantidade), a memória existente será reutilizado primeiro antes que quaisquer alocações adicionais ocorram para atender ao tamanho do aumento.

Para poder economizar memória, um aplicativo precisa não apenas diminuir um pool de blocos, mas também remover e remapear mapeamentos existentes após o final do novo tamanho menor do pool de blocos.

O ato de diminuir (e remover mapeamentos) não necessariamente produz economia de memória imediata. A liberação de memória depende de quão granulares são as alocações subjacentes do driver para o pool de blocos. Quando uma diminuição no tamanho de um pool de blocos é suficiente para tornar uma alocação de driver não usada, o driver pode liberar a alocação. Se um pool de blocos foi aumentado e, se você diminuir para tamanhos anteriores (e remover e remapear mapeamentos de bloco correspondentemente), provavelmente gerará economia de memória. No entanto, esse cenário não é garantido caso os tamanhos não estejam exatamente alinhados com os tamanhos de alocação subjacentes escolhidos pelo driver.

Para obter mais informações sobre recursos lado a lado, consulte Recursos lado a lado.

Requisitos

Confira também

ID3D11DeviceContext2