Archiv verlassen und diese Seite im Standarddesign anzeigen : DirectX 10 und Windows XP
Cleric
2006-09-25, 22:19:54
DirectX 10 per OpenGL und Wine auf WindowsXP :D
Klingt komisch, ist aber so ! :D
OpenGL weil wine winegl nutzt und es vermutlich auch nicht mit DX9 möglich ist DX10 komplett zu wrappen :D
http://www.winehq.com/?issue=320
"Direct3D10, which will ship with Windows Vista in a few months, doesn't seem to be a large cause for concern. At first glance it appears to be more of an evolutionary change rather than revolutionary. New shader support will be needed, but extending ours once OpenGL supports it should be pretty easy. Stefan mentioned Microsoft is currently offering a lot of incentives for Windows developers who develop D3D10-only games since they'll only be usable on Vista - there's no plan to backport D3D10 to XP. Dan Kegel asked if that means we should port Wine's forthcoming D3D10 implementation to Windows, which would be relatively easy when we switch to WGL."
Cleric
2006-09-26, 02:37:22
eh... wieso wurde der Thread verschoben?!
Bitte wieder zurückschieben! Das es so kommen wird ist klar... nur wann ist eine andere Frage! DX1-9 funktionieren schon jetzt quasi als wrapper mit OpenGL ... unter Windows!
tokugawa
2006-09-26, 03:31:13
Spekulation weil's noch nicht draussen ist.
Weil es mehr als nur die reine Existenzfrage gibt (gibt ja Entwickler wie Demirug, die, so wie ich verstanden hab, auch einen Wrapper geschrieben haben um im Direct3D10-Stil zu programmieren, es aber mit DirectX9 gerendert wird). Das ist also nichts neues.
Es ist auch eine Frage der Performance und Kompatibilität.
Demirug
2006-09-26, 10:30:35
"Direct3D10, which will ship with Windows Vista in a few months, doesn't seem to be a large cause for concern"
"Dan Kegel asked if that means we should port Wine's forthcoming D3D10 implementation to Windows, which would be relatively easy when we switch to WGL."
Ich fürchte sie haben sich das noch nicht wirklich richtig angeschaut. Im Vergleich zu D3D9 haben wir es mit ganz anderen Dimensionen zu tun.
Und ja ich weiß wovon ich spreche.
Effektframework in der API? ;)
Demirug
2006-09-26, 11:58:03
Effektframework in der API? ;)
Nicht nur der. Der Shader compiler ist jetzt entsprechend auch im Core. Zudem müssen sie auch noch DXGI implementieren und am schlimmsten die D3DX10 DLL funktioniert nicht mit XP weil sie gegen die Vista Version der MSVCRT gelinkt ist.
Zocker_28
2006-09-26, 13:45:53
Ich versteh zwar nur Bahnhof aber wäre das möglich (oder ist) DX10 auf XP zu Installieren ?
Cleric
2006-09-26, 21:27:54
naja ... ich denke mal das ist alles nicht wirklich so das problem... ich meine die entwickler bilden fast die gesamte windows api unter linux nach... da ist der dx kram, der relativ gut dokumentiert ist "pretty easy" :D
funktionieren wirds auch nur mit OpenGL weil DX9 einfach bei den Shadern zu eingeschränkt ist.
naja ... ich denke mal das ist alles nicht wirklich so das problem...
Da denkst du aber falsch. Die haben schon Urzeiten gebraucht um SM2.0 abzubilden. D3D10 ist nochmal ein deutlich größeres Kaliber.
Demirug
2006-09-26, 21:46:54
Gut dokumentiert ist relative. Gerade die Binärformate für Shader und Effekte sind derzeit überhaupt nicht dokumentiert. Für die Effektfiles bekam ich nicht mal ein BNF und ich habe bei einem der Entwickler direkt angefragt.
Der reine Core ist relative leicht nachzubilden. Das hat mich gerade mal drei Tage gekostet die entsprechenden Objekte anzulegen und die Aufrufe auf das Treiberinterfaces umzuleiten. Allerdings fehlen noch die ganzen nicht dokumentierten Aspekte.
Alles was darüber liegt ist jedoch der reinste Horror.
Corrail
2006-09-27, 20:28:59
Da denkst du aber falsch. Die haben schon Urzeiten gebraucht um SM2.0 abzubilden. D3D10 ist nochmal ein deutlich größeres Kaliber.
Da lag aber das Problem wo anders. Hatte mit einem Streit mit Cedega zu tun...
ShadowXX
2006-10-04, 12:32:01
Da denkst du aber falsch. Die haben schon Urzeiten gebraucht um SM2.0 abzubilden. D3D10 ist nochmal ein deutlich größeres Kaliber.
AFAIK haben Sie auch SM2.0 noch nicht vollständig abgebildet (bzw.: habne Sie davon überhaupt schon was abgebildet, den bei den ganzen Shader2.0 Games steht immer das Shader nicht unterstützt werden, bis auf ein paar ausnahmen).
Bevor Sie sich also D3D10 vornehmen, sollten Sie lieber erst mal SM2.0 & 3.0 vollständig abbilden.....
Wenn ich so lese bei testticker heute "VISTA Kernel schon gehackt" frag ich mich echt warum ich es mir kaufen sollte, nur wegen dem Schader 4 ach ne ! Microsoft täte echt gut daran das 3D10 auch für ältere Win Versionen zu bringen, diese Monopol Stellung die da Billi Boy vertritt ist echt skandallös in meinen Augen. Ich hoffe noch sehr stark das noch etwas in diese Richtung geht, den ich habe auch nicht im Sinn alle 3 Jahre ein neues Betriebssystem zu kaufen das auch immer teurer ist als das alte.
mfg
SavageX
2006-10-04, 21:37:56
Aus der Newsmeldung von 3dcenter.de vom 3. Oktober:
schon allein eine Übertragung von Direct3D10 auf Linux wäre ein mittleres Wunder, ist doch Direct3D10 seitens Microsoft noch extra an ein neues Treibermodell gebunden, was auch die (einfache) Integration in Windows XP unmöglich macht
Wine hat seine eigene DirectX Implementation, die sich einen Dreck darum scheren dürfte, welches Treibermodell die Microsoftsche Implementierung voraussetzt. Der Teil, der D3D nach OpenGL umsetzt, wird als "Treiber" für eine "OpenGL-Grafikkarte" implementiert. Dieser Treiber muss nur mit dem DX von Wine klarkommen - er wird mit grosser Wahrscheinlichkeit nicht mit dem Microsoft DX zusammenarbeiten. (Warum sollte er auch?).
Trotzdem sicherlich ein gutes Stück Arbeit, insbesondere wenn man tatsächlich noch einen HLSL compiler etc. und andere Sachen, die nun nicht mehr in Hilfsbibliotheken (die bei den Spielen mitgeliefert werden) enthalten sind, nachimplementieren muss. Zumindest der Compiler kann ja auch nicht schaden, da man sich so die HLSL --> DX "assembler" --> ARBvp/vp (bzw. GLSL) Kette abkürzen kann.
Edit: Wine setzt DX9 Shader (zumindest 2.0) halbwegs vernünftig um (Spiel läuft im DX9 Pfad)
http://img412.imageshack.us/img412/7118/halflife2wj5.th.jpg (http://img412.imageshack.us/my.php?image=halflife2wj5.jpg)
Zumindest das Normalmapping scheint zu laufen, Taschenlampe funktioniert und auch die Propagandatafeln von Dr. Breen (ich gehe mal davon aus, dass die per Shader dargestellt werden). Läuft ingesamt ganz gut, auch wenn ich keine Windows Referenz habe.
ShadowXX
2006-10-05, 12:05:04
Aus der Newsmeldung von 3dcenter.de vom 3. Oktober:
Wine hat seine eigene DirectX Implementation, die sich einen Dreck darum scheren dürfte, welches Treibermodell die Microsoftsche Implementierung voraussetzt. Der Teil, der D3D nach OpenGL umsetzt, wird als "Treiber" für eine "OpenGL-Grafikkarte" implementiert. Dieser Treiber muss nur mit dem DX von Wine klarkommen - er wird mit grosser Wahrscheinlichkeit nicht mit dem Microsoft DX zusammenarbeiten. (Warum sollte er auch?).
Nicht ganz, da bestimmte Fähigkeiten von D3D10 auf das neue Treibermodell aufsetzen.....und die kannst du nicht mal eben nach WinXp umsetzen, weil dort dort auch unter OGL an das Windows-Treibermodell gebunden bist.
Demirug
2006-10-05, 12:28:44
Nicht ganz, da bestimmte Fähigkeiten von D3D10 auf das neue Treibermodell aufsetzen.....und die kannst du nicht mal eben nach WinXp umsetzen, weil dort dort auch unter OGL an das Windows-Treibermodell gebunden bist.
Ein IHV könnte die entsprechenden Fähigkeiten durchaus auch selbst in seinen Treiber implementieren. Letzten Endes stellt Vista hier ja nur eine Infrastrukture zur Verfügung welche die Treiberentwicklung vereinfacht. Ähnlich wie es damals OpenGL Treiber für Win95 gab könnten nVidia und ATI auch D3D10 für XP anbieten. Ich habe allerdings aufgrund des damit verbundenen Mehraufwandes Zweifel.
ollix
2006-10-05, 15:07:24
Ein IHV könnte die entsprechenden Fähigkeiten durchaus auch selbst in seinen Treiber implementieren. Letzten Endes stellt Vista hier ja nur eine Infrastrukture zur Verfügung welche die Treiberentwicklung vereinfacht. Ähnlich wie es damals OpenGL Treiber für Win95 gab könnten nVidia und ATI auch D3D10 für XP anbieten. Ich habe allerdings aufgrund des damit verbundenen Mehraufwandes Zweifel. :eek: Es hieß doch immer, daß technische Gründe D3D10 auf 2k/XP verhindern. Jetzt ist es auf einmal nur eine (wenn auch aufwendige) Sache für einen IHV? Das wäre doch ein enormes Verkaufsargument und verstehe ich das Posting falsch?
Monger
2006-10-05, 15:29:14
:eek: Es hieß doch immer, daß technische Gründe D3D10 auf 2k/XP verhindern. Jetzt ist es auf einmal nur eine (wenn auch aufwendige) Sache für einen IHV? Das wäre doch ein enormes Verkaufsargument und verstehe ich das Posting falsch?
Ein völlig neues Betriebssystem zu schreiben ist auch "nur" aufwendig.
Demirug
2006-10-05, 15:39:51
:eek: Es hieß doch immer, daß technische Gründe D3D10 auf 2k/XP verhindern. Jetzt ist es auf einmal nur eine (wenn auch aufwendige) Sache für einen IHV? Das wäre doch ein enormes Verkaufsargument und verstehe ich das Posting falsch?
Wenn es um Software geht sind technische Gründe immer nur eine Frage des Aufwands.
stefandoesinger
2006-10-05, 16:02:20
(Disclaimer: Dieses Posting stellt meine persönliche Meinung dar, und ist kein offizielles Statement der Wine-Community oder CodeWeavers)
Ich fürchte sie haben sich das noch nicht wirklich richtig angeschaut. Im Vergleich zu D3D9 haben wir es mit ganz anderen Dimensionen zu tun.
Nun, ich war derjenige der als erstes angefangen hat von D3D10 zu träumen :-)
Kurz: Ja, wir sind uns alle bewusst dass d3d10 keine Hallo-Welt Bibliothek ist und eine Implementierung eine Frage von Monaten oder Jahren ist :-)
Der Shader-Compiler dürfte der größte Brocken sein. Zwar gibt es bereits HLSL-Compiler, aber sie schauen alle nicht wirklich brauchbar für unseren Zweck aus :-(
Das Treiber-Modell macht mir wenig Sorge - Die Wine-d3d Implementierung sitzt im User-Mode(ddraw.dll, d3d8.dll und d3d9.dll), diese rufen unsere eingene wined3d.dll auf welche auf OpenGL aufbaut(derzeit noch abhängig von GLX). Es gibt Änderungen die auch Auswirkungen auf den User-Mode haben, soweit mir bekannt ist können z.B. Texturen mit verschiedenen Devices verwendet werden. Das ist in OpenGL machbar, haarig wird es jedoch wenn es über mehrere Prozesse hinweg funktioniert.
Ein ReactOS-Entwickler, der sich mit dem Kernel-Seitigen DirectDraw und Direct3D-Interface beschäftigt hat, sagt mir dass es auch mit Vista gleich geblieben ist. Ich kann das nicht überprüfen, seine Aussage klingt jedoch glaubwürdig.
Die C-Runtime ist auch kein grundlegendes Problem, Wine hat eine eigene crt Implementierung die auch unter Windows verwendet werden kann. Diese lässt sich um die in Vista vorhandene Funktionalität erweitern.
Die interessante Frage ist, wann und ob OpenGL die nötigen Features für D3D10 hat, insbesondere die neuen Shader. Ich denke jedoch, dass recht bald mit D3D10-Fähiger Hardware entsprechende GL-Extensions kommen. Ich glaube jedoch, dass die Vista-Only Beschränkung von D3D10 rein marketingtechnisch begründet ist.
Zum Zustand unserer DirectX-Implementierung: Im Großen und Ganzen sind wir Feature-Complete. Unser Shader-Code kommt mit 3.0-Shadern klar, wir können aus d3d-Shadern GLSL-Shader und Shader für die GL_ARB_fragment_program und GL_ARB_vertex_program erstellen(Nur 1.X-Shader).
Was noch große Probleme macht ist offscreen rendering, multithreaded d3d, und unser nicht vorhandenes State-Management. Es fehlen auch noch ein paar andere Sachen wie DDraw-Overlays und manche Pixelformate. (Andere DX-Libs wie DirectSound, DirectPlay und DirectInput erwähne ich mal vorsorglich nicht :-| )
Was viele Spiele vom funktionieren abhält sind Bugs, Bugs und Bugs. Zwar ist die DirectX-Dokumentation vergleichsweise brauchbar und wir haben einige kleine Testprogramme, aber es gibt viele große und kleine Fehler in unserem Code die Spiele zum Abstürzen bringen oder Fehler in der Grafikausgabe haben. Auch sind andere Teile von Wine nicht Fehlerfrei, so stürzt Half-Life 2 im Multiplayermodus wegen eines Fehlers in der Schriftenverarbeitung in gdi32.dll ab :-/
Mein Plan ist, das Statemanagement zu richten, was bessere Performance bringen sollte und Multithreaded d3d sowie offscreen rendering besser möglich macht, und dann mit d3d10 zu beginnen, noch bevor wir auf Bug-Suche gehen. Einfach weil d3d10 ein paar Änderungen an wined3d.dll erfordern wird(ein paar bekannte, und sicher unbekannte Gemeinheiten), woduch neue Probleme mit alten Spielen auftreten können.
ollix
2006-10-05, 16:19:12
Wenn es um Software geht sind technische Gründe immer nur eine Frage des Aufwands. Jaja, aber da Du von Zweifeln ob des Mehraufwandes sprachst, hört sich das so an als wäre das durchaus ein Möglichkeit, die die Hersteller ziehen könnten; wenn auch unwahrscheinlich. Das ist eben von der gefühlten Dimension ein Unterschied, wie wenn zwar machbar aber ob des Aufwandes völlig überzogen und mit den begrenzten Möglichkeiten von ATi und nVidia nicht zu stemmen :)
Demirug
2006-10-05, 16:39:01
Der Shader-Compiler dürfte der größte Brocken sein. Zwar gibt es bereits HLSL-Compiler, aber sie schauen alle nicht wirklich brauchbar für unseren Zweck aus :-(
Dabei nicht vergessen dass ihr auch FX Files parsen müßt. Eines der größten Probleme dabei ist die fehlende Dokumentation des Binärformats. Das gleiche gilt übrigens auch für die D3D10 Shader. Das Format ist auch neu. Wir können uns darüber gerne in einem anderen Rahmen austauschen. Die meisten hier dürfte das herzlich wenig interessieren.
Das Treiber-Modell macht mir wenig Sorge - Die Wine-d3d Implementierung sitzt im User-Mode(ddraw.dll, d3d8.dll und d3d9.dll), diese rufen unsere eingene wined3d.dll auf welche auf OpenGL aufbaut(derzeit noch abhängig von GLX). Es gibt Änderungen die auch Auswirkungen auf den User-Mode haben, soweit mir bekannt ist können z.B. Texturen mit verschiedenen Devices verwendet werden. Das ist in OpenGL machbar, haarig wird es jedoch wenn es über mehrere Prozesse hinweg funktioniert.
Es funktioniert über Prozessgrenzen hinweg. Allerdings glaube ich kaum das dieses Feature von Spielen genutzt werden wird.
Ein ReactOS-Entwickler, der sich mit dem Kernel-Seitigen DirectDraw und Direct3D-Interface beschäftigt hat, sagt mir dass es auch mit Vista gleich geblieben ist. Ich kann das nicht überprüfen, seine Aussage klingt jedoch glaubwürdig.
Ich weiß ja nicht woher er seine Informationen sind aber Vista hat ein neues Interface im Kernel für das Grafiksubsystem. Das alte wird aus kompatibilitätsgründen noch unterstützt allerdings gibt es damit kein D3D10.
Die C-Runtime ist auch kein grundlegendes Problem, Wine hat eine eigene crt Implementierung die auch unter Windows verwendet werden kann. Diese lässt sich um die in Vista vorhandene Funktionalität erweitern.
Könnte aufgrund der Side by Side Excecution Engine allerdings etwas kompliziert werden.
Die interessante Frage ist, wann und ob OpenGL die nötigen Features für D3D10 hat, insbesondere die neuen Shader. Ich denke jedoch, dass recht bald mit D3D10-Fähiger Hardware entsprechende GL-Extensions kommen. Ich glaube jedoch, dass die Vista-Only Beschränkung von D3D10 rein marketingtechnisch begründet ist.
nvidia spricht von Zeitnah.
Zum Zustand unserer DirectX-Implementierung: Im Großen und Ganzen sind wir Feature-Complete. Unser Shader-Code kommt mit 3.0-Shadern klar, wir können aus d3d-Shadern GLSL-Shader und Shader für die GL_ARB_fragment_program und GL_ARB_vertex_program erstellen(Nur 1.X-Shader).
Was noch große Probleme macht ist offscreen rendering, multithreaded d3d, und unser nicht vorhandenes State-Management. Es fehlen auch noch ein paar andere Sachen wie DDraw-Overlays und manche Pixelformate. (Andere DX-Libs wie DirectSound, DirectPlay und DirectInput erwähne ich mal vorsorglich nicht :-| )
Ums multithreading würde ich mir die wenigsten Sorgen machen. Das funktioniert nämlich auch unter Windows nicht richtig.
Was viele Spiele vom funktionieren abhält sind Bugs, Bugs und Bugs. Zwar ist die DirectX-Dokumentation vergleichsweise brauchbar und wir haben einige kleine Testprogramme, aber es gibt viele große und kleine Fehler in unserem Code die Spiele zum Abstürzen bringen oder Fehler in der Grafikausgabe haben. Auch sind andere Teile von Wine nicht Fehlerfrei, so stürzt Half-Life 2 im Multiplayermodus wegen eines Fehlers in der Schriftenverarbeitung in gdi32.dll ab :-/
Es gibt einige nicht dokumentierte Spezialitäten beim Referenzcounting. Wenn man das nicht exakt nachbaut wird man z.b. Need For Speed nicht richtig zum Laufen bekommen.
Mein Plan ist, das Statemanagement zu richten, was bessere Performance bringen sollte und Multithreaded d3d sowie offscreen rendering besser möglich macht, und dann mit d3d10 zu beginnen, noch bevor wir auf Bug-Suche gehen. Einfach weil d3d10 ein paar Änderungen an wined3d.dll erfordern wird(ein paar bekannte, und sicher unbekannte Gemeinheiten), woduch neue Probleme mit alten Spielen auftreten können.
Dann wünsche ich mal viel Erfolg.
Demirug
2006-10-05, 16:42:12
Jaja, aber da Du von Zweifeln ob des Mehraufwandes sprachst, hört sich das so an als wäre das durchaus ein Möglichkeit, die die Hersteller ziehen könnten; wenn auch unwahrscheinlich. Das ist eben von der gefühlten Dimension ein Unterschied, wie wenn zwar machbar aber ob des Aufwandes völlig überzogen und mit den begrenzten Möglichkeiten von ATi und nVidia nicht zu stemmen :)
Es kommt auch noch ein gewisses rechtliches Problem dazu. Ich weiß nicht ob sich ati und nvidia mit Microsoft wegen Namensrechten anlegen wollen.
Dabei nicht vergessen dass ihr auch FX Files parsen müßt. Eines der größten Probleme dabei ist die fehlende Dokumentation des Binärformats. Das gleiche gilt übrigens auch für die D3D10 Shader. Das Format ist auch neu. Wir können uns darüber gerne in einem anderen Rahmen austauschen. Die meisten hier dürfte das herzlich wenig interessieren.
[/QUOTE]
Na ja, mit undokumentiertem Zeug haben wir nach 14 Jahren ein wenig Erfahrung :-/
Es wäre für uns aber sicher sehr Hilfreich uns mit D3D-Programmierern austauschen zu können, schon alleine wegen der vielen undokumentierten Feinheiten die uns noch nicht aufgefallen sind, aber anderen bekannt sind :-)
Ich weiß ja nicht woher er seine Informationen sind aber Vista hat ein neues Interface im Kernel für das Grafiksubsystem. Das alte wird aus kompatibilitätsgründen noch unterstützt allerdings gibt es damit kein D3D10.
Er sagt, dass er das gdi- und kernel-Interface reverse engineered hat. Ob er dabei versehentlich das alte Xp-Interface erwischt hat kann ich nicht sagen. Ich werde mir auch selbst aus rechtlichen Gründen kein Windows-Disassembly anschauen, und mir reicht auch das User-Mode interface.
Ums multithreading würde ich mir die wenigsten Sorgen machen. Das funktioniert nämlich auch unter Windows nicht richtig.
Na ja, es tut aber immerhin mehr als einfach nur abstürtzen :-) Das Problem ist, dass D3D-Anwendungen von jedem Thread rendern können, während in opengl ein Context an einen Thread gebunden ist. Daher brauchen wir einen eigenen Context pro Thread, Texturen und dgl. lassen sich per Share List gemeinsam Nutzen, die Renderstates & Co müssen jedoch synchronisiert werden :-/
Es gibt einige nicht dokumentierte Spezialitäten beim Referenzcounting. Wenn man das nicht exakt nachbaut wird man z.b. Need For Speed nicht richtig zum Laufen bekommen.
Jup, ich bin ewig dabei gesessen das Refcounting für ddraw richtig hinzubekommen, und mir sind noch immer Sachen bekannt die Wine nicht richtig macht(Es ist jedoch kein Spiel bekanntermaßen davon betroffen, daher hat es auch noch niemand ausgebesser). Ähnliches gilt für d3d8/d3d9.
Beim refcounting sind viele Sachen nicht nur undokumentiert, sondern auch komplett falsch dokumentiert :-/. Allerdings ist es leicht das herauszufinden, einfach ein kleines Programm schreiben das auf ein ganz spezielles Problem testet
Problematischer sind Spezialitäten in den Treibern. So bietet z.B. kein Treiber D3DFMT_R8G8B8 an, was aber in OpenGL leicht zu tun ist. Das Vorhandensein dieses Formats löst dann aber einen Fehler in BF1942 aus: http://doesi.gmxhome.de/ScreenShot3.jpg (Die Schrift, der nicht ganz richtige Flugzeugträger war ein Fehler im ATi-Treiber, womit wir beim nächsten Problem wären)
Dann wünsche ich mal viel Erfolg.
Danke :-)
Es kommt auch noch ein gewisses rechtliches Problem dazu. Ich weiß nicht ob sich ati und nvidia mit Microsoft wegen Namensrechten anlegen wollen.
Ich sehe für ati/nvidia keinen driftigen Grund, so viel aufwand zu investieren. Dass die Kunden Vista brauchen um die Spiele spielen zu können kommt ihnen durchaus entgegen. Solange nicht eine Firma dx10 auf Xp anbietet entgeht keinem etwas.
Zudem sind sie in gewissen Belangen auch von Microsoft abhängig, und es ist nicht lustig in dieser Situation MS zu verärgern.
Demirug
2006-10-05, 17:57:49
Er sagt, dass er das gdi- und kernel-Interface reverse engineered hat. Ob er dabei versehentlich das alte Xp-Interface erwischt hat kann ich nicht sagen. Ich werde mir auch selbst aus rechtlichen Gründen kein Windows-Disassembly anschauen, und mir reicht auch das User-Mode interface.
Warum so umständlich?
Die Treiber Interfaces sind doch öffentlich zugänglich dokumentiert.
Strenggenommen müßte man für eine vollständige Direct3D Emulation auch das Treiberinterface kennen weil die Software Rasterizierer darauf aufbauen.
stefandoesinger
2006-10-05, 18:47:00
So dieses mal wieder richtig angemeldet :-)
Warum so umständlich?
Die Treiber Interfaces sind doch öffentlich zugänglich dokumentiert.
Strenggenommen müßte man für eine vollständige Direct3D Emulation auch das Treiberinterface kennen weil die Software Rasterizierer darauf aufbauen.
Es geht nicht nur um die Treiberinterfaces, sondern auch wie D3D durch gdi und win32k zum Treiber geroutet wird. Und das ist zwar auch dokumentiert, aber die Doku angeblich unbrauchbar. Mehr weiß ich dazu leider auch nicht.
NiCoSt
2006-10-14, 13:32:17
über was zur hölle redet ihr hier eigentlich?
könnt ihr mir irgendwelche tipps geben wie ich auch soviel kenntnisse über solche sachen erlange wie ihr? irgendwelche seiten oder sowas? :(
Stebs
2006-10-14, 18:31:53
Wir können uns darüber gerne in einem anderen Rahmen austauschen. Die meisten hier dürfte das herzlich wenig interessieren.Och, ich denke das Thema selbst interessiert schon die meisten, leider wird nur kaum einer der Diskussion richtig folgen können.
Ich persönlich lese so etwas trotzdem gerne weil man dann doch einfach mehr erfährt als bei allgemein gehaltenen Statements ala "When it's done".
Allein PS 3.0 Games per Wine wäre schon richtig Klasse, aber dazu müsste dann noch Problematik von Kopierschutz und Anti-cheat-programmen ala Punkbuster gelöst werden.
PS 4.0 Games per Wine auf Linux und WinXP wäre wohl DER Knaller.
Demogod
2006-10-14, 18:43:57
können pixelshader aus dem (psquell) code nicht sowiso problemlos für opengl und d3d kompiliert werden?
also ist quasi die frage was die beiden shader sdks von nvidia und ati in zukunft werden bauen können.
für apple müssen ja sowiso treiber für die neuesten funktionen der neuen karten geschrieben werden. apple verbaut ja nv und ati.
an die devs hier: wieviel besser ist das neue vista treibermodell im allgemeinen?
also nicht nur für d3d und grafik.
über was zur hölle redet ihr hier eigentlich?
könnt ihr mir irgendwelche tipps geben wie ich auch soviel kenntnisse über solche sachen erlange wie ihr? irgendwelche seiten oder sowas? :(
Viel lernt man indem man indem man das API benutzt, oder eine Implementierung schreibt. Es gibt auch gute Bücher zum Thema, etwa den OpenGL programming guide("red book", ISBN 0201604582)
Ich hab das meiste gelernt als ich mich vor einem Jahr praktisch ohne vorkenntnisse an die DirectDraw-Implementierung von wine gemacht hab :-) .
Vielleicht auch interessant:
http://source.winehq.com/git/?p=wine.git;a=tree;f=dlls/ddraw
http://source.winehq.com/git/?p=wine.git;a=tree;f=dlls/d3d8
http://source.winehq.com/git/?p=wine.git;a=tree;f=dlls/d3d9
http://source.winehq.com/git/?p=wine.git;a=tree;f=dlls/wined3d
können pixelshader aus dem (psquell) code nicht sowiso problemlos für opengl und d3d kompiliert werden?
HLSL shader theoretisch ja, d3d Assembler Shader müssen geparst, interpretiert und dann ein entsprechender OpenGL-Shader geschrieben werden. Im Moment hat Wine nur Code um asm shader zu verwerten, wenn ein Spiel HLSL-Shader benutzt muss die Microsoftsche d3dx_??.dll bibliothek verwendet werden(0 < ?? <= 30), die aus HLSL den asm shader erstellt der dann von Wine geparst wird. Das Übersetzten der Shader-Anweisungen ist nicht so ein großes Problem, so gut wie alle Anweisungen lassen sich 1:1 übersetzten. Probleme gibt es, wenn Eingangsdaten oder Ausgangsdaten von d3d selbst noch irgendwie verarbeitet werden(e.g. clamping auf das Intervall [-1.0;1.0]).
an die devs hier: wieviel besser ist das neue vista treibermodell im allgemeinen?
also nicht nur für d3d und grafik.
Das kann ich nicht wirklich beurteilen, da ich weder das neue noch das alte Treibermodell kenne. Man muss die Dinge die die Marketingabteilung von sich gibt von den wirklichen Technischen Informationen unterscheiden :-)
Das Ziel scheint jedoch zu sein, den CPU-Aufwand möglichst weit zu verringern; Das ist insofern eine gute Sache da viele Spiele sehr CPU-Intensiv sind(KI, Sound, Physik, ...), und Treiberseitig ein Multithreading zu unterstützen(Der CPU-Aufwand der noch möglich ist wird auf einer anderen CPU gemacht, sofern vorhanden).
Die andere Sache ist, dass d3d10 scheinbar viele Dinge übernimmt, die an sich Aufgabe des Spiels wären. Multithreading ist meiner Meinung nach Aufgabe der Anwendung, so können z.B. KI, Physik und Sound in seperaten Threads behandelt werden. Das ganze von einer Bibliothek(d3d10) handlen zu lassen klingt zwar bequem, allerdings kommt es dann zwangsläufig zu undokumentierten und unbehabsichtigten Problemen und die Synchronisation wird zum Albtraum. So gesehen zum Beispiel beim ATI-Linux-Treiber der vor einem glXSwapBuffers ein glFinish braucht da sonst die CPU der GPU davon läuft und das Bild mehrere Frames hinterherhinkt.
Was d3d10 und die Diskutierten und teilweise schon vorhandenen OpenGL Neuerungen bringen wird die Zeit zeigen. In der Zwischenzeit wird sicher viel Marketinggeschwätz durch die Fachmedien gehen und viel Geld vom Kunden in die Geldbörsen von MS, ATi, Nvidia, Intel und AMD wandern...
stefandoesinger
2006-10-29, 12:01:31
Hrmpf, schon wieder als Gast geantwortet :-(
ScottManDeath
2006-10-30, 21:54:35
Warum so umständlich?
Die Treiber Interfaces sind doch öffentlich zugänglich dokumentiert.
Strenggenommen müßte man für eine vollständige Direct3D Emulation auch das Treiberinterface kennen weil die Software Rasterizierer darauf aufbauen.
Wobei ich bezweifle das die jeder zu sehen bekommt. An der Arbeit stand da immer fett "highly confidental" dabei und ein disclaimer bei dem ich beinahe in Ohnmacht gefallen bin ;)
Demirug
2006-10-30, 22:02:38
Wobei ich bezweifle das die jeder zu sehen bekommt. An der Arbeit stand da immer fett "highly confidental" dabei und ein disclaimer bei dem ich beinahe in Ohnmacht gefallen bin ;)
Die Interfaces sind im WDK dokumentiert. Möglicherweise hattest du Teile der Refrasts Sourcen. Den bekommt wirklich nicht jeder. Schnittstellen muß Microsoft ja dokumentieren. Hatte deswegen vor nicht allzu langer Zeit einen Email Wechsel aus dem DX-Team.
ScottManDeath
2006-10-30, 22:07:48
Die Interfaces sind im WDK dokumentiert. Möglicherweise hattest du Teile der Refrasts Sourcen. Den bekommt wirklich nicht jeder. Schnittstellen muß Microsoft ja dokumentieren. Hatte deswegen vor nicht allzu langer Zeit einen Email Wechsel aus dem DX-Team.
Mhmm, jetzt wo Du es sagst, ja könnte der refrast gewesen sein.
BTW ...
Vielleicht schon irgendwo gepostet, aber ich stell es hier mal rein, weil es weder in den g80 noch in den R600 richtig passt. :wink:
From China with Love (http://forums.anandtech.com/messageview.aspx?catid=31&threadid=1949593&frmKeyword=&STARTPAGE=1&FTVAR_FORUMVIEWTMP=Linear)
Wer nur eine DirectX 10 Unterstützung für seine Spiele benötigt, der braucht gar kein Windows Vista zu kaufen,
denn die Entwickler der Windows Umgebung Wine haben nämlich schon geplant, Wine und ihre geplante DirectX 10 Implementierung nach Windows XP zu portieren.
Das steht auch auf ihrer ToDo Liste:
[D3D](d3d10)
* Start implementing D3D10 once it gets released
* Possibly port D3D10 to Windows XP
http://wiki.winehq.org/DirectX-ToDo?action=show
Informationen zu Wine gibt es hier:
www.winehq.org (offizielle Webseite, Englisch)
http://de.wikipedia.org/wiki/Wine (grober verständlicher Überblick über Wine in Deutsch)
Wer sich mal von Wine unter Windows 2k/XP überzeugen möchte, der kann sich mal das Wine Paket für Windows downloaden.
Es unterstützt zwar momentan nur DirectX 7-9, aber DirectX 10 sollte wie oben geschrieben, bald folgen, sobald Vista offiziel mit DirectX 10 released wurde.
Hier der Link für die Windows Version von Wine:
http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=112520
Madman123456
2007-01-23, 07:06:09
Na, was hab ich gesagt? :tongue:
Ich muss wohl Hellseher sein =)
War aber auch abzusehn. Mal ehrlich, wenn ich ein Spiel rausbringen wollte, dann würde ich mich nicht auf eine recht kleine Zielgruppe beschränken wollen. Und in der Anfangszeit nach Vista Release wird diese Zielgruppe recht klein sein.
Da hätt ich garkeinen Bock drauf. Ich will auch das die Leute mein Spiel kaufen, denen es egal ist das sie das nicht am Kauftag schon mit höchsten Einstellungen spielen können. Die bringen nämlich auch Kohle, ich würde sogar kühn behaupten, das die die meiste Kohle bringen.
Mit einigen Tweaks kann ich Oblivion zb flüssig spielen, mit meiner Radeon 9600.
Die ist noch nicht mal wesenstlich übertacktet.
Ich werde aus dem selben Spiel noch ein zweites mal einen grafischen "aha!" Effekt holen können, wenn ich es nochmal installiere, wenn ich wieder mal aufrüste. Aber auch meine nächste Grafikkarte wird keine DX10 Karte sein. Vielleicht ist mein nächstes Board ein PCIe Board.
Dann spiel ich oblivion nochmal und werde wahrscheinlich drüber staunen, wie weit ich die Grafik nun auftrehen kann und wie flüssig es trotzdem läuft.
Mal ehrlich, so ein bekloppter Scheiss wäre auch niemals durchzusetzen gewesen. Wenn heute ein Spiel rauskommt, welches aber zwingend ein Betriebsystem benötigt, was gestern rauskam, dann werden viele potentielle Käufer sagen "leckt mich am Arsch, da spiel ich lieber Blablubb weiter!"...
Spearhead
2007-01-23, 08:09:16
Na warten wir mal ab wie lang das dauern wird. So einfach wird das wahrscheinlich auch nicht sein, und auch die aktuelle DX Implementation in Wine ist soweit ich weiß noch nicht fertig. Mehrere Monate dürfte man denke ich mindestens rechnen.
Ganz abgesehen davon das immer noch die Einschränkung "possibly" da steht, d.h. ich würde nicht fest damit rechnen.
die überschrift is sowas von quark,und nein dx10 wirds nie für xp geben
deekey777
2007-01-23, 10:09:38
Die ganze Idee läuft ins Leere.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=322579
http://letskilldave.com/archive/2006/10/17/DirectX-10-for-Windows-XP_3F00_--Repeat-after-me_3A00_-No.-No.-No_2E00_.aspx
D3D10 wird es nicht für Windows XP geben. Der Titel ist irreführend. Wenn man es per Wine emuliert, ist das ganze bei weitem nicht so unproblematisch, wie es hier dargestellt wird.
Wenn es so toll wäre mit Wine zu spielen, warum kauft sich trotzdem fast jeder Spieler ein Windows?
Die ganze Idee läuft ins Leere.
http://letskilldave.com/archive/2006/10/17/DirectX-10-for-Windows-XP_3F00_--Repeat-after-me_3A00_-No.-No.-No_2E00_.aspx
Was willst du mit dem schrottigen Link?
Auf Wine trifft der sowieso nicht zu.
Wenn es so toll wäre mit Wine zu spielen, warum kauft sich trotzdem fast jeder Spieler ein Windows?
Wine IST toll es läuft schon einiges.
Aber unter Linux braucht man für Wine noch spezielle Vorkehrungen für das ganze Kopierschutzgerrafel.
Unter Windows bräuchte man nur ein Wine mit DirectX, die Kopierschutzfunktionen sind im OS schon vorhanden.
Es gibt bis heute auch keine Engines die wirklich auf D3D10 ausgelegt sind.Richtig. Ich weiß nur nicht wie man das werten soll...
Ich kenne das Treiberdesign von XP. Und es ist wirklich grausam.Das ist ok. Ich dagegen kenne die Treibersitutaion von Mitte 2007. Mit einer Anlaufphase für die Hersteller die mindestens auf Mitte 2006 zurückgeht. Diese Situation lies mich nicht erkennen, daß DX10 für die Treiberteams geradezu ein Befreiungsschlag war. Ich hab das schon erwähnt. Es mühsam, mit der Wand und so...
Daß die NV- wie auch ATI-Jungs gelegentlich auch noch wie Rohrspatzen fluchten weißt du genauso wie ich. Was soll das also?
Das neue schöne scheint wesentlich grausamer gewesen zu sein als das alte grausame.
Mag die Alte in der Küche noch so "häßlich" geworden sein, nach 10 Jahren Ehe weiß man bestens wie man sie zum Lachen bringen kann...
Da es aber nun langsam OT wird, Nacht und viel Spaß noch.
BH
Das D3D10 nur auf Vista läuft ist nur keine "künstliche Barriere".
wenn frueher directX mit verschiedenen OS versionen und treiberarchitekturen ging und jetzt nicht, ist es eine kuenstliche barriere. zwischen win9x und w2k war die treiberarchitektur viel drastischer veraendert als jetzt w2k/wxp zu vista.
wenn frueher directX mit verschiedenen OS versionen und treiberarchitekturen ging und jetzt nicht, ist es eine kuenstliche barriere. zwischen win9x und w2k war die treiberarchitektur viel drastischer veraendert als jetzt w2k/wxp zu vista.Ja. Aber eben nicht so drastisch wie zwischen dem OS und DirectX. Das muß man auch verstehen. Dein Einwand ist aber schon ok. Man trieb es damals halt nicht so auf die Spitze. Ob aber das alles sich bei DX10 so klar aus verbesserungstechnischen Notwendigkeiten ergeben hat steht eben auf einem anderen Blatt.
Imho war es vom Design auch problemlos möglich man DX10 (samt D3D9EX) mit 95% der Vorzügen der neuen Architektur für XP zu bringen. Man wollte es aber einfach nicht. Punkt.
Ist aber wie gesagt OT hier. Von diesen Diskussionen hatten wir ja schon zu genüge.
Verstehen muß man aber auch, daß die Leute damit gezwungen sind ihre bestens funktionierenden Systeme gegen eine bis auf DX10 sonst teilweise recht fragwürdige Qualität aufzugeben und daß man eben Verständnis dafür haben muß, wenn das Thema immer wieder leicht aufkocht.
BH
Grestorn
2008-07-28, 14:46:36
Imho war es vom Design auch problemlos möglich man DX10 (samt D3D9EX) mit 95% der Vorzügen der neuen Architektur für XP zu bringen. Man wollte es aber einfach nicht. Punkt.
Welches Wissen hast Du, dass den Experten hier (damit meine ich nicht mich) fehlt, dass Dir zu dieser Sicherheit verhilft?
Ich denke, solche Aussagen sollten wirklich nur diejenigen treffen, die sich wirklich gut mit DX und der Windows Treiberarchitektur auskennen. Alle anderen sollten sich da besser einer Meinung enthalten.
Imho war es vom Design auch problemlos möglich man DX10 (samt D3D9EX) mit 95% der Vorzügen der neuen Architektur für XP zu bringen. Man wollte es aber einfach nicht. Punkt.
Nein war es nicht. D3D9EX und D3D10 bringen unter anderem mit, dass Surfaces nicht verloren gehen können, d.h. der Treiber kopiert automatisch zurück in den Hauptspeicher wenn ein Task-Switch passiert (sogar bis zurück als Swap auf die Festplatte). Aufbauend darauf können Spiele auch einfach beim Spielbeginn alles laden und Windows streamt dann automatisch in den VRAM.
Das geht mit XP einfach nicht ohne größeren Kernelumbau.
Das geht mit XP einfach nicht ohne größeren Kernelumbau.
Unsinn!
Natuerlich geht das, man muss die Textur einfach nur mit D3DPOOL_MANAGED statt D3DPOOL_DEFAULT erstellen, nichts anderes macht D3D10 auf treiberseite, ein paar Hardware-features tragen das restliche dazu bei, was auch bei WinXP moeglich waere.
Nichts Unsinn. Das ist nicht das gleiche. Bei D3DPOOL_MANAGED legt D3D die Daten sowohl im VRAM als auch im RAM ab.
Bei Vista ist es so, dass die Daten entweder im VRAM oder im RAM liegen und das ganze funktioniert auch mit D3DPOOL_DEFAULT. Eine Schattenkopie ist nicht nötig. Der VRAM ist virtualisiert und das ganze wird auf OS-Level gehandhabt.
XP "weiß nichts" vom VRAM und kann deshalb auch nicht verhindern dass mein ein Surface verliert beim Task Switch. Vista kopiert (NICHT der Treiber) das Zeug dabei aber automatisch um.
Nichts Unsinn. Das ist nicht das gleiche. Bei D3DPOOL_MANAGED legt D3D die Daten sowohl im VRAM als auch im RAM ab.
Bei Vista ist es so, dass die Daten entweder im VRAM oder im RAM liegen und das ganze funktioniert auch mit D3DPOOL_DEFAULT. Eine Schattenkopie ist nicht nötig. Der VRAM ist virtualisiert und das ganze wird auf OS-Level gehandhabt.
XP "weiß nichts" vom VRAM und kann deshalb auch nicht verhindern dass mein ein Surface verliert beim Task Switch. Vista kopiert (NICHT der Treiber) das Zeug dabei aber automatisch um.
Das ist nicht der punkt. Der punkt ist dass der Treiber sehr wohl weiss welche texturen er noch im RAM und welche schon im VRAM hat. Er weiss also sehr wohl ueber einen Taskswitch bescheid und kann selbststaendig die VRAM resourcen neu zuweisen.
Klar, ohne dass Windows paging uebernimmt. Aber Vista wird dir auch keine page auf die festplatte stecken!
Also hast du zwei Systeme, bei dem einem lagert das OS die daten ins RAM, beim zweiten koennte das der treiber, und versuch hier nicht zu erzaehlen dass der Treiber garnichts von den einzelnen applikationen weiss die die Graka benutzen. Das ist ein system auf unterster ebene, entsprechend kann der Treiber auch bei WindowsXP nach einem Absturz die Graka hochfahren ohne dass Windows neu startet (siehe Featureliste bei z.b. NV).
Und wie das intern implementiert ist, ist der applikation dann auch egal die D3D10 nutzt.
Demirug
2008-07-28, 18:09:22
wenn frueher directX mit verschiedenen OS versionen und treiberarchitekturen ging und jetzt nicht, ist es eine kuenstliche barriere. zwischen win9x und w2k war die treiberarchitektur viel drastischer veraendert als jetzt w2k/wxp zu vista.
Das war doch die Crux. Weil man es den Treiberentwicklern einfach machen wollte hat man bei W2K das 95er übernommen und lediglich den allgemeinen Windows NT Treiber Rahmen darum gesetzt. Und dann hat man sich bis Vista nicht mehr getraut es zu ändern.
Imho war es vom Design auch problemlos möglich man DX10 (samt D3D9EX) mit 95% der Vorzügen der neuen Architektur für XP zu bringen. Man wollte es aber einfach nicht. Punkt.
Ist aber wie gesagt OT hier. Von diesen Diskussionen hatten wir ja schon zu genüge.
Für die Vorzüge braucht man das Graphics Kernelsubsystem von Vista oder jeder IHV müsste die Funktionalität selbst vollständig im Treiber nachbauen. Ist natürlich machbar. Aber wenn es einfach wer hätte sicherlich schon jemand die freie Dokumentation zur Radeon benutzt um es zu tun.
XP "weiß nichts" vom VRAM und kann deshalb auch nicht verhindern dass mein ein Surface verliert beim Task Switch. Vista kopiert (NICHT der Treiber) das Zeug dabei aber automatisch um.
Technisch gesehen fordert das Graphics Kernel Subsystem den Treiber auf die Kopieraktionen durchzuführen. Ist aber auch nichts anderes als wenn das Memory Kernel Subsystem den Harddisktreiber auffordert speicher ein oder auszulagern.
Welches Wissen hast Du, dass den Experten hier (damit meine ich nicht mich) fehlt, dass Dir zu dieser Sicherheit verhilft?Bei dem Thema gibt es keine Sicherheit. die habe ich nicht, die hast du nicht und die haben Coda oder Demirug auch nicht.
Es sind Designentscheidungen getroffen worden dessen wahrer Nutzen Mitte 2008 noch bewiesen werden muß, da es keine waschechten DX10 Engines gibt. Die Gründe und Hintergründe die zu ihrer Entstehung führten kennst du nicht. Fuchtel hier also nicht mit fremden Federn rum :|
Ich denke(...) Ich bin mir nicht erst seit heute dieses Problems sehr wohl bewußt.
BH
deekey777
2008-07-28, 20:04:51
Wäre es möglich den Ton zu mäßigen?
Kriton
2008-07-28, 22:09:14
Es sind Designentscheidungen getroffen worden dessen wahrer Nutzen Mitte 2008 noch bewiesen werden muß, da es keine waschechten DX10 Engines gibt. Die Gründe und Hintergründe die zu ihrer Entstehung führten kennst du nicht. Fuchtel hier also nicht mit fremden Federn rum :|
Das ist IMHO eine eher sophistische Argumentation - das logisch fortgeführt führt letztlich auch zu der Aussage, dass die Verweigerung von DX außerhalb des Windows-OS auch nur eine Designentscheidung ist. Denn letztlich ist es auch bei anderen OSs nur eine Frage des Aufwands DX auf diese anzupassen, denn die entsprechenden Effekte ließen sich ja auch auf diesen realisieren...
Nichts Unsinn. Das ist nicht das gleiche. Bei D3DPOOL_MANAGED legt D3D die Daten sowohl im VRAM als auch im RAM ab.
Vollkommen OT:
Kann man darus nicht ein kleines Tool basteln, was die Infos aus Ram und VRam oder mit FP Daten vergleicht? Wär doch ein praktisch, um so Ram und VRam bis an die Grenzen zu übertakten, je nach Aufwand sogar on the fly rauf und runter takten.
Sry, hab von der Materie nicht soviel Ahnung...
(del)
2008-07-29, 00:02:01
Das ist IMHO eine eher sophistische Argumentation - das logisch fortgeführt führt letztlich auch zu der Aussage, dass die Verweigerung von DX außerhalb des Windows-OS auch nur eine Designentscheidung ist. Denn letztlich ist es auch bei anderen OSs nur eine Frage des Aufwands DX auf diese anzupassen, denn die entsprechenden Effekte ließen sich ja auch auf diesen realisieren...Das ist ein interessanter Gedanke, denn eine extrem lange Zeit haben die Coder die meisten und aufwendigsten Demos auf OpenGL laufen lassen. Ich hab nie verstanden warum... Zu dem Zeitpunkt war auch DX9 schon mehr als nur ein alter Hut.
Und OpenGL geht quasi überall, als Platform. Ich bin jetzt aber leicht verwirrt dadurch und bin mir garnicht sicher welche Schlüsse ich aus den beiden Aussagen ziehen soll...
Es wird kein DX10 auf XP angepasst und es geht so wie das Ding nun aussieht imho nichtmal theoretisch (imho). Es sei denn man verpasst XP die Hälfte des Unterbaus von Vista :usweet: Das alles war aber auch nicht mein Thema jetzt.
Das war doch die Crux. Weil man es den Treiberentwicklern einfach machen wollte hat man bei W2K das 95er übernommen und lediglich den allgemeinen Windows NT Treiber Rahmen darum gesetzt. Und dann hat man sich bis Vista nicht mehr getraut es zu ändern.
auch bei vista hat man nur den Rahmen geaendert. Wie du schon hier drunter sagst, kuemmert sich weiterhin der treiber um den speicher der graka. hin und her kopieren war schon immer moeglich, mit dem AGP war es zwar langsam, aber die funktionalitaet war im treiber.
Was man NICHT machen kann, ist dass winXP derart viel zugriff auf die Graka verlangt. Dem waere es immer noch egal wo das vram ist, aber das ist kein feature was D3D10 zu D3D10 macht, es ist eher etwas, was Vista der Hardware bzw. dem treiber abverlangt.
Technisch gesehen fordert das Graphics Kernel Subsystem den Treiber auf die Kopieraktionen durchzuführen. Ist aber auch nichts anderes als wenn das Memory Kernel Subsystem den Harddisktreiber auffordert speicher ein oder auszulagern.
aber mal ganz ehrlich, dass es keinen device lost gibt als grund zu nehmen d3d10 nicht auf winxp anzubieten ist echt kein argument. selbst wenn es device lost geben wuerde mit der winxp implementierung, man koennte wenigstens einheitlich fuer d3d10 programmieren.
so wie es jetzt ist werden alle entwickler gezwungen zwei APIs zu unterstuetzen und die arbeit die sich MS und die treiberprogrammierer erspart haben, muss jeder entwickler nun machen.
Demirug
2008-07-30, 18:26:52
Ich habe jetzt ehrlich gesagt nicht die Zeit und die Lust hier das ganze WDK für XP und Vista zu übersetzten und zu kommentieren. Die Dokumentation ist ja frei zugänglich. Soll sich also jeder selbst ein Bild machen was sich alles geändert hat.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.