Ich hab das gestern schon auf diversen anderen Seiten verfolgt.
Mir ging bei dem Thema sofort durch den Kopf, warum das früher noch keiner gemacht hat. Der 2. Gedanke war, dass das echt genial ist - KANN ein Riesenschritt für Linux hin zum Desktop werden und selbst wenn dieser Tracker nicht erfolgreich wird, zeigt es, dass Gallium in die richtige Richtung geht.
Gedanke 3 war dann, wann und ob Nvidia/ATI ihre Treiber wohl Gallium-fähig machen
Und zu guter letzt dann die Ernüchterung - was wird wohl MS sagen? DX ist garantiert kein offener Standard und ob die sich das gefallen lassen, dass ein System plötzlich "native" D3D/DX können ist fraglich.
Von Anonymous am Do, 23. September 2010 um 20:23 #
Sowohl NVidia als auch ATi haben ihre Treiber so geschrieben, dass der allergrößte Teil des Codes unter Windows und Linux der gleiche ist. Es ist vollkommen illusorisch, dass deren Treiber jemals Gallium usw. unterstützen.
Von Version0.1 am Mi, 22. September 2010 um 08:58 #
hier schon mal der zeitplan:
22.09.2010 - Meldung auf Pro-Linux April 2011 - d3d11gears kommt in der version 0.5 mit Stabilitätsverbesserungen Dezember 2011 - Wine unterstützt Gallium3D mit Direct3D Patch in einer Vorabversion - Notepad lässt sich öffnen. Juni 2012 - Mit Treiber "name_des_neuen_projektes_einsetzen" kann man mit Wine+Gallium3D+Direct3D Patches jetzt Spiele von 2006 mit Grafikkarten von 2004 ausführen
1.April 2012: Zum 3 Jährigen Jubiläum der Direct3D Patches portieren alle CAD-, Modellierungswerkzeug- und Visualisierungshersteller ihre OpenGL Anwendungen zu Ehren Hr. Barbieri auf D3D. Auf Smartphones der 11.Generation läuft nur noch Gallium3D mit Direct3DPatches (notepad läuft jetzt stabil)
Was ich vermisse ist so ein Desaster wie bei Compiz - das könnte man in deine Story noch einbauen:
2011 - die Entwicklung von Gallium/dx1x geht nicht schnell genug voran - ein Fork wird von 83,8% der Entwickler angestrebt und heisst Geryll.
2012 - Die Entwicklung von Geryll gerät ins stocken - die Entwicklung wird zusätzlich durch rechtliche Vorwürfe seitens MS gebremst. MS hat Angst dass weitere, jahrelang entwickelte Technologien wie der Doppelklick und der grafische Bootvorgang von Linuxfricklern kopiert werden.
2013 - Die erste gemeinsame Entwicklerkonferenz von Geryl und Gallium/dx1x findet statt - man kann jetzt neben einem Würfel auch eine Pyramide in 3D drehen (aber nur Links rum)
2014 - Geryll und Gallium fusionieren zu "Gallium Fusion" - Geryll wird eingestellt. Gleichzeitig kündigt AMD an, in Kürze die erste Treiberunterstützung für Geryll fertig zu stellen
Von theBohemian am Mi, 22. September 2010 um 08:29 #
Krasser Patch. Hat zugegebernmaßen noch lose Enden (Abhängigkeit von proprietären HSLS-Compiler wird wohl nicht so auf Gegenliebe stoßen.), aber das ganze sollte trotzdem gut genug sein, um in einem Branch von Mesa auf Hochglanz gebracht zu werden.
Ich hoffe die Beteiligten Parteien (Mesa, Wine, ...) verhalten sich kooperativ, dh. in Sinn derjenigen, die das Stück Software bald einsetzen wollen ...
Von sturmflut am Mi, 22. September 2010 um 23:00 #
Bislang hat nur ein einziger Wine-Entwickler Kritik geäußert, und das unter der Annahme falscher Tatsachen (er ging davon aus dass d3d1x auf Basis von Code aus dem Microsoft-SDK geschrieben wurde, was nicht stimmt).
Wenn d3d1x seine Funktion wie versprochen erfüllt wird sich Wine nicht ewig wehren können. Man kann dem User ja schlecht erklären warum er sich mit einer auf ewig unzureichenden und langsamen OpenGl-Brücke herumschlagen soll wenn das Direct3D-Subsystem auch unter Linux nativ existiert.
Von theBohemian am Do, 23. September 2010 um 08:37 #
Oh 'tschuldigung, dass Software nicht gleich komplett fertig und fehlerfrei aus den Köpfen der Entwickler kommt, die du nicht bezahlt hast oder über deren Freizeit zu Verfügen du kein Recht hast.
Abgesehen davon referenzierst du die falsche Seite und für die Wahl des richtigen Treibers ist ein Stück Code des X-Servers notwendig, dass nur funktionieren kann, wenn du die richtigen Pakete deiner Distribution installiert hast, was aber bei Standardinstallationen kein Problem darstellt.
Schade finde ich aber trotzdem, dass es in der Community Leute gibt, die den Wert dessen was für sie als Einzelne geleistet wird, ohne das von ihnen eine Gegenleistung erwartet wird, nicht erkennen. Sollte man mal einen Grundsatzartikel zu verfassen ...
> Das dritte erklärte Ziel von Barbieri birgt dagegen durchaus Potential für politischen > Sprengstoff: Direct3D 10/11 sei demnach wegen der deutlich kleineren API > und des modernen Designs OpenGL überlegen, und per Definition stabiler. > Ein Beweis dafür sei die Größe seines Patches > gegenüber der des existierenden OpenGL-State-Trackers. > Da sich die standardisierende Khronos Group einer deutlichen Überarbeitung > von OpenGL bislang verweigert habe, insbesondere durch Ablehnung des > mit dem Codenamen »Longs Peak« betitelten ürsprünglichen Vorschlags für > OpenGL 3.0, sei OpenGL technologisch > zurückgefallen und biete keine moderne Programmierschnittstelle. > Direct3D solle seiner Meinung nach eine direkte Alternative zu OpenGL > für Linux und andere freie Systeme werden.
Selten so einen hanebüchenen Nonsens gelesen. Wer einen OpenGL 3.x bzw. 4.x Context erzeugt, hat auch jetzt schon seine aufgeräumte API ohne Altlasten. Und eine reine OpenGL 3.x/4.x Implementierung ist sicher nicht komplexer als das jetzige Direct3D 10.x/11 Patch. Wenn er schon unbedingt einen fairen Vergleich will, dann soll er gefälligst alle alten Direct3D Versionen, die ab Mitte der 90er entwickelt wurden auch gleich mit einpflegen. Aber das war ihm ja schon bei D3D 9 zu kompliziert. OpenGL ist dagegen voll abwärtskompatibel. Meine uralten, fast 15 Jahre alten OpenGL Programme laufen auch heute noch auf moderner Hardware. Geht das bei Direct3D auch oder muss ich alle 2 Jahre die API wechseln? Wenn er Direct3D zum neuen Grafikstandard unter Linux machen will, dann ist das schlicht dumm. Erst jetzt hat die Khronos Group bei der Standardisierung wieder an fahrt aufgenommen und dann will der sich ernsthaft an eine von Microsoft entwickelte (pseudostandard) API klammern?
Von quark hoch neun am Mi, 22. September 2010 um 13:53 #
> Erst jetzt hat die Khronos Group bei der Standardisierung wieder an fahrt aufgenommen und dann will der sich ernsthaft an eine von Microsoft entwickelte (pseudostandard) API klammern?
Was spricht dagegen zweigleisig zu fahren? Wem schadet den die zusätzliche Unterstützung?????????????
Du kannst so viel zweigleisig fahren wie du willst. Ich halte sicher niemanden davon ab. Nur habe ich seine falschen Behauptungen und die sich daraus ergebende Implikation der technologisch "überlegenen" Alternative zu OpenGL auf Linux richtig gestellt.
Ja, weil die Unterstützung implementiert ist, oder was glaubst du? Schließlich reden wir hier von einer Linux-Treiberarchitektur für 3D-Grakas und nicht von Win7. Hat Barbieri auch Unterstützung für die alten D3D Programme in Gallium3D integriert? Der Vergleich "technisch überlegenes"/"kompaktes" Direct3D 10.x/11 vs "veraltetes"/"fettes" OpenGL ist unsinnig, da die OpenGL Implementierung abwärtskompatibel ist und die Direct3D-Implementierung in Gallium3D eben nicht. Also bitte beim Thema bleiben.
zur erklärung: einige directX versionen sind zwar abwärts kompatibel zu ihren vorgängerversionen, jedoch gibt es immer wieder größere änderungen im system.
directX 10 und 11 sind miteinander kompatibel, aber dx9 wird wenn du dx10 installierst, extra mitinstalliert - und alle davor mitgenommenen "wechselreleases" von dx.
opengl dagegen ist immer mit sich kompatibel, sodass ein opengl1.0 programm in zeiten von opengl2 problemlos anpassungslos verwendet werden kann.
was als modern bei dx1x bezeichnet der schreiber von dx1x jedoch nur die zugriffe auf bestimmte technologien - er geht davon aus, dass dx12 und dx13 dann ebenfalls noch auf dx10 basieren.
das problem zweigleisig zu fahren ist also, dass bei jeder änderung von ms auch die community hinter linux hinsetzen muss, und die neue dx version implementieren muss.
dass man aber dadurch alle dx10 und dx11 basierten programme schön portieren könnte, wäre ein vorteil, und man könnte heutige effekte schon nutzen und müsste nicht warten bis opengl sich entschließt, erneut die architektur zu erweitern.
es schadet auf jeden fall nicht, soetwas zu haben, aber es könnte in nur 5 jahren wieder einfach ein antiquiertes system sein, welches mitgeschleppt und verändert werden muss.
ausser man kann mit einer freien implementation microsoft dazu zwingen, ab dann ihren eigenen standard so zu pflegen, dass auch linux mitkommt - und das wird es wohl derzeit noch nicht spielen. aber wer weiss. ms ändert ja langsam das gesicht.
Von Anonymous am Mi, 22. September 2010 um 14:30 #
"dazu ist wohl DX nicht Patentfrei. Bei MS kann ich mir das nicht vorstellen."
Das ist OpenGL auch nicht. Geht schon bei S3TC los. Bei OGL und D3D wird man wohl Patente Lizenzieren müssen um eine Vollständigen Implementierung zu haben.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Sep 2010 um 14:33.
Von Anonymous am Mi, 22. September 2010 um 14:29 #
"Wenn er Direct3D zum neuen Grafikstandard unter Linux machen will, dann ist das schlicht dumm. Erst jetzt hat die Khronos Group bei der Standardisierung wieder an fahrt aufgenommen und dann will der sich ernsthaft an eine von Microsoft entwickelte (pseudostandard) API klammern?"
Es gibt keinen unterschied zwischen D3D und OpenGL in der Hinsicht. Mal abgesehen das Microsoft die Hand auf D3D hat. Es sind beides nur APIs die man Implementieren müsste (Was ja nun bei D3D10 und 11 geschehen ist).
Die Khronos Gruppe sagt was zu OpenGL gehört und Microsoft sagt was zu D3D gehört. Der einzige unterschied ist das Microsoft mehr am Pushen ist. Wenn ich mir mal anschaue was ich alle mit dem DX SDK bekomme und was ich auf der OpenGL Seite bekomme dann fällt es nicht schwer sich für eine zu entscheiden.
Zu D3D9: Warum sollte er das auch noch Implementieren? Auf einem System wo man eh die Software anpassen müsste würde ich mir das Tote Pferd DX9 nicht mehr ans Bein binden.
> Zu D3D9: Warum sollte er das auch noch Implementieren? > Auf einem System wo man eh die Software anpassen müsste würde ich > mir das Tote Pferd DX9 nicht mehr ans Bein binden.
Genau deswegen ist der Vergleich "technisch überlegenses" DirectX 10.x/11 vs. "veraltetes" OpenGL des Entwicklers unangebracht. Meine alten OGL Programme werden auf Gallium3D laufen aber kein einiziges Direct3D 9 Programm.
Von Anonymous am Mi, 22. September 2010 um 15:09 #
Wo hat er denn D3D10/11 mit einer alten OpenGL Version verglichen? Er findet halt das D3D10/11 OpenGL überlegen ist weil es aufgeräumter ist und Moderner verglichen mit der aktuellen OpenGL Version.
"Meine alten OGL Programme werden auf Gallium3D laufen aber kein einiziges Direct3D 9 Programm."
Aber halt nur weil die OpenGL Implementierung Mesa Abwärtskompatible ist. Bei Einführung einer "neuen" API ist das aber kein Kriterium da es einfach keine alten Anwendungen gibt. Und nachträglich die D3D APIs der letzten 10 Jahre zu Implementieren ist eine Extrem aufwendige Arbeit. Ich glaube auch kaum, das wenn jemand Heute noch eine neue OpenGL Implementierung schreibt auf OGL 2.0 und niedriger achten würde.
> Wo hat er denn D3D10/11 mit einer alten OpenGL Version verglichen? > Er findet halt das D3D10/11 OpenGL überlegen ist weil es aufgeräumter > ist und Moderner verglichen mit der aktuellen OpenGL Version.
Von fghjdfu@cdu.de am Do, 23. September 2010 um 17:41 #
Das erfolgreichste Kompjutaspiel 2010 basiert rein auf D3D9, nämlich StarCraft2. Wer hohe Stückzahlen verkaufen will, kann es sich nicht leisten die WindowsXP Nutzer auszuschließen.
Ich hab das gestern schon auf diversen anderen Seiten verfolgt.
Mir ging bei dem Thema sofort durch den Kopf, warum das früher noch keiner gemacht hat. Der 2. Gedanke war, dass das echt genial ist - KANN ein Riesenschritt für Linux hin zum Desktop werden und selbst wenn dieser Tracker nicht erfolgreich wird, zeigt es, dass Gallium in die richtige Richtung geht.
Gedanke 3 war dann, wann und ob Nvidia/ATI ihre Treiber wohl Gallium-fähig machen
Und zu guter letzt dann die Ernüchterung - was wird wohl MS sagen? DX ist garantiert kein offener Standard und ob die sich das gefallen lassen, dass ein System plötzlich "native" D3D/DX können ist fraglich.
LG
NVidia und ATI sollten erst einmal KMS implementieren.
Wofür braucht man das unbedingt?
Kernel Modesetting ist Voraussetzung zur Verwendung des GPU Memory Managers im Kernel und damit auch für den ganzen Rest des neuen Grafikstacks.
Sowohl NVidia als auch ATi haben ihre Treiber so geschrieben, dass der allergrößte Teil des Codes unter Windows und Linux der gleiche ist. Es ist vollkommen illusorisch, dass deren Treiber jemals Gallium usw. unterstützen.
hier schon mal der zeitplan:
22.09.2010 - Meldung auf Pro-Linux
April 2011 - d3d11gears kommt in der version 0.5 mit Stabilitätsverbesserungen
Dezember 2011 - Wine unterstützt Gallium3D mit Direct3D Patch in einer Vorabversion - Notepad lässt sich öffnen.
Juni 2012 - Mit Treiber "name_des_neuen_projektes_einsetzen" kann man mit Wine+Gallium3D+Direct3D Patches jetzt Spiele von 2006 mit Grafikkarten von 2004 ausführen
1.April 2012: Zum 3 Jährigen Jubiläum der Direct3D Patches portieren alle CAD-, Modellierungswerkzeug- und Visualisierungshersteller ihre OpenGL Anwendungen zu Ehren Hr. Barbieri auf D3D.
Auf Smartphones der 11.Generation läuft nur noch Gallium3D mit Direct3DPatches (notepad läuft jetzt stabil)
Sehr geil
Was ich vermisse ist so ein Desaster wie bei Compiz - das könnte man in deine Story noch einbauen:
2011 - die Entwicklung von Gallium/dx1x geht nicht schnell genug voran - ein Fork wird von 83,8% der Entwickler angestrebt und heisst Geryll.
2012 - Die Entwicklung von Geryll gerät ins stocken - die Entwicklung wird zusätzlich durch rechtliche Vorwürfe seitens MS gebremst. MS hat Angst dass weitere, jahrelang entwickelte Technologien wie der Doppelklick und der grafische Bootvorgang von Linuxfricklern kopiert werden.
2013 - Die erste gemeinsame Entwicklerkonferenz von Geryl und Gallium/dx1x findet statt - man kann jetzt neben einem Würfel auch eine Pyramide in 3D drehen (aber nur Links rum)
2014 - Geryll und Gallium fusionieren zu "Gallium Fusion" - Geryll wird eingestellt. Gleichzeitig kündigt AMD an, in Kürze die erste Treiberunterstützung für Geryll fertig zu stellen
was ist daran geil? Schwachsinn wird jetzt geil genannt. Wie geil!
Oh, verzeihn' se gnädger Herr ...
Krasser Patch. Hat zugegebernmaßen noch lose Enden (Abhängigkeit von proprietären HSLS-Compiler wird wohl nicht so auf Gegenliebe stoßen.), aber das ganze sollte trotzdem gut genug sein, um in einem Branch von Mesa auf Hochglanz gebracht zu werden.
Ich hoffe die Beteiligten Parteien (Mesa, Wine, ...) verhalten sich kooperativ, dh. in Sinn derjenigen, die das Stück Software bald einsetzen wollen ...
> Ich hoffe die Beteiligten Parteien (Mesa, Wine, ...) verhalten sich kooperativ
Noch nicht ganz:
http://forum.golem.de/kommentare/opensource/d3d1x-direct3d-10-und-11-fuer-linux/bloed-das-wine-nichts-damit-zu-tun-haben-moechte./45287,2441306,2441306,read.html#msg-2441306
Bislang hat nur ein einziger Wine-Entwickler Kritik geäußert, und das unter der Annahme falscher Tatsachen (er ging davon aus dass d3d1x auf Basis von Code aus dem Microsoft-SDK geschrieben wurde, was nicht stimmt).
Wenn d3d1x seine Funktion wie versprochen erfüllt wird sich Wine nicht ewig wehren können. Man kann dem User ja schlecht erklären warum er sich mit einer auf ewig unzureichenden und langsamen OpenGl-Brücke herumschlagen soll wenn das Direct3D-Subsystem auch unter Linux nativ existiert.
Welchen Treiber nehm ich denn für meine Grafikkarte?
Da schau ich mal nach:
http://www.x.org/wiki/GalliumStatus
Ah ja. Keinen.
yeah, mein radeon (r300) ist ja schon ziemlich weit! glaube ich teste den spaß einfach mal
Ich glaube kaum das die DX9 Hardware da mitmacht.
Ist eine solche Einschränkung hardwarebedingt oder ist das softwareseitige "Absicht"?
Wenn man keine Ahnung hat, einfach mal die Fresse halten.
Ganz genau deswegen halte den Rand.
Der r600g oder nouveau werden wohl zu den ersten gehören.
Oh 'tschuldigung, dass Software nicht gleich komplett fertig und fehlerfrei aus den Köpfen der Entwickler kommt, die du nicht bezahlt hast oder über deren Freizeit zu Verfügen du kein Recht hast.
Abgesehen davon referenzierst du die falsche Seite und für die Wahl des richtigen Treibers ist ein Stück Code des X-Servers notwendig, dass nur funktionieren kann, wenn du die richtigen Pakete deiner Distribution installiert hast, was aber bei Standardinstallationen kein Problem darstellt.
Schade finde ich aber trotzdem, dass es in der Community Leute gibt, die den Wert dessen was für sie als Einzelne geleistet wird, ohne das von ihnen eine Gegenleistung erwartet wird, nicht erkennen. Sollte man mal einen Grundsatzartikel zu verfassen ...
> Das dritte erklärte Ziel von Barbieri birgt dagegen durchaus Potential für politischen
> Sprengstoff: Direct3D 10/11 sei demnach wegen der deutlich kleineren API
> und des modernen Designs OpenGL überlegen, und per Definition stabiler.
> Ein Beweis dafür sei die Größe seines Patches
> gegenüber der des existierenden OpenGL-State-Trackers.
> Da sich die standardisierende Khronos Group einer deutlichen Überarbeitung
> von OpenGL bislang verweigert habe, insbesondere durch Ablehnung des
> mit dem Codenamen »Longs Peak« betitelten ürsprünglichen Vorschlags für
> OpenGL 3.0, sei OpenGL technologisch
> zurückgefallen und biete keine moderne Programmierschnittstelle.
> Direct3D solle seiner Meinung nach eine direkte Alternative zu OpenGL
> für Linux und andere freie Systeme werden.
Selten so einen hanebüchenen Nonsens gelesen. Wer einen OpenGL 3.x bzw. 4.x Context erzeugt, hat auch jetzt schon seine aufgeräumte API ohne Altlasten. Und eine reine OpenGL 3.x/4.x Implementierung ist sicher nicht komplexer als das jetzige Direct3D 10.x/11 Patch.
Wenn er schon unbedingt einen fairen Vergleich will, dann soll er gefälligst alle alten Direct3D Versionen, die ab Mitte der 90er entwickelt wurden auch gleich mit einpflegen. Aber das war ihm ja schon bei D3D 9 zu kompliziert. OpenGL ist dagegen voll abwärtskompatibel. Meine uralten, fast 15 Jahre alten OpenGL Programme laufen auch heute noch auf moderner Hardware. Geht das bei Direct3D auch oder muss ich alle 2 Jahre die API wechseln?
Wenn er Direct3D zum neuen Grafikstandard unter Linux machen will, dann ist das schlicht dumm. Erst jetzt hat die Khronos Group bei der Standardisierung wieder an fahrt aufgenommen und dann will der sich ernsthaft an eine von Microsoft entwickelte (pseudostandard) API klammern?
> Erst jetzt hat die Khronos Group bei der Standardisierung wieder an fahrt aufgenommen und dann will der sich ernsthaft an eine von Microsoft entwickelte (pseudostandard) API klammern?
Was spricht dagegen zweigleisig zu fahren? Wem schadet den die zusätzliche Unterstützung?????????????
Du kannst so viel zweigleisig fahren wie du willst. Ich halte sicher niemanden davon ab. Nur habe ich seine falschen Behauptungen und die sich daraus ergebende Implikation der technologisch "überlegenen" Alternative zu OpenGL auf Linux richtig gestellt.
Vielleicht ist das alles nur ein genialer Schachzug um der Khronos Group Feuer unterm Hintern zu machen?
>> Meine uralten, fast 15 Jahre alten OpenGL Programme laufen auch heute noch auf moderner Hardware.
Diablo2, StarCraft, Doom1-Win32 und Co beweisen das 10-15Jahre alte DX-Programme durchaus auch noch unter Win7 laufen können...
Ja, weil die Unterstützung implementiert ist, oder was glaubst du? Schließlich reden wir hier von einer Linux-Treiberarchitektur für 3D-Grakas und nicht von Win7. Hat Barbieri auch Unterstützung für die alten D3D Programme in Gallium3D integriert?
Der Vergleich "technisch überlegenes"/"kompaktes" Direct3D 10.x/11 vs "veraltetes"/"fettes" OpenGL ist unsinnig, da die OpenGL Implementierung abwärtskompatibel ist und die Direct3D-Implementierung in Gallium3D eben nicht. Also bitte beim Thema bleiben.
zur erklärung: einige directX versionen sind zwar abwärts kompatibel zu ihren vorgängerversionen, jedoch gibt es immer wieder größere änderungen im system.
directX 10 und 11 sind miteinander kompatibel, aber dx9 wird wenn du dx10 installierst, extra mitinstalliert - und alle davor mitgenommenen "wechselreleases" von dx.
opengl dagegen ist immer mit sich kompatibel, sodass ein opengl1.0 programm in zeiten von opengl2 problemlos anpassungslos verwendet werden kann.
was als modern bei dx1x bezeichnet der schreiber von dx1x jedoch nur die zugriffe auf bestimmte technologien - er geht davon aus, dass dx12 und dx13 dann ebenfalls noch auf dx10 basieren.
das problem zweigleisig zu fahren ist also, dass bei jeder änderung von ms auch die community hinter linux hinsetzen muss, und die neue dx version implementieren muss.
dass man aber dadurch alle dx10 und dx11 basierten programme schön portieren könnte, wäre ein vorteil, und man könnte heutige effekte schon nutzen und müsste nicht warten bis opengl sich entschließt, erneut die architektur zu erweitern.
es schadet auf jeden fall nicht, soetwas zu haben, aber es könnte in nur 5 jahren wieder einfach ein antiquiertes system sein, welches mitgeschleppt und verändert werden muss.
ausser man kann mit einer freien implementation microsoft dazu zwingen, ab dann ihren eigenen standard so zu pflegen, dass auch linux mitkommt - und das wird es wohl derzeit noch nicht spielen.
aber wer weiss. ms ändert ja langsam das gesicht.
dazu ist wohl DX nicht Patentfrei. Bei MS kann ich mir das nicht vorstellen.
"dazu ist wohl DX nicht Patentfrei. Bei MS kann ich mir das nicht vorstellen."
Das ist OpenGL auch nicht. Geht schon bei S3TC los.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Sep 2010 um 14:33.Bei OGL und D3D wird man wohl Patente Lizenzieren müssen um eine Vollständigen Implementierung zu haben.
Du "kannst dir das nicht vorstellen"? Dann weißt du's also nicht? Warum schreibst du dann was dazu?
"Wenn er Direct3D zum neuen Grafikstandard unter Linux machen will, dann ist das schlicht dumm. Erst jetzt hat die Khronos Group bei der Standardisierung wieder an fahrt aufgenommen und dann will der sich ernsthaft an eine von Microsoft entwickelte (pseudostandard) API klammern?"
Es gibt keinen unterschied zwischen D3D und OpenGL in der Hinsicht. Mal abgesehen das Microsoft die Hand auf D3D hat. Es sind beides nur APIs die man Implementieren müsste (Was ja nun bei D3D10 und 11 geschehen ist).
Die Khronos Gruppe sagt was zu OpenGL gehört und Microsoft sagt was zu D3D gehört.
Der einzige unterschied ist das Microsoft mehr am Pushen ist. Wenn ich mir mal anschaue was ich alle mit dem DX SDK bekomme und was ich auf der OpenGL Seite bekomme dann fällt es nicht schwer sich für eine zu entscheiden.
Zu D3D9: Warum sollte er das auch noch Implementieren? Auf einem System wo man eh die Software anpassen müsste würde ich mir das Tote Pferd DX9 nicht mehr ans Bein binden.
> Zu D3D9: Warum sollte er das auch noch Implementieren?
> Auf einem System wo man eh die Software anpassen müsste würde ich
> mir das Tote Pferd DX9 nicht mehr ans Bein binden.
Genau deswegen ist der Vergleich "technisch überlegenses" DirectX 10.x/11 vs. "veraltetes" OpenGL des Entwicklers unangebracht. Meine alten OGL Programme werden auf Gallium3D laufen aber kein einiziges Direct3D 9 Programm.
Wo hat er denn D3D10/11 mit einer alten OpenGL Version verglichen? Er findet halt das D3D10/11 OpenGL überlegen ist weil es aufgeräumter ist und Moderner verglichen mit der aktuellen OpenGL Version.
"Meine alten OGL Programme werden auf Gallium3D laufen aber kein einiziges Direct3D 9 Programm."
Aber halt nur weil die OpenGL Implementierung Mesa Abwärtskompatible ist. Bei Einführung einer "neuen" API ist das aber kein Kriterium da es einfach keine alten Anwendungen gibt. Und nachträglich die D3D APIs der letzten 10 Jahre zu Implementieren ist eine Extrem aufwendige Arbeit. Ich glaube auch kaum, das wenn jemand Heute noch eine neue OpenGL Implementierung schreibt auf OGL 2.0 und niedriger achten würde.
> Wo hat er denn D3D10/11 mit einer alten OpenGL Version verglichen?
> Er findet halt das D3D10/11 OpenGL überlegen ist weil es aufgeräumter
> ist und Moderner verglichen mit der aktuellen OpenGL Version.
Was zu beweisen wäre...
Sicher aber er ist nicht der einzige der so denkt bzw. solche Aussagen macht.
Gut, dann seid ihr schon mal 2 die keine Ahnung haben. q.e.d.
Jetzt machst du dich aber lächerlich.
Den Beleg bist du mir immer noch schuldig.
Das erfolgreichste Kompjutaspiel 2010 basiert rein auf D3D9, nämlich StarCraft2. Wer hohe Stückzahlen verkaufen will, kann es sich nicht leisten die WindowsXP Nutzer auszuschließen.