Linkdump

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.

Re: Linkdump

Beitragvon joggel » 24.02.2018, 15:25

bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1351
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Linkdump

Beitragvon joggel » 02.03.2018, 13:11

Ich find den Link ziemlich interessant und vlt ist da etwas nützliches dabei.
Ich denke es ist eine Erwähnung wert...falls es noch nicht bekannt ist.

https://opensource.google.com/

Weiß nicht, ob es nicht besser in den Thread "Nützliche Opensource Projekte" gehört...
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1351
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Linkdump

Beitragvon Krishty » 05.07.2018, 22:58

https://obscuritory.com/

Alte Spiele, die niemals released wurden.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6591
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Linkdump

Beitragvon joggel » 11.07.2018, 15:00

bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1351
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Linkdump

Beitragvon Krishty » 12.07.2018, 22:02

Das GameCube-Spiel Animal Crossing enthält einen vollständigen NES-Emulator, der aber nie zum Einsatz kam.

Wie man ihn hackt, um beliebige NES-ROMs abzuspielen (via Memory Card): https://jamchamb.github.io/2018/07/11/a ... hacks.html
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6591
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Linkdump

Beitragvon Biolunar » 28.07.2018, 16:16

The Elusive Frame Timing
Kann dieses Problem auch auftauchen, wenn ich in die Simulation per Frame um eine konstante Zeit voranschreiten lasse?
Benutzeravatar
Biolunar
Establishment
 
Beiträge: 128
Registriert: 27.06.2005, 17:42
Alter Benutzername: dLoB

Re: Linkdump

Beitragvon Krishty » 28.07.2018, 16:30

Für alle, die draufklicken: Überspringt die ersten 15 bis 20 Absätze, die sind nur Gelaber. Ich fasse kurz zusammen: Weil die GPU ihre Befehle puffert, hat das Spiel keine Möglichkeit, zu erfahren, wie lange sie tatsächlich für einen Frame brauchte. Das Raten geht manchmal schief, und dann hat man Ruckeln.

Ja, das Problem manifestiert sich möglicherweise auch mit fester Physik-Framerate. Es geht wohl von der GPU aus. Und da verstehe ich den Artikel nicht – ich dachte, bei D3D 12 und Vulkan hätte man direkte Kontrolle über die Nebenläufigkeit der GPU. Schließlich muss man auch händisch synchronisieren, dass man Daten mit der CPU nicht überschreibt, während der aktuelle Frame im Gange ist. Schon D3D 11.1 auf Windows 8 fügte SetMaximumFrameLatency() hinzu, damit man Latenz über Durchsatz bevorzugen kann (also reaktionsschnelles Bild über FPS) indem man die GPU nicht zu weit vorausrendern lässt.

Vielleicht habe ich aber auch falsch gelesen; wie gesagt, in den 10.000 Wörtern ist schwer zu verstehen, was der Typ überhaupt aussagen möchte.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6591
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Linkdump

Beitragvon Jörg » 28.07.2018, 18:55

In der Tat etwas weit ausgeholt. Natürlich kann man perfekte Animationsschritte berechnen wenn man die komplette Dauer eines Frames kennt. Dumm nur das man dann ebenso mit dem nächsten warten muss, ich kann ja nicht zeichnen &animieren ohne das vorige Delta zu kennen.
Also bezahlt man entweder mit dem Verlust jeglichen Pipelinings zwischen Frames oder man schiebt die Animationsberechnung selbst auf die GPU und füttert diese mit einem 'late-latched' Delta welches von der Display-Engine kommt.
Mit genügend Rechenpower ist die erste Variante sicherlich die leichtere, oder habt ihr schon alle die Animationsberechnung in Compute-Shadern laufen? ;)
Jörg
Establishment
 
Beiträge: 294
Registriert: 03.12.2005, 14:06
Wohnort: Trondheim

Re: Linkdump

Beitragvon Krishty » 28.07.2018, 19:44

Ich mache auch mal lange Rede mit kurzem Sinn:

Ich wollte dieses Wochenende was Ähnliches machen: Die Transformationsmatrizen in meinem Scene Graph ändern sich ja pro Frame, was sie inhärent feindlich gegenüber Command Lists macht. Ich kann es umgehen, indem ich die Object-to-World-Matrizen pro Objekt in eigene Constant Buffers packe (ändern sich fast nie) und die View-Projection-Matrix in einen globalen Constant Buffer (ändert sich jeden Frame). Dann aktualisiere ich den Buffer mit View-Projection einmal am Anfang des Frames, stoße die Command List an, und die CPU ist fertig. Nicht mal zehn D3D11-Aufrufe für einen Graph mit 40.000 Objekten – sportlich.

Verdammt, dachte ich – das geht sicher noch besser:
  • Ich habe 40.000 einzelne Constant Buffers rumliegen, die dauernd geswitcht werden. Das ist fett rot im Profiler.
  • Warum muss jedes Vertex zwei Mal transformiert werden? Nicht, dass es viel kostet, aber mir missfällt halt der Gedanke, dass alle Vertex Shader parallel die identische Matrixmultiplikation wiederholen …

Also, warum nicht alle Matrizen des ganzen Graphen in einen riesen Buffer, und am Anfang des Frames einen Compute Shader anstoßen, der alle World-View-Projection-Matrizen aktualisiert? Dann sind die Kosten pro Vertex nochmal niedriger, und die Constant Buffer-Switches weg.

Wie dein Animationsvorschlag.

Naja, erstmal wollte ich einen Structured Buffer dafür benutzen. Dann habe ich gelesen, dass Structured Buffers eigentlich für verteilte Leseoperationen bestimmt sind (jedes Vertex liest von anderer Position), dass sie deshalb hohe Latenz haben und dass ich lieber einen riesen Constant Buffer benutzen sollte, das sei viel schneller.

Aber Constant Buffers haben eine Größenbegrenzung. Die liegt deutlich unter 40.000 Matrizen. D3D 11.1 hat eingeführt, dass man sie viel größer anlegen und dann Subsets adressieren kann – also das erste Objekt nutzt die ersten 72 Bytes, das zweite Objekt die zweiten 72, usw.

Aber D3D 11.1 braucht Windows 8 und das habe ich nicht, also scheiß drauf.

Also doch Structured Buffer. Und da merke ich: Wie zur Hölle teile ich eigentlich einem Modell mit, von welcher Position im Structured Buffer es lesen soll?! Ich müsste jedem Vertex ein zusätzliches uint verpassen, das im kompletten Objekt uniform ist. Oder ich mache einen Constant Buffer pro Objekt nur für den Index im Structured Buffer. Selber Mist in Grün.

DrawIndexedInstanced() hat zwar einen Parameter StartInstanceLocation, aber der wird nicht als SV_InstanceID an den Vertex Shader weitergeleitet. Ich bin nicht der erste, der damit auf die Nase gefallen ist.

Also bleibt alles wie es ist. Weil dieser Aspekt von D3D 11 einfach scheiße entworfen ist. Und weil ich kein Windows 8 habe. Und weil ich für Vulkan gerade nicht die Nerven und Zeit habe.

Und das heißt kurz gefasst: Ich stimme deiner Meinung zu, dass Animationsberechnung im Compute Shader höllisch komplex ist. Nichtsdestotrotz ist es wohl langfristrig und in Anbetracht der Framerate-Probleme der richtige Weg.

Nachtrag: Hier habe ich die gleiche Diskussion und einen tollen Beitrag gefunden.
  • Man erzeugt einen Vertex Buffer, der einfach uint hochzählt: 0, 1, 2, 3, …. So viele Zahlen, wie man Objekte hat.
  • Dann fügt man der Vertex Declaration ein R32_UINT-Element mit dem D3D11_INPUT_PER_INSTANCE_DATA-Attribut hinzu.
  • Vor dem Zeichnen bindet man zusätzlich zu den tatsächlichen Vertex-Daten den hinaufzählenden Buffer.
  • Dann nutzt man DrawInstanced…() statt den normalen Draw…()-Aufrufen, zeichnet nur eine einzige Instance, und übergibt als StartInstanceLocation die ID des Objekts.
  • Das zusätzliche R32_UINT-Element für das Objekt wird im per-Instance Vertex Buffer nachgeschlagen, mit dem Offset von StartInstanceLocation, und da … liegt exakt der gleiche Wert wie StartInstanceLocation, denn der Buffer zählt ja einfach hoch.
  • ???
  • PROFIT
Boah. Wer das für irre hält: So zeichnet Ogre seit 2.1 die gesamte Szene.

OpenGL hat seit 4.schlagmichtot eine extra-Shader-Konstante gl_baseinstance dafür. D3D hat nix. Boah ist das scheiße.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6591
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Vorherige

Zurück zu Allgemeines Talk-Brett

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste