Stimmt es, daß Direct3d threadingfähig ist und OpenGL nicht?



  • Das würde also heißen, daß man mit Direct3d 3d Berechnungen bei einer Dual Core CPU auf beide Kerne verteilen kann, was bei OpenGL aber nicht geht, da OpenGL nicht threadingfähig ist und
    somit 3d Berechnungen nicht auf eine andere CPU aufgeteilt werden können.

    Ist das richtig?



  • 3D Berechnungen werden von der GPU gemacht. Daher hat deine CPU damit nichts zu tun. (Der Grund warum Grafikkarten mehr Transistoren als CPUs haben).

    Aber bei OpenGL kommt es wohl auf die Implementierung an. Hier zB für die Apple OpenGL Implementierung

    http://developer.apple.com/graphicsimaging/opengl/optimizingdata.html schrieb:

    Use Threads

    The Mac OS X OpenGL implementation is not thread-safe but you can still split your processing onto multiple threads. It is extremely important for developers not to issue OpenGL commands for a single context from multiple threads without proper thread synchronization. This is a leading cause of both rendering anomalies and application crashes. There are three specific ways to use threads with OpenGL. First, use one thread per context, which will not require any special thread synchronization. Second, use standard thread synchronization techniques with a single context to ensure that multiple threads do not enter OpenGL simultaneously. Please note that the OpenGL Profiler has a thread safety check (turn on "Break on thread error" in the Breakpoints window) that can be used to help ensure this requirement is maintained. Finally, in a technique that is particularly relevant for this article, you can split the computation of vertex data off onto one thread while another thread handles the drawing of that data. You can gain performance advantages by applying threads on single processor machines but threads really shine on multiple CPU machines since each processor can devote itself to a thread, thereby potentially doubling your throughput.

    Ich denke aber, dass die meisten Anwendungen eh ein Thread für die Zeichendaten und einen für Sachen wie KI oder Physik benutzen, so dass man sich da eh nicht so leicht in die Quere kommt. Quake3 konnte afaik von mehreren Prozessoren profitieren und läuft ja mit OpenGL. Die meiste Profi Software unterstützt ja auch mehrere Prozessoren (daher haben die teuren Workstations ja auch immer mehrere) und die läuft ja auch auf OGL.



  • wat is los? ne is nicht richtig. multithreading in games jetzt kannste eh vergessen is völlig überbewertet.



  • Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Themen rund um den PC in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • kingruedi schrieb:

    Ich denke aber, dass die meisten Anwendungen eh ein Thread für die Zeichendaten und einen für Sachen wie KI oder Physik benutzen, so dass man sich da eh nicht so leicht in die Quere kommt. Quake3 konnte afaik von mehreren Prozessoren profitieren und läuft ja mit OpenGL. Die meiste Profi Software unterstützt ja auch mehrere Prozessoren (daher haben die teuren Workstations ja auch immer mehrere) und die läuft ja auch auf OGL.

    Ok, danke für die schnelle Antwort, aber was ist mit Sofware die das ganze Grafikzeugs wirklich auf mehreren CPUs durchführen muß bzw. möchte.
    Vielleicht nimmt die Physikberechnung in einem Simple Game nur 10 % ein, während der Rest für die Grafik notwendig ist.

    Und wenn die OpenGl Implementierung auf dem Apple nicht Thread sicher ist, dann bedeuted das ja, daß OpenGL defacto nicht Thread sicher ist, zumindest gilt das dann für crossplattform Anwendungen die auch unter dem Mac laufen sollen.
    Wie sieht es mit den OpenGL Implementierungen von Nvidia und Ati unter Windows und Linux aus? Sind die Thread sicher?



  • Wie stellst du dir das denn vor, das OpenGL in mehreren Threads ablaufen soll? Ich pers. kann mir das schlecht vorstellen, wie OpenGL die Grafikpipeline auf mehrere Threads aufteilen soll. OGL schiebt doch die ganzen Daten die man reingesteckt hat an die Grafikhardware und die macht dann den Rest.

    das einzige was ich mir vorstellen kann, ist das man als Entwickler zwei OGL-Kontexe instanziert, z.B. eines für die obere Bildhälfte und eines für die untere Bildhälfte und dann füttert man diese mit Daten. Aber das macht nur Sinn, wenn man jeden Kontext einer eigenen GPU zuweist. Einen anderen Sinn kann ich in Multithreading für ein OGL nicht erkennen. Es macht ja nur Sinn, wenn die HW dafür da ist.

    Da wäre auch meine nächste Frage: was macht denn D3D bzgl. MT?



  • man kann vllt. einen Thread erstellen, der die Vertex-Daten an die GPU schickt und einen Thread, der diese Daten zeichnen lässt.

    also Thread 1.

    data = berechneData();
    
    gl.glGenBuffer(1, buffers);
    gl.glBindData(..., buffer[0]);
    gl.glBufferData(..., data, ...);
    gl.glBindData(..., null);
    

    Thread 2.

    gl.glBindData(..., buffer[0]);
    gl.glVertexPointer(...);
    gl.glDrawElements(...);
    gl.glBindData(..., null);
    

    aber man müsste sie so synchronisieren, das Thread 1. nicht startet, wenn Thread 2. nicht komplett abgeschlossen ist. Was irgendwie eh keinen Sinn macht. Also Parallel kann man die 2 Thread nicht laufen lassen.

    Was Thread-Safed OpenGL erlauben würde ist eine Art Double-Buffering. Man benutzt 2 Buffers, die sich immer wechseln. Ein Buffer wird mit Daten gefüllt, wärend dessen wird der andere Buffer gerendert. So kriegt der Benutzer nichts mit, wenn neue Vertex-Daten an die GPU gesendet werden. Solange die neuen Daten noch nicht vollständig an die GPU übermittelt worden sind, zeichnet der andere Thread die alten Daten weiter.


Anmelden zum Antworten