UMA-Optimierungen: Barrierefreie CPU-Texturen und Swizzle-Standardtest
Unified Memory Architecture (UMA)-GPUs bieten einige Effizienzvorteile gegenüber diskreten GPUs, insbesondere bei der Optimierung für mobile Geräte. Das Gewähren des CPU-Zugriffs auf Ressourcen, wenn die GPU UMA ist, kann den Kopieraufwand zwischen CPU und GPU verringern. Es wird zwar nicht empfohlen, Anwendungen blind CPU-Zugriff auf alle Ressourcen in UMA-Designs zu gewähren, aber es gibt Möglichkeiten, die Effizienz zu verbessern, indem sie den richtigen RESSOURCEN-CPU-Zugriff gewähren. Im Gegensatz zu einzelnen GPUs kann die CPU technisch über einen Zeiger auf alle Ressourcen verfügen, auf die die GPU zugreifen kann.
Übersicht über cpu zugängliche Texturen
CPU-barrierefreie Texturen sind in der Grafikpipeline ein Feature der UMA-Architektur und ermöglichen CPUs Lese- und Schreibzugriff auf Texturen. Bei den häufigeren diskreten GPUs hat die CPU keinen Zugriff auf Texturen in der Grafikpipeline.
Die allgemeine bewährte Methode für Texturen besteht darin, diskrete GPUs aufzunehmen, was in der Regel die Folgenden der Prozesse beim Hochladen von Texturdaten über Puffer umfasst, zusammengefasst als:
- Es gibt keinen CPU-Zugriff für die meisten Texturen.
- Festlegen des Texturlayouts auf D3D12_TEXTURE_LAYOUT_UNKNOWN.
- Hochladen der Texturen in die GPU mit CopyTextureRegion.
In bestimmten Fällen kann die CPU und GPU jedoch so häufig auf denselben Daten interagieren, dass Zuordnungstexturen hilfreich sind, um Energie zu sparen oder ein bestimmtes Design für bestimmte Adapter oder Architekturen zu beschleunigen. Anwendungen sollten diese Fälle erkennen und die unnötigen Kopien optimieren. Beachten Sie in diesem Fall folgendes, um die beste Leistung zu erzielen:
Beginnen Sie nur mit der besseren Leistung von Zuordnungstexturen, wenn D3D12_FEATURE_DATA_ARCHITECTURE::UMA WAHR ist. Achten Sie dann auf CacheCoherentUMA , wenn Sie entscheiden, welche CPU-Cacheeigenschaften für den Heap ausgewählt werden sollen.
Die Nutzung des CPU-Zugriffs für Texturen ist komplizierter als für Puffer. Die effizientesten Texturlayouts für GPUs sind selten row_major. Tatsächlich können einige GPUs nur row_major Texturen beim Kopieren von Texturdaten unterstützen.
UMA-GPUs sollten universell von einer einfachen Optimierung profitieren, um Die Ladezeiten zu reduzieren. Nach der Erkennung von UMA kann die Anwendung die anfängliche CopyTextureRegion optimieren, um Texturen aufzufüllen, die die GPU nicht ändert. Anstatt die Textur in einem Heap mit D3D12_HEAP_TYPE_DEFAULT zu erstellen und die Texturdaten durch zu marshallen, kann die Anwendung WriteToSubresource verwenden, um das verständnis des tatsächlichen Texturlayouts zu vermeiden.
In D3D12 sind Texturen, die mit D3D12_TEXTURE_LAYOUT_UNKNOWN erstellt wurden, und kein CPU-Zugriff für häufiges GPU-Rendering und Sampling am effizientesten. Bei Leistungstests sollten diese Texturen mit D3D12_TEXTURE_LAYOUT_UNKNOWN mit CPU-Zugriff verglichen werden, und D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE mit CPU-Zugriff und D3D12_TEXTURE_LAYOUT_ROW_MAJOR für die Adapterübergreifende Unterstützung.
Die Verwendung von D3D12_TEXTURE_LAYOUT_UNKNOWN mit CPU-Zugriff ermöglicht die Methoden WriteToSubresource, ReadFromSubresource, Map (voreinschließen des Anwendungszugriffs auf Zeiger) und "Unmap". Dies kann jedoch die Effizienz des GPU-Zugriffs opfern.
Die Verwendung von D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE mit CPU-Zugriff ermöglicht WriteToSubresource, ReadFromSubresource, Map (der einen gültigen Zeiger auf Anwendung zurückgibt) und "Unmap". Sie kann auch die Effizienz des GPU-Zugriffs mehr als D3D12_TEXTURE_LAYOUT_UNKNOWN mit CPU-Zugriff opfern.
Übersicht über standard Swizzle
D3D12 (und D3D11.3) stellen ein mehrdimensionales Standarddatenlayout vor. Dadurch können mehrere Verarbeitungseinheiten auf denselben Daten ausgeführt werden, ohne die Daten zu kopieren oder die Daten zwischen mehreren Layouts zu schwenken. Ein standardisiertes Layout ermöglicht Effizienzgewinne durch Netzwerkeffekte und ermöglicht Algorithmen, kurze Kürzungen unter einem bestimmten Muster vorzunehmen.
Eine detaillierte Beschreibung der Texturlayouts finden Sie unter D3D12_TEXTURE_LAYOUT.
Beachten Sie jedoch, dass dieser Standard-Swizzle ein Hardwarefeature ist und von allen GPUs möglicherweise nicht unterstützt wird.
Informationen zu Hintergrundinformationen zum Schwenken finden Sie in der Z-Reihenfolge-Kurve.
APIs
Im Gegensatz zu D3D11.3 unterstützt D3D12 standardmäßig die Texturzuordnung, sodass keine Abfrage D3D12_FEATURE_DATA_D3D12_OPTIONS erforderlich ist. D3D12 unterstützt jedoch nicht immer den Standardschwizzle - dieses Feature muss mit einem Aufruf von CheckFeatureSupport abgefragt und das StandardSwizzle64KBSupported-Feld von D3D12_FEATURE_DATA_D3D12_OPTIONS überprüft werden.
Die folgenden APIs verweisen auf die Texturzuordnung:
Enumerationen
- D3D12_TEXTURE_LAYOUT: Steuert das Swizzle-Muster von Standardtexturen und aktiviert die Kartenunterstützung für CPU-barrierefreie Texturen.
Strukturen
- D3D12_RESOURCE_DESC : beschreibt eine Ressource, z. B. eine Textur, dies ist eine umfassend verwendete Struktur.
- D3D12_HEAP_DESC: beschreibt einen Heap.
Methoden
- ID3D12Device::CreateCommittedResource : erstellt eine einzelne Ressource und sichert den Heap der richtigen Größe und Ausrichtung.
- ID3D12Device::CreateHeap : erstellt einen Heap für einen Puffer oder eine Textur.
- ID3D12Device::CreatePlacedResource : erstellt eine Ressource, die in einem bestimmten Heap platziert wird, in der Regel eine schnellere Methode zum Erstellen einer Ressource als CreateHeap.
- ID3D12Device::CreateReservedResource : erstellt eine Ressource, die reserviert, aber noch nicht zugesichert ist oder in einem Heap platziert wird.
- ID3D12CommandQueue::UpdateTileMappings: aktualisiert Zuordnungen von Kachelspeicherorten in nebeneinander angeordneten Ressourcen zu Speicherspeicherorten in einem Ressourcenhap.
- ID3D12Resource::Map : Ruft einen Zeiger auf die angegebenen Daten in der Ressource ab und verweigert den GPU-Zugriff auf die Unterressource.
- ID3D12Resource::GetDesc : ruft die Ressourceneigenschaften ab.
- ID3D12Heap::GetDesc ruft die Heap-Eigenschaften ab.
- ReadFromSubresource : Kopiert Daten aus einer Textur, die mithilfe von Map zugeordnet wurde.
- WriteToSubresource : Kopiert Daten in eine Textur, die mithilfe von Map zugeordnet wurde.
Ressourcen und übergeordnete Heaps haben Ausrichtungsanforderungen:
- D3D12_DEFAULT_MSAA_RESOURCE_PLACEMENT_ALIGNMENT (4 MB) für Textur mit mehreren Beispielen.
- D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT (64 KB) für einzelne Beispieltexturen und Puffer.
- Das Kopieren linearer Unterressourcen muss an D3D12_TEXTURE_DATA_PLACEMENT_ALIGNMENT (512 Byte) ausgerichtet werden, wobei der Zeilenabstand an D3D12_TEXTURE_DATA_PITCH_ALIGNMENT ausgerichtet ist (256 Byte).
- Konstantenpufferansichten müssen an D3D12_CONSTANT_BUFFER_DATA_PLACEMENT_ALIGNMENT ausgerichtet werden (256 Byte).
Texturen, die kleiner als 64 KB sind, sollten über CreateCommittedResource verarbeitet werden.
Bei dynamischen Texturen (Texturen, die jeden Frame ändern) schreibt die CPU linear in den Upload-Heap, gefolgt von einem GPU-Kopiervorgang.
Zum Erstellen dynamischer Ressourcen erstellen Sie in der Regel einen großen Puffer in einem Upload-Heap (siehe Unterlastung innerhalb von Puffern). Um Stagingressourcen zu erstellen, erstellen Sie einen großen Puffer in einem Readback-Heap. Um statische Standardressourcen zu erstellen, erstellen Sie benachbarte Ressourcen in einem Standardhap. Um standardmäßige aliasierte Ressourcen zu erstellen, erstellen Sie überlappende Ressourcen in einem Standardhap.
WriteToSubresource und ReadFromSubresource ordnen Texturdaten zwischen einem Zeilen-Hauptlayout und einem nicht definierten Ressourcenlayout neu an. Der Vorgang ist synchron, sodass die Anwendung die CPU-Planung berücksichtigen sollte. Die Anwendung kann das Kopieren immer in kleinere Regionen aufteilen oder diesen Vorgang in einem anderen Vorgang planen. MSAA-Ressourcen und Tiefenschablonenressourcen mit undurchsichtigen Ressourcenlayouts werden von diesen CPU-Kopiervorgängen nicht unterstützt und verursachen einen Fehler. Formate, die keine Power-of-Two-Elementgröße aufweisen, werden ebenfalls nicht unterstützt und verursachen auch einen Fehler. Nicht genügend Arbeitsspeicher-Rückgabecodes können auftreten.
Zugehörige Themen