OpenGL Shader Builder und Sonderzeichen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • OpenGL Shader Builder und Sonderzeichen

    Ich bin sowas von genervt: Jedes Mal, wenn ich im OpenGL Shader Builder ein Sonderzeichen eingebe, schmiert das Ding sang- und klanglos ab und alle aktuellen Änderungen sind weg. Nicht einmal superbesondere Zeichen, es reicht, wenn ich bei einer Null danebenhaue und ein ß tippe (dabei fällt auf, wie oft mir das passiert).

    Frage 1: Ist das bei Euch genauso?
    Frage 2: Kennt Ihr eine Lösung für das Problem, die nicht beinhaltet, die entsprechenden Tasten aus der Tastatur zu meißeln?
    Multigrad - 360°-Produktfotografie für den Mac

  • Ich nehm alles zurück.
    Stürzt auch bei mir ab, ich musste halt eine Variable so benennen.

    EDIT:
    Darf ich "rofl" schreiben? Oder "lolololol"?
    Habs mal im gdb gestartet:

    Quellcode

    1. Program received signal EXC_BAD_ACCESS, Could not access memory.
    2. Reason: KERN_INVALID_ADDRESS at address: 0x000000012120cc60
    3. 0x00007fff8656b120 in strlen ()

    Die verwenden tatsächlich strlen(). Das geht mit unicode wahrscheinlich schief. Du könntest strlen() patchen (Preload-Lib, dtrace koennte eventuell reichen). Oder lachen und so eine Mist-Software nicht verwenden ;)

    EDIT #2:
    Es wird immer schlimmer, der Stacktrace verrät, der Fehler liegt in OpenGL:

    Quellcode

    1. #0 0x00007fff8656b120 in strlen ()
    2. #1 0x00007fff8115e07f in yylex_CPP ()
    3. #2 0x00007fff8115ddd2 in yy_get_next_buffer ()
    4. #3 0x00007fff8115dad5 in yylex ()
    5. #4 0x00007fff8114a443 in yyparse ()
    6. #5 0x00007fff81149daf in PaParseStrings ()
    7. #6 0x00007fff81148263 in ShCompile ()
    8. #7 0x00000001140ee03d in gleShaderParse ()
    9. #8 0x0000000114054e7a in glCompileShaderARB_Exec ()

    Lösungsvorschlag: Für Graphik-Anwendungen nicht die denkbar ungünstigste Plattform (Apple) mit den schlechtesten Treibern (Apple) verwenden. Ich empfehle eine Plattform, auf der original NVidia Treiber laufen (Windows, Linux, evtl. auch Solaris, FreeBSD). AMD Treiber sollen auch inzwischen ganz gut sein, da habe ich aber keine Ahnung.

    EDIT #3:
    Das Problem liegt in libGLProgrammability.dylib (OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib)
    ..mal sehen, ob man da was machen kann...

    EDIT #4:
    Schreib eine Library, welche nur folgende Methode (C++) implementiert:

    Quellcode

    1. PaParseStrings(char ** shaders, int *, int, int, TParseContext &)

    TParseContext& wirst Du als void* annehmen können.
    Darin dann shaders[0] durchgehen und unicode bzw. Sonderzeichen ersetzen. Ich weiss nicht, welcher Parameter die Anzahl der Shader enthält, eventuell probieren - wirkt aber auf mich, als wäre immer nur shaders[0] in verwendung.
    Nach dem ersetzen dann das original PaParseStrings aufrufen, fertig.
    Das ganze könnte schon mit dtrace klappen, ansonsten eine Preload-Lib - hab grad kein Code dafür und keine Lust mehr für heute ;)

    EDIT #5:
    Irgendwie startet der Shader-Builder mit DYLD_FORCE_FLAT_NAMESPACE=1 nicht. Eine andere Möglichkeit fällt mir dann nicht ohne weiteres ein, zumindest keine noch diesseits von ganz fiesen Hacks.
    Also wird es wirklich das beste sein, auf Windows/Linux umzusteigen :P
    ♥C++

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von zerm ()

  • Wow, das nenne ich mal Fehleranalyse! Danke, zerm!

    Die leidige Geschichte mit Apples Support für antiquierte OpenGL-Versionen hatten wir ja schon. Für OGL-zentrische Sachen mit freier Systemwahl würde ich mit Sicherheit eine andere Plattform nehmen (und da eher Windows als Linux, zumindest bei den Quadros gab's da noch einige Unterschiede). Geht aber bei dem aktuellen Projekt nicht, da ist 3D ein Teil von vielen und die Plattform ist gesetzt. Als billigen Workaround werde ich erstmal meine Tastatur umstellen und mir bei Gelegenheit einen kleinen eigenen Tester schreiben, der vorweg die Unicode-Zeichen ersetzt. Hui, wenn das überall im Treiber so aussieht, verstehe ich die Bedenken bei WebGL...

    Vielleicht bringt ein Bugreport etwas - der Fix kommt dann zeitgleich mit der Unterstützung von OpenGL 4, mit etwas Glück noch vor dem Umstieg auf 128 Bit ;)
    Multigrad - 360°-Produktfotografie für den Mac

  • Hab mich noch etwas angestrengt, und bisschen mehr als als "Unexpected EOF" geschafft:

    Quellcode

    1. *** Compiling shader "glsl_v" failed: ERROR: 0:9: '' : preprocessor encountered non-ASCII character in shader source


    Also hier scheint noch ein Preproccessor dazwischen zu liegen, der auf non-ASCII prüft.

    Bau Dir doch dein eigenen Shaderbuilder in WebGL :P Da gabs sogar schon sowas fertig, wenn ich mich recht erinner..
    ♥C++

  • @zerm: Beruhigend, dass die wenigstens daran gedacht haben. Wäre aber auch zu einfach gewesen. WebGL-Tester ist eigentlich gar keine so schlechte Idee, so riesig ist der Unterschied zwischen GLSL und ESSL ja nicht.

    @wolf: Die Sonderzeichen sorgen nicht an jeder Stelle für einen Absturz, ist mir danach auch aufgefallen. Probier' mal etwas wie "float f = ßa * 2.0;" (von Hand eintippen), da geht's bei mir den Bach runter. Ohne Autocompile/Autolink lässt sich das Ganze natürlich bis zum nächsten händischen Trigger verzögern. Das macht zwar eigentlich gerade den Witz des Programms aus, aber erstmal hilft es etwas, da hast Du Recht.
    Multigrad - 360°-Produktfotografie für den Mac

  • Wann kommt voller OpenGL 4.x Support unter MacOS X 5
    1.  
      Dies Jahr noch (1) 20%
    2.  
      Naechste Jahr (0) 0%
    3.  
      In 2-3 Jahren (1) 20%
    4.  
      Spaeter (0) 0%
    5.  
      Nie - Apple wird OpenGL den Ruecken kehren und "erfindet" DirectOSX-3D (3) 60%
    Dabei faellt mir ein, ich wollte immer schonmal Tesselation-Shader ausprobieren.

    Gut, dass ich hier ein Windows Rechner hab. Der kann das schon seit einem Jahr. Ob's das bei Apple noch in diesem Jahrzehnt geben wird? Ich nehm wetten an! :)
    ♥C++

  • zerm schrieb:

    Dabei faellt mir ein, ich wollte immer schonmal Tesselation-Shader ausprobieren.

    Gut, dass ich hier ein Windows Rechner hab. Der kann das schon seit einem Jahr. Ob's das bei Apple noch in diesem Jahrzehnt geben wird? Ich nehm wetten an! :)

    Das hab ich doch schon längst aufgegeben, da auf was zu warten

  • Was ganz gut funktioniert, ist das Sharing zwischen OpenGL und OpenCL. Da kannst Du ja zumindest Transform&Feedback mit OpenCL "emulieren" und Deine Shader halt als Kernels in OpenCL schreiben.
    So ein Typ von NVidia hat mir auch mal versichert, dass Zugriff auf die Blending Unit und den Rasterisierer irgendwann mal moeglich wird - dann kann man ja wirklich alles einfach in OpenCL machen ;)
    Aber bis dahin hat Apple bestimmt OpenCL auch wieder aufgegeben, weil alles (also auch Desktops/MacBooks) nur noch auf ARM mit OpenGL ES laeuft :P
    ♥C++