MipMap-Verpackung
Abhängig von der Ebene der Unterstützung gekachelter Ressourcen folgen Mipmaps mit bestimmten Dimensionen nicht den Standardkachelformen und werden als alle zusammengepackt, die für die Anwendung undurchsichtig sind. Höhere Unterstützungsebenen bieten umfassendere Garantien darüber, welche Arten von Oberflächendimensionen in die Standardkachelformen passen (und daher von Anwendungen einzeln zugeordnet werden können).
Je nach Implementierung kann es vorkommen, dass – angesichts der Dimensionen, des Formats, der Anzahl der Mipmaps und array-Slices einer gekachelten Ressource – eine Anzahl M von Mips (pro Array-Slice) in einige Anzahl-N-Kacheln gepackt werden kann. Die ID3D11Device2::GetResourceTiling-API ist vorhanden, damit der Treiber an die Anwendung melden kann, was M und N sind (neben anderen Details zur Oberfläche, die diese API meldet, die standard sind und nicht je nach Hardwareanbieter variieren). Der Kachelsatz für die gepackten Mips beträgt immer noch 64 KB und kann einzeln in unterschiedlichen Speicherorten in einem Kachelpool zugeordnet werden. Aber die Pixelform der Kacheln und die Art, wie die Mipmaps auf den Kachelnsatz passen, sind spezifisch für einen Hardwareanbieter und zu komplex, um sie verfügbar zu machen. Daher müssen Anwendungen entweder alle Kacheln, die als gepackt gekennzeichnet sind, oder keine der Kacheln gleichzeitig zuordnen. Andernfalls ist das Verhalten für den Zugriff auf die gekachelte Ressource nicht definiert.
Für arrayierte Oberflächen gilt der Satz der gepackten Mips und die Anzahl der gepackten Kacheln, die diese Mips speichern (M und N, die zuvor beschrieben wurden), einzeln für jeden Array-Slice.
Dedizierte APIs zum Kopieren von Kacheln (ID3D11DeviceContext2::CopyTiles und ID3D11DeviceContext2::UpdateTiles) können nicht auf gepackte mips zugreifen. Anwendungen, die Daten in und aus gepackten mips kopieren möchten, können dazu alle nicht gekachelten ressourcenspezifischen APIs zum Kopieren und Rendern auf Oberflächen verwenden.
Zugehörige Themen