Swapchain Class

Die Swapchain-Klasse soll eine Swapchain, sowie Surface zu einem Window hinzufügen

Erste Schritte:

• Einlesen in das Erstellen einer Swapchain sowie Surface, sowie die Vorbereitungen für das Resizing-Event treffen oder ggf. einbauen.

Hilfreiche Links:

• Intels "API without secrets" zur Swapchain
• Intels "API without secrets" zu "Frame Resources"

Erstes großes Ziel:

• Erstellen der Surface
• Erstellen der Swapchain
• Unterscheidung der Presentation-Modes
• ? Resizing -> moved to #14 (closed)

CC: @gaida @kkraemer4 @vaka1997 @jfmorgenstern

added 🍪 ToDo 🖥️ I/O labels

marked this issue as related to #14 (closed)

changed the description

• vk::SurfaceCapabilitiesKHR abfragen und schauen, was das surface kann -> wichtig um valides Fenster zu erstellen (in den Dimensionen von min/maximageExtend.heigh und width)
• welchen presentationmode wählen wir -> könnte bei jedem anders sein. Bevorzugt VK_PRESENT_MODE_MAILBOX_KHR (in vulkan.h)

Generell denke ich auf jeden Fall, dass wir einen sinnvollen default setzen sollten, damit der Nutzer des Frameworks sich darüber nicht zwangsweise Gedanken machen muss und dann trotzdem die Option geben sollten, den manuell zu setzen. Ich gehe mal davon aus, dass Strom sparen nicht so eine große Rolle spielt, also sollte man versuchen Mailbox zu setzen mit Fallback auf FIFO.

Noch eine Offtopic Verständnisfrage: Wenn ich jetzt sowas wie VRR (Gsync, Freesync) benutzen will, benötigt man dafür zwangsweise einen bestimmten presentationmode? Ist das unabhängig?

changed the description

added 👍 Feature label

changed milestone to %First Triangle

changed due date to May 18, 2021

added 💻 Doing label and removed 🍪 ToDo label

mentioned in issue #18 (closed)

assigned to @gaida

created merge request !12 (merged) to address this issue

mentioned in merge request !12 (merged)

soll eigentlich in der SwapChain Klasse schon das logical device erstellt werden? mit den extensions für die Swap chain hätte man nämlich dafür schon alles zusammen. Nehme mal an ja, weil für Queues und physical Device hatten wir ja jetzt auch keine eigenen Klassen. Oder was denkt ihr?

(Ich habe die Klasse mal SwapChain genannt und nicht Swapchain, weil es im Khronos-Wiki aus zwei Einzelbegriffen besteht.)

Ich bin mir nicht sicher ob diese Abhängigkeit von Logical Device zu SwapChain so gut wäre. Ich würde eher erwarten, dass die SwapChain eine Abhängigkeit von dem Logical Device hat.
Aber ich finde, dass da das Architektur-Team eher antworten sollte.

Macht es nicht sogar Sinn, das Logical Device auch in die Context Klasse zu packen?

Okay, das war grade sehr verwirrend. Wir haben die schon längst in der Context Klasse. Das device brauchen wir ja auch, um die Context Instanz zu erstellen. Warum ich jetzt darauf kam war wegen des ersten Punktes "Hinzufügen der Extensions". Der ergibt ja dann gar kein Sinn, weil nach dem Erstellen des logicaldevices sollte man ja schon alle Extensions angegeben haben. Die für die Swapchain nötig sind, sind damit auch schon abgedeckt. Das Todo ergibt also keinen Sinn.

Gut, das Hinzufügen ergibt insofern Sinn, dass man es in der main() hinzufügen muss. Für die deviceExtensions haben wir nämlich keine defaults. Hab das aber trotzdem mal als ToDo gestrichen, weils nichts mit der Swap chain Klasse zu tun hat.

Das ist von Vulkanseite etwas umständlich. Um eine logical device zu erstellen, muss im entsprechenden info struct dafür schon eine Liste von queue familiy indices angegeben werden, die man von dieser device eventuell ansprechen möchte. Für die surface/swapchain muss man herausfinden, welcher queue family index entsprechend für die Präsentation auf dem Bildschirm verantwortlich ist, bzw. das überhaupt kann.

Eine Idee wäre, zu erst benötigte Fenster zu initialisieren (samt glfw), dann daraus die benötigten extensions zu extrahieren und diese in die Erstellung des Context-Objektes mitzugeben. Ich glaube sogar, so machen wir es auch momentan.

Sebastian hat da definitiv recht, dass eine swapchain/surface abhängig von der logical device ist. Ihr müsst auch noch irgendwie einmal den glfwWindow* übergeben zur surface/swapchain-Erstellung. Ich denke es ist nicht verkehrt, das ganze auch über eine zentrale Stelle managen zu lassen, die für euch die surface und swapchain samt Eigenschaften hält und auf Benutzerseite nur sowas wie ein WindowHandle zurückgibt.

Klärt das irgendwelche Verwirrungen auf? Wenn nicht, bitte weiter fragen, swapchain und surface sind schon etwas nervige Dinger.

Ich glaube das mit den Extensions war nur ein kleines Missverständnis. Zum getten der Queues für die Swapchaininfo müssten wir glaube ich noch device.getQueue() implementieren. Das war noch ein TODO für die Contextklasse.

ja, genau. Bisher haben wir die instanceExtensions, die fürs Fenster (und die Swapchain) wichtig sind schon automatisch mit glfwGetRequiredInstanceExtensions() mitgegeben.

Das mit der zentralen Stelle hab ich nicht ganz verstanden. Bisher habe ich für die Swapchain auch eine Create-Funktion, die dann alles nötige übergeben bekommt.

changed the description

marked the checklist item Erstellen der Surface as completed

mentioned in commit b0e06cd0

Nach derzeitigen Stand wählen wir die Parameter von SwapchainCreateInfo aus, ohne dass der Nutzer des Frameworks darauf einfluss nehmen kann. Idee wäre, dass er die Möglichkeit hat, bestimmte Settings beim Initalisieren des Windows "überschreiben" kann - z.B. PresentationMode

Eine Idee dafür wäre die Übergabe eines optionalen Config Structs, aus dem dann die entsprechend gesetzten Werte bei Erstellung genommen werden. Wenn gar nichts übergeben wird, bzw. nur ein Teil der Daten gesetzt wird, werden Defaults ermittelt und gesetzt.

mentioned in commit 54cf3b45

mentioned in commit bf2673c2