News Valve-Entwickler zur Qualität von OpenGL-Treibern

Ich glaube ein paar UVD Module fehlen noch, oder so … Und da hängen auch irgendwelche Drittanbieter mit drin, glaube ich. Aber keine Ahnung, das erzähle ich hier nur aus einem recht nebligen Gedächtnis. Die wichtigen Hardwarefeatures hat der Radeontreiber doch schon alle, afaik ist das größte Performanceproblem das schlechtere VRAM Management.
 
Fonce schrieb:
Kurz nachdem das Gerücht aufkam, kam schon dazu schon ein Kommentar(finde ich aber grade nicht mehr) eines Managers von AMD dazu welcher auch sagte das es auch wenn es solche Pläne geben würde warscheinlich sehr schwer werden würde sowas umzusetzen, vorallem mit Blick auf die Lizenzen von Dritten angeht.

OK, danke. Das habe ich dann damals nicht mitbekommen.
Klar wäre das ein großer Schritt, aber wohl halt auch in die richtige Richtung ;)
 
Ja von dem was ich so rauslesen sind das VRAM Management und das umsetzten der OpenGL Specs > 3.2 auf Treiberebene.(@Zehkul: also wirklich im radeon Treiber und nicht Mesa^^)
 
Zehkul schrieb:
Erm, Mesa IST der Treiber. In Mesa sitzt OpenGL.

Das ist nicht richtig. Mesa ist das Interface für die OpenSource-Treiber (bzw. die Opensource-Softwareimplementation wenn kein "Hardware-Treiber" da ist). Der Catalyst- bzw. der nVidia-Treiber braucht/verwendet kein Mesa.
 
Von den proprietären Treibern hat auch keiner gesprochen …

Fonce schrieb:
Ja von dem was ich so rauslesen sind das VRAM Management und das umsetzten der OpenGL Specs > 3.2 auf Treiberebene.(@Zehkul: also wirklich im radeon Treiber und nicht Mesa^^)

Die OpenGL Spec muss sowohl in Mesa als auch im eigentlichen Treiber unterstützt sein. Der eigentliche Treiber muss die Features unterstützen, die OpenGL braucht, zum Beispiel Geometrieshader, die für OpenGL 3.2 nötig waren. Dass Mesa Extensions unterstützt, die der Treiber nicht kann, kommt aber eh nur bei Gallium3D vor, ist von daher ziemlich Banane bei Intel. Und noch mal, es ging ja nicht um Vram, Treiberspezialitäten und sonstewas, es ging ums Erreichen der GL Spec :P



DocWindows schrieb:
@Zehkul: Reicht es überhaupt aus wenn die Treiber in Sachen OpenGL up to date sind? Als ich letztes Mal X-Plane unter Ubuntu ausprobieren wollte waren nicht die Treiber für die Karte das Problem, sondern irgendwas mit MESA.
 
Man hätte ruhig den Original-Artikel posten können, in der Übersetzung fehlt so viel :(
 
Der Landvogt schrieb:
Hab ich auch gedacht. Der geilste Name ever! :D
Beste Name wenn man das South Park Spiel spielen möchte !

Ich habe ehrlich keine Ahnung über OpenGl. Ich habe da kaum eingelesen, ich erinnere mich nur, dass ich damals in paar Spielen die Auswahl hatte, auf OpenGl zu stellen.
Aber:
er Valve-Entwickler Rich Geldreich kritisiert in seinem Blog in zwei Artikeln den Zustand der OpenGL-Treiber zur Spieleentwicklung und mahnt, AMDs Mantle und DirectX 12 könnten OpenGL „bald zu Mittag verspeisen“. Geldreich betont, er sei gerade in Meckerlaune und stellt klar, dies sei seine rein persönliche Sicht der Dinge.
sich in der nächsten Situation aber zu beschweren, dass es so gut wie nirgendwo umsetzbar ist, spricht jetzt nicht gerade für das Szenario, dass sich das über Mantle und DirectX12 schnell verspeisen wird.
Man muss die Software nun auch auf der Hardware zum Laufen bringen und auch Entwickler außerhalb von Valve müssen es dann nützten. Und im Gegensatz zu AMD mit Mantle, oder MS mit DirectX12, ist Valve theoretisch auch Konkurrent zu vielen Spieleentwickler.
Jetzt dürft ihr mich belehren :D Für Dinge, die ich nicht weiß :D

PS: Bin ein Valve Fan seit HL 1 und Action HL :D
 
Zuletzt bearbeitet:
Also ich muss sagen unter Windows ist AMD mit OpenGL eine kleine Katastrophe. Ich hatte Anfangs manche Probleme mit OpenGL Spielen. Von fehlerhaften Darstellungen,Startprobleme oder FPS Einbrüche oder unspielbar bei ATI/AMD Karten. Erst durch spätere Treiber/Spieleupdates wurden die Probleme gemildert oder waren verschwunden. Nvidia legt hier die Priorität deutlich mehr auf OpenGL,warum? Nicht in erster Linie den Kunden Gutes zu tun,sondern aus Eigennutz,um proprietäre Erweiterungen wie "nv_fog_ distance" (Distanznebel) durchzusetzen,der sich nie etablieren konnte und bei Call of Duty enthalten war und im späteren Spiel Call of Duty 2 weg war, wo AMD meist auf offene Standards setzt,wie jüngst mit VSync.
Wenn man sich im OpenGL Extensions Viewer die Extensions ansieht,dann merkt man ganz schnell,wer die meisten Extensions entwickelt hat und wer da mehr Engagemant zeigt. Für AMD/ATi war DirectX/Mantle immer die erste Geige (siehe DX 8.1 im Spiel Bloodrayne 1, DX10.1 bei Assasins Creed 1 oder DX 11.2/Mantle bei Battlefield 4),dann kam mal OpenGL dran,wenn sonst noch Zeit war/ ist und bei Intel? Für Intel ist Treiberentwicklung im 3D Grafikbereich ein notwendiges Übel! Intel muss hier gerade im Notebooksegment aufpassen,das sie da nicht eines Tages mit den APU`s von AMD überrollt werden. Gerade wenn der CPU Teil von den "Grünen" stärker oder die GPU auch im Office/Multimediabreich immer wichtiger und der Strom/ Preis bei AMD gesenkt wird und vor allem eine bessere Verfügbarkeit mit sinnvoller Gamerkonfiguration bei den Händlern da sein sollte.

So fühlt es sich für mich jedenfalls an, obwohl ich mit Nvidia Hardware wieder unter DX so manche Probleme bei einigen älternen Games hatte, wie grad jetzt mit Enclave und ner 650TI Boost (Texturen der Wände im Tunnel schwarz) und damals mit der 6600GT die mit SIS Chipsätzen nicht klar kam.
Eine Intel HD3000 läuft immer noch schlecht mit Doom 3 und das Spiel ist von 2004!
Rage hatte Startschwierigkleiten mit AMD Karten und Texturprobleme, bei den Legacy Karten der HD Serie wurde das nie gefixt. Serious Sam und Alien Arena liefen auf meiner Radeon 3850 bei Sam mit 20FPS und bei Arena schwankend von spielbar bis ruckelig auf mittleren bis hohen Einstellungen! Dies sind meine persönlichen Erfahrungen und stellt kein Angriff auf den jeweiligen Hersteller oder Festlegung darauf dar. Ich wechsel ziemlich oft,wer mir das besere P/L Verhältnis bieten kann und was grad im Angebot ist.
Dazu muss man auch sagen,die Spielehersteller legen deutlich,wenn das Spiel in OpenGL erscheint, den Fokus auf Nvidia Hardware, wie z.B. in 18 Wheels of Steel,wo das Spiel speziell angepasst wurde für die FX und 6000er Serie oder bei Bridge Builder was nur unter Nvidia lief (war ja auch gesponsert) und letzlich das Spiel Rage wo GPU Transcode ausschlißlich für Nvidia Karten aktivierbar ist. Warum steht im Artikel von Geldreich ja erklärt. Auch weil Nvidia mehr Manpower in der Spieleentwicklung hat und da findet ja bei AMD zur Zeit ein Umdenken statt.
Doch was nützt tolle Hardware,wenn die Software halbherzig umgesetzt (AMD) wird und proprietär (Nvidia) ist oder aber Märkte verschläft (Intel). Siehe Creative, die ihren Hochmut bezüglich Engstirnigkeit bei offenen Standards und Faulheit beim Treibersupport und fehlender Anpassbarkeit/Innovation an den Markt im Soundkarten und Schnittstellenbereich (OpenAL/Xaudio2/TrueAudio) ab Windows Vista teuer bezahlen mussten. Dies sollte alle Hersteller eine Warnung sein!

Der DX Render Pfad bei OpenGL Spielen ist für die Karten gedacht,wo die OpenGL Unterstützung etwas mau ist,damit das Spiel überhaupt erstmal unter Windows läuft. Valve hat beim SteamSpiel Half Life unter Windows den DX Renderer komplett rausgenommen,auch weil er Probleme mit neueren Betriebssystemen von MS verursacht hatte und um eine einheitliche Schnittstelle unter verschieden Umgebungen zu schaffen. Beim Laden der Levels hing sich das Spiel unter DX manchmal gerne auf.
OpenGL von Half Life 1 und co wurde aktualisiert und auf neuerer Hardware aller Hersteller angepasst. Früher zu IdTech 3 Zeiten,wo es noch mehr Hardwarehersteller gab,konnte man zufrieden sein,wenn das Spiel in 3d unter DX überhaupt lauffähig war, von OpenGL ganz zu schweigen, die damals die beste Schnittstelle war,abgesehen von Glide. Da z:B. eine ATI Rage 2 "3D" nicht richig beherrschte,war man schon mit dem Software Modus zufrieden. Aber damals zur Rage 2 Zeit war ja miniGL aka Glide von 3dfx das Maß aller Dinge. Es ist schön zu sehen das Valve hier Interesse am Gaming zeigt,denn Microsoft zeigt ja mit der Xbox One und Games for Windows Live und Windows 8 (obwohl ichs selber hab), das sie gerne was möchten,aber nicht wirklich mit Herz und Verstand beim Gamer sind.

Man merkt hier ein wenig, schon unter Windows wer wo seine Kraft rein steckt und ich denke das ist unter Linux ähnlich,oder? Deshalb kann ich Rich Geldreich in diesem Artikel nur zustimmen. Aber werte Gamer es tut sich was und es bleibt mit OpenGL,Mantle und Directx 12 spannend und wir werden sehen welche Hersteller von Hard und Software zukünftig den Ton angeben, es liegt an uns, was wir als besser erachten.
Unter Linux kann ich leider nix sagen,wie sind eure Treibererfahrungen?
 
Zuletzt bearbeitet: (Formatierung zur beseren Lesbarkeit/Nachtrag/ Rechtschreibung)
5@n!töt3r schrieb:
Wer ist "die Treiber"? Es gibt (meist) 3 zur Auswahl.

Gemeint war der stinknormale fglrx (von AMD bezogen) für aktuelle Grafikkarten. Hab das mit "die Treiber" so formuliert, weil über die letzten Jahre eigentlich alle fglrx-Versionen bei mir ganz gut liefen. Außer eben, wenn es wirklich um die 3D-Performance geht, da gibt es bei mir dann öfters Probleme.

Gruß
Pandemic
 
Das OpenGL Problem hat damals am besten 3DFX gelöst, man nahm sich die Funktionen die wichtig fürs Gaming waren, schraubte bissle daran und raus kam eine Schnittstelle die seinerzeit DirectX zerstörte. Dann gab es noch später für ID Spiele miniGL Treiber und da muß Valve anknöpfen.

Eine neue API basiert auf OpenGL für SteamOS in zusammenarbeit von Nvidia, AMD und Intel die Valve Koordiniert um eine neue schlanke moderne Schnittstelle zu schaffen. Alles andere wird nicht funktionieren.
 
Sinnvoller wäre es einfach Vorschläge zur modernisierung von OpenGL in die Khronos Group einzubringen, davon würden alle profitieren und Valve ist ja eh schon Mitglied der Khronos Group.
 
Soweit ich weiß läuft die PS4 auch mit OpenGL und nutzt als BS-Basis ein FreeBSD. Insofern müssten Spiele die für die PS4 programmiert wurden auch einfach auf Linux zu portieren sein. Einmal wegen der gemeinsamen OpenGL Basis und weil FreeBSD Programme leicht auf Linux zu portieren sind(hat mal einer meiner Freunde gesagt).
Ich hab allerdings ziemlich wenig Ahnung von Programmierung.

Liebe Grüße :)
 
Zuletzt bearbeitet:
Fonce schrieb:
Mesa ist eine OpenGL Implementierung, aber nicht der Treiber.

Anwendung -> Mesa -> Treiber

Könnte also bedeuten dass Mesa mit dem Treiber den ich installiert hatte nicht zusammenarbeiten wollte/konnte, oder die Anwendung wollte/konnte nicht mit Mesa sprechen? X-Plane meinte immer mein System würde kein OpenGL 2.1 unterstützen, bzw. zwei Funktionen davon die ich grad nicht mehr im Kopf habe.
 
Kommt ganz drauf an wie lange das her ist.
Laut der Seite vom Projekt Mesa war volle OpenGL 2.1 Kompatiblität am 22. Juni 2007 mit Version 7.0 hergestellt(mögliche bugfixes mal ausgenommen).
Wenn es also vor dieser Zeit war, dann könnten eben Funktionen noch nicht umgesetzt worden sein. Andere Möglichkeit ist das es nur für die GPU deiner Grafikkarte noch nicht umgesetzt war.

Aber dran denken, das bezieht sich normal nur auf die freien Grafiktreiber, da in der Regel nur diese Mesa überhaupt nutzen. Die propritären Treiber liefern eine eigene libgl mit.
 
Nee, das war mit Ubuntu 13.10. Ist noch kein halbes Jahr her.
Dann wirds an was anderem gelegen haben. Hab auch nur die freien Treiber getestet.
 
Zurück
Oben