Results 1 to 6 of 6

Thread: GL_INVALID_OPERATION nach glUseProgram()

  1. #1
    Master
    Join Date
    Oct 2010
    Posts
    124
    Thanks
    22
    Thanked 10 Times in 9 Posts

    GL_INVALID_OPERATION nach glUseProgram()

    Hi,

    Meine Applikation möchte einfach keinen Strich zeichnen. Ich habe heute den ganzen Tag versucht, zumindest den Fehler einzugrenzen. Folgendes Problem konnte ich ausmachen:

    Zuerst lade ich die Shader, kompiliere und linke sie zu einem Shader-Programm, und setze das zu benutzende Shader-Programm wieder auf 0:
    Code:
    // Shader-Programme laden, kompilieren und linken - Program Handle speichern
    // ...
    glUseProgram(0);
    Beim Rendering binde ich mein Shader-Programm wieder:
    Code:
    glUseProgram(_programHandle);
    
    // MVP Uniform übergeben
    //...
    // VAO binden
    //...
    Frage ich nach dem erneuten Binden des Shader-Programmes die OpenGL Error Codes ab, dann bekomme ich einen GL_INVALID_OPERATION. Ich bin mir sicher dass der zweite Call von glUseProgram() den Fehler verursacht (vorher wird kein Fehler-Code zurückgegeben). Weiters bin ich mir sicher, dass ich das Kompilieren und Linken der Shader-Codes richtig überprüfe. Zwischen den beiden glUseProgram() Calls sind lediglich folgende OpenGL Calls:
    Code:
    glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    OpenGL doc zu glUseProgram():
    (1) GL_INVALID_OPERATION is generated if program is not a program object
    (2) GL_INVALID_OPERATION is generated if program could not be made part of current state.
    (3) GL_INVALID_OPERATION is generated if glUseProgram is executed between the execution of glBegin and the corresponding execution of glEnd.
    Wobei ich (1) und (3) eigentlich ausschließen würde. Was könnte also mein Problem sein? Bitte um Hilfe! Danke :-)

  2. #2
    Principal
    Join Date
    Apr 2010
    Posts
    45
    Thanks
    3
    Thanked 3 Times in 3 Posts
    hi, nachdem keiner antwortet hier mal ich ^^

    also ... glUseProgram(0) brauchst du nicht.. das sagt nämlich du willst die fixed-pipeline verwenden soweit ich weiß.
    vielleicht hängt es ja damit zusammen.
    ich halte mich im einfach an das tutorial:http://www.opengl-tutorial.org/ welches auch im wiki steht und es funktioniert einwandfrei.
    Den shader-loader habe ich auch 1:1 übernommen und ich habe nicht vor meinen eigenen zu schreiben.

    also: glUseProgram(0) weglassen... ansonsten mal deinen code mit dem tutorial vergleichen und fehler suchen
    grüße

  3. #3
    Baccalaureus
    Join Date
    Oct 2005
    Location
    Wien
    Posts
    606
    Thanks
    4
    Thanked 110 Times in 94 Posts
    Generell empfehle ich schon, zumindest im Debug build, glUseProgram(0) zu verwenden, um potentielle fehler oder State-Leaking zu finden.

    Schaut euch evtl. mal die OpenGL debug output extensions an. (AMD, ARB) Damit koennt ihr eine Callback-Funktion definieren die bei einem OpenGL Fehler aufgerufen wird.

    Das hat mehrere Vorteile:

    Einerseits habt ihr mit einem Callback den Vorteil dass der aufgerufen wird, sobald es ein Fehler auftritt. Ihr koennt in der Callback-Funktion also einfach einen Debugger-Breakpoint setzen und findet dann im Callstack den genauen GL-Aufruf der den Fehler verursacht hat.

    Andererseits gibt, vor allem der AMD Treiber, wesentlich genauere Fehlermeldungen, was nuetzlich zum Debuggen der Problems ist.

  4. The Following User Says Thank You to ThomasW For This Useful Post:


  5. #4
    Master
    Join Date
    Oct 2010
    Posts
    124
    Thanks
    22
    Thanked 10 Times in 9 Posts
    Quote Originally Posted by ThomasW View Post
    Generell empfehle ich schon, zumindest im Debug build, glUseProgram(0) zu verwenden, um potentielle fehler oder State-Leaking zu finden.

    Schaut euch evtl. mal die OpenGL debug output extensions an. (AMD, ARB) Damit koennt ihr eine Callback-Funktion definieren die bei einem OpenGL Fehler aufgerufen wird.

    Das hat mehrere Vorteile:

    Einerseits habt ihr mit einem Callback den Vorteil dass der aufgerufen wird, sobald es ein Fehler auftritt. Ihr koennt in der Callback-Funktion also einfach einen Debugger-Breakpoint setzen und findet dann im Callstack den genauen GL-Aufruf der den Fehler verursacht hat.

    Andererseits gibt, vor allem der AMD Treiber, wesentlich genauere Fehlermeldungen, was nuetzlich zum Debuggen der Problems ist.
    Hi!

    Danke, werde mal die Debug-Output Extension versuchen. (ARB - hab leider keine ATI Card).

  6. #5
    Master
    Join Date
    Oct 2010
    Posts
    124
    Thanks
    22
    Thanked 10 Times in 9 Posts
    Und meine GForce 9400M unterstützt die ARB_debug_extension auch nicht ... Bitter :-( ... Habe aber mittlerweile durch einen Rewrite den Fehler beseitigt. Gibt es noch andere vergleichbare Debug-Extensions die meine Karte vielleicht unterstützen könnte?

    LG

  7. #6
    Baccalaureus
    Join Date
    Oct 2005
    Location
    Wien
    Posts
    606
    Thanks
    4
    Thanked 110 Times in 94 Posts
    Hmm.. Ansonsten kannst Du das mit dem Breakpoint on GL-Error wohl auch mit gDebugger machen.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •