Hallo,

ich besitze eine AMD Grafikkarte und da lief der Bumpmapshader aus der Shadersammlung ganz normal. Dann habe ich das Programm auf einer Intel HD Grafikkarte laufen lassen und war entsetzt. Daraufhin testete ich auf einigen Systemen.
AMD Radeon4670 (openGL 3.3) und AMD A4 Prozessor (openGL 4.x) alles schön.
Nvidia GT660M (openGL 4.5), Intel HD 2000 (openGL 3.0) und Intel HD 4000 (openGL 4.x) siehe Bild.
Kennt jemand das Problem und eine Lösung?

Ich würde mal schauen, ob der Shadercompiler was dazu zu sagen hat. Manchmal sind da interessante Warnungen drin. Beachte dabei auch die nicht-betroffenen Systeme: Die zeigen eventuell eine Warnung für einen Fehler oder eine Ungenauigkeit an und korrigieren diesen oder diese für dich, während die betroffenen Systeme daher dieses Verhalten zeigen. Kann aber genausogut andersherum sein.

Will damit sagen: Auf allen Systemen ins Log schauen.

viele Grüße
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Die Nvidia ist nicht betroffen der Laptop hat es nicht für nötig gehalten auf die Nvidia umzuschalten, war auch eine Intel HD 4000.
Habe den Fehler auch gefunden.

Wenn gl_FrontMaterial.shininess = 0 , müsste der pow() eigentlich 1 zurückgeben - habe es auch mit einer Ziffer 0 probiert . Scheint er bei Intel aber nicht zu wollen.
Manchmal stürzt sogar der ganze Treiber ab.

Man sollte eh auf die (veralteten) eingebauten Fixed-Function Variablen im Shader verzichten (also z.B. gl_FrontMaterial). Als ich das früher noch benutzt hab gab es damit bei ATI auch regelmäßig Probleme.

Heute macht man das eh anders, für Strukturen wie Lichtquellen die man als Parameter an einen Shader übergeben kann bieten sich z.B. uniform buffer objecte an.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Zum Testen dachte ich geht das mit den Lichtquellen schneller. Nutze es in der Zwischenzeit auch nicht mehr.
Aber daran liegt es ja nicht.
Die pow() funktion kommt nicht mit 'x hoch 0' zurecht.

Und noch etwas ist mir aufgefallen. Der Intel HD 3000 und 4000 Treiber stürzen ab wenn LIGHT_COUNT > 1 bei
Nutzt man kein Array sondern einzelne Variablen ist die GPU zur Mitarbeit bereit.

Das varying ist veraltet, wen ich dich wäre, würde ich mich mit OpenGL 3.3 beschäftigen.
Ich habe bei deinen Postings zu Teil gesehen, das du noch glBegin und glEnd verwendest.

_________________
OpenGL

Ich habe einfach versucht den Shader einzubinden und zu verstehen. Nvidia und AMD kommen damit auch klar nur der Intel Treiber verhält sich sehr seltsam.
Soweit ich weiß ist auch in Open GL 3.3 die pow() funktion drinnen und wenn Intel mit x hoch 0 nicht klarkommt ist das einfach ein Treiberfehler.

Das muss kein Treiberfehler sein, evtl. hält sich Intel einfach nur strikter an die GLSL-Specs, siehe Dokumentation von Pow. Das ist aber etwas Grundlegendes, denn was GLSL angeht verhalten sich fast alle IHVs zumindest minimal anders. Heute zum Glück nicht mehr so stark wie früher, aber trotzdem sehr schwierig bei der Fehlersuche. Teilweise hat man sogar innerhalb eines IHVs zwischen unterschiedlichen GPUs und Treiber Unterschiede was das Schaderverhalten angeht.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Eine Zahl hoch 0 ergibt 1.
Setze ich anstatt pow(max(dot(Reflected, Eye), 0.0), gl_FrontMaterial.shininess)---pow(max(dot(Reflected, Eye), 0.0), 0) ein kommt die selbe fehlerhafte Ansicht raus.
Ersetze ich pow(max(dot(Reflected, Eye), 0.0), gl_FrontMaterial.shininess) durch die Mathematisch richtige 1 ist der Bumpeffekt richtig.

Das jeder sein eigenes Treibersüppchen kocht verstehe ich schon. Ich möchte das auch eher als Hinweis für andere verstanden haben - Bei Intel kann es bei x hoch 0 Probleme geben - .

En kleiner Hinweis 1.0 und 1 ist nicht bei allen Shadern daselbe.
Bei mir war wegen so etwas ein ganzer Tag futsch.

_________________
OpenGL

Wie Sascha schon verlinkt hat: Das trifft aber nicht auf pow() zu.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Ich verstehe das Argument mit der pow-Spezifikation nicht. Da steht doch, dass pow(x,y) = x^y. Als einzige Ausnahme wird aufgeführt:
Mal von der dilettantischen Schreibweise (Gleichheitszeichen vergessen) abgesehen, steht da *nicht*, dass x^0 undefined ist für den Fall, dass x != 0.0. Wenn also bei einem bestimmten Grafiktreiber pow(x, 0.0) nicht 1.0 ergibt (für alle x != 0.0), so ist das ein Fehler.

In dem Fall würde ich ein Treiberupdate in Erwägung ziehen. Ich habe bei meinem Laptop ca. 2 Jahre nach Erscheinungsdatum der integrierten Intel-Grafik neue Treiber raufgespielt. Das hat einige GLSL-Probleme behoben.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)