Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 01:39

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 9 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Do Aug 27, 2015 13:34 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Hey,
derzeit baue ich gerade ein kleines Partikelsystem mit Ping-Pong-VBOs und Transform-Feedback. Ich bin mir aber unsicher, was ich beim Erstellen der VBOs als usage am besten angeben sollte. Es werden ja nie (bzw. genau einmal bei der Initialisierung) Daten vom Hauptspeicher in den Grafikspeicher geladen, dennoch wird sehr häufig ins VBO geschrieben. Genauer: Auf jeden Schreibzugriff folgen genau 2 Lesezugriffe (einer zum Rendern der Partikel und einer zum Updaten des jeweils anderen VBOs).

Die Erklärungen zu glBufferData (auch im offiziellen Wiki) beziehen sich offenbar auf die Anzahl der Zugriffe von CPU-Seite aus. Daher die Verunsicherung. Hat da jemand Erfahrungen?

Danke schonmal!

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Aug 27, 2015 16:43 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
müsste das hier nicht genau das sein was du bauen willst?

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Aug 27, 2015 17:03 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Ja, im Prinzip mache ich genau das. Den von dir verlinkten Text habe ich vorhin schon auf irgendeiner anderen Seite gelesen. Aber eine solche Aussage stellt mich nicht zufrieden:
Zitat:
By the way, I don’t think the GL_STREAM_DRAW hint really matters; most drivers are smart enough to manage memory in a way that they think is best.
Der usage Paramter ist doch nunmal da, damit der Treiber eine intelligente Entscheidung treffen kann, basierend auf der Information die man ihm gibt. Ihm irgendeine Information zu geben, führt auch zu irgendeinem Ergebnis, aber wahrscheinlich nicht zum optimalen. Nur, wie sage ich dem Treiber: "CPU-Zugriff findet nur einmal und nur schreibend statt, die GPU liest und schreibt hingegen oft."?

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Aug 27, 2015 18:21 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Naja....
Code:
  1.  
  2. usage​ is a hint to the GL implementation as to how a buffer object's data store will be accessed. This enables the GL implementation to make more intelligent decisions that may significantly impact buffer object performance. It does not, however, constrain the actual usage of the data store. usage​ can be broken down into two parts: first, the frequency of access (modification and usage), and second, the nature of that access. The frequency of access may be one of these:
  3.  

Sprich du müsstest da jetzt also selbst entscheiden was du häufiger benutzt. Wenn du also perfektes Balancing hinbekommst dann wird es wohl sowas wie DYNAMIC & COPY sein...

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Aug 27, 2015 21:38 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Also ich hatte mal bemerkt, dass "GL_STATIC_DRAW" unabhänig von der Verwendung in meiner Applikation immer die beste Performance geliefert hat. Im Prinzip ist das Ergebnis eh ziemlich unvorhersehbar und der Parameter eher eine historische Altlast als wirklich ein nützlicher Tipp für den Treiber. Aus der Information kann er schlecht ableiten, welche Entscheidungen er treffen soll. Der GPU RAM ist, soweit ich weiß, heutzutage eh überall ziemlich allgemein und nicht sehr spezialisiert. Wenn also nicht ein falscher Hint dazu führt, dass der Treiber auf eine dumme Idee kommt (halte ich für unwahrscheinlich), ist das ziemlich egal. Probiere es einfach schnell aus und wenn es keinen Unterschied macht, nimm einfach den Standard "GL_STATIC_DRAW".
"READ" und "COPY" bezieht sich mit Sicherheit auf eine andere Art Operation. Bedenke, dass die Formulierung in OpenGL 1.1 festgelegt wurde. Es ergibt auch Sinn, denn Transform Feedback ist ein Teil der Rendering Pipeline und die konnte damals noch mit "DRAW" beschrieben werden.

Hast du eigentlich darüber nachgedacht ComputeShader zu nutzen? Soweit ich weiß, sollte da möglicherweise eine höhere Performance zu höherer Flexibilität drin sein.


Zuletzt geändert von OpenglerF am Fr Aug 28, 2015 12:05, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 28, 2015 08:39 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
jup wenn das COPY,DRAW und READ halt nur auf die Kommunikation zwischen GPU und CPU auswirkt dann ists natuerlich
ganz eindeutig. Ist halt die Frage was der jeweilige Treiber da reininterpretiert.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 28, 2015 12:55 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Also, ich habe es jetzt ausprobiert und ich kann tatsächlich keinen Unterschied feststellen. Das liegt auch daran, dass der TransformFeedback-Schritt sehr schnell geht. Ich kann über 1.000.000 (ja, eine Million) Partikel von meiner Intel GPU bewegen lassen, ohne dass die Framerate unter 60 fps fällt. Sobald es allerdings ans Rendern der Partikel geht, sind bereits wenige tausend ein Problem (unabhängig von usage).

OpenCL oder ComputeShader setze ich aus Kompatibilitätsgründen nicht ein. Wie schon erwähnt ist Transform Feedback auch schon schnell genug. Warum meinst du, dass ComputeShader schneller wären?

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 28, 2015 13:32 
Offline
DGL Member

Registriert: Do Dez 29, 2011 19:40
Beiträge: 421
Wohnort: Deutschland, Bayern
Programmiersprache: C++, C, D, C# VB.Net
Transform Feedback kommt mit dem Overhead der ganzen Rendering Pipeline und es werden viele Operationen durchgeführt, die du wahrscheinlich nicht benötigst. (Daten im Hintergrund zwischen Buffern hin und hergeschoben, Vertex Shader, w-Division, Ping Pong, etc.)

Ich finde gerade die Quelle nicht mehr. Zum Beispiel steht hier (Seite 33), dass ein Fullscreen Quad einem Compute Shader prinzipiell sehr stark unterlegen ist.

1 000 000 Partikel sind eigentlich nicht wirklich sehr viel. Denke daran, dass in einer einfachen 3D Szene in Full HD mindestens etwa 2 000 000 Millionen Pixel geshaded werden müssen. Das mit vielen Texturen und Shadern, die deutlich mehr machen als ein einfaches Partikelsystem. Das Rendering scheint mir ein wenig extrem langsam, wie gehst du da vor?


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Aug 28, 2015 19:21 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 14, 2013 21:17
Beiträge: 587
Programmiersprache: C++
Den größten Teil der Rendering Pipeline schalte ich bereits hiermit ab:
Code:
  1. glEnable(GL_RASTERIZER_DISCARD);
Da ich auch nur einen Vertexshader habe, findet keine w-Division statt.

Viel hin- und hergeschoben wird auch nicht. Es wird eben aus einem VBO gelesen, die Berechnungen durchgeführt und das Ergebnis ins andere VBO geschrieben. Der Shader ist ziemlich einfach:
Code:
  1. #version 330
  2. layout(location=1) in vec4 inS;
  3. layout(location=2) in vec4 inV;
  4. layout(location=3) in float inTLeft;
  5. layout(location=4) in float inTStart;
  6.  
  7. out vec4 s;
  8. out vec4 v;
  9. out float tLeft;
  10. out float tStart;
  11.  
  12. uniform vec4 u_a;
  13. uniform float u_tStep;
  14.  
  15. uniform vec4 u_minStartS;
  16. uniform vec4 u_rangeStartS;
  17. uniform vec4 u_minStartV;
  18. uniform vec4 u_rangeStartV;
  19. uniform float u_minStartT;
  20. uniform float u_rangeStartT;
  21.  
  22. void main(void)
  23. {
  24.   if(inTLeft < 0.0) {
  25.     // generate new particle
  26.     float rand = float(gl_VertexID % 100) * 0.01;
  27.     s = u_minStartS + rand * u_rangeStartS;
  28.     v = u_minStartV + rand * u_rangeStartV;
  29.     tLeft = u_minStartT + rand * u_rangeStartT;
  30.     tStart = tLeft;
  31.     float deltaT = -inTLeft;
  32.     s += v * deltaT;
  33.     v += u_a * deltaT;
  34.   }
  35.   else {  
  36.     // move particle
  37.     s = inS + inV * u_tStep;
  38.     v = inV + u_a * u_tStep;
  39.     tLeft = inTLeft - u_tStep;
  40.     tStart = inTStart;
  41.   }
  42. }

Er ist auch gar nicht für den "produktiven" Einsatz gedacht (siehe z.B. dieser billige "Zufalls"generator), sondern nur als Test, ob Transform Feedback überhaupt funktioniert. Den Support dafür habe nämlich gestern erst in meine Engine eingebaut. Übrigens, die 60fps-Grenze liegt nicht bei 1.000.000, sondern irgendwo darüber. Ich habe es nicht genau gemessen, aber bei 5.000.000 lief es nicht mehr komplett flüssig - das habe ich nur gesehen, weil ich etwas anderes gerendert habe, denn wenn ich >1 Mio. Partikel rendere, geht die Performance wie gesagt allein deswegen in den Keller. Wieviel Performance nun für die Partikelberechnung draufging und wieviel zum Rendern der eigentlichen Szene - keine Ahnung. Ich fand die Million nur an sich recht beeindruckend, weil es ein Vielfaches von dem ist, was man überhaupt braucht. Und das auf einer ollen Intel HD 4000.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 9 Beiträge ] 
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

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


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.230s | 19 Queries | GZIP : On ]