Archiv verlassen und diese Seite im Standarddesign anzeigen : Windows Longhorn und OpenGL
Corrail
2004-03-01, 15:41:19
Hi all!
Ich hoffe, der Thread ist hier im forum richtig aufgehoben...
Wollte mal nachfragen, wies beim neuen Windows Longhorn mit OpenGL ausschaut. Wird Longhorn OpenGL Unterstützung haben?
Vielen Dank
Dei Wahrscheinlichkeit dürfte bei 99% liegen wenn Longhorn auch professionelle Anwender anprechen soll :D
Godmode
2004-03-01, 15:51:12
Meinst du bezogen of Avalon als das 3D-GUI? Wenn ja, würde ich sagen das sie hier nur DX verwenden!! Da DirectX aus dem Hause M$ kommt und warum sollten sie da OpenGL verwenden?
Wenn du aber jetzt was anderes meinst sag bescheid.
Corrail
2004-03-01, 15:54:20
Nein, ich meine ob das Windows Longhorn die OpenGL API für normale Programme unterstützt. Spiele, Render wie 3DS Max und Maya, ...
Wäre "echt Schade" (<- nicht zu ernst nehmen... :-), wenn ich mit meinen Programmierspielereien auf Linux umsteigen müsste.
StefanV
2004-03-01, 15:58:16
natürlich, aber eigentlich unterstützt M$ OGL seit einiger Zeit nicht mehr...
Godmode
2004-03-01, 16:04:14
Original geschrieben von Corrail
Nein, ich meine ob das Windows Longhorn die OpenGL API für normale Programme unterstützt. Spiele, Render wie 3DS Max und Maya, ...
Wäre "echt Schade" (<- nicht zu ernst nehmen... :-), wenn ich mit meinen Programmierspielereien auf Linux umsteigen müsste.
Axxo, ja klar müssen sie das wieder unterstützen sonst werden sie sicher wieder verklagt!! Was würde den John Carmack machen wenn Win LH kein OGL unterstützen würde, der würde doch glatt durchdrehen ;D ;D
Spass bei Seite :)
Ja, zum zutrauen wär es ja M$ dass sie DX als einzige Grafik API durchsetzen wollen. Ich weiss jetzt nicht ob die IHVs damit mehr Arbeit haben, dass die Karten mit DX und OGL klarkommen denke aber schon.
Ich programmiere leider nur mit DX und hab mit OGL noch keine Erfahrungen gemacht, also kann ich nicht sagen ob OGL besser oder schlecht ist als DX. Aber es ist sicher eine gute API sonst würde es ja John Carmack nicht verwenden!!
Corrail
2004-03-01, 16:10:03
Original geschrieben von bans3i
Ich programmiere leider nur mit DX und hab mit OGL noch keine Erfahrungen gemacht, also kann ich nicht sagen ob OGL besser oder schlecht ist als DX.
Bei mir ist es genau umgekehrt. Ich hab nichts gegen DX, aber M$ Politik... Naja, wie auch immer.
Freut mich jedenfalls zu hören, dass MS doch nicht ganz durchgeknallt ist :-)
deekey777
2004-03-01, 17:02:41
Axxo, ja klar müssen sie das wieder unterstützen sonst werden sie sicher wieder verklagt!! Was würde den John Carmack machen wenn Win LH kein OGL unterstützen würde, der würde doch glatt durchdrehen.
Nein, würde er nicht - er hat nur gedroht, dass kein Doom 3 für Windows erscheinen wird, falls Next Windows keine OpenGL-Unterstützung haben wird.
marco42
2004-03-01, 18:18:02
Original geschrieben von Stefan Payne
natürlich, aber eigentlich unterstützt M$ OGL seit einiger Zeit nicht mehr...
Naja, leichte Untertreibung, wenn man sich die ARB Meeting Notes durchliest. Da hat dann Mircosoft immer behauptet, dass sie Patente auf Shader beantragt haben. Deswegen gab es die auch erst so spaet. Die OpenGL32.dll scheint ja auch noch bei 1.1 stehen geblieben zu sein.
Das ist halt der Nachteil von fehlendem Wettbewerb. Ich hoffe wirklich Linux bekommt so einen Marktanteil von 30%. MacOS bekommt vielleicht noch etwas mehr.
Beim Internet Explorer probieren sie es ja im Moment auch schon wieder. CSS unterstuetzen sie nicht richtig(da waren sie mal die Besten) und mit Longhorn wollen sie eher etwas eigenes einfuehren. Ich hoffe da passiert einfach was. Vielleicht werden die Mobiltelefone MS das an tun, was der PC IBM angetan hat. IBM in den Siebzigern war auch nicht besser als MS heute.
ShadowXX
2004-03-01, 23:39:43
Original geschrieben von marco42
Naja, leichte Untertreibung, wenn man sich die ARB Meeting Notes durchliest. Da hat dann Mircosoft immer behauptet, dass sie Patente auf Shader beantragt haben. Deswegen gab es die auch erst so spaet. Die OpenGL32.dll scheint ja auch noch bei 1.1 stehen geblieben zu sein.
Das ist halt der Nachteil von fehlendem Wettbewerb. Ich hoffe wirklich Linux bekommt so einen Marktanteil von 30%. MacOS bekommt vielleicht noch etwas mehr.
Beim Internet Explorer probieren sie es ja im Moment auch schon wieder. CSS unterstuetzen sie nicht richtig(da waren sie mal die Besten) und mit Longhorn wollen sie eher etwas eigenes einfuehren. Ich hoffe da passiert einfach was. Vielleicht werden die Mobiltelefone MS das an tun, was der PC IBM angetan hat. IBM in den Siebzigern war auch nicht besser als MS heute.
Findest du die 30 Prozent Marktanteil fuer Linux (plus nochmal 30 plus x fuers MacOs) nicht etwas optimistisch.;D ;D
Zumindest fuer die naechsten 5 bis 15 Jahre?
J.S.Shadow
marco42
2004-03-02, 00:45:51
Original geschrieben von ShadowXX
Findest du die 30 Prozent Marktanteil fuer Linux (plus nochmal 30 plus x fuers MacOs) nicht etwas optimistisch.;D ;D
Zumindest fuer die naechsten 5 bis 15 Jahre?
J.S.Shadow
Ach, in zehn Jahren kann viel passieren. Bei den Server ist das ja in 4-5 Jahren soweit. Wenn ich mich an den Unis so umschaue waechst da doch eine Menge Linux know how heran.
Beim Desktop(X11 ist einfach brackig alt) bin ich mir nicht so sicher, aber der wird sich IMHO noch sehr veraendern, allein durch das Aufkommen von Smartphones. Und hier versuchen die Hersteller MS bloss kein Bein auf den Boden bekommen zu lassen.
Bei OpenGL sehe ich im Moment wieder positiver in die Zukunft. Es scheint sich wirklich was zu bewegen. VBO's, GLSlang und Superbuffers, es geht in die richtige Richtigung.
Komische Diskussion.
OpenGL wird in erster Linie von den Treibern zur Verfügung gestellt, Win bietet nur eine 1.1 Version, die rein in Software läuft.
Da verstehe ich nicht, was das heissen soll, Win unterstütze kein OpenGL mehr. Die Version, die mitgeliefert wird, braucht eh keiner - jede halbwegs vernünftige Graphikkarte bringt eine aktuellere und v.a. beschleunigte mit.
marco42
2004-03-08, 17:12:37
Original geschrieben von Gast
Komische Diskussion.
OpenGL wird in erster Linie von den Treibern zur Verfügung gestellt, Win bietet nur eine 1.1 Version, die rein in Software läuft.
Da verstehe ich nicht, was das heissen soll, Win unterstütze kein OpenGL mehr. Die Version, die mitgeliefert wird, braucht eh keiner - jede halbwegs vernünftige Graphikkarte bringt eine aktuellere und v.a. beschleunigte mit.
Du hast aber nur die OpenGL 1.1 Symbols in der OpenGL32.dll und darueber greifen alle Spiele darauf zu. OpenGL interagiert mit dem Windows System und darum ging es.
Wenn du OpenGL Symbols ueber 1.1 zugreifen willst must du dir unter Windows einen "Ast" abbrechen, auf jeden Fall ist es komplizierter als unter Linux.
Die Treiber, die viele Karten mitbringen reichen meistens gerade fuer Quake aus. Nvidia ist da eine Ausnahme, da sie auch professionelle Karten verkaufen.
Unter Linux kann man im Moment unter OpenGL eigentlich nur Nvidia empfehlen, da ATI geruechteweise den Support wieder einstellt(wirklich schade). Ok, unter Linux duerfte der Grund auch mehr professionelle Anwendungen als Spiele(gibt es kaum) sein. ATI hat da immer noch einen nicht so guten Ruf.
Hauwech
2004-03-08, 17:48:43
Ich habe nicht viel bis keine Ahnung von OGL unter Windows, koennte mir aber vorstellen das entweder nVidia oder das jeweilige Programm (Doom3 zB) entsprechende Dateien mitbringen um die Limitierung in Windows zu umgehen. So aehnlich wie zB Windows BIOS Einstellungen uebergeht bzw eigene Dateien benutzt.
Statt der Windows OpenGL32.dll eine von mir aus benannte JCOGL32.dll :D von JC oder NVOGL32.dll :D von nVidia zum Beispiel die halt mehr koennen.
Richtig? Falsch? Doof? Toll? :)
Corrail
2004-03-08, 17:56:12
Original geschrieben von Hauwech
... entsprechende Dateien mitbringen um die Limitierung in Windows zu umgehen.
Es ist auch unter Windows möglich sämtliche OpenGL Funktionen zu nutzen. Man muss sie aber durch Extensions ansprechen, sie sind also nicht in der Core-API enthalten. Wenn man z.B. die OpenGL Shading Language verwenden will muss man at runtime die Funktionen, die diese Extension erfordert binden.
@Marco42: versteh ich noch immer nicht. Ich kann mir irgendwie nicht vorstellen, dass die Spiele die alte opengl32.dll v1.1 ansprechen, um extensions anzusprechen, die Win gar nicht mitbringt?
Wie war das dann unter Win98? Die hatte gar keine opengl32.dll.
AFAIK gibts einen registry-eintrag, der auf die opengl-Bibliothek der Karte verweist, das macht auch mehr Sinn. Wie findet die Anwendung heraus, was überhaupt an Möglichkeiten sprich OpenGL-Version vorhanden ist? Sowas kann doch nur über Prüfung der echten OpenGL-Bibliothek erfolgen.
Abgesehen davon verstehe ich leider auch nicht, warum zB Atis OpenGL-dll nicht für Profis taugen soll (bestenfalls für Quake??), die Prozeduren stehen zur Verfügung, sonst darf sie sich nicht für eine OpenGL-Version ausgeben, die die Prozedur definiert(extensions sind da anders).
Bei Profi-Tauglichkeit ist AFAIK nur von Performance die Rede (und von Stabilität klar).
marco42
2004-03-08, 20:35:21
Original geschrieben von Hauwech
Ich habe nicht viel bis keine Ahnung von OGL unter Windows, koennte mir aber vorstellen das entweder nVidia oder das jeweilige Programm (Doom3 zB) entsprechende Dateien mitbringen um die Limitierung in Windows zu umgehen. So aehnlich wie zB Windows BIOS Einstellungen uebergeht bzw eigene Dateien benutzt.
Statt der Windows OpenGL32.dll eine von mir aus benannte JCOGL32.dll :D von JC oder NVOGL32.dll :D von nVidia zum Beispiel die halt mehr koennen.
Richtig? Falsch? Doof? Toll? :)
Ich bin da auch nicht Experte, aber AFAIK rufst du durch die opengl32.dll den nvidia treiber auf. Nennt sich ICD, es gibt da noch MCD, dass ist wohl mehr dem DirectX Mechanismus ahenlich, aber tot.
marco42
2004-03-08, 20:40:19
Original geschrieben von Corrail
Es ist auch unter Windows möglich sämtliche OpenGL Funktionen zu nutzen. Man muss sie aber durch Extensions ansprechen, sie sind also nicht in der Core-API enthalten. Wenn man z.B. die OpenGL Shading Language verwenden will muss man at runtime die Funktionen, die diese Extension erfordert binden.
Du verwechselst hier Extensions mit dem wglGetProc Mechanismus um einen Function Pointer zu bekommen. Den benutzt du unter Windows zwar auch fuer Extensions, aber auch fuer alles Core Funktionen ueber 1.1. Das ist IMHO ziemlich umstaendlich. Unter Linux brauchst du das nicht, da die Libraries hier auf 1.5 Niveau sind. Ich kann hier sogar die Extensions ganz normal ansprechen.
marco42
2004-03-08, 20:52:50
Original geschrieben von Gast
@Marco42: versteh ich noch immer nicht. Ich kann mir irgendwie nicht vorstellen, dass die Spiele die alte opengl32.dll v1.1 ansprechen, um extensions anzusprechen, die Win gar nicht mitbringt?
Wie war das dann unter Win98? Die hatte gar keine opengl32.dll.
Es gab ein SDK von Microsoft? Ob das dabei war, weiss ich nicht. Ich dachte immer ab 95b waere es dabei gewesen.
Original geschrieben von Gast
Abgesehen davon verstehe ich leider auch nicht, warum zB Atis OpenGL-dll nicht für Profis taugen soll (bestenfalls für Quake??), die Prozeduren stehen zur Verfügung, sonst darf sie sich nicht für eine OpenGL-Version ausgeben, die die Prozedur definiert(extensions sind da anders).
Bei Profi-Tauglichkeit ist AFAIK nur von Performance die Rede (und von Stabilität klar).
Die Performance von nvidia bei vielen Sachen ist/war einfach besser. Ausser Unterstuetzt ATI einfach ein paar Sachen nicht so gut. Schau dir mal die einschlaegigen Tests an. Es gibt viele Sachen, die musst du nicht machen. Ich sag nur GL_LINE_SMOOTH/glHint oder es laeuft in sehr langsam(glMap). ATI hat da einfach einen schlechteren Ruf, der aber besser gewerden ist. Unter Linux sieht es im Moment sehr Mau aus.
Wie sieht es eigentlich mit Overlays bei ATI aus?
Im profesionellen Bereich gibt es dann auch wieder 3Dlabs.
Corrail
2004-03-08, 21:55:44
Original geschrieben von marco42
Du verwechselst hier Extensions mit dem wglGetProc Mechanismus um einen Function Pointer zu bekommen. Den benutzt du unter Windows zwar auch fuer Extensions, aber auch fuer alles Core Funktionen ueber 1.1. Das ist IMHO ziemlich umstaendlich. Unter Linux brauchst du das nicht, da die Libraries hier auf 1.5 Niveau sind. Ich kann hier sogar die Extensions ganz normal ansprechen.
Ähm... Alles ab OGL 1.1 muss ich in Windows sowieso mit wglGetProcAddress vorher bindern. Und alles, was derzeit im Core ist, ist auch als Extension vorhanden (ARB_multitexture, ...). Somit kannst/musst du alles was neuer ist als OGL 1.1 durch Extensions ansprechen.
Und so umständlich ist das nicht. Die interessanten Extensions (ARB_*_program, GLslang, ...) sind noch nicht im Core somit muss man sie eh als Extensions implementieren. Und ob man dann auch noch die paar mehr extensions mehr macht, die im Core drinnen sind ist dann auch schon ziehmlich egal.
Original geschrieben von Gast
Komische Diskussion.
OpenGL wird in erster Linie von den Treibern zur Verfügung gestellt, Win bietet nur eine 1.1 Version, die rein in Software läuft.WinXP scheint OpenGL auf DirectX zu wrappen (solange der Treiber keine eigene OpenGL-Unterstützung mitbringt.)
tokugawa
2004-03-09, 09:20:33
Original geschrieben von Gast
@Marco42: versteh ich noch immer nicht. Ich kann mir irgendwie nicht vorstellen, dass die Spiele die alte opengl32.dll v1.1 ansprechen, um extensions anzusprechen, die Win gar nicht mitbringt?
Wie war das dann unter Win98? Die hatte gar keine opengl32.dll.
AFAIK gibts einen registry-eintrag, der auf die opengl-Bibliothek der Karte verweist, das macht auch mehr Sinn. Wie findet die Anwendung heraus, was überhaupt an Möglichkeiten sprich OpenGL-Version vorhanden ist? Sowas kann doch nur über Prüfung der echten OpenGL-Bibliothek erfolgen.
Abgesehen davon verstehe ich leider auch nicht, warum zB Atis OpenGL-dll nicht für Profis taugen soll (bestenfalls für Quake??), die Prozeduren stehen zur Verfügung, sonst darf sie sich nicht für eine OpenGL-Version ausgeben, die die Prozedur definiert(extensions sind da anders).
Bei Profi-Tauglichkeit ist AFAIK nur von Performance die Rede (und von Stabilität klar).
Auf meiner ATI Radeon 9500 Pro bin ich schon öfters über diverse "Bugs" und Schwächen gestolpert.
Bei Cat 3.4 (soweit ich mich erinnern kann) hab ich bei einem von mir implementierten (Level-)Editor-Tool, das 4 Viewports nutzte (und damit 4 GL Render Contexts, zwischen denen mit wglMakeCurrent() geswitcht wurde), Probleme beim Löschen der Render-Contexts bekommen, wenn ich in jeden der 4 Render-Contexts Display-Lists generiert habe mittels wglUseFontBitmaps(), also ohne Shared Display List Space. Es trat soweit ich mich erinnern kann ein Invalid Page Fault oder ähnliches auf im ATI Treiber (also nicht in meiner Anwendung).
Und jetzt bin ich wieder auf eine (kleinere) Unzulängigkeit (Cat 4.2) gestoßen: in meiner OpenGL-3D-Engine hab ich implementiert, dass ich Display List Space Sachen sowie Texture Object usw. nicht neu laden muß, wenn man das Hauptfenster, zu dem der Render Context gehört, zerstört und neu erstellt wird (um beim Wechsel Fullscreen/Windowed etwa den Window Style zu ändern). Ich benutze dafür wglShareLists(), um den Display List Space mit dem neu erstellten Fenster zu sharen bevor ich das alte Fenster zerstöre. Das funktioniert gut, jedoch beim Wechsel von Fullscreen Modus in den Windowed Modus krieg ich über den ganzen Bildschirm (auch außerhalb meines Viewports) schwarze Balken, die erst nach einem Repaint der betroffenen Anwendungen weggehen; das ist etwas lästig, wenn auch nicht gravierend. Vielleicht mach aber auch ich was falsch...
Sorry, war da ungenau, hab mit der 1.1 Version noch die uralte nt-Variante gemeint.
Was bringts eigentlich, opengl auf directx abzubilden, wenn die Treiber kein OpenGL unterstützen? Wenn das der Fall ist, kann man doch ruhig sagen, dass der Treiber auch kein DirectX unterstützt, ausser DirectDraw vielleicht ;-).
Corrail
2004-03-09, 19:22:05
Original geschrieben von tokugawa
Auf meiner ATI Radeon 9500 Pro bin ich schon öfters über diverse "Bugs" und Schwächen gestolpert.
Bei Cat 3.4 (soweit ich mich erinnern kann) hab ich bei einem von mir implementierten (Level-)Editor-Tool, das 4 Viewports nutzte (und damit 4 GL Render Contexts, zwischen denen mit wglMakeCurrent() geswitcht wurde), Probleme beim Löschen der Render-Contexts bekommen, wenn ich in jeden der 4 Render-Contexts Display-Lists generiert habe mittels wglUseFontBitmaps(), also ohne Shared Display List Space. Es trat soweit ich mich erinnern kann ein Invalid Page Fault oder ähnliches auf im ATI Treiber (also nicht in meiner Anwendung).
Und jetzt bin ich wieder auf eine (kleinere) Unzulängigkeit (Cat 4.2) gestoßen: in meiner OpenGL-3D-Engine hab ich implementiert, dass ich Display List Space Sachen sowie Texture Object usw. nicht neu laden muß, wenn man das Hauptfenster, zu dem der Render Context gehört, zerstört und neu erstellt wird (um beim Wechsel Fullscreen/Windowed etwa den Window Style zu ändern). Ich benutze dafür wglShareLists(), um den Display List Space mit dem neu erstellten Fenster zu sharen bevor ich das alte Fenster zerstöre. Das funktioniert gut, jedoch beim Wechsel von Fullscreen Modus in den Windowed Modus krieg ich über den ganzen Bildschirm (auch außerhalb meines Viewports) schwarze Balken, die erst nach einem Repaint der betroffenen Anwendungen weggehen; das ist etwas lästig, wenn auch nicht gravierend. Vielleicht mach aber auch ich was falsch...
Schick ein Mail an devrel@ati.com (wenn du das eh noch nicht getan hast)!
marco42
2004-03-09, 20:55:03
Original geschrieben von Gast
Sorry, war da ungenau, hab mit der 1.1 Version noch die uralte nt-Variante gemeint.
Was bringts eigentlich, opengl auf directx abzubilden, wenn die Treiber kein OpenGL unterstützen? Wenn das der Fall ist, kann man doch ruhig sagen, dass der Treiber auch kein DirectX unterstützt, ausser DirectDraw vielleicht ;-).
Der OpenGL Treiber hat nichts mit dem DirectX Treiber zu tun.
marco42
2004-03-09, 20:55:57
Original geschrieben von aths
WinXP scheint OpenGL auf DirectX zu wrappen (solange der Treiber keine eigene OpenGL-Unterstützung mitbringt.)
Ja, und welche Version? Updaten sie dann endlich mal auf 1.5?
Corrail
2004-03-09, 23:26:47
Original geschrieben von marco42
Ja, und welche Version? Updaten sie dann endlich mal auf 1.5?
Ich glaube aths meint den Standart Windows-OpenGL Treiber. Der, der bei Windows sowieso dabei ist, auch wenn du nur eine 0815-Grafikkarte hast, die kein OpenGL unterstützt (rennt dann halt über Software). So wies ausschaut wird es für alle derzeit verfügbaren Windows Versionen kein OpenGL Update geben. Ich hoffe, dass sich das mit Longhorn ändert (deshalb auch dieser Thread).
mapel110
2004-03-10, 07:46:21
Original geschrieben von aths
WinXP scheint OpenGL auf DirectX zu wrappen (solange der Treiber keine eigene OpenGL-Unterstützung mitbringt.)
http://www.opengl.org/applications/installing.html#6
Q. I have an old graphics card that does not have a a current OpenGL driver. Is there any hope for me?
A. First, send an email to the graphics card manufacturer. Tell them you want them to release a full and stable OpenGL driver. They do listen and may have one already to go.
Then check the Savage News website. They have unofficial drivers for older and discontinued graphics cards that have been updated by developers.
Finally if you have an older card that does not yet have an OpenGL hardware driver but does support Direct X then you might still be able to take advantage of OpenGL by using SciTech GLDirect or the now dated, AltSoftware Mesa-DirectX 6 Driver;. Both enable OpenGL-based 3D applications to use Microsoft Direct 3D drivers for 3D hardware acceleration. This may or may not work, but it is worth a shot!
:grübel:
macht das also windows XP von sich aus und braucht keine "third party software" mehr dafür?!
zeckensack
2004-03-10, 18:23:04
*huuuuuust* (http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000362.html)
*krächz*
________________
"Pixel formats have nothing to do with Microsoft's implementation of OpenGL, they are used on ALL OpenGL implementations (on Windows at least, pfd's are not part of OpenGL but part of the GDI)"
The pixel format you choose on a display context is a modifier to the choice of GL implementation. The popular example is 16bit color + stencil on a Gf2MX or something. It does not even go through to NVIDIA's ICD, as is indicated by the renderer string. So it chooses the MS implementation. Based on pixel format. Now you could argue that you just would load NVOGL.DLL yourself and hope that it falls back to software itself. But ...
"nothing changes pixel format wise when you dynamically load OpenGL. You still go through the same procedure"
Please outline 'the same procedure'. You're aware that you'd somehow have to connect the GL implementation to the windowing system and all that crap. Everything that MS's OpenGL32.dll handles right now. It's not just DLL-Loading. And, as evidenced by comments from NVIDIA employees, right here on this board, the ICD isn't even designed to know about pfds.
The only exception is - tada - the 3dfx MiniGL because it just ignores the window system and pops up 16 bit fullscreen without bothering about anything. You don't want to make that common behaviour.
Yet more fun, you might have multiple monitors driven by totally different cards in your machine. Choice of ICD would depend on the window position. If it overlaps both monitors, it would fall back to software, otherwise it would chose the card the monitor is plugged into. Application programmers are simply in no position to choose an implementation, that's OS stuff.
I could pick up some more, but I'm not quite in the mood. In the end I think, if there were no OpenGL32.dll, as it is right now, someone would have to make one. I agree that the 'support' has been less than stellar, but it works, and every vendor making cards that run in Windows supports it.
_____________________
zeckensack
2004-03-10, 18:30:46
Original geschrieben von Gast
Sorry, war da ungenau, hab mit der 1.1 Version noch die uralte nt-Variante gemeint.
Was bringts eigentlich, opengl auf directx abzubilden, wenn die Treiber kein OpenGL unterstützen? Wenn das der Fall ist, kann man doch ruhig sagen, dass der Treiber auch kein DirectX unterstützt, ausser DirectDraw vielleicht ;-). MS legt aus purer Menschenfreundlichkeit ihren Windows-Versionen Treiber für diverse Grafikkarten bei. Also selbst wenn man zB auf XP nie einen Graka-Treiber installiert, hat man bei älteren Modellen ala Gf2MX trotzdem funktionierende Grafik, inklusive Direct3D.
Diese mitgelieferten Treiber enthalten aber (ebenfalls aus wahrscheinlich purer Menschenfreundlichkeit) keine OpenGL-ICDs. Und da wird dann gewrappt.
marco42
2004-03-10, 18:31:25
Original geschrieben von zeckensack
If it overlaps both monitors, it would fall back to software, otherwise it would chose the card the monitor is plugged into.
Du koenntest es AFAIK auch an beide Treiber schicken und der andere Teil wird halt weggeschnitten.
zeckensack
2004-03-10, 18:32:49
Original geschrieben von Gast
Komische Diskussion.
OpenGL wird in erster Linie von den Treibern zur Verfügung gestellt, Win bietet nur eine 1.1 Version, die rein in Software läuft.
Da verstehe ich nicht, was das heissen soll, Win unterstütze kein OpenGL mehr. Die Version, die mitgeliefert wird, braucht eh keiner - jede halbwegs vernünftige Graphikkarte bringt eine aktuellere und v.a. beschleunigte mit. Die OpenGL-Treiber sind aber auf die Zusammenarbeit mit der (von Microsoft gelieferten) opengl32.dll angewiesen. Alles andere wäre auch unsauber (siehe zwei Postings weiter oben).
Original geschrieben von ShadowXX
Findest du die 30 Prozent Marktanteil fuer Linux (plus nochmal 30 plus x fuers MacOs) nicht etwas optimistisch.;D ;D
Zumindest fuer die naechsten 5 bis 15 Jahre?
J.S.Shadow
10% marktanteil reichen vollkommen aus;)
bei ca. 5% marktanteil auf dem desktop wird sich automatisch starkter hardwaresupport für linux einstellen, ohne weiteres zutun.
apple liegt seit jahren bei 5%, aber für sich gibts alles an treibern, direkt vom hersteller, und unter linux müssten die hersteller ja nicht mal nen finger krum machen, einfach die specs rausrücken und fertig :)
Demirug
2004-03-10, 20:23:16
Original geschrieben von Gast
10% marktanteil reichen vollkommen aus;)
bei ca. 5% marktanteil auf dem desktop wird sich automatisch starkter hardwaresupport für linux einstellen, ohne weiteres zutun.
apple liegt seit jahren bei 5%, aber für sich gibts alles an treibern, direkt vom hersteller, und unter linux müssten die hersteller ja nicht mal nen finger krum machen, einfach die specs rausrücken und fertig :)
wenn man sich anschaut was man für mac hardware so bezahlen muss dürfte die Treiberentwicklung damit abgedeckt sein.
Aquaschaf
2004-03-10, 20:28:59
So bugfrei sind Mac-Treiber auch nicht. Bugs fallen soweit ich das sehe auch einfach seltener auf, weil weniger dafür programmiert wird.
Aquaschaf
2004-03-10, 20:28:59
Doppelpost
marco42
2004-03-11, 00:08:47
Original geschrieben von Demirug
wenn man sich anschaut was man für mac hardware so bezahlen muss dürfte die Treiberentwicklung damit abgedeckt sein.
Aber wie willst du Linux von Windows Hardware unterscheiden? :-)
Bei der Server Hardware werden dir ja mittlerweile die Treiber hinterhergeschmissen, vor drei Jahren sah das noch ganz anders aus.
tokugawa
2004-03-11, 08:47:53
Original geschrieben von Corrail
Schick ein Mail an devrel@ati.com (wenn du das eh noch nicht getan hast)!
Is nich mehr nötig, der Catalyst 4.3 hat das Problem gefixt *freu*
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.