2016-07-30 8 views
3

Die Standard-Verwendung von Barriers ist relativ einfach, aber ich frage mich, was ist das Verhalten von zwei (oder mehr) überlappenden Image Barriers (vor allem in Bezug auf ihre Nebenwirkung - der Layout-Übergang). Z.B. (Pseudo-Code):Was ist das Verhalten von überlappenden Bildbarrieren?

begin(commandBuffer); 
1: write(image); 
2: imageBarrier(
    image, 
    src=STAGE_FRAGMENT(from the write at 1:), 
    dst=STAGE_FRAGMENT(intended for read in FS of read at 4:), 
    appropriate src and dst access flags, 
    newLayout=A 
    ); 
3: imageBarrier(
    image, 
    src=STAGE_FRAGMENT(from the write at 1:), 
    dst=STAGE_TRANSFER(intended for read by transfer of readT at 5:), 
    appropriate src and dst access flags, 
    newLayout=B 
    ); 
4: read(image); // through vkCmdDraw -- expects layout A 
5: readT(image); // different kind of read through Transfer -- expects layout B 
end(commandBuffer); 
  1. Ist das überhaupt legal? (Können Sie es durch spezifisches Angebot sichern?)
  2. Was ist das Bild-Layout an jedem Punkt des Programms?
  3. Der Vollständigkeit halber, was ist der richtige/beste Weg, dies zu schreiben (ein Produzent, zwei Verbraucher Situation)? (Zeilen 3: und 4: tauschen und Read-Read-Abhängigkeit machen?)

Antwort

2

Ein Bild kann nicht mehrere Layouts gleichzeitig annehmen. In dem Fall des oben vorgeschlagenen Codes, würde, da die zwei Barrieren keine Abhängigkeiten voneinander haben, einer vor dem anderen passieren, aber die Reihenfolge ist nicht spezifiziert. Also würde das Layout des Bildes nachher das eine oder das andere sein. Das bedeutet, dass eine der beiden Leseoperationen fehlschlägt.

Wenn Sie zwei Operationen verwenden, die das Bild aus zwei verschiedenen Layouts verwenden, muss eine dieser Operationen vor der anderen ausgeführt werden, da beide das Bild im Layout, das sie benötigen, nicht lesen können. Und deshalb muss es eine Ausführung seine Abhängigkeit zwischen sie:

1: write(image); 
2: imageBarrier(image, src=COLOR_ATTACHMENT_OUT, dst=FRAGMENT_SHADER, newLayout=A); 
3: read(image); // e.g. through vkCmdDraw -- expects layout A 
4: imageBarrier(image, src=FRAGMENT_SHADER, dst=TRANSFER, newLayout=B); 
5: readT(image); // different kind of read e.g. Transfer -- expects layout B 

Die Abhängigkeit in # 4 sagt, dass das Layout Übergang und späte TRANSFER-Befehle werden nicht auftreten, bis alle vorherigen FRAGMENT_SHADER Operationen abgeschlossen haben.

machen es Read-Read Abhängigkeit

Es ist kein "Read-Read Abhängigkeit". Ein Layout-Übergang verändert das Bild (theoretisch jedenfalls) genauso sicher, als ob Sie direkt Werte in das Bild geschrieben hätten. Also logisch, was Sie haben, ist "Ich muss davon in der FS lesen. Danach muss ich es in ein neues Layout überführen. Danach muss ich von ihm in einer Übertragungsoperation lesen".

Es ist eine "Lese-Schreib-Lese-Abhängigkeit". Der mittlere Teil muss warten, bis der erste Lesevorgang abgeschlossen ist, aber der zweite Lesevorgang kann erst erfolgen, wenn der mittlere Teil beendet ist. Sie benötigen eine Ausführungsabhängigkeit mit einer zugeordneten Bildspeichersperre & Layout-Übergang.

+0

Ok, das war meine Intuition (es ist die Verantwortung von Apps - wie immer). Ich habe mich nur gefragt, ob ich mich auf eine bestimmte Reihenfolge der beiden Lesefunktionen festlegen muss. (Es gibt einen Trick mit Subpasses, aber nicht inline dann, denke ich). – krOoze

+0

@krOoze: Sie können nicht zwei unabhängige Subpässe haben, die von demselben Bild mit unterschiedlichen Layouts lesen. Ein * muss * abhängig sein von dem anderen, da die Implementierung Subpässe verschachteln darf, wenn man nicht von dem anderen abhängig ist. –

+0

Ich meinte das (spezifisches Zitat): "Wenn zwei Subpasses denselben Anhang in verschiedenen Layouts verwenden, aber beide Verwendungen schreibgeschützt sind, muss die Anwendung keine Abhängigkeit zwischen den beiden Subpässen ausdrücken. [.. .] " – krOoze

Verwandte Themen