Hi
Ich habe eine GeForce 5200. Dieser Code : liefert folgende Werte: Ich kann mir aber nicht vorstellen, dass diese Krafikkarte eine OGL 2.0 Implementation mit sich bringt. Unter Linux (Ubuntu 7.10) liefert das Befehl "glxinfo" u.a. Folgendes:Ich gehe davon aus, dass meine Garka eine ver.1.4 OGL Implementation besitzt.

Wie soll ich das aber aus meinem Programm feststellen?

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Ich geh mal davon aus, dass du einen neueren NVidia-Treiber installiert hast. Die Treiber von NVidia "erweitern" die Funktionen deiner Grafikkarte, in dem sie fehlende Features zu OGL 2.0 per Software nachreichen. Hatte vor kurzen auch meine GeForce 5700 im Rechner und hatte OpenGL 2.1. Ich glaube, das es ohne viel aufwand sehr schwer feststellbar ist, herauszufinden, welche Features wirklich von der Hardware unterstützt werden.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

und wie machen die 'großen' entwickler das?
wie stellen die sicher dass der treiber nicht in den software-modus zurückfällt?
gibt es da drüber evtl listen?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Opengl 2.1 brningt hauptsächlich GLSL 1.2 mit aund dort sind quasi alle neuen features nur verbesserungen in der API gewesen, so das ein neuerere GLSL compiler schon fast alles war. Neue hardware ist dafür nicht nötig gewesen.
Ob nun eine Karte in den software modus zurückfällt lässt sich leider nicht feststellen, allerdings sind viele fallbacks sehr langsam.

_________________
Lumina plattform unabhängige GLSL IDE

"Vermutungsmodus ein"

Ich glaub dir großen machen das über eine Art "HardwareID". Aus jeder Grafikkarte lässt sich mit einen spezielen Algorithmus eine HardwareID erstellen (z.B. aus dem Namen der Grafikkarte). Anhand einer Spezifikationstabelle lässt sich aus dieser HardwareID die Features auslesen. Da große Entwicklerstudios auch viele Rechnerkonfigurationen und somit auch viele verschiedene Grafikkarten zum Testen haben, können sie so diese Tabelle erstellen

"Vermutungsmodus aus"

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com

Es gibt kaum noch professionelle Anwendungen die OpenGL nutzen (selbst solche "Flagschiffe" wie 3das 3D-Studio MAX sind inzwischen primär D3D9), und die selbst die "Profis" haben keine Möglichkeit in OpenGL zu ermitteln was jetzt in Software, bzw. was in Hardware läuft. Nichtmal die Meldungen der Shader (die ja auch je nach Fall in SW laufen können) sind normiert, und bei den Extensions hat man eigentlich gar keine einfache Möglichkeit irgendwie zu ermitteln ob es in Hardware oder Software läuft. Schuld daran sind sowohl die IHVs als auch das ARB (jetzt Khronos), da hätte man von vorneherein sagen sollen : Entweder in Hardware implementieren oder gar nicht.

Hardware-IDs sind übrigens eine relativ schlechte Lösung, da man hier die Anwendung rein theoretisch jedesmal beim Release neuer Karten aktualisieren müsste. Ja, es gibt Spiele und Anwendungen die Hardware-IDs checken, allerdings nicht um festzustellen was diese in HW/SW können, sondern um ggf. ein vorgegebenes Leistungspreset zu laden (GPUs und CPUs haben dann z.B. ein Performancerating zur groben Orientierung) oder um GPU-spezifische Hacks bzw. Workarounds für Treiberprobleme zu implementieren. Unter D3D hat man übrigens die Möglichkeit abzufragen was in Hardware bzw. in Software läuft (da gibts die sog. "HW-Caps"), sowas fehlt OpenGL leider. Evtl. ist auch dies ein Grund warum kaum noch Hersteller OpenGL nutzen wollen, da die IHVs ja machen was sie wollen (selbst Uralt-Karten werden via Software "Fit" für OpenGL2.0 gemacht, ohne dass Khronos da einschreitet, MS würde sowas wohl kaum dulden).

Letztendlich ein Armutszeugnis, und ich "durfte" es bei der Entwicklung von Projekt "W" live miterleben, schade um die schöne API...

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

Hi~



Stimmt nur so halb...
3DS Max ist da eher die ausnahme, und selbst das bietet ja noch an zwischen OpenGL und D3D zu wählen. Lustigerweise läuft da unter Windows Vista (!!) x64 mit ner GeForce 8800 die OpenGL Variante wieder viel besser als die D3D Variante (die bei XP besser lief).

Ansonsten kenne ich eigentlich keine einzige professionelle software die mit D3D Arbeitet.. Maya, Houdini, Fusion, Shake, FinalCut, AfterEffects, Modo, Rhino, bla blubb.. alle benutzen OpenGL, und das aus dem ziemlich simplen grund der platformunabhängigkeit. Einzig bei XSI bin ich mir nicht so sicher, aber ich würde mit 95%iger sicherheit tippen das die auch OpenGL verwenden.

Würde Maya jetzt spontan sagen "So leutchen, wir machen jetzt nurnoch D3D".. dann wäre Maya in der Professionellen branche schnell weg vom fenster (ok "schnell".. in 10 jahren.. bis dahin arbeiten dann alle noch mit der alten Maya version weiter )

Aya~

Der D3D-Renderer vom 3D Studio kann viel mehr, weil das ARB halt einfach gepennt hat und sich Hersteller dann logischerweise auf eine API richten die wirklich Fortschritte macht und auch aktiv unterstützt wird. Und u.A. Maya gehört inzwischen ja auch Autodesk und dass hat auch einen D3D-Renderer der mehr Features hat als der OpenGL-Renderer. Das solche Produkte wie Adobes AfterEffects bei OpenGL (XSI hat übrigens nen Renderer für beide, nutzt aber u.a. .fx-File, also ist der D3D-Renderer wohl der bessere) bleiben, liegt ja eher daran dass diese primär auch auf anderen Systemen genutzt werden.

Ich wollte mit meinem Kommentar halt zum Ausdruck bringen dass OpenGL mehr und mehr an Bedeutung verliert, und dies eindeutig die Schuld von Khronos (bzw. des ARBs) ist, und zu dieser "Schuld" zähle ich auch die Sachen die hier im Thread angesprochen worden. Es kann in meinen Augen einfach nicht sein dass man OpenGL x.x-konform durch Softwareimplementation werden kann, die dann ja eigentlich immer nutzlos sind.

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

Sascha, könnte es nicht einfach eine Frage der Entwicklungsphilosophie sein?
- Direct3D verspricht eine High-Level-Schinttstelle zu Hardwarebeschleunigerfunktionen unter Windows
- OpenGL verspricht plattformübergreifend einheitliches 3D-Rendering

Direct3D richtet sich mehr danach, was die Hardware verlangt oder kann. Wenn eine Anwendung neue Funktionen benötigt (z.B. Shader 3.0) auf einer Karte die nur 2.0 unterstützt, so kann man nur eine neue Karte kaufen.
Unter OpenGL ist es anders. nVidia kann alter Hardware per Treiber die Möglichkeit geben alle neuen Features zu unterstützen und erfüllt so die Anforderungen der API.
Unter Direct3D käme ein Hinweisfenster: Sie können diese Programm nicht ausführen, denn es benötigt Shader 3.0.
Unter OpenGL bleibt man kompatibel, sieht dass ein paar der komplexeren Shader langsam laufen und überlegt sich bei Zeiten neue Hardware zu kaufen.

Ich hoffe ich konnte den Unterschied zwischen hardwarebasierter und API-basierter Entwicklung deutlich machen.
Als Spieleentwickler würde ich auf D3D setzen, als Anwendungsentwickler auf OpenGL. Aber zu sagen OpenGL dürfe keine Implementierung von Shadern erlauben, die nicht in Hardware laufen ist blödsinn. Es gibt ja auch Software OpenGL und Direct3D Implementierungen. Und zu guter letzt ist jede Hardware nun mal einzigartig in ihrem Funktionsumfang. Einer bestimmten Karte zu verbieten Shader ÜBERHAUPT anzubieten - geschweige denn in Software zu berechnen -, weil ihr für Standard XY zwei Texturzugriffe pro Pixel fehlen kann doch auch keine Lösung sein.
Wonach soll man sich denn im ARB richten? Nach dem 'kleinen Bruder' Direct3D?

Was ich voll unterstreichen kann ist, dass eine Abfrage der Hardware Fähigkeiten fehlt. Bzw. sowas wie 'kannst du ruhig benutzen' oder 'nicht für Echtzeitanwendungen verwenden'.