Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

31

22.02.2012, 10:51

Ein ganz deutlicher ist eben auch, dass OpenGL nur noch eine Statemachine-basierte Schnittstelle zur Grafikkarte ist, was weder hübsch, noch sinnvoll oder gar komfortabel ist. Von zeitgemäß mal gar nicht zu reden. OpenGL bedarf schon seit sehr viel Jahren ein gründliches Refactoring und eine nützliche Sammlung an Klassen statt diesem 90er-Jahre-C-Interface. Angedacht war das auch irgendwann mal, aber da hat das ARB erstens den Release um Längen verzögert und zweitens am Ende nichtmal was gemacht.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

32

23.02.2012, 12:47

Wenn man nicht gerade ein Faible für Grafikprogrammierung hat, spielt es meiner Meinung nach unter Hobbyisten in 99% der Fälle überhaupt keine Rolle, ob nun OpenGL oder DirectX unter der Oberfläche arbeitet. Ein paar Sprites auf den Schirm klatschen, hier ein Mesh und da ein Shader.. denke, das kriegen OpenGL und DirectX beide noch ganz gut auf die Reihe. Letztendlich bleibts damit einfach Geschmackssache.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

33

23.02.2012, 12:52

Meiner Meinung nach spielt es eben doch eine Rolle, denn sonst würd ich einem Hobbyisten der hier um Rat fragt ja sagen, dass es egal ist ;)
Von den rein technischen Argumenten abgesehen, sollte man auch nicht vergessen, dass es für Direct3D z.B. sehr viel bessere Debugging Tools (Debug Runtime, PIX, Visual Studio 11 Graphics Debugger), bzw. eigentlich generell sehr viel mehr und bessere Tools, Dokumentation und Samples gibt als für OpenGL, was wohl auch für Hobbyisten sehr relevant ist.
Vermutlich sogar sehr viel relevanter als technische Details, da hast du recht...

Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »dot« (23.02.2012, 13:01)


stef

Treue Seele

Beiträge: 246

Wohnort: Kassel

Beruf: Softwareentwickler

  • Private Nachricht senden

34

23.02.2012, 23:14

Zitat

Durch das merkwürdige Objektmodell (der ganze Bind Kram), ist das entweder nur sehr ineffizient möglich ...
Ich habe das aus Interesse gerade mal ausprobiert indem ich in meiner Render-Loop in einer For-Schleife via BIND eine Texture und drei Buffer swappe. Einen Einfluß auf meine Framerate hat das erst wenn die For-Schleife 20000 durchlaufen wird (also 20000 Texture- und 60000 Buffer-Swaps pro Render pass). So ein performancekiller kann das also nicht sein.
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." — Bjarne Stroustrup.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

35

23.02.2012, 23:20

Wie genau hast du das ausprobiert? Beachte auch den Kontext aus dem du das Zitat genommen hast...

stef

Treue Seele

Beiträge: 246

Wohnort: Kassel

Beruf: Softwareentwickler

  • Private Nachricht senden

36

23.02.2012, 23:28

Zitat

Beachte auch den Kontext aus dem du das Zitat genommen hast...

Vieleicht habe ich ja was falsch verstanden, aber ziehlte der Teil deines Posts (und der NV-Link) nicht darauf ab dass das Bind-Use Model von OpenGL ineffizient (langsam) ist ?
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." — Bjarne Stroustrup.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

37

23.02.2012, 23:30

Zitat

Beachte auch den Kontext aus dem du das Zitat genommen hast...

Vieleicht habe ich ja was falsch verstanden, aber ziehlte der Teil deines Posts (und der NV-Link) nicht darauf ab dass das Bind-Use Model von OpenGL ineffizient (langsam) ist ?

Das ist es auch, wie du hier nachlesen kannst: http://origin-developer.nvidia.com/objec…s_graphics.html

Zitat von »NVIDIA«

Measurements have shown that bindless graphics can result in more than 7x speedup!

Natürlich hängt es von der konkreten Anwendung ab ob es relevant wird oder nicht, aber es war offenbar Grund genug für NVIDIA eine eigene OpenGL Extension zu entwickeln um das Ganze zu umgehen...

Meine Aussage, die du oben zitiert hast, bezog sich allerdings nicht auf das, sondern darauf, dass ein Wrappen von OpenGL in Klassen im Sinne der OOP imo nicht sinnvoll möglich ist.
Falls du eine kennst, so bin ich bin natürlich immer an einer guten Lösung interessiert. Ich hab bisher jedenfalls noch keine finden können...

Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von »dot« (23.02.2012, 23:43)


stef

Treue Seele

Beiträge: 246

Wohnort: Kassel

Beruf: Softwareentwickler

  • Private Nachricht senden

38

23.02.2012, 23:42

Das mit dem Wrapper hat mich an dem Post nicht interessiert, sondern nur die Aussage in deinem Link auf die NV-Seite das Bind-Use langsam ist. Ich dachte mir das kann man schnell mal selber ausprobieren indem man einfach ne Menge Binds in eine Render-Loop einbaut und schaut ab wievielen das Einfluß auf die Framerate nimmt.
Das Ergebnis habe ich oben beschrieben.
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." — Bjarne Stroustrup.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

39

23.02.2012, 23:46

Etwas mehr Details wie genau du das gemessen hast wären interessant. Ich hab's selber noch nicht ausprobiert, aber ehrlich gesagt glaub ich, dass NVIDIA sowas nicht umsonst macht. Es hängt natürlich wie gesagt sehr von der Anwendung ab, vermutlich konntest du mit deinem einfachen Test nicht die entsprechenden Bedingungen simulieren, wo das zu messbaren Auswirkungen auf die Performance geführt hätte.

stef

Treue Seele

Beiträge: 246

Wohnort: Kassel

Beruf: Softwareentwickler

  • Private Nachricht senden

40

24.02.2012, 00:06

Also hier erst mal der code von meiner Render-Loop. (Du kennst ja mein Copy and Paste and fort sind die Tabs Problem schon, aber der code ist ja nicht sonderlich komplex)

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
// main message loop
QueryPerformanceFrequency((LARGE_INTEGER*)(&llFrequency));
while (1) 
{
  QueryPerformanceCounter((LARGE_INTEGER*)(&llTime1));
  // check for messages
  if ( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) ) 
  {
    // handle or dispatch messages
    if ( msg.message == WM_QUIT ) 
      break; 
    else 
    {
      TranslateMessage( &msg );
      DispatchMessage( &msg );
    }
  } 
  // Clear buffer (color and depth)
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   
  // move camera
  if(bForward == true)
    Camera.Forward(150.0f * g_fTimeDiff); 
    
  // pasing uniform to shader
  CVector3 vLightPos(0.0f, 200.0f, 0.0f);
  CMatrix44 MVM1, MVM2, NM1, NM2;
  GLint nLocation;
  float m3[9]; 
  CVector3 vTemp(0.0f, 0.0f, 0.0f);
  CMatrix44 mTemp;
  
  // set light pos
  vTemp = Camera.GetCameraMatrix() * (/*CMatrix44::Build_RotationMatrix(g_fTimeElapsed, 0.0f, 0.0f) * */vLightPos);
  nLocation = GL::glGetUniformLocation(nShaderProg, "zLightPos"); 
  GL::glUniform3f(nLocation, vTemp.x, vTemp.y, vTemp.z);
  
  // set mv matrix 1
  MVM1 = Camera.GetCameraMatrix() * CMatrix44::Build_RotationMatrix(0.0f, 0.0f, (PI/ 4.0f) * sinf(g_fTimeElapsed / 0.1f));
  nLocation = GL::glGetUniformLocation(nShaderProg, "zMVM1"); 
  GL::glUniformMatrix4fv(nLocation, 1, false, MVM1.m); 
  
  // set normal matrixn 1
  mTemp = MVM1.Invert();
  mTemp = mTemp.Transpose();
  mTemp.ConvertToMat3(m3);
  nLocation = GL::glGetUniformLocation(nShaderProg, "zNM1"); 
  GL::glUniformMatrix3fv(nLocation, 1, false, m3);
  
  // set mv matrix 2
  MVM2 = Camera.GetCameraMatrix() * CMatrix44::Build_RotationMatrix(0.0f, 0.0f, (PI/-2.0f) * sinf(g_fTimeElapsed / 2.0f));
  nLocation = GL::glGetUniformLocation(nShaderProg, "zMVM2"); 
  GL::glUniformMatrix4fv(nLocation, 1, false, MVM2.m); 
  
  // set normal matrixn 2
  mTemp = MVM2.Invert();
  mTemp = mTemp.Transpose();
  mTemp.ConvertToMat3(m3);nLocation = GL::glGetUniformLocation(nShaderProg, "zNM2");GL::glUniformMatrix3fv(nLocation, 1, false, m3);

  for(int x=0; x<20000; x++) 
  {
    //::Sleep(0);
    Plane.Bind();
    Torus.Bind();
  }
  
  // draw
  Plane.Bind();
  glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
  Plane.Draw();
  Torus.Bind();
  glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
  Torus.Draw();
   
  // Swap back-buffer to front
  SwapBuffers( GL::m_hDC );
  // Calculate frametime
  QueryPerformanceCounter((LARGE_INTEGER*)(&llTime2));g_fTimeDiff = ((float)llTime2 - (float)llTime1) / (float)llFrequency; 
  g_fTimeElapsed += g_fTimeDiff;
}


Die Bind-Methoden von Torus und Plane innerhalb der For-Schleife binden einen Vertex-Buffer, Normal-Buffer, TexCoord-Buffer und eine Textur.
Mit und ohne die For-Schleife habe ich 60 Frames (gemessen mit Fraps).
Erst ab 25000 hat das Ganze Einfluß auf die Framerate.

EDIT by dot: Hab mir erlaubt den Code etwas leserlicher zu machen.
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." — Bjarne Stroustrup.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »dot« (24.02.2012, 00:15)


Werbeanzeige