Freigeben über

IDMLBindingTable::BindInputs-Methode (directml.h)

  • Artikel

Bindet eine Gruppe von Ressourcen als Eingabe-Tensors.

Bei der Bindung für einen kompilierten Operator muss die Anzahl der Bindungen genau mit der Anzahl der Eingaben des Operators übereinstimmen, einschließlich optionaler Tensoren. Dies kann anhand der Operatorbeschreibung bestimmt werden, die zum Erstellen des Operators verwendet wird. Wenn zu viele oder zu wenige Bindungen bereitgestellt werden, wird das Gerät entfernt. Für optionale Tensoren können Sie DML_BINDING_TYPE_NONE verwenden, um "keine Bindung" anzugeben. Andernfalls muss der Bindungstyp mit dem Tensortyp übereinstimmen, als der Operator erstellt wurde.

Bei Operatorinitialisierern wird erwartet, dass Eingabebindungen vom Typ DML_BINDING_TYPE_BUFFER_ARRAY mit einer Eingabebindung pro zu initialisierenden Operator sein, die in der Reihenfolge angegeben wird, in der Sie die Operatoren beim Erstellen oder Zurücksetzen des Initialisierers angegeben haben. Jedes Pufferarray sollte eine Größe aufweisen, die der Anzahl der Eingaben des entsprechenden zu initialisierenden Operators entspricht. Eingabe-Tensoren, für die das DML_TENSOR_FLAG_OWNED_BY_DML-Flag festgelegt war, sollten während der Initialisierung gebunden werden, andernfalls sollte für diesen Tensor nichts gebunden werden. Wenn für die Initialisierung eines Operators nichts als Eingabe gebunden werden kann (d. h. es gibt keine Tensoren mit dem DML_TENSOR_FLAG_OWNED_BY_DML-Flag), können Sie einen leeren DML_BUFFER_ARRAY_BINDING angebennullptr, um "keine Bindung" anzugeben.

Um die Bindung aller Eingaberessourcen aufzuheben, geben Sie einen rangeCount von 0 und den Wert für nullptrBindungen an.

Wenn für einen Eingabe tensor das flag DML_TENSOR_FLAG_OWNED_BY_DML festgelegt ist, kann er nur beim Ausführen eines Operatorinitialisierers gebunden werden. Andernfalls ist das DML_TENSOR_FLAG_OWNED_BY_DML-Flag nicht festgelegt, das Gegenteil ist wahr: Der Eingabe-Tensor darf beim Ausführen des Initialisierers nicht gebunden sein, sondern muss beim Ausführen des Operators selbst gebunden sein.

Alle Puffer, die als Eingabe gebunden werden, müssen den Heaptyp D3D12_HEAP_TYPE_DEFAULT haben, außer wenn das DML_TENSOR_FLAG_OWNED_BY_DML-Flag festgelegt ist. Wenn der DML_TENSOR_FLAG_OWNED_BY_DML für einen Tensor festgelegt ist, der als Eingabe für einen Initialisierer gebunden wird, kann der Heaptyp des Puffers entweder D3D12_HEAP_TYPE_DEFAULT oder D3D12_HEAP_TYPE_UPLOAD sein.

In einigen Fällen dürfen mehrere Bindungen auf dieselbe ID3D12Resource verweisen. Sie sollten jedoch darauf achten, wenn ein Operator gleichzeitig liest und in dieselbe Region einer Ressource schreibt. Eine potenzielle Bindungsgefahr besteht, wenn ein Bindungspaar auf dieselbe ID3D12Resource verweist und mindestens eine der Bindungen am Schreiben beteiligt ist und sich die Pufferbereiche überschneiden (überlappen um mindestens ein Byte). Bindungsrisiken werden mit den folgenden Regeln ab DirectML 1.7.0 überprüft:

  • Bei der Bindung für die Initialisierung kann eine Eingabebindung niemals auf dieselbe Ressource wie die Ausgabebindung verweisen. Eingaben werden in die Ausgaberessource (die zukünftige persistente Ressource für die Ausführung) kopiert, und das Kopieren erfordert möglicherweise einen Ressourcenstatusübergang.
  • Bei der Bindung für die Ausführung verweist eine Eingabebindung möglicherweise auf dieselbe Ressource wie eine Ausgabebindung. Die jeweiligen Bindungsbereiche können sich jedoch nur überschneiden, wenn die Regionen identisch sind und der Operator die direkte Ausführung unterstützt.
  • Falls vorhanden, darf sich eine persistente Bindung nicht mit einer Ausgabe- oder temporären Bindung überschneiden.
  • Falls vorhanden, darf eine temporäre Bindung keine Eingabe-, Ausgabe- oder persistente Bindung überschneiden.

Bei den obigen Regeln wird davon ausgegangen, dass zwei Ressourcen nicht dieselbe Region eines Heaps aliasen. Daher ist bei der Verwendung platzierter oder reservierter Ressourcen besondere Vorsicht geboten.

Syntax

void BindInputs(
                 UINT                   bindingCount,
  [in, optional] const DML_BINDING_DESC *bindings
);

Parameter

bindingCount

Typ: UINT

Dieser Parameter bestimmt die Größe des Bindungsarrays (sofern angegeben).

[in, optional] bindings

Typ: const DML_BINDING_DESC*

Ein optionaler Zeiger auf ein konstantes Array von DML_BINDING_DESC , das Beschreibungen der zu bindenden Tensorressourcen enthält.

Rückgabewert

Keine

Bemerkungen

Bindungsgefahrenbeispiele

In den folgenden Beispielen stellen die Rechtecke eine Pufferressource dar, auf die mindestens eine Bindung in einer Bindungstabelle verweist. Jede Zeile gibt den Bereich von Bytes an, die durch die benannte Bindung potenziell gelesen (R) oder geschrieben (W) sind. Alle Beispiele gehen davon aus, dass Ressourcen nicht den gleichen physischen Arbeitsspeicher nutzen.

Beispiel 1

Dieses Beispiel zeigt eine Eingabe- und Ausgabebindung, die auf verschiedene Ressourcen verweist. Ein Paar von Bindungen, die auf unterschiedliche Ressourcen verweisen, stellt nie eine Gefahr dar, daher ist dies immer eine gültige Bindung.

          Resource A          Resource B
          +---------------+   +---------------+
Input  0: |RRRRRRRRRRRRRRR|   |               |
Output 0: |               |   |WWWWWWWWWWWWWWW|
          +---------------+   +---------------+

Beispiel 2

Dieses Beispiel zeigt eine Eingabe- und Ausgabebindung, die auf verschiedene Regionen derselben Ressource verweist. Ein Paar von Bindungen mit nicht überlappenden Regionen derselben Ressource stellt bei der Bindung für die Ausführung keine Gefahr dar. Dies ist eine gültige Bindung bei der Bindung für die Ausführung, aber sie ist ungültig, wenn die Bindung für die Initialisierung gebunden wird.

          Resource A      
          +---------------+
Input  0: |RRRRRRR        |
Output 0: |       WWWWWWWW|
          +---------------+

Beispiel 3

Dieses Beispiel zeigt zwei Eingabebindungen, die Bereiche überlappen. Ein Paar schreibgeschützter Bindungen (Eingabebindungen und persistente Bindungen) kann unabhängig von einer Pufferregionsüberschneidung nie eine Gefahr darstellen, sodass dies immer eine gültige Bindung ist.

          Resource A          Resource B
          +---------------+   +---------------+
Input  0: |RRRRRRRRR      |   |               |
Input  1: |      RRRRRRRRR|   |               |
Output 0: |               |   |WWWWWWWWWWWWWWW|
          +---------------+   +---------------+

Beispiel 4

Dieses Beispiel zeigt eine Eingabe- und Ausgabebindung mit identischen Regionen. Diese Bindung ist nur gültig, wenn der gebundene Operator die direkte Ausführung unterstützt und die Bindung für die Ausführung bestimmt ist.

          Resource A      
          +---------------+
Input  0: |RRRRRRRRRRRRRRR|
Output 0: |WWWWWWWWWWWWWWW|
          +---------------+

Beispiel 5

Die folgende Bindung ist unabhängig von der Direkten Ausführungsunterstützung des Operators nie gültig, da sie ein Paar von Bindungen mit sich überlappenden Regionen umfasst, die nicht identisch sind.

          Resource A      
          +---------------+
Input  0: |RRRRRRRRRRRRR  |
Output 0: |    WWWWWWWWWWW|
          +---------------+

Anforderungen

Anforderungen

   
Zielplattform Windows
Kopfzeile directml.h
Bibliothek DirectML.lib
DLL DirectML.dll

Weitere Informationen

Bindung in DirectML

IDMLBindingTable