DGL
https://delphigl.com/forum/

SIGSEV wegen Bezeichnername
https://delphigl.com/forum/viewtopic.php?f=20&t=11451		 Seite 1 von 3
Autor:  mathias [ Fr Okt 30, 2015 20:13 ]
Betreff des Beitrags:  SIGSEV wegen Bezeichnername
Code:
  1. layout(std140) uniform mu {Material zmate;};

Der Bezeichner zmate muss etwas ganz ominöses sein.
Ursprünglich hiess er Material, da wollte ich ihn in material umbenennen. Dann kahm aber bei der Ausführung des Programmes ein SIGSEV.
Mit Material oder zmate, läuft es ohne Fehler.
Aber bei material, mate9 oder mate, kommt ein SIGSEV.
Natürlich habe ich alle Bezeichner im Shader und nicht nur die Deklaration umbenannt.

Wen ich einen Bezeichner vergessen hätte umzubenennen, dann hätte es einen Shader-Kompilerfehler gegeben.

Egal, ob ich unter Win oder Linux compiliere.

Manchmal fragt man sich schon, was in den Computern passiert.

Edit:Mein Intel Atom, hat den gleichen Fehler.
Autor:  Sascha Willems [ Sa Okt 31, 2015 11:44 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Was für eine SIGSEV kommt denn? Aus dem OpenGL-Treiber oder aus deiner Anwendung? Der Name dürfte damit nichts zu tun haben. Wenn du ein reserviertes Keyword nutzt, schlägt ja schon das Compilieren des Shaders fehl.

Und wie sieht der Rest des Codes aus?
Autor:  mathias [ Sa Okt 31, 2015 20:01 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Kann es sein, das GLSL Probleme mit einem kleinen "m" am Anfang eines Bezeichners hat.

Wen ich hie m2aterial oder material nehme, hat meine Mesh einen Rotstich.
Bei Material oder zmaterial klappts.
Wenigsten kommt bei folgenden Beispiel kein SIGSEV.

Code:
  1.   LightingShader =
  2.     '    struct materialParams {' + LineEnding +
  3.     '       vec4 emission;' + LineEnding +
  4.     '       vec4 ambient;' + LineEnding +
  5.     '       vec4 diffuse;' + LineEnding +
  6.     '       vec4 specular;' + LineEnding +
  7.     '       float shininess;     // Glanz' + LineEnding +
  8.     '    };' + LineEnding +
  9.  
  10.     '    struct Lighting {' + LineEnding +
  11.     '      vec4 position;' + LineEnding +
  12.     '      vec4 ambient;    // Umgebungslicht' + LineEnding +
  13.     '      vec4 diffuse;    // Lichtfarbe' + LineEnding +
  14.     '      vec4 specular;   // Spiegelnd' + LineEnding +
  15.     '    };' + LineEnding +
  16.  
  17.     '    uniform materialParams m2aterial;' + LineEnding + // ?????
  18.  
  19.     '    uniform Lighting LightSource;' + LineEnding +
  20.  
  21.     '    vec4 Light(in vec3 Normal, in vec3 Position)' + LineEnding +
  22.     '    {' + LineEnding +
  23.     '      vec3 N       = normalize(Normal);' + LineEnding +
  24.     '      vec4 emissiv = m2aterial.emission;' + LineEnding +
  25.     '      vec4 ambient = m2aterial.ambient * LightSource.ambient;' + LineEnding +
  26.     '      vec3 L = vec3(0.0);' + LineEnding +
  27.     '      vec3 H = vec3(0.0);' + LineEnding +
  28.  
  29.     '      L            = normalize(vec3(LightSource.position) - Position);' + LineEnding +
  30.     '      vec4 Pos_eye = vec4(0.0, 0.0, 1.0, 0.0);' + LineEnding +
  31.     '      vec3 A       = Pos_eye.xyz;' + LineEnding +
  32.     '      H            = normalize(L + A);' + LineEnding +
  33.  
  34.     '      vec4 diffuse       = vec4(0.0, 0.0, 0.0, 1.0);' + LineEnding +
  35.     '      vec4 specular      = vec4(0.0, 0.0, 0.0, 1.0);' + LineEnding +
  36.     '      float diffuseLight = max(dot(N, L), 0.0);' + LineEnding +
  37.     '      if (diffuseLight > 0.0) {' + LineEnding +
  38.     '        diffuse         = diffuseLight * m2aterial.diffuse * LightSource.diffuse;' + LineEnding +
  39.     '        float specLight = pow(max(dot(H, N), 0.0), m2aterial.shininess);' + LineEnding +
  40.     '        specular        = specLight * m2aterial.specular * LightSource.specular;' + LineEnding +
  41.     '      }' + LineEnding +
  42.     '      return emissiv + ambient + diffuse + specular;' + LineEnding +
  43.     '    }';
  44.  
  45. var
  46.   i: integer;
  47.  
  48. begin
  49.   Lighting.Enabled := lightON;
  50.  
  51.   for i := 0 to Length(AShader) - 1 do begin
  52.     if Lighting.Enabled then begin
  53.       AShader[i] := StringReplace(AShader[i], '$light.glsl', LightingShader, [rfReplaceAll, rfIgnoreCase]) + #0;
  54.     end else begin
  55.       AShader[i] := StringReplace(AShader[i], '$light.glsl', noLightingShader, [rfReplaceAll, rfIgnoreCase]) + #0;
  56.     end;
  57.   end;
  58.  
  59.   inherited Create(AShader);
  60.  
  61.   if Lighting.Enabled then begin
  62.     with Lighting.UniformID do begin
  63.       with Light do begin
  64.         position := UniformLocation('LightSource.position');
  65.         ambient := UniformLocation('LightSource.ambient');
  66.         diffuse := UniformLocation('LightSource.diffuse');
  67.         specular := UniformLocation('LightSource.specular');
  68.       end;
  69.       with Material do begin
  70.         emission := UniformLocation('m2aterial.emission');
  71.         ambient := UniformLocation('m2aterial.ambient');
  72.         diffuse := UniformLocation('m2aterial.diffuse');
  73.         specular := UniformLocation('m2aterial.specular');
  74.         shininess := UniformLocation('m2aterial.shininess');
  75.       end;
  76.     end;    
Autor:  Sascha Willems [ So Nov 01, 2015 11:36 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Nein, ein kleines "m" am Anfang ist kein spezieller Bezeichner oder so.

Ich habe eher deinen Code zum Hochladen der Daten im Verdacht. Poste bitte mal den Teil in dem du die UBOs aktualisierst. Evtl. wir da wegen des fehlenden std140 ein Padding gemacht,
Autor:  mathias [ So Nov 01, 2015 13:29 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Bei diesem Codeschnippsel kann es nicht am UBO liegen, da dieser dort gar nicht verwendet wird.
Dort hat es nur gewoehliche Uniforms.

Ich werde spaeter trozdem den UBO Code hochladen, aber in dem OBO Thread.
Weil dort stimmt auch etwas nicht.
Dort hat es irgendwelche Kompflickte mit anderen Buffer.
Autor:  TAK2004 [ So Nov 01, 2015 21:51 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Klingt für mich eher nach nen Fehler in deinem Speicherbezogenen Code, also alle Bufferübergaben, falsche größe oder format vom Sader lade Code.
Ein häufiger Kandidat ist die 0 terminierung der einzelnen Shaderzeilen.
Man kann ja 2 Varianten übergeben, entweder über 0 terminierung jedes strings oder über eine 2. liste mit den längen.
Wenn man das mixt, dann kommen auch lustige Fehler Zustande.

Ich bin damals auf ein Bug in meiner String Klasse gestoßen, weil ich in mein Shader Buchstaben geändert hab und er dann ab und zu mal Speicherfehler warf.
Lag an der 0 Terminierung, die nicht immer passierte und häufig im nicht Alloziierten Speichermüll ne 0 folgte.
Autor:  mathias [ So Nov 01, 2015 22:28 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Ich habe gerade probehalber den Shader 0-Terminiert übergeben, es hatte keine Wirkung
Code:
  1. procedure TShader.LoadShaderObject(const AShader: ansistring; shaderType: GLuint);
  2. var
  3.   ShaderObject: GLhandle;
  4.   Str: ansistring;
  5.   l: GLint;
  6.  
  7.   ErrorStatus: integer;
  8.   InfoLogLength: GLsizei;
  9. begin
  10.   ShaderObject := glCreateShader(shaderType);
  11.  
  12.   l := Length(AShader);
  13.   Str:=AShader + #0;
  14.   glShaderSource(ShaderObject, 1, @Str, nil);
  15. //  glShaderSource(ShaderObject, 1, @AShader, @l);
  16.   glCompileShader(ShaderObject);
  17.   glAttachShader(FProgramObject, ShaderObject);


Zitat:
Ein häufiger Kandidat ist die 0 terminierung der einzelnen Shaderzeilen.

Wieso kommst du auf einzelne Zeilen ?
Autor:  mathias [ So Nov 01, 2015 23:06 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
glEnableVertexAttribArray, glDisableVertexAttribArray könnten diese beiden Befehle einen Einfluss auf das Ganze haben ?
Ich habe nirgends ein glDisableVertexAttribArray,
Autor:  TAK2004 [ So Nov 01, 2015 23:23 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Ich bin kein delphi profie aber du brauchst ein pointer auf ein pchar, ka. Ob ansistring auch ein pointer ist aber Sonnst sehe ich kein problem an der stelle.

Vertexattrib wird im aktuell gebundenen objekt angewandt und ist kein globaler state.
Man macht in der regel noch ein bind auf 0 um sicher zu gehen, dass kein folgender coder noch gültige änderungen auf das objekt macht.

Am besten mal codexl starten und gucken was er so sagt.
Sonnst würde ich mal unter linux valgrind durchjagen.
Beide tools helfen in der regel recht zuverlässig das problem zu finden.
Autor:  end [ Mo Nov 02, 2015 17:28 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Das geht bei mir:

Code:
  1.  
  2. function TEVOpenGLShader.Load(shadertype: GLenum; text: String): Boolean;
  3. var
  4.   shader: GLHandle;
  5.   len: GLint;
  6.   txt: PAnsiChar;
  7. begin
  8.   fOwner.Bind;
  9.   shader := glCreateShader(shadertype);
  10.   txt := @text[1];
  11.   len := Length(text);
  12.   glShaderSource(shader,1,@txt,@len);
  13.   glCompileShader(shader);
  14.   if CheckShader(shader) then
  15.   begin
  16.     glAttachShader(fProgram, shader);
  17.     Result := true;
  18.   end
  19.   else
  20.     Result := false;
  21.   CheckProgram;
  22.   glDeleteShader(shader);
  23. end;
Autor:  mathias [ Mo Nov 02, 2015 18:21 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Bewirkt bei mir keine Änderung. :cry:
Trotzdem Danke.
Autor:  Sascha Willems [ Mo Nov 02, 2015 18:57 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Mal mit den Debug Extensions von OpenGL geschaut was der Treiber sagt? Ansonsten wie von Tak angesprochen ein passendes Tool, evtl. auch den glDebugger oder was in der IDE deiner Wahl so integriert ist (wenn es sowas überhaupt für Delphi gibt).
Autor:  mathias [ Mo Nov 02, 2015 20:31 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Zitat:
Mal mit den Debug Extensions von OpenGL geschaut was der Treiber sagt?

Code:
  1.   // Assign our message event to the gl debug callback
  2.   glDebugMessageCallback(@GLDebugCallBack, nil);
  3.     // And tell the driver to give us all available GL debug messages, see http://davidgow.net/musings/nvidia-open ... utput.html
  4.   glDebugMessageControl(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, nil, True);

Sind das das relevanten Zeilen. das man den Debugger nutzen kann ?


Ich habe deine GLDebugCallBack procedure kopiert, nur motzt der Complier.
Code:
  1. oglshader.pas(256,42) Error: Incompatible types: got "<address of procedure(LongWord;LongWord;LongWord;LongWord;LongInt;const PChar;Pointer);StdCall>" expected "<procedure variable type of procedure(LongWord;LongWord;LongWord;LongWord;LongInt;const PChar;Pointer);CDecl>"


glDebugMessageControl kompiliert er anstandslos mit, nur dort gibt es keine Ausgabe.
Autor:  TAK2004 [ Mo Nov 02, 2015 22:30 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
CodeXL für Windows oder Linux laden und damit die Executable starten.
CodeXL hängt sich automatisch an die Debug API mit dem Prozess und nutzt noch zusätzlich die alten Möglichkeiten aus der glDebugger Codebase.

Die Stackmechanik ist die Falsche, stdcall ist üblicherweise VS c++ und ein paar andere Hochsprachen und haben will er cdecl also Standard C Stackmechanik.
Die muss übereinstimmen, weil der Compiler den auf und abbau Code für eine externe Funktion im eigenen Code generieren muss.

edit:
stdcall
cdecl
fastcall <- gibt es im 32bit Bereich bei Optimierungen noch ab und zu
Autor:  mathias [ Di Nov 03, 2015 16:56 ]
Betreff des Beitrags:  Re: SIGSEV wegen Bezeichnername
Zitat:
CodeXL für Windows oder Linux laden und damit die Executable starten.

So nun habe ich Debian-Version des Tools installiert.

Nur wie kann ich es jetzt starten ?

Ich habe mir die Quick Start Guide angeguckt, nur kann ich dort nirgends etwas finden wie man es startet.
Seite 1 von 3 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/