gleiche performance trotz vertex array?



  • hi folks!

    ich bastle grade ein wenig mit opengl.

    habe eine skybox, plus eine FPS-anzeige als pseudo-HUD.
    und in der skybox noch eine landscape, die aus einer heightmap generiert wurde.
    bis jetzt habe ich jedes triangle per glTexCoord2f() und glVertex3f() gezeichnet.
    dabei bekam ich auf meinem laptop (IBM thinkpad t23 mit 16 MB graka von S3) so um die 10 fps im durchschnitt. das hat mich nicht weiter gewundert, bei der alten graka. also habe ich es zuhause auf meinem rechner getestet, und der hat immerhin eine radeon 9250. dort war die FPS schlechter(!!!), so um die 8 fps im durchschnitt.

    habe ich mir gedacht, wird wohl dran liegen dass ich das alles per function calls zeichne. also habe ich auf vertex arrays umgestellt.

    ergebnis: auf dem laptop immernoch 10 fps durchschnitt, und auf dem desktop-rechner jetzt auch ca. 10 fps.
    und das wundert mich jetzt wirklich. dass eine radeon 9250 da nicht besser performed als eine alte 16MB-notebook-graka...

    ich denke mir mit VBOs wuerde das bestimmt ganz anders aussehen, aber dazu bin ich noch nicht gekommen, da die mein laptop nicht unterstuetzt...

    also, irgendwelche ideen dazu?

    mfg,

    ---loki



  • displayliste?
    vertexarrays sparen dir "nur" (cpu-seitige) api-calls - die vertexdaten liegen aber nach wie vor im hauptspeicher.



  • aha, ok, scheinbar habe ich das falsche erwartet....

    dann probier ich mal display lists aus, thanks ๐Ÿ™‚


  • Mod

    es hat gewisse vorteile, wenn man vorher testet/profiled wo das performance problem ist, bevor man einfach mal ne optimierung macht. ansonsten kannst du ja auch mal alle loops unrollen, oder die float berechnungen durch fixpoint ersetzen ๐Ÿคก und dich wundern dass sich nichts an der performance aendert ๐Ÿ˜‰



  • haste nicht unrecht, werde da mal gprof bemuehen....

    habe naemlich jetzt mal schnell auf display lists umgestellt, hat auf beiden systemen keine merkliche performanceverbesserung gebracht...



  • wenn man vorher profiled wo das performance problem ist, bevor man einfach mal ne optimierung macht

    im rahmen privater (ideologischer) projekte ist es aber durchaus noch vertretbar, daten einfach mal von vorne herein so zu struktuieren, dass es erst gar nicht zu vorhersehbaren performance-problemen kommen kann.
    in der professionellen software-entwicklung macht man sowas natuerlich nicht ๐Ÿ˜‰


  • Mod

    hellihjb schrieb:

    wenn man vorher profiled wo das performance problem ist, bevor man einfach mal ne optimierung macht

    im rahmen privater (ideologischer) projekte ist es aber durchaus noch vertretbar, daten einfach mal von vorne herein so zu struktuieren, dass es erst gar nicht zu vorhersehbaren performance-problemen kommen kann.

    ja, absichtlich schlecht arbeiten sollte man nicht, aber wenn man es nicht besser wuste, oder keine zeit hatte, dann sollte man die dinge beheben, die uhrsache fuer die fehler/probleme sind,

    hellihjb schrieb:

    in der professionellen software-entwicklung macht man sowas natuerlich nicht ๐Ÿ˜‰

    natuerlich, je mehr man programmiert, desto mehr lazy wird man und da man nicht 9 von 10 optimierungen um sonst machen will, findet man erstmal raus, was wirklich effektiv ist und freut sich dann das man weitere 9 effektive dinge machen kann. sonst sinkt die motivationskurve sehr sehr schnell ab ๐Ÿ˜‰

    :xmas2:



  • hmm, also wie gesagt, display lists haben auch nichts gebracht.... ๐Ÿ˜ž

    habe aber das ganze mal durch gprof gejagt, und der scheint die zeit, die bei opengl-calls anfaellt, nicht einzurechnen....
    wahrscheinlich weil die calls nicht mehr innerhalb des eigentlichen programms, sondern der opengl-implementation oder des treibers sind.

    weiss da jemand etwas mehr, worauf muss ich beim profilen von opengl-apps achten?



  • wenn displaylisten keine vorteile gegenueber immediate-mode-rendering haben, machst du wahrscheinlich irgendwas grundlegendes falsch.
    ich verweise wiedermal dorthin...


  • Mod

    ...oder das problem liegt grundlegend ganz wo anders.

    aber es gibt natuerlich tools fuer oGL z.b. http://developer.nvidia.com/object/gdebugger.html

    wobei man den nvidia papern um das bottleneck zu finden folgen sollte;)



  • ok, danke fuer die tips, werde mir das mal anschauen.


Log in to reply