DE102018104193A1

DE102018104193A1 - Grafik-Engine-Ressourcenverwaltung und -Zuweisungssystem

Info

Publication number: DE102018104193A1
Application number: DE102018104193.4A
Authority: DE
Inventors: Teemu Virolainen; Mikko Alaluusua
Original assignee: BASEMARK Oy
Current assignee: BASEMARK Oy
Priority date: 2017-11-06
Filing date: 2018-02-23
Publication date: 2019-05-09
Also published as: US10475151B2; GB2577029A; GB2577029B; US20190139180A1; GB201801957D0

Abstract

Das hier beschriebene Verfahren ist ein Verfahren zur Zuweisung von Ressourcen für das Rendem. Die Verfahren kann das Zusammensetzen einer Vielzahl von Rendering- Knoten beinhalten. Die Rendering- Knoten können ihre definierten Ein- und Ausgänge haben. Aus der zusammengesetzten Menge von Rendering- Knoten kann ein Zeitplan zusammengestellt werden. Der kompilierte Zeitplan für die Vielzahl von Rendering- Knoten kann zumindest auf den definierten Ein- und Ausgängen basieren. Zusätzlich kann die Vielzahl der Rendering- Knoten so eingeplant werden, dass zu einem bestimmten Zeitpunkt mehr als ein Rendering- Algorithmus ausgeführt werden kann. Innerhalb der Kompilierung kann eine Reihe von Ressourcenbarrieren definiert werden. Die Menge von Ressourcenbarrieren kann Systemressourcenbarrieren umfassen. Diese Systemressourcenbarrieren können für die Verarbeitung der Menge der Rendering- Knoten auf der Grundlage des erstellten Zeitplans verwendet werden.

Description

ERFINDUNGSBEREICH
Die vorliegende Erfindung bezieht sich auf den Bereich der Visualisierung und des Renderings. Das System befasst sich insbesondere mit der Ressourcenverwaltung und - zuordnung innerhalb von Grafik- Engines. Darüber hinaus ermöglichen das System und die Verfahren signifikante Verbesserungen in Bezug auf Geschwindigkeit, Leistung und Zuverlässigkeit von Computergeräten, insbesondere von Grafikprozessoren (GPUs).
ERFINDUNGSHINTERGRUND
Mit den aktuellen Grafik- Engines ist die Ressourcenzuweisung nicht für einzelne Anwendungsfälle optimiert, sondern sie nutzen im Wesentlichen Pool- Speicher, die unabhängig vom Anwendungsfall sindt. Beispielsweise können in einer Unterhaltungs- Grafik- Engine einige Ressourcen permanent für das Rendem von Explosionen zugewiesen werden, unabhängig davon, ob es in einer bestimmten Rendering- Menge Explosionen gibt. Daher werden diese Ressourcen bei großen Teilen der Spielnutzung und praktisch immer, z.B. bei industriellen Anwendungen, verschwendet.
Darüber hinaus verbergen die aktuellen Engines oft ihre Ressourcenzuweisung, so dass es schwierig ist, festzustellen, ob bestimmte Operationen zu neuen Zuweisungen führen.
Um eine kombinatorische Explosion zwischen den Konfigurationen der Algorithmen zu vermeiden, werden außerdem bestimmte Ressourcen redundant zugewiesen. Zum Beispiel könnte ein Algorithmus eine temporäre Textur für Zwischenergebnisse benötigen, aber die Textur wird nicht benötigt, nachdem der Algorithmus abgeschlossen ist, jedoch wird die Textur dann nur für diesen Algorithmus beibehalten und ist für andere Teile der Rendering- Pipeline nicht zugänglich, wodurch unnötig Systemspeicherressourcen genutzt werden. Daher kann diese Textur in aktuellen Grafik-Engines nicht in einem späteren Stadium oder einem anderen Stadium der Rendering- Pipeline wiederverwendet werden.
Ein Hauptproblem, das durch die aktuelle Systemressourcenzuweisung der Grafik- Engines verursacht wird, ist ein hohes Maß an Speicherfragmentierung. Aus diesem Grund und aus vielen anderen bekannten Gründen sind aktuelle Grafik- Engines für sicherheitskritische Umgebungen nicht gut geeignet.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung ermöglicht es, Systemressourcen (Speicher- und Prozessorleistung) für eine Grafik- Engine für das Rendering effizienter zuzuordnen und zu nutzen. Dies ermöglicht eine bessere Nutzung der Ressourcen eines Geräts, so dass entweder die Mindestanforderungen an die Rechenleistung eines Geräts für eine bestimmte Funktion reduziert werden können und/ oder der Ressourcenbedarf der Grafik- Engine begrenzt werden kann, wodurch Ressourcen für andere Anwendungen freigesetzt werden.
Darüber hinaus kann in sicherheitskritischen Anwendungsfällen die hier beschriebene Ressourcenzuweisung vor der Verwendung auf die effizienteste Art und Weise für die jeweils benötigte Visualisierung vordefiniert werden. Vor der Verwendung können die Systemressourcen mit der optimierten Systemressourcenzuweisung in ihren optimierten Einstellungen fixiert werden, so dass Ressourcen während der Nutzung nicht neu zugewiesen werden müssen. Dies ermöglicht den Einsatz in vielen sicherheitskritischen Umgebungen.
Die hier beschriebenen Verfahren sind Verfahren zur Zuweisung von Ressourcen für das Rendem. Die Verfahren können das Zusammensetzen einer Vielzahl von Rendering- Knoten beinhalten. Die Rendering- Knoten können ihre definierten Ein- und Ausgänge haben. Aus der zusammengesetzten Menge von Rendering- Knoten kann ein Zeitplan zusammengestellt werden. Der kompilierte Zeitplan für die Vielzahl von Rendering- Knoten kann zumindest auf den definierten Ein- und Ausgängen basieren. Zusätzlich kann die Vielzahl der Rendering- Knoten so eingeplant werden, dass zu einem bestimmten Zeitpunkt mehr als ein Rendering- Algorithmus ausgeführt werden kann. Innerhalb der Kompilierung kann eine Reihe von Ressourcenbarrieren definiert werden. Die Menge von Ressourcenbarrieren kann Systemressourcenbarrieren umfassen. Diese Systemressourcenbarrieren können für die Verarbeitung der Menge der Rendering- Knoten auf der Grundlage des erstellten Zeitplans verwendet werden.
Der Zeitplan und/ oder die Schranken können dann in einem Speicher eines elektronischen Geräts gespeichert werden. Diese können vor dem Rendem gespeichert werden, z.B. vor der Durchführung eines zugehörigen Rendering- Verfahrens auf einem Anzeigegerät.
Sobald ein Rendering- Prozess gestartet ist, können auf der Grundlage des Zeitplans und/ oder der Barrieren Aufträge an ein Host- Gerät erteilt werden. Das Host- Gerät kann eine Grafikprozessoreinheit (GPU) sein oder enthalten. Das Host- Gerät kann auch eine zentrale Verarbeitungseinheit (CPU) oder ein anderes Ganzes oder Teil einer Verarbeitungseinheit sein oder enthalten. Sobald die Aufträge vom Hostgerät ausgeführt werden, wird ein gewünschtes Bild gerendert.
Figurenliste

1 zeigt ein Beispiel für einen azyklischen Graphen von Rendering- Knoten.
2 zeigt ein Beispiel für ein Ressourcenallokations- Verfahren.

DETAILLIERTE BESCHREIBUNG EXEMPLARISCHER AUSFÜHRUNGSFORMEN
Ein Verfahren der Systemressourcenzuweisung besteht darin, einen Rendering- Algorithmus als eigenständige Arbeitseinheit zu definieren, die ihre eigene Ressourcenzuweisung handhabt. Ein weiteres Verfahren der Systemressourcenzuweisung ist die Definition eines Rendering- Algorithmus als Sammlung von verknüpften Rendering- Knoten. In den Beispielen hierin ist der Rendering-Algorithmus typischerweise der Letztere, wie im Folgenden näher erläutert wird. Jedoch können beide Verfahren hierin verwendet werden.
Jeder Rendering- Algorithmus und/ oder Rendering- Knoten kann definieren, was er als Input erwartet und was er ausgibt. Ein Beispiel für einen Rendering- Algorithmus kann ein opaker Rendering- Algorithmus sein. Ein Beispiel für eine Eingabe für einen opaken Rendering-Algorithmus sind Schattenwurfdaten. Zusätzlich kann es mehrere Eingänge für einen bestimmten Rendering- Algorithmus geben. Eine weitere Beispieleingabe wären beispielsweise Lichtdaten für den opaken Rendering- Algorithmus.
Rendering- Algorithmen können zu einer High- Level- Rendering- Pipeline kombiniert werden. Eine High- Level- Rendering- Pipeline kann eine Kette von Rendering- Algorithmen und/ oder Rendering-Knoten definieren, die ein fertiges Bild erzeugt. Beispielsweise kann eine High- Level- Rendering-Pipeline einen Rendering- Algorithmus zur Erzeugung von Schattenwurf/ Shadow Mapping, einen Algorithmus zur Berechnung von Lichtdaten, einen Algorithmus zur Berechnung von opaken Objekten, einen Algorithmus zur Darstellung transparenter Objekte, einen Algorithmus zur Darstellung von Dynamikkompression/ Tonemapping und einen Algorithmus zur Berechnung der Tiefenschärfe enthalten.
Ein Rendering- Algorithmus selbst kann eine verkettete Kette von Rendering- Knoten sein. Jeder Rendering- Knoten kann definieren, welche Art von Ressourcen er als Input benötigt und welche Art von Ressourcen er ausgibt. Die übergeordnete Rendering- Pipeline kann eine kompilierte/ zusammengesetze Kette, eine Liste oder ein Graph von Rendering- Knoten sein. So können z.B. die Rendering- Knoten verschiedener Rendering- Algorithmen in der Kette der übergeordneten Rendering- Pipeline miteinander vermischt werden. Zusätzlich kann die verkettete Kette eine Kombination aus parallelen und seriellen Gliedern haben, so dass bestimmte Rendering- Knoten und/ oder Rendering- Algorithmen gleichzeitig ausgeführt werden können.
Ressourcen können die benötigten Ein- und Ausgänge eines Rendering- Knotens oder Rendering-Algorithmus sein. Dies können Daten, Datensätze, Szenen, Parameter usw. sein, die in einen Rendering- Prozess eines Rendering- Knotens einfließen.
Generell kann ein Rendering- Algorithmus, wie er hier beschrieben wird, ein dedizierter Prozess innerhalb einer Rendering- Pipeline sein (z.B. ein Rendering- Algorithmus zur Erzeugung von Schattenwurf, ein Rendering- Algorithmus zur Berechnung von Lichtdaten, ein opaker Rendering-Algorithmus für Objekte, ein transparenter Rendering- Algorithmus für Objekte, ein Tonemapping-Rendering- Algorithmus und ein Tiefenschärfentiefe- Rendering- Algorithmus). Ein Rendering-Algorithmus kann nur einen einzigen Rendering- Knoten oder mehrere Rendering- Knoten enthalten.
Ein Rendering- Knoten, wie er hier beschrieben wird, kann ein Prozess, eine Routine, ein Rendering- Durchgang oder eine Arbeitseinheit sein, die Abhängigkeiten hat. Z.B. ein Durchgang eines Schatten- Rendering- Algorithmus oder ein Orb glow/ Orb- Glüh- Rendering- Knoten für einen Objekttyp. Eine Untereinheit, z.B. eine einzelne Arbeitseinheit, eines größeren Rendering-Algorithmus (z.B. ein Kreis von Verwirrungsarbeitseinheiten/ circle of confusion work unit innerhalb eines Tiefenschärfe- Rendering- Algorithmus).
Systemressourcen können unter anderem GPU- Speicher, CPU- Speicher und Verarbeitungskapazitäten sein.
Rendering- Ressourcen, wie hier beschrieben, können entweder Datensätze sein, die der Grafik-Engine zur Verfügung stehen (z.B. Texturen) oder Datensätze, die innerhalb einer Rendering-Pipeline erstellt wurden (z.B. Lichtdaten aus einer Light- Datenberechnungsphase), SpeicherCache- Bedarf oder Verarbeitungsanforderungen.
Framebuffers
System-Barrieren können, sind aber nicht beschränkt auf, Cache Flushing von Speicher (GPU, CPU, etc.) sein, Planungsanweisungen für die Ausführung bestimmter Rendering- Algorithmen/ Rendering- Knoten, Verarbeitungsanforderungen für einen bestimmten Rendering- Knoten/ Rendering- Algorithmus oder einer Menge davon, Angabe, welche Rendering- Knoten/ Rendering-Algorithmen von anderen abhängig sind, Angabe, welche Rendering- Knoten/ Rendering-Algorithmen Systemressourcen gemeinsam nutzen können, Angabe, welche Rendering- Knoten/ Rendering- Algorithmen gleichzeitig ausgeführt werden können. System- Barrieren können auch explizite Befehle sein, die an einen Prozessor, z.B. eine GPU, ausgegeben werden. Ein Beispiel für eine Systembarriere ist der Befehl, dass alles, was vor der Barriere eintrifft, beendet werden muss, bevor die nächste Menge von Prozessen beginnt. Semaphore können eine System- Barriere sein.
Mit „gleichzeitig“ ist gemeint, dass zu einem bestimmten Zeitpunkt während des Rendems zwei oder mehr verschiedene Prozesse, z.B. Rendering- Knoten und/ oder Rendering- Algorithmen, aktiv sein können. Sie können gleichzeitig laufen, wobei sie beide gleichzeitig starten und/oder enden. Sie können sich aber auch nur überlappen, wobei die beiden gleichzeitig laufenden Prozesse unabhängig voneinander starten und enden können.
Es kann ein azyklischer Graph erstellt werden, bei dem die Knoten des azyklischen Graphen Rendering- Algorithmen und/ oder Rendering- Knoten innerhalb einer Pipeline darstellen. Beispielsweise kann die gesamte Arbeit, die eine GPU leisten muss, als Knoten in einem azyklischen Graphen dargestellt werden. Innerhalb eines azyklischen Graphen können die Kanten/ Verbindung zwischen den Knoten des azyklischen Graphen die jeweiligen Ein- und Ausgänge der Rendering- Algorithmen und/ oder Rendering- Knoten sein. Wie hier beschrieben, ist ein azyklischer Graph typischerweise ein gerichteter azyklischer Graph.
Ein beispielhafter azyklischer Graf 10 einer einfachen Rendering- Pipeline ist in 1 dargestellt. Der azyklische Graf 10 enthält eine Vielzahl von Rendering- Knoten 12a- 12c & 13-17. Jeder Rendering- Knoten ist ein Prozess, der über definierte Ein- und Ausgänge R1- R9 verfügt. Wie im Beispiel gezeigt, kann es einen Rendering- Algorithmus 12 geben, der sich aus einer Reihe von Rendering- Knoten 12a, 12b und 12c zusammensetzt. Der Rendering- Algorithmus kann als solcher unterteilt werden, basierend auf den Teilprozessen mit unterschiedlichen Eingangs- und Ausgangsanforderungen.
Wie aus dem Graf 10 ersichtlich ist, gibt Rendering- Knoten 12a die Ressource R1 aus, die ein Input für Rendering- Knoten 12b ist. Der Rendering- Knoten 12b benötigt auch die Ausgabe R2 des Rendering- Knotens 13. Der Rendering- Knoten 12b gibt dann die Ressourcen R3 und R4 aus, die Eingänge sind, um die Knoten 12c und 15 zu rendem. Die Ressourcen R3 und R4 können die gleichen Informationen sein und einfach als zwei Flanken im azyklischen Graf 10 dargestellt werden, da, während die Informationen gleich sind, es zwei verschiedene Eingänge gibt. Außerdem kann der Prozess des Rendering-Knotens 12b zwei getrennte Datensätze gleichzeitig erzeugen, die unterschiedliche Ausgänge und unterschiedliche Eingänge sind.
Rendering- Knoten 13 und 15 zum Beispiel können im Wesentlichen der gleiche Prozess und einfach zwei verschiedene Durchläufe desselben Prozesses sein. Da die beiden Durchläufe des gleichen Prozesses unterschiedliche Ein- und Ausgänge haben, wie aus dem Graf ersichtlich, können sie daher als separate Rendering- Knoten innerhalb der Rendering- Pipeline betrachtet werden.
Wie aus dem gerichteten Graphen zu ersehen ist, speisen die Rendering- Knoten 12a- 16 in den Endknoten 17 ein, der dann in der Lage ist, das fertige Bild zu rendem. Ein konkreteres Beispiel für eine Rendering- Pipeline mit definierten Rendering- Knoten wird im Folgenden beschrieben. Jede Rendering- Pipeline kann jedoch als solche Rendering- Knoten mit unterschiedlichen Ein- und Ausgängen beschrieben werden. Mit diesen Informationen kann die Pipeline zu einem ähnlichen azyklischen Graphen zusammengesetzt werden.
Die Reihenfolge einer Rendering- Pipeline, z.B. einer High- Level- Rendering- Pipeline, kann anhand eines azyklischen Graphen der Einheiten festgelegt werden. Die Einheiten der High- Level-Rendering- Pipeline können Rendering- Knoten, Rendering- Algorithmen einer Kombination davon sein. Die Reihenfolge kann z.B. durch Ausführen einer topologischen Sortierfunktion auf dem azyklischen Graphen festgelegt werden. Das Ergebnis kann dann eine geordnete Einzelliste von Arbeitseinheiten sein, die beim Rendem ausgeführt werden sollen. Zusätzlich kann diese Liste der Arbeitseinheiten die gleichzeitig ausführbaren Arbeitseinheiten und/ oder Informationen darüber enthalten, welche Arbeitseinheiten gleichzeitig ausgeführt werden können. Solche Informationen können Informationen darüber enthalten, welche Arbeitseinheiten nicht von bestimmten anderen abhängig sind, oder Informationen von bestimmten anderen benötigen. Ebenso können solche Informationen auch Informationen darüber enthalten, welche Arbeitseinheiten die gleichen oder ähnlichen Ressourcen benötigen.
Darüber hinaus kann auf Basis der Kanten/ Verbindungen eines azyklischen Graphen eine Reihe von Systemressourcenbarrieren definiert werden. Diese Barrieren oder Informationen über diese Barrieren können in einer Rendering- Pipeline gespeichert und/ oder zugänglich gemacht werden. Daher können diese Systemressourcenbarrieren vor oder während der Ausführung einer Rendering- Pipeline, auf die sie sich beziehen, ausgegeben werden.
Auf Basis eines azyklischen Graphen kann auch eine Liveness Analyse (Lebensdauer-Analyse) durchgeführt werden. Aus der Lebensdauer-Analyse kann die Speicherzuordnung bzw. SpeicherCache- Flush für eine zugehörige Rendering- Pipeline ermittelt werden. Die Speicherzuordnung bzw. das Memory- Cache Flushing kann somit anhand der Ressourcen bestimmt werden, die durch die Kanten/ Verbindungen des azyklischen Graphen beschrieben werden. Ebenso kann die Speicherzuordnung bzw. das Memory Cache Flushing anhand der Ein- und Ausgänge von Rendering- Knoten und Rendering- Algorithmen bestimmt werden. Daher kann einem Rendering-Knoten oder Rendering- Algorithmus nur so lange Speicher zugewiesen werden, wie er während der Ausführung benötigt wird.
Die Speicherzuweisung und/ oder die Speicher- Cache- Löschung oder Informationen darüber können in einer Rendering- Pipeline gespeichert und/oder darauf zugegriffen werden. Daher kann der Speicher vor oder während der Ausführung einer Rendering- Pipeline, auf die er sich bezieht, partitioniert, allokiert und/ oder geflusht/entleert werden.
Rendering- Knoten können unabhängig von einem breiteren Rendering- Algorithmus erstellt werden. Beispielsweise kann eine High- Level- Rendering- Pipeline eine Reihe von generischen Rendering- Algorithmen enthalten, z.B. Shadow Map Generation (Schattenwurferzeugung) Rendering- Algorithmus, Light Data Calculation (Lichtdatenberechnung) Rendering- Algorithmus, Opak- Object- Rendering- Algorithmus usw. Ein Benutzer kann dann einen oder mehrere eindeutige und/oder zusätzliche Rendering- Knoten definieren.
Ein Beispiel für einen Rendering- Knoten kann ein spezifisches Glühen um ein bestimmtes Objekt oder einen bestimmten Objekttyp sein. Ein Rendering- Knoten kann als eine bestimmte Arbeitseinheit betrachtet werden. Ein Rendering- Knoten kann auch als durch seine Ein- und Ausgänge definiert betrachtet werden. So kann z.B. ein Kugel /Orb- Glüh- Rendering- Knoten die Kugel /Orb- Glühdaten für ein Objekt als Ausgabe haben und als Eingangslichtdaten, Objektpositions- / Orientierungsdaten und Objektoberflächentexturdaten haben.
Ein Rendering- Knoten, der durch seine Ein- und Ausgänge definiert ist, kann von einem Benutzer ohne detaillierte Kenntnisse einer größeren Rendering- Pipeline oder, wie der Rendering- Knoten zu integrieren ist, einfach erstellt werden. Mit definierten Ein- und Ausgängen kann der Rendering-Knoten jedoch einfach zu einem azyklischen Graphen, z.B. einem bestehenden azyklischen Graphen, hinzugefügt und anschließend sortiert und nahtlos in eine Rendering- Pipeline integriert werden.
Zusätzlich kann ein Rendering- Knoten ein Durchlauf eines Rendering- Algorithmus sein. Ein Rendering- Knoten kann auch mehrere verknüpfte Durchläufe eines oder mehrerer Rendering-Algorithmen sein. Ein Rendering- Knoten kann auch eine Rendering- Routine sein oder enthalten. Beispielsweise empfängt die Unterarbeitseinheit eine Menge von Eingaben, durchläuft eine Routine und erzeugt eine Ausgabe. Die Routine kann einfach oder komplex sein und kann vorbestimmt oder dynamisch sein.
Nach bestimmten Beispielen können Informationen über den Speicherbedarf gespeichert und/ oder zugänglich gemacht werden für eine Low- Level- Rendering- Pipeline. So kann z.B. eine High-Level- Rendering- Pipeline die Reihenfolge der Arbeitseinheiten (Rendering- Knoten und/ oder Rendering- Algorithmen) festlegen, die während des Renderings ausgeführt werden sollen, und eine Lower- Level- Pipeline kann einen Rendering- Graphen durchlaufen, um minimale Zustandsübergänge und den damit verbundenen Speicherbedarf zu bestimmen.
Darüber hinaus kann z.B. eine Low- Level Rendering- Pipeline festlegen, dass mehr Speicher als minimal benötigt wird, um mehrere Arbeitseinheiten oder Rendering- Knoten gleichzeitig zu betreiben. Die Informationen darüber, welche Arbeitseinheiten und/ oder Rendering- Knoten gleichzeitig betrieben werden können, können in den High- Level- Rendering- Pipelines gespeichert und/ oder zugänglich gemacht werden.
Zusätzlich, während hierin eine high/ higher -Level- Rendering- Pipeline und eine Rendering-Pipeline mit Low/Lower- Level Ebene beschrieben wird, kann jedes Merkmal, das hierin in einer Ebene beschrieben wird, auf die andere Ebene verschoben und/ oder kopiert werden. Darüber hinaus können alle hier beschriebenen Merkmale in einer einstufigen Rendering- Pipelinekombiniert oder in einer oder mehreren dritten Rendering- Pipelines verteilt werden. Ähnlich kann das, was hier als High- Level- Rendering- Pipeline beschrieben wird, in eine Low- Level- Rendering-Pipeline getauscht und/ oder einfach als Low- Level- Rendering- Pipeline betrachtet werden und umgekehrt.
Die hier beschriebenen Verfahren können in Echtzeit ausgeführt werden oder vor dem Rendem ausgeführt werden. So können z.B. der Inhalt und/ oder die Reihenfolge von Rendering- Pipelines, Systemressourcenbarrieren, Speicherzuordnungsinformationen oder eine Kombination davon vorgegeben werden. Während der Ausführung eines Programms zur Anzeige eines Bildes auf einem Anzeigegerät kann die Programm/ Grafik- Engine einfach ausgegeben werden oder auf die vorgegebenen Informationen zugreifen und anschließend das finale Rendering durchführen.
Als Beispiel kann eine einfache Rendering- Pipeline einen Schattenwurfgenerierungs- Rendering-Knoten, einen Lichtdatenberechnungs- Rendering- Knoten, einen Opakes- Objekt- Rendering-Algorithmus, einen Transparentes- Objekt- Rendering- Algorithmus, einen Tonemapping-Rendering- Knoten und einen Tiefenschärfe- Rendering- Algorithmus enthalten. Aus einem azyklischen Graphen kann bestimmt werden, dass der Algorithmus für das Rendem opaker Objekte und der Algorithmus für das Rendern transparenter Objekte jeweils Schattenwurfdaten aus dem Rendering- Knoten für die Erzeugung von Schattenwurf und Lichtdaten aus dem Rendering- Knoten für die Berechnung von Lichtdaten benötigen.
Da Lichtdaten- und Schattenwurfgenerierung unabhängig voneinander sind, kann eine Grafik-Engine oder GPU diese Arbeit, z.B. diese beiden Rendering- Knoten, parallel, z.B. gleichzeitig, einplanen. Darüber hinaus kann die Grafik- Engine sicherstellen, dass diese Rendering- Knoten abgeschlossen/verbunden sind, bevor ein opaker Pass- Rendering- Knoten aus dem Rendering-Algorithmus für opake Objekte eingeplant wird. Die Systemressourcenbarrieren können hier die Reihenfolge oder Informationen über die Reihenfolge der auszuführenden Rendering- Knoten und die damit verbundenen CPU- / GPU- Anforderungen sein.
Da der Rendering- Algorithmus für transparente Objekte sowohl von Schattenwurfdaten als auch von Lichtdaten und einer opaken Passausgabe als Eingaben abhängt, kann die Grafik- Engine den Rendering- Algorithmus für transparente Objekte so einplanen, dass er ausgeführt wird, nachdem ein erforderlicher opaker Pass-Rendering- Knoten beendet ist.
Anschließend können Tonemapping/ Dynamikkompression und Schärfentiefe festgelegt werden. Wenn der Tonemapping- Rendering- Knoten als Eingabe Zwischentexturen (z.B. Downsample der Szene) benötigt und der Algorithmus für die Tiefenschärfe auch die Zwischentexturen benötigt, kann der Scheduler den gleichen Speicher für den Tonemapping- Rendering- Knoten und den Algorithmus für die Tiefenschärfe verwenden. Bei Bedarf kann der Scheduler auch korrekte Barrieren zwischen ihnen ausgeben. Anstatt z.B. einen Befehl zu geben, um einen Speichercache der Zwischentexturen nach einem tonemapping Rendering- Knotenübergang zu leeren, kann ein Tiefenschärfe- Rendering- Knotenübergang zu einem ähnlichen Zeitpunkt eingeplant werden, die gleichen zwischengespeicherten Zwischentexturdaten verwenden und erst danach ist eine Anweisung für die Zwischentexturdaten, die aus dem Speichercache zu leeren sind, abzugeben.
Darüber hinaus kann der Algorithmus für die Tiefenschärfe nur die Tiefe für einen internen Kreis von einem Konfusion- Berechnungs- Rendering- Knoten benötigen. In einem späteren Rendering-Knoten benötigt der Algorithmus für die Tiefenschärfe jedoch die Tonemapping- Ausgabe. Daher kann der Scheduler den tonemapping Rendering- Knoten und den Kreis des Konfusion-Berechnung Rendering- Knoten ausführen, die parallel ausgeführt werden sollen. Daher können diese Rendering- Knoten gleichzeitig ausgeführt werden, auch wenn ein Tonemapping- Rendering-Algorithmus und ein Tiefenschärfe- Rendering- Algorithmus nicht gleichzeitig ausgeführt werden können.
2 zeigt ein Beispiel für ein High- Level- Verfahren 40, das die hier beschriebenen Prinzipien umsetzt. Das High- Level- Verfahren 40 kann zwei getrennte Verfahren 20 und 30 enthalten. Das gezeigte Verfahren 20 kann als Vorverarbeitungsstufe betrachtet werden. Verfahren 20 kann z.B. in der Vorverarbeitung auf einem ersten Gerät, Hostgerät oder Anzeigegerät durchgeführt werden.
Verfahren 30 kann z.B. ein Rendering- Verfahren auf einem Anzeigegerät sein. Somit können die Verfahren 20 und 30 von unabhängigen Geräten oder am selben Gerät durchgeführt werden. Zusätzlich können Schritte innerhalb der beiden Verfahren oder die beiden Verfahren selbst sequentiell oder parallel ablaufen. Zusätzlich kann z.B. Verfahren 20 einmal auf einem ersten Gerät und dann Verfahren 30 später auf mehreren verschiedenen Anzeigegeräten ausgeführt werden.
Verfahren 20 beschreibt ein Verfahren zur Zuweisung von Ressourcen für das Rendering. Das Verfahren beinhaltet das Zusammensetzen 21 von einer Vielzahl von Rendering- Knoten. Die Rendering- Knoten können ihre definierten Ein- und Ausgänge haben. Aus der zusammengesetzten Menge von Rendering- Knoten kann ein Zeitplan erstellt werden 22. Der kompilierte Zeitplan für die mehreren Rendering-Knoten kann zu mindestens auf den definierten Eingaben und Ausgaben basieren. Zusätzlich kann die Vielzahl der Rendering-Knoten so eingeplant werden, dass mehr als ein Rendering-Algorithmus zu einem Zeitpunkt ausgeführt werden kann. Innerhalb der Kompilierung/Zusammenführung kann eine Reihe von Ressourcenbarrieren definiert werden. Die Menge von Ressourcenbarrieren kann Systemressourcenbarrieren beinhalten. Diese Systemressourcenbarrieren können bei der Bearbeitung der Menge der Rendering- Knoten basierend auf dem erstellten Zeitplan verwendet werden.
Der Zeitplan und/ oder die Schranken können dann in einem Speicher eines elektronischen Gerätes gespeichert werden. Diese können vor dem Rendem gespeichert werden, z.B. vor der Durchführung der zugehörigen Verfahren 30 auf einem Anzeigegerät.
Die Informationen aus Verfahren 20 können dann durch einen Rendering- Prozess 30 abgerufen werden. Sobald der Rendering- Prozess 30 gestartet ist, können auf Basis des Zeitplans und/ oder der Barrieren Aufträge an ein Host- Gerät erteilt werden. Das Host- Gerät kann eine Grafikprozessoreinheit (GPU) sein oder enthalten. Das Host- Gerät kann auch eine zentrale Verarbeitungseinheit (CPU) oder ein anderes Ganzes oder Teil einer Verarbeitungseinheit sein oder enthalten. Sobald die Aufträge vom Hostgerät ausgeführt werden, wird ein gewünschtes Bild gerendert 33.
Verfahren 20, 30 oder 40 kann die Erstellung einer High- Level- Rendering- Pipeline und einer Lower- Level- Rendering- Pipeline beinhalten. Die High- Level- Rendering- Pipeline kann die Baugruppe 21 von Rendering- Knoten und deren Abhängigkeiten enthalten. Die Rendering-Pipeline der unteren Ebene kann das Zusammensetzen 22 und die erstellten/ gespeicherten Zeitpläne und Barrieren umfassen. Die Pipeline der unteren Ebene kann die Bestimmung von minimalen Zustandsübergängen und/oder Speicherbedarf für jeden der Rendering- Knoten beinhalten. Darüber hinaus kann die Pipeline auf der unteren Ebene die expliziten Aufträge enthalten und/ oder die expliziten Aufträge erteilen 32.
Im Wesentlichen kann die untergeordnete Pipeline die tatsächliche Ressourcenzuweisung für das Rendering übernehmen. Die High- Level- Rendering- Pipeline kann somit die Informationen über die Prozesse und Abhängigkeiten enthalten, die die Ressourcenzuweisung erfordern. Beispielsweise kann die High- Level- Rendering- Pipeline eine Kette der Rendering- Knoten definieren, die in der Lage ist, ein gewünschtes gerendertes Bild oder eine Reihe von Bildern zu erzeugen. Die untergeordnete Rendering- Pipeline kann dann u.a. bestimmen, wie viele Rendering-Knoten zu einem bestimmten Zeitpunkt gleichzeitig parallel betrieben werden können.
Das Erstellen eines Zeitplans und/ oder Kompilieren kann die Erstellung des gerichteten azyklischen Graphen der Rendering- Knoten, ihrer Eingänge und ihrer jeweiligen Ausgänge beinhalten. Innerhalb des azyklischen Graphen können die Knoten Rendering- Knoten und/oder Rendering- Algorithmen sein. Die Kanten zwischen den Knoten im azyklischen Graphen können die Abhängigkeiten zwischen den Rendering- Knoten sein, basierend auf den Ein- und Ausgängen der Rendering- Knoten.
Verfahren 20 kann weiterhin, z.B. im Kompilierschritt 22, die topologische Sortierung eines azyklischen Graphen in eine einzige Liste umfassen. Die Einzelliste kann eine Folge von Rendering- Knoten sein, die ausgeführt werden können. Ein Auftrag kann Abhängigkeiten zwischen verschiedenen Rendering- Knoten enthalten, einschließlich derjenigen, die aussagen, welche Rendering- Knoten oder Mengen von Rendering- Knoten unabhängig von anderen ausgeführt werden können.
Systemressourcenbarrieren können auf der Basis der Kanten aus dem azyklischen Graphen definiert werden, z.B. im Kompilierschritt 22. Eine definierte Menge von Systemressourcen kann die Ressourcenanforderungen und/oder die Zuweisung von Host- Geräten (z.B. CPU oder GPU) umfassen. So kann z.B. für einen Rendering- Knoten nur so viel Speicherplatz zugewiesen werden, wie für den Rendering- Knoten benötigt wird. Rendering- Ressourcen, die als Input/ Eingabe für einen Rendering- Knoten benötigt werden, können in einem Memory/ Speicher- Cache gehalten und für einen anderen Rendering- Knoten wiederverwendet werden.
Zusätzlich, z.B. wenn eine Ressource schreibgeschützt ist, können mehrere Rendering- Knoten, die die gleichen oder ähnliche Rendering- Ressourcen verwenden und die unabhängig voneinander sind, nahe beieinander eingeplant werden, um die gecachte Rendering- Ressource zu nutzen.
Speicher- Cache- Flush- Befehle 32 können für die gecachte Rendering- Ressource aus der Menge der Systemressourcenbarrieren ausgegeben werden, oder sie werden nach der Ausgabe des letzten Rendering- Knotens, der die gleiche oder ähnliche Rendering- Ressource benötigt, ausgegeben. Speicher kann allokiert werden und/ oder Speicher- Cache- Flush- Befehle können auf der Grundlage einer Lebensdauer-Analyse der Kanten eines azyklischen Graphen der Rendering-Knoten einer Rendering- Pipeline erstellt werden. Ein Beispiel hierfür ist das Einfärben von Graphen / graph coloring.
Ein Vorteil, der sich aus den bisherigen Verfahren ergibt, besteht darin, dass der Anwender einen Prozess unabhängig von einer Rendering- Engine bzw. Grafik- Engine definieren kann. Der Prozess kann dann als Rendering- Knoten mit den Ressourcen, die er benötigt, bestimmt werden. Der Rendering- Knoten kann dann zu einer bestehenden Rendering- Pipeline und/ oder einer Menge von Rendering- Knoten hinzugefügt werden. Die neue Menge von Rendering- Knoten mit dem zusätzlichen Rendering- Knoten kann dann neu kompiliert werden. Auf diese Weise kann ein Entwickler auf einfache Weise kleine Prozesse oder Gruppen von Prozessen aus einer größeren Pipeline hinzufügen, modifizieren und entfernen, ohne dass er selbst explizit wissen muss, wie sich diese Änderungen auf die gesamte Ressourcenzuweisung des Rendering- Prozesses auswirken. Daher kann ein Verfahren 20 auch die Definition eines neuen Rendering- Knotens, seiner erforderlichen Eingaben und Ausgaben, sowie das Hinzufügen des neuen Rendering- Knotens zu einer bestehenden Rendering- Pipeline beinhalten. Der neue Rendering- Knoten kann durch Hinzufügen des neuen Rendering- Knotens zu einem azyklischen Graphen der vorhandenen Rendering- Pipeline auf der Grundlage der erforderlichen Ein- und Ausgänge hinzugefügt werden.
Zusätzlich kann es ein elektronisches Gerät geben, das eine Grafikverarbeitungseinheit (GPU), ein elektronisches Display, das mit der GPU verbunden ist, eine eingebettete Grafik- Engine mit einer Menge von Rendering- Algorithmen, die auf der GPU ausgeführt werden, hat, um ein Bild auf dem elektronischen Display zu erzeugen, und ein nicht- transitorisches, computerlesbares Medium, auf dem eine Menge vordefinierter Systemressourcenbarrieren gespeichert ist, die der GPU zugeordnet werden können, und eine vordefinierte zeitgesteuerte Reihenfolge der Rendering- Algorithmen für die Verarbeitung.
Darüber hinaus kann es ein nicht- transitorisches, computerlesbares Medium geben, auf dem eine Menge von computerlesbaren Anweisungen gespeichert ist, um einen Prozessor eines Rechengeräts dazu zu veranlassen, die oben beschriebenen Verfahren und Schritte auszuführen.
Es ist festzustellen, dass die Ausführungsformen der offenbarten Erfindung nicht auf die hierin offenbarten Strukturen, Verfahrensschritte oder Materialien beschränkt sind, sondern auf Äquivalente davon ausgedehnt werden können, wie sie von denjenigen anerkannt werden, die in den einschlägigen technischen Gebiet üblicherweise ausgebildet sind. Es sollte auch verstanden werden, dass die hier verwendete Terminologie nur zur Beschreibung bestimmter Ausführungsformen verwendet wird und nicht als einschränkend zu verstehen ist.
Der Verweis in dieser Beschreibung auf „eine Ausführungsform“ oder „die Ausführungsform“ bedeutet, dass ein bestimmtes Merkmal, eine Struktur oder ein Merkmal, das im Zusammenhang mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. So beziehen sich die Erscheinungen der Begriffe „in einer Ausführungsform“ oder „in der Ausführungsform“ an verschiedenen Stellen dieser Beschreibung nicht notwendigerweise alle auf dieselbe Ausführungsform.
Wie hierin verwendet, können eine Vielzahl von Elementen, Strukturelementen, Kompositionselementen und/ oder Materialien in einer gemeinsamen Liste zur Vereinfachung dargestellt werden. Diese Listen sollten jedoch so ausgelegt werden, als ob jedes Mitglied der Liste einzeln als separates und einzigartiges Mitglied identifiziert wird. Daher ist kein einzelnes Mitglied einer solchen Liste als de facto gleichwertig mit einem anderen Mitglied derselben Liste zu verstehen, das allein auf der Grundlage seiner Darstellung in einer gemeinsamen Gruppe ohne gegenteilige Hinweise auftritt. Darüber hinaus können verschiedene Ausführungsformen und Beispiele für die vorliegende Erfindung sowie Alternativen für die verschiedenen Bestandteile der Erfindung genannt werden. Es versteht sich von selbst, dass solche Ausführungsformen, Beispiele und Alternativen nicht als faktische Äquivalente zueinander zu verstehen sind, sondern als eigenständige und autonome Repräsentationen der vorliegenden Erfindung.
Darüber hinaus können die beschriebenen Merkmale, Strukturen oder Merkmale in geeigneter Weise in einer oder mehreren Ausführungsformen kombiniert werden. In der folgenden Beschreibung sind zahlreiche spezifische Details aufgeführt, wie z.B. Beispiele für Längen, Breiten, Formen usw., um ein gründliches Verständnis der Ausführungsformen der Erfindung zu vermitteln. Ein Fachmann wird jedoch erkennen, dass die Erfindung ohne eines oder mehrere der spezifischen Details, oder mit anderen Verfahren, Komponenten, Materialien usw. praktiziert werden kann. In anderen Fällen werden bekannte Strukturen, Materialien oder Vorgänge nicht detailliert dargestellt oder beschrieben, um zu vermeiden, dass Aspekte der Erfindung verdeckt werden.
Während die vorangehenden Beispiele die Prinzipien der vorliegenden Erfindung in einer oder mehreren speziellen Anwendungen illustrieren, wird es für einen Fachmann auf diesem Gebiet offensichtlich sein, dass zahlreiche Änderungen in Form, Gebrauch und Einzelheiten der Umsetzung ohne die Ausübung der erfinderischen Fähigkeit und ohne Abweichung von den Prinzipien und Konzepten der Erfindung vorgenommen werden können. Dementsprechend ist es nicht beabsichtigt, die Erfindung zu beschränken, es sei denn, es handelt sich um die nachfolgend aufgeführten Ansprüche.

Claims

Verfahren zum Zuweisen von Ressourcen zum Rendem, umfassend die computerimplementierten Schritte von: - Zusammensetzen einer Vielzahl von Rendering- Knoten, von denen jeder einen definierten Eingang und Ausgang hat, - Erstellen eines Zeitplans für die Vielzahl von Rendering- Knoten, der zumindest auf dem definierten Input und Output basiert, wobei die Vielzahl von Rendering- Knoten so geplant sind, dass mehr als ein Rendering- Algorithmus zu einem Zeitpunkt ausgeführt werden kann, - Definieren einer Menge von Systemressourcenbarrieren für die Verarbeitung der Menge von Rendering- Knoten basierend auf dem erstellten Zeitplan.
Das Verfahren nach Anspruch 1, wobei die definierte Menge von Systemressourcenbarrieren und der erstellte Zeitplan vor dem Rendem in einem computerlesbaren Medium gespeichert werden.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei das Verfahren das Erstellen einer High- Level- Rendering- Pipeline und einer Low- Level Rendering- Pipeline umfasst, wobei die High- Level- Rendering- Pipeline das Zusammensetzen von Rendering- Knoten und deren Abhängigkeiten umfasst, und wobei die Low- Level Rendering- Pipeline das Erstellen des Zeitplans und einer definierten Menge von Systemressourcenbarrieren umfasst, und wobei die Low- Level Rendering- Pipelinefemer das Bestimmen von minimalen Zustandsübergängen und/ oder Speicheranforderungen für jeden der Rendering- Knoten umfasst.
Das Verfahren nach Anspruch 3, wobei die High- Level- Rendering- Pipeline eine Kette der Rendering- Knoten definiert, die in der Lage ist, ein gewünschtes gerendertes Bild oder eine Reihe von Bildern zu erzeugen.
Das Verfahren nach einem der Ansprüche 3 oder 4, wobei die Low- Level- Rendering- Pipeline bestimmen kann, wie viele Rendering- Knoten zu einem bestimmten Zeitpunkt gleichzeitig parallel betrieben werden können.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei das Erstellen des Zeitplans das Erstellen eines gerichteten azyklischen Graphen der Rendering- Knoten, ihrer Eingänge und ihrer jeweiligen Ausgänge umfasst.
Das Verfahren nach Anspruch 6, bei dem innerhalb des azyklischen Graphen die Knoten Rendering- Knoten und/ oder Rendering- Algorithmen sind und die Kanten zwischen den Knoten im azyklischen Graphen Abhängigkeiten zwischen den Rendering- Knoten auf der Grundlage der Ein- und Ausgänge der Rendering- Knoten sind.
Das Verfahren nach Anspruch 6 oder 7, ferner umfassend die topologische Sortierung des azyklischen Graphen in eine einzige Liste, die eine Ordnung von ausführbaren Rendering-Knoten ist.
Das Verfahren nach Anspruch 8, wobei die Reihenfolge Abhängigkeiten zwischen verschiedenen Rendering- Knoten einschließt, einschließlich derjenigen, die Rendering- Knoten oder Rendering- Knoten- Mengen unabhängig von anderen ausgeführt werden können.
Das Verfahren nach einem der Ansprüche 6-9, wobei die Systemressourcenbarrieren ausgehend von den Kanten des azyklischen Graphen definiert werden.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei eine Vielzahl von Rendering-Knoten einen Rendering- Algorithmus bildet.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei ein Rendering- Knoten ein Durchlauf eines Rendering- Algorithmus ist.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei jeder Rendering- Knoten eine Routine und/ oder ein Abarbeiten ist, die von einer Grafikverarbeitungseinheit (GPU) ausgeführt werden soll.
Das Verfahren nach einem der vorangehenden Ansprüche, ferner umfassend das Definieren eines neuen Rendering- Knotens, seiner erforderlichen Eingaben und seiner erforderlichen Ausgaben und das Hinzufügen des neuen Rendering- Knotens zu einer bestehenden Rendering- Pipeline.
Das Verfahren nach Anspruch 14, bei dem der neue Rendering- Knoten durch Hinzufügen des neuen Rendering- Knotens zu einem azyklischen Graphen der bestehenden Rendering-Pipeline auf der Grundlage seiner erforderlichen Ein- und Ausgänge hinzugefügt wird, und durch Neukompilieren, um einen neuen Zeitplan und eine Menge von Systemressourcenbarrieren auf der Grundlage der neuen Menge von Rendering- Knoten zu erstellen.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei die definierte Menge von Systemressourcen Speicher- Cache- Flush-Befehle und/ oder Speicherzuweisung enthält.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei die definierte Menge von Systemressourcen die Anforderungen an die Ressourcen des Hostgeräts und/ oder die Zuweisung umfasst.
Das Verfahren nach einem der Ansprüche 16 oder 17, wobei Speicher für einen Rendering-Knoten nur für die erforderliche Zeitdauer für den Rendering- Knoten allokiert wird.
Das Verfahren nach einem der Ansprüche 16 oder 17, wobei Rendering- Ressourcen, die als Input für einen Rendering- Knoten erforderlich sind, in einem Speichercache gehalten und für einen anderen Rendering- Knoten wiederverwendet werden.
Das Verfahren nach Anspruch 19, wobei mehrere Rendering- Knoten, die gleiche oder ähnliche Rendering- Ressourcen verwenden und unabhängig voneinander sind, nahe beieinander angeordnet sind, um die gecachte Rendering- Ressource zu nutzen.
Das Verfahren nach Anspruch 20, bei dem Speichercache- Flush- Befehl für die zwischengespeicherte Rendering- Ressource aus der Menge der Systemressourcenbarrieren ausgegeben werden oder geplant werden, nachdem der letzte Rendering- Knoten, der die gleiche oder ähnliche Rendering- Ressource benötigt, sein Ergebnis ausgegeben hat.
Das Verfahren nach einem der vorangehenden Ansprüche, wobei der Speicher allokiert wird und/ oder Speicher- Cache- Flush- Befehle auf einer Lebensdauer-Analyse der Kanten eines azyklischen Graphen der Rendering- Knoten einer Rendering- Pipeline basieren.
Nicht- transitorisches, computerlesbares Medium, auf dem eine Menge von computerimplementierbaren Anweisungen zur Durchführung der Schritte eines der Verfahrensansprüche 1-22 gespeichert ist.
Verfahren zum Rendem eines Bildes auf einer elektronischen Anzeigevorrichtung, umfassend die computerimplementierten Schritte von: - Empfangen einer Menge von Systemressourcenbarrieren für eine Grafikverarbeitungseinheit (GPU), die mit dem elektronischen Anzeigegerät verbunden ist, - Empfangen einer geplanten Reihenfolge einer Menge von Rendering- Algorithmen, die von der GPU gerendert werden sollen, wobei mindestens einige der Rendering- Algorithmen gleichzeitig verarbeitet werden können, - Rendern eines Bildes auf dem elektronischen Anzeigegerät durch Ausführen der Rendering-Algorithmen in Übereinstimmung mit der empfangenen geplanten Reihenfolge unter Verwendung der zugewiesenen Systemressourcen der GPU auf der Grundlage der Menge der empfangenen Systemressourcenbarrieren.
Das Verfahren zum Rendem nach Anspruch 24, wobei die Menge der Systemressourcenbarrieren und die geplante Reihenfolge der Menge der Rendering-Algorithmen in Übereinstimmung mit einem der Ansprüche 1-22 bestimmt wird.
Elektronische Vorrichtung, umfassend; - eine Grafikverarbeitungseinheit (GPU), - ein elektronisches Display, das mit der GPU verbunden ist, - eine eingebettete Grafik- Engine mit einer Menge von Rendering- Algorithmen, die auf der GPU ausgeführt werden, um ein Bild auf der elektronischen Anzeige zu erzeugen, und - ein nicht- transitorisches, computerlesbares Medium, auf dem eine Menge vordefinierter Systemressourcenbarrieren, die der GPU zugeordnet werden können, und eine vordefinierte zeitgesteuerte Reihenfolge der Rendering- Algorithmen für die Verarbeitung gespeichert ist.
Die elektronische Vorrichtung nach Anspruch 26, wobei die Menge von Systemressourcenbarrieren und die geplante Reihenfolge der Menge von Rendering-Algorithmen in Übereinstimmung mit einem der Ansprüche 1-22 bestimmt wird.