Integrierte Grafik in Longhorn nicht unterstützt

[Juerg]

Hallo zusammen,

Ich habe die Folien von der WinHEC mal angeschaut. Da siehts danach aus, dass die nächste WIndows Version keine UMA-Architekturen mehr unterstützen oder nur sehr rudimentär.

Auszug:
-------
- Single Channel UMA configurations are not supported
- Dual Channel UMA configurations with DDR RAM may be supported
- UMA is constrained because memory bandwidth is shared with the rest of the system
- Decision will come by Longhorn Beta


Das heisst dann, das die News vom 2. Dez für den Gulli sind:

Auszug:
-------
..., doch der RS480 mit integrierter DirectX9 Grafik hört sich zweifelslos erfolgsversprechend an, wenn man an die DirectX9-Anforderungen von Windows Longhorn denkt.


DirectX 9 ist ja schön und gut (software spec erfüllt) aber wenn dann die Hardware Specs nicht reichen dafür...
Übrigens heisst das auch, dass ca 80% der Office PC ala i810, i815, i845 oder auch nForce1 usw. für die Tonne sind. Was ja ja höchst wahrscheinlich so gewollt ist. Hui was für ein Geschäft wenn alle Soft- und Hardware wieder mal neu her muss.


Wie seht ihr das so?

P.S. Also auch kein Longhorn für die XBox wenn ich das recht sehe (NV2x DX8 Hardware, UMA Konfig 64MB DDR)?

[mapel110]

longhorn läuft auch schon mit dx7 chips. allerdings der volle (höchstwahrscheinlich nur auf optik-schnick-schnack zurückzuführende) funktionsumfang steht nur dx9 chips zur verfügung.

[Juerg]

Original geschrieben von mapel110
longhorn läuft auch schon mit dx7 chips. allerdings der volle (höchstwahrscheinlich nur auf optik-schnick-schnack zurückzuführende) funktionsumfang steht nur dx9 chips zur verfügung. Das ist ja gerade der springende Punkt. DX9 ist die Software Spec. Wenn jetzt ein integrierter DX9 Chipsatz (ich nehme an in UMA Konfig) ala RS480 wie in den News geschrieben auf den Markt kommt ist es gelinde gesagt eine Lotterie davon auszugehen, dass Longhorn damit (mit allen Features on natürlich, ansonsten braucht man kein Longhorn) rennt. Rennt nicht stolpert...

Ich wage mal zu behaupten, das alles unter ATI 9500/9600 oder NV 5600/5700 keinen Spass macht.

[mapel110]

Original geschrieben von Juerg
Das ist ja gerade der springende Punkt. DX9 ist die Software Spec. Wenn jetzt ein integrierter DX9 Chipsatz (ich nehme an in UMA Konfig) ala RS480 wie in den News geschrieben auf den Markt kommt ist es gelinde gesagt eine Lotterie davon auszugehen, dass Longhorn damit (mit allen Features on natürlich, ansonsten braucht man kein Longhorn) rennt. Rennt nicht stolpert...

Ich wage mal zu behaupten, das alles unter ATI 9500/9600 oder NV 5600/5700 keinen Spass macht.

hehe, ich glaube kaum, dass es zu performance-problemen kommen wird. so aufwendig und ansprichsvoll wie ein 3dshooter wird wohl die windows oberfläche kaum werden :)

[Juerg]

Original geschrieben von mapel110
hehe, ich glaube kaum, dass es zu performance-problemen kommen wird. so aufwendig und ansprichsvoll wie ein 3dshooter wird wohl die windows oberfläche kaum werden :) Tier 2
-DX9-class GPU
-Vertex Shader 2.0
-Pixel Shader 2.0
-2x2 full scene antialiasing
-Bump and environment mapping with luminance
-Hardware transformations and lighting
-Minimum: 64 MB Recommended: 128 MB
-AGP 4x or PCI Express minimum

Welche Grafikkarten würdest Du als Minimum für die oben gennanten Specs kaufen? 5200? Siehste...

[mapel110]

Original geschrieben von Juerg
Tier 2
-DX9-class GPU
-Vertex Shader 2.0
-Pixel Shader 2.0
-2x2 full scene antialiasing
-Bump and environment mapping with luminance
-Hardware transformations and lighting
-Minimum: 64 MB Recommended: 128 MB
-AGP 4x or PCI Express minimum

Welche Grafikkarten würdest Du als Minimum für die oben gennanten Specs kaufen? 5200? Siehste...

auch die 5200er sollte ausreichen für die windows oberfläche. wenn hardwarefunktionen vorrausgesetzt werden, heisst das noch lange nicht, dass sie auch so übermässig eingesetzt werden, dass es viel performance kostet.

siehe zb max payne2 ps1.4 vorraussetzung für max details. und was bekommt man dafür?! den spiegeleffekt. und den sieht man nen paar duzent mal im ganzen spiel auf ner winzigen popeligen fläche.

[Juerg]

Original geschrieben von mapel110
siehe zb max payne2 ps1.4 vorraussetzung für max details. und was bekommt man dafür?! den spiegeleffekt. und den sieht man nen paar duzent mal im ganzen spiel auf ner winzigen popeligen fläche. Da hast Du allerdings recht... war trotzdem eines der unterhaltsameren Spiele der letzten Zeit. Hatte eigentlich vor HL2 zu kaufen. Kam dann nicht. Ja wat den nu... Okay spielen wir halt MP2 :D

Hast Du die freigeschalteten Modi mal versucht. Bringst das was?

[Radeonator]

Was mich dabei freut : IBM will nächstest Jahr Linux stärker in den Markt einbringen. Sie wollen zusätzliche 10% des Desktop Marktes in Angriff nehmen. Ergo wird Linux wohl einen deutlichen kompatiblitätsschub bekommen...was nun fehlt wäre die Unterstützung einer uns allen sehr bekannten API oder zumindest eine EMU dafür :)

Für alle die noch Angst vor Linux haben : http://www.jollix.de <- Von CD lauffähiges Desktop / Multimedia-Gamer Linux :)

[Juerg]

Original geschrieben von Radeonator
Was mich dabei freut : IBM will nächstest Jahr Linux stärker in den Markt einbringen. Sie wollen zusätzliche 10% des Desktop Marktes in Angriff nehmen. Ergo wird Linux wohl einen deutlichen kompatiblitätsschub bekommen...was nun fehlt wäre die Unterstützung einer uns allen sehr bekannten API oder zumindest eine EMU dafür :)DX ist nebst der installierten Basis woll der beste Joker von MS. Nicht zuletzt oder gerade deshalb pushen sie DX da ein reverse engeeniering von DX mit akztebtabler Kompat. und Perf. woll ein Wunschtraum bleibt. Sie werden sich hüten DX Sourcen zu veröffentlichen. Somit macht das ganze für MS erst recht Sinn. Nebst dem profitablen Geschäft, dass alle wieder einen zünftigen Batzen investieren müssen, sollen, können, dürfen, wollen usw.. um ja nichts zu verpassen, kann damit wieder ein "Alleinstehungsmerkmal" (was für ein Unwort) geschaffen werden um so die Konkurrenz vom Leibe zu halten. Cross-Platform ist nicht mehr möglich oder nur sehr, sehr beschränkt im W2K Komp. Modus. Und wer will dann schon auf die immersiven, interaktiven 3D Welten verzichten in der man an einem Brief 5h lang mit Spass geschrieben hat (inkl. 1 Treiberupdate zweier Neustarts und 3 Abstürze wovon einer ein world-overflow war ;D)

Abgesehen davon, dass man das mit vi innert 15min den "Brief" geschrieben hätte verbleiben einem noch 4.75 Stunden um dem Empfänger zu erklären mit welchem Vertex Version er den Brief übersetzen muss, dass er ihn überhaupt lesen kann. ("Lesen" meint hier generieren einer virtuellen Bibliothek inkl. Schreibtisch, fauteuil und Leselampe, Beleuchung damit schwarz-auf-weiss Mustererkennung durchgeführt werden kann...):o

[ShadowXX]

Ich bin mir auch ziemlich sicher, dass Longhorn dazu benutzt werden soll, den User zu neuen HW-Käufen zu "zwingen".

Selbst den grössten Deppen unter den Admins und HW-Beschaffern bemerken inzwischen nämlich, dass man keine 2.5Ghz für Office braucht....

Nun mit Longhorn braucht man diese dann schon und dazu gleich noch eine neue Grafikkarte....und wenn wir schon dabei sind: vielleicht meint Longhorn ja auch noch, dass 100MBit für Netzwerke zu Lahm sind....;D ;D

J.S.Shadow

[BlackArchon]

Wie will Longhorn eigentlich erkennen, ob ein Chipsatz mit integrierter Grafik im Rechner steckt oder eine echte Grafikkarte ihre Arbeit verrichtet?

Außerdem, ich glaube nicht, dass Microsoft die Systemintegratoren, die Billig-PCs mit Mainboards mit Onboardgrafik herstellen, vor den Kopf stoßen will.

[Juerg]

Original geschrieben von BlackArchon
Wie will Longhorn eigentlich erkennen, ob ein Chipsatz mit integrierter Grafik im Rechner steckt oder eine echte Grafikkarte ihre Arbeit verrichtet?Also dafür sind Vendor ID und Device ID gedacht.

Original geschrieben von BlackArchon Außerdem, ich glaube nicht, dass Microsoft die Systemintegratoren, die Billig-PCs mit Mainboards mit Onboardgrafik herstellen, vor den Kopf stoßen will. Deshalb ja meine Originalfrage: ATI hat einen Chipsatz mit integr. DX9 angedacht (steht in den News vom 2.Dez). Doch Longhorn unterstützt höchst wahrscheinlich keine UMA Arch. mehr. Jedenfalls nicht mit der ganzen Dröhnung zugeschaltet. ?(

[Endorphine]

Original geschrieben von Juerg
Doch Longhorn unterstützt höchst wahrscheinlich keine UMA Arch. mehr. Jedenfalls nicht mit der ganzen Dröhnung zugeschaltet. ?( Es ist nicht so, dass Longhorn diese Architektur nicht mehr "unterstützt", nein, Microsoft hätte es gern, wenn die Hersteller diese Technik möglichst wenig verwenden. Oder zumindest ein schnelles Speicherinterface verwenden.

Es macht nunmal keinen guten Eindruck, wenn bei Longhorn schon die GUI erbärmlich ruckelt und kein produktives arbeiten möglich ist, wenn gleichzeitig mit Windows XP (oder älter) alles wie geschmiert läuft. Das könnte der Benutzer dann schnell Microsoft in die Schuhe schieben. Deshalb wird integrierte UMA-Grafik mit langsamem Hauptspeicher in low-end Rechnern nicht gern gesehen von Microsoft.

Die Aussage ist ja nicht "gegen UMA", sondern "gegen UMA mit langsamer Speicheranbindung". Da hat Microsoft Bedenken in Bezug auf die "end-user experience", verständlicherweise.

[Gast]

Original geschrieben von BlackArchon
Wie will Longhorn eigentlich erkennen, ob ein Chipsatz mit integrierter Grafik im Rechner steckt oder eine echte Grafikkarte ihre Arbeit verrichtet?

Außerdem, ich glaube nicht, dass Microsoft die Systemintegratoren, die Billig-PCs mit Mainboards mit Onboardgrafik herstellen, vor den Kopf stoßen will.

Braucht es gar nicht.

6.4GB/sec Bandbreite sind für DX9-Grafik incl. 4xMSAA einfach zu wenig, da der Prozessor ja auch noch was davon ab haben will.

Lösungen / Lösungsansätze :

TBDR : Auf mich macht die Longhorn-spec den Eindruck, als ob sie einem TBDR auf den Leib geschneidert wäre bzgl. integrierter Chipsätze

QBM : verdoppelt mal so ohne größeren Chipsatz/Mainboard-Aufwand die Bandbreite von 6.4GB/sec auf 12.8GB/sec wenn es Kentron (sp?) schafft das QBM auch bei 200MHz stabil zum laufen zu bringen. 12.8GB/sec reichen dann locker für R9600Pro-Leistung aus, auch wenn die CPU gerade mal selbst viel Bandbreite braucht.

Allerdings wird 2005 schon DDR2 für Mainboards verfügbar sein, und dann könnte auch eine inzwischen ja normale 128bit - Speicheranbindung mit 667MHz ( =10,67GB/sec ) ausreichen ;)

Neue Hardware braucht man als M$-Sklave aber auf alle Fälle um Longhorn einzusetzen. Eine interessante Meinung zu Longhorn und M$ für alle M$-Sklaven findet man hier :
http://www.pbs.org/cringely/pulpit/pulpit20031120.html

[Juerg]

Original geschrieben von Endorphine
Es ist nicht so, dass Longhorn diese Architektur nicht mehr "unterstützt"Woher Du wissen das?

[DrumDub]

Original geschrieben von Juerg
Woher Du wissen das?

in der c't 24/03 stand in einem der longhorn-artikel, dass auch der ganz normale windows-desktop verwendet werden kann. xp kannste ja schließlich auch auf windows 95-2000 (okay, vielleicht nicht ganz genau 95/98 bei den symbolen) darstellung runterschrauben. nur ist eben standardmäßig diese fiese luna-oberfläche aktiviert... :kotz:

[Juerg]

Original geschrieben von DrumDub
in der c't 24/03 stand in einem der longhorn-artikel, dass auch der ganz normale windows-desktop verwendet werden kann. xp kannste ja schließlich auch auf windows 95-2000 (okay, vielleicht nicht ganz genau 95/98 bei den symbolen) darstellung runterschrauben. nur ist eben standardmäßig diese fiese luna-oberfläche aktiviert... :kotz: Ja, da hast Du schon recht. Ich habe mich unklar ausgedrückt. Ich wollte eigentlich damit sagen, dass diese Arch. nicht meht unterstützt wird, *wenn* die neuen 3D Animationen/Oberfläche/GUI/WasAuchImmer eingeschaltet sind.

[Matrix316]

Original geschrieben von DrumDub
in der c't 24/03 stand in einem der longhorn-artikel, dass auch der ganz normale windows-desktop verwendet werden kann. xp kannste ja schließlich auch auf windows 95-2000 (okay, vielleicht nicht ganz genau 95/98 bei den symbolen) darstellung runterschrauben. nur ist eben standardmäßig diese fiese luna-oberfläche aktiviert... :kotz:

Höy, so schlecht ist Luna garnicht! Oder denk mal an style-xp!

Die Sache bei Longhorn ist, dass bislang die neue Oberfläche noch garnicht eingebaut ist (afaik). WENN die neue Oberfläche drinnen ist, dann kannste wahrscheinlich DX7 und 8 Hardware vergessen.

Allerdings bis LH rauskommt, wird eh jeder (oder die meisten) eine bessere Grafikkarte haben.

[Tigerchen]

Original geschrieben von Juerg
Ja, da hast Du schon recht. Ich habe mich unklar ausgedrückt. Ich wollte eigentlich damit sagen, dass diese Arch. nicht meht unterstützt wird, *wenn* die neuen 3D Animationen/Oberfläche/GUI/WasAuchImmer eingeschaltet sind.

Ja und?
Wer so ne poppelige UMA-Grafik nutzt dürfte auch sonst eher niedrige Ansprüche haben.Dann wird der Schnick-Schnack eben abgeschaltet und fertig.Wollen wir ehrlich sein.Spätestens nach einer Stunde nerven die meisten Effekte sowieso.Ein Desktop sollte funktionell sein.

[DrumDub]

Original geschrieben von Matrix316
Höy, so schlecht ist Luna garnicht! Oder denk mal an style-xp!

da gibts für mich nichts zu denken. da gibts nur eins: abschalten.

genauso wie die schwachsinnigen persönlich angepassten menüs, die zusammenfassung von tasks zu programmgruppen oder das xp-startmenü.

tigerchen hats ja eigentlich schon gesagt: funktionell soll ein desktop sein. da hat ms mit der widnows 95-oberfläche als grundstein bisher imho das beste abgeliefert, was es bis dahin gab.

in punkto funktionalität und ergonomie macht aber jedes mac os windows in meinen augen locker platt.

[LOCHFRASS]

Ich glaube nicht dass sich Intel von M$ sagen lässt, was sie für onboard-Lösungen zu verbauen haben, was soll M$ schon gegen Intel ausrichten? Wenn sie den Laden kaputt machen, zerstören sie sich doch ihr eigenes Geschäft oder verbaut irgendwer mit Verstand non-Intel CPUs in Büro-PCs?

[Juerg]

Original geschrieben von Tigerchen

Ja und?
Wer so ne poppelige UMA-Grafik nutzt dürfte auch sonst eher niedrige Ansprüche haben.Dann wird der Schnick-Schnack eben abgeschaltet und fertig.Wollen wir ehrlich sein.Spätestens nach einer Stunde nerven die meisten Effekte sowieso.Ein Desktop sollte funktionell sein.
Funktionalität und 3D schliessen sich nicht gegenseitig a priori aus. Ab und an den Skin wechseln (oder halt den WindowManager) bringt etwas Abwechslung. I denke mal Longhorn wird 3D salonfähig machen, will heissen, wird nicht mehr belächelt als Spielzeug für die Kids oder Konstruieren für "Profis" sondern akzeptiert als Hilfswerkzeug für jedermann.

[Tigerchen]

Original geschrieben von Juerg
Funktionalität und 3D schliessen sich nicht gegenseitig a priori aus. Ab und an den Skin wechseln (oder halt den WindowManager) bringt etwas Abwechslung. I denke mal Longhorn wird 3D salonfähig machen, will heissen, wird nicht mehr belächelt als Spielzeug für die Kids oder Konstruieren für "Profis" sondern akzeptiert als Hilfswerkzeug für jedermann.


Ich kenn ja Microsoft's Windows schon eine Weile.Würde mich doch schon sehr wundern wenn der 3D Teil nicht vor allem für das Herbeizaubern einer quitschbunten Teletubbie Welt genutzt werden wird.
Wäre aber nett wenn deine Vision Wirklichkeit wird.:)

[Matrix316]

Original geschrieben von DrumDub
da gibts für mich nichts zu denken. da gibts nur eins: abschalten.

genauso wie die schwachsinnigen persönlich angepassten menüs, die zusammenfassung von tasks zu programmgruppen oder das xp-startmenü.

tigerchen hats ja eigentlich schon gesagt: funktionell soll ein desktop sein. da hat ms mit der widnows 95-oberfläche als grundstein bisher imho das beste abgeliefert, was es bis dahin gab.

in punkto funktionalität und ergonomie macht aber jedes mac os windows in meinen augen locker platt.

Es steht nirgendwo, dass ein Betriebsystem optisch altmodisch aussehen muss um Funktionell zu sein. Die Persönlich angepassten Menüs, das Zusammenfassen von Tasks schalte ich z.B. immer ab. Das neue Startmenü finde ich wesentlich besser als das alte, weil ich damit viel schneller navigieren kann und auch schneller auf den Arbeitsplatz komme z.B..

[Radeonator]

Darum geht es auch net! Es geht eher um die vielen anderen Schmankerl :

-TCP/Palladium
-DX9 Karte minimum
-Keine UMA Lösungen
-höchstwarscheinlich Brutal ressourcen fressend
etc.

Mein XP ist schon auf Standard "roh" Ansicht gestellt, ich verbrauche doch net 40% des Speichers für diesen KlickiBunti Sh1c3 und bei Doofhorn wirds garantiert richtig derbst...

[Exxtreme]

Original geschrieben von Matrix316
Es steht nirgendwo, dass ein Betriebsystem optisch altmodisch aussehen muss um Funktionell zu sein.
Klar, aber zuviel Klicki-Bunti iss auch net gut. Schau dir mal KDE in voller Ausbaustufe an. Das würde Bill Gates und Luna-Jüngern Tränen in die Augen treiben.

[DrumDub]

Original geschrieben von Matrix316
Es steht nirgendwo, dass ein Betriebsystem optisch altmodisch aussehen muss um Funktionell zu sein. Die Persönlich angepassten Menüs, das Zusammenfassen von Tasks schalte ich z.B. immer ab. Das neue Startmenü finde ich wesentlich besser als das alte, weil ich damit viel schneller navigieren kann und auch schneller auf den Arbeitsplatz komme z.B..

geschmacksache. ich find die funktionalität der "alten" (nein, nicht 3.1 ;) ) windowsoberfläche unerreicht auf dem pc.

[Matrix316]

Original geschrieben von Exxtreme
Klar, aber zuviel Klicki-Bunti iss auch net gut. Schau dir mal KDE in voller Ausbaustufe an. Das würde Bill Gates und Luna-Jüngern Tränen in die Augen treiben.

Hm, was willst du jetzt damit genau sagen? Dass der KDE noch 10 Mal mehr Klicki-Bunti sein kann wie Windows jemals sein wird? ;D

[deekey777]

Wer ist den der grösste Anbieter für Grafiklösungen? ATi? nVidia? Nein, Intel mit seinen xxx G-Chipsätzen! Und diese sind nunmal in den meisten Bürorechnern der Welt zu finden. Und wie schon oben gesagt, Intel wird sich da nichts vorschreiben lassen.

[Radeonator]

Naja der Intel Extreme III ist ja ein DX9 Chip, die finden schon eine Lösung...

[Gast]

Original geschrieben von Tigerchen
Würde mich doch schon sehr wundern wenn der 3D Teil nicht vor allem für das Herbeizaubern einer quitschbunten Teletubbie Welt genutzt werden wird.
Wäre aber nett wenn deine Vision Wirklichkeit wird.:)
Wie Du die eine Anwendung von MS dieser Technologie nennst, spielt letztendlich keine Rolle. Faktisch werden ein paar Mill. Benutzer eine 3D API benutzen (vielleicht sogar meist unwissentlich).

[zeckensack]

Original geschrieben von Juerg
Hallo zusammen,

Ich habe die Folien von der WinHEC mal angeschaut. Da siehts danach aus, dass die nächste WIndows Version keine UMA-Architekturen mehr unterstützen oder nur sehr rudimentär.

Auszug:
-------
- Single Channel UMA configurations are not supported
- Dual Channel UMA configurations with DDR RAM may be supported
- UMA is constrained because memory bandwidth is shared with the rest of the system
- Decision will come by Longhorn Beta


Das heisst dann, das die News vom 2. Dez für den Gulli sind:
<...>WinHEC ist eben auch für den Gulli.

Ein Treiber für UMA-Grafik kann vom System überhaupt nicht von einem Treiber für diskrete Grafik unterschieden werden. Ob Single- oder Dual-Channel erst recht nicht.

... es sei denn, man ist 'intelligent' genug, eine zwölf Kilometer lange Liste anzulegen, und anhand dieser in Kombination mit der PCI-ID zu entscheiden. Fehldesign ahoi.

[stickedy]

Eben!
Zeckensack bringt es auf den Punkt: Die Aussage, dass UMA-Architekturen von Longhorn nicht mehr unterstützt werden ist - gelinde gesagt - Schwachsinn!

Es steht natürlich zu befürchten, dass langsame UMA-Lösungen zu langsam für alle 3D-Funktionen von Longhorn sind. Das ist aber wohl eher ein Problem des PC-Herstellers dann...

[Gast]

Original geschrieben von stickedy
Eben!
Zeckensack bringt es auf den Punkt: Die Aussage, dass UMA-Architekturen von Longhorn nicht mehr unterstützt werden ist - gelinde gesagt - Schwachsinn!

Es steht natürlich zu befürchten, dass langsame UMA-Lösungen zu langsam für alle 3D-Funktionen von Longhorn sind. Das ist aber wohl eher ein Problem des PC-Herstellers dann...

Doch das geht ganz einfach. M$ verdonnert einfach die OEM's dazu. Ein kleiner "Approved for Longhorn" - Aufkleber und eine entsprechende Zertifizierung. Wo-la mehr braucht M$ gar nicht zu machen. Geld verdienen sie damit dann auch noch, da die OEM's für die Zertifizierung natürlich zahlen müssen.

Natürlich kann man seine alte Mühle auf Longhorn "aufrüsten", aber dann verweigert M$ natürlich jede Hilfe und jeden Support (siehe mein letztes Posting mit dem Link). Wenn die Mühle also abkackt ist man selber Schuld und M$ hat wieder einen zufriedenen Kunden mehr.

[Gast]

Original geschrieben von zeckensack
WinHEC ist eben auch für den Gulli.

Ein Treiber für UMA-Grafik kann vom System überhaupt nicht von einem Treiber für diskrete Grafik unterschieden werden. Ob Single- oder Dual-Channel erst recht nicht.

... es sei denn, man ist 'intelligent' genug, eine zwölf Kilometer lange Liste anzulegen, und anhand dieser in Kombination mit der PCI-ID zu entscheiden. Fehldesign ahoi. Ok, WinHEC -> Gulli.


Das System kann den Treiber nicht auseinanderhalten, das ist richtig. Am Treiber sieht mans nicht. Allerdings wäre es ja ein leichtes die UMA von nicht UMA-Arch. zu unterscheiden. Also da wäre zu Beispiel der Umstand, dass der Hersteller solcher Boards eben *immer* eine Grafikeinheit aus dem eigenen Regal nehmen.

Also SiS-board-SiS-Grafik, nVboard-nVgrafik, Atiboard-Atigrafik usw.... Somit kann kann zweifelsfrei davon ausgegangen werden, dass unterschiedliche Hersteller von Board und Grafik nie ein UMA Arch. ist. Somit muss umgekehrt nur dann ein Test durchgeführt werden wenn VendorIDboard gleich VendorIDgrafik.

Und somit muss auch nur die Liste DeviceID *eines* Herstellers veglichen werden was sicher im Rahmen des möglichen liegt (denke mal alle < 100).


Die ist nur mal ein quick workaround den ich hier poste. Ich bin sicher es gibt weit clevere Methoden, dies zu bewerkstelligen.

Vielleicht hast Du trotzdem recht, aber deine Argumentation lasse ich so nicht gelten.

[Gast]

Original geschrieben von stickedy
Eben!
Zeckensack bringt es auf den Punkt: Die Aussage, dass UMA-Architekturen von Longhorn nicht mehr unterstützt werden ist - gelinde gesagt - Schwachsinn!

Es steht natürlich zu befürchten, dass langsame UMA-Lösungen zu langsam für alle 3D-Funktionen von Longhorn sind. Das ist aber wohl eher ein Problem des PC-Herstellers dann... Die *meisten* Kunden werden sich dann ein Bild davon machen (in der Werbung usw.) wie Longhorn aussieht. Natürlich auf einem MultiMegaSupaDupa System mit allem Firlefanz on.

Wenn sie dann ein System in den Fingern haben, das eine UMA Arch. ist und der ganze Firlefanz abgestellt, ist sagen Sie: "Das ist nicht Longhorn". Womit Sie vom tech. Standpunkt eigenlich nicht Recht haben, aber eben sonst schon.

Das ist das Katze <-> Kater Bespiel.

Sieht aus wie eine Katze (W2K), miaut wie eine Katze (W2K), benimmt sich wie eine Katze (W2K), ist aber keine Katze (W2K), was ist es dann: ein Kater (Longhorn). Niemand möchte dies.

[zeckensack]

Original geschrieben von Gast
Ok, WinHEC -> Gulli.

Das System kann den Treiber nicht auseinanderhalten, das ist richtig. Am Treiber sieht mans nicht. Allerdings wäre es ja ein leichtes die UMA von nicht UMA-Arch. zu unterscheiden.
<...>
Die ist nur mal ein quick workaround den ich hier poste. Ich bin sicher es gibt weit clevere Methoden, dies zu bewerkstelligen.Clever? Was ist daran clever? Was wird damit erreicht?
Das ist, sorry, rasender Unsinn.

Nach der Logik wird dann eine FX5200 (gar noch mit 64 Bit-Speicherbus) über eine hypothetische, leistungsfähigere integrierte (DX9-)Lösung des Jahres 2006 eingeordnet (und nein, ich habe nicht den kleinsten Zweifel, daß die Dinger bis dahin die FX5200/64 klar schlagen werden).
Tolle Wurst. Echt clever! Genau darauf hat die Menschheit gewartet! Man kann Engineering-Resourcen überhaupt nicht sinnvoller einsetzen! :bonk:
/sarkasmus
Vielleicht hast Du trotzdem recht, aber deine Argumentation lasse ich so nicht gelten.Ich habe nicht behauptet daß es gänzlich unmöglich ist, das so hinzubiegen, aber sinnvoll ist es nicht.

[ShadowXX]

Original geschrieben von zeckensack
Ich habe nicht behauptet daß es gänzlich unmöglich ist, das so hinzubiegen, aber sinnvoll ist es nicht.

Wieviele sinnvolle Sachen hat M$ den in den letzten Jahren gemacht ;D

J.S.Shadow

P.S.
nur weil etwas in unseren/deinen Augen nicht sinnvoll ist, muss es M$ deswegen nicht auch so sehen....

[Matrix316]

Original geschrieben von ShadowXX
Wieviele sinnvolle Sachen hat M$ den in den letzten Jahren gemacht ;D


Direct X zum Beispiel. ;D

[Radeonator]

DX ist wohl eher für M$ sinnvoll, als für alle anderen...

WinXP, das erste OS von MS, das nach 98SE wirklich nen Burner ist :) oder Server2003 als Workstation konfiguriert!
Office2003 . jo da jibbet schon einiges!

[zeckensack]

Original geschrieben von Radeonator
Office2003.Wieso (http://www.geizhals.at/deutschland/a66262.html) das (http://www.geizhals.at/deutschland/a66235.html) denn (http://www.openoffice.org/)?

[Matrix316]

Original geschrieben von Radeonator
DX ist wohl eher für M$ sinnvoll, als für alle anderen...


Mit DirectX ist aber die Hardware egal. Und nicht nur die Grafikkarte sondern auch Sound, und alles andere. Es ist viel einfacher für DX Spiele zu machen, weil man eben nicht mehr direkt auf die spezielle Hardware zugreift oder wie das so geht. ;)

[ShadowXX]

Original geschrieben von Matrix316
Mit DirectX ist aber die Hardware egal. Und nicht nur die Grafikkarte sondern auch Sound, und alles andere. Es ist viel einfacher für DX Spiele zu machen, weil man eben nicht mehr direkt auf die spezielle Hardware zugreift oder wie das so geht. ;)

a.) Man könnte ja auch OGL nehmen...
b.) Wie egal die HW ist, sieht man sehr schön am Beispiel nv3x vs. r3xx ;D

J.S.Shadow

P.S.
aber zugegeben: DX ist besser als nix....aber ob sinnvoll?? (OGL gab es damals schon)

[Matrix316]

Original geschrieben von ShadowXX
a.) Man könnte ja auch OGL nehmen...
b.) Wie egal die HW ist, sieht man sehr schön am Beispiel nv3x vs. r3xx ;D

J.S.Shadow

P.S.
aber zugegeben: DX ist besser als nix....aber ob sinnvoll?? (OGL gab es damals schon)

Soweit ich weiß ist aber OpenGL nur für die Grafik zuständig und sonst nix. (Jedenfalls hat das unser Professor in "Schnittstellenprogrammierung" [z.B. GLUT] erzählt. ;))

Das einzige Problem von Direct X ist, dass es nur unter Windows läuft. ;D

[Exxtreme]

Original geschrieben von Gast
Das System kann den Treiber nicht auseinanderhalten, das ist richtig. Am Treiber sieht mans nicht. Allerdings wäre es ja ein leichtes die UMA von nicht UMA-Arch. zu unterscheiden. Also da wäre zu Beispiel der Umstand, dass der Hersteller solcher Boards eben *immer* eine Grafikeinheit aus dem eigenen Regal nehmen.

Also SiS-board-SiS-Grafik, nVboard-nVgrafik, Atiboard-Atigrafik usw.... Somit kann kann zweifelsfrei davon ausgegangen werden, dass unterschiedliche Hersteller von Board und Grafik nie ein UMA Arch. ist. Somit muss umgekehrt nur dann ein Test durchgeführt werden wenn VendorIDboard gleich VendorIDgrafik.

Haha, das funktioniert aber nur bei bekannten Hardware-Komponenten. M$ kann aber nicht in die Zukunft schauen.

[ShadowXX]

Original geschrieben von Exxtreme
Haha, das funktioniert aber nur bei bekannten Hardware-Komponenten. M$ kann aber nicht in die Zukunft schauen.

Nein, dass nicht...aber Sie können die Hersteller dazu verdonnern, das sich die Grakas dementsprechend bei Windows zu melden haben...sonst gibts keine Treiberfreigabe....

J.S.Shadow

P.S.
@Matrix316
du hast recht...OGL ist nur für Grafik...aber M$ hat am Anfang wirklich darüber nachgedacht, OGL als Schnittstelle zu benutzen...

[Demirug]

Original geschrieben von Matrix316
Soweit ich weiß ist aber OpenGL nur für die Grafik zuständig und sonst nix. (Jedenfalls hat das unser Professor in "Schnittstellenprogrammierung" [z.B. GLUT] erzählt. ;))

Japp. Das G steht ja auch für Graphics.

Das einzige Problem von Direct X ist, dass es nur unter Windows läuft. ;D

Stimmt nicht ganz. Es gibt DX8 für den MAC.

Der Vorteil von D3D (als Teil von DX) gegenüber OpenGL ist das es nur jeweils nur eine Schnittstelle für eine Funktion gibt. Programmtechnisch sind alle Pixelshader gleich zu behandeln. Bei OpenGL gibt es für den Pixelshader komplex viele unterschiedliche Schnitsttellen die jeweils nur mit einer bestimmten Menge von Chips funktionieren. Ein Alptraum für die Entwicklung.

So gesehen hat MS da schon was gutes gemacht. Ich erinnere mich noch mit grauen an die DOS Zeiten als jede Soundkarte und die SVGA Karten anders angesprochen werden mussten.

[Gast]

Original geschrieben von zeckensack
Ich habe nicht behauptet daß es gänzlich unmöglich ist, das so hinzubiegen, aber sinnvoll ist es nicht. Ganz genau dieser Meinung bin ich auch...

[Gast]

Original geschrieben von Exxtreme
Haha, das funktioniert aber nur bei bekannten Hardware-Komponenten. M$ kann aber nicht in die Zukunft schauen. Für zukünftige könnte ein Flag herhalten. Für alle bestehenden reicht dies.

[mapel110]

Original geschrieben von Demirug
So gesehen hat MS da schon was gutes gemacht. Ich erinnere mich noch mit grauen an die DOS Zeiten als jede Soundkarte und die SVGA Karten anders angesprochen werden mussten.

naja, fast jede soundkarte hatte nen "creative soundblaster emulator (tm)" dabei :)
und svga grafik? soviele funktionen konnten damals dir grafikkarten doch ohnehin nicht. ich kann mich jedenfalls an kein grafikkartenlimiertes spiel errinnern. fette CPU und gut war. grafikkarte spielte dann nur eine rolle, bei der farbanzahl und der zu wählenden auflösung, und das war ja widerrum nur abhängig von der menge des lokalen speichers der graka.

[Demirug]

Original geschrieben von mapel110
naja, fast jede soundkarte hatte nen "creative soundblaster emulator (tm)" dabei :)

Ich sage nur Adlib oder Roland Sound System. Die Soundblaster Karten konnte ja nur deswegen eine so dominate Rolle einnehmen weil es eben keine genormete Schnittstelle gab.

und svga grafik? soviele funktionen konnten damals dir grafikkarten doch ohnehin nicht. ich kann mich jedenfalls an kein grafikkartenlimiertes spiel errinnern. fette CPU und gut war. grafikkarte spielte dann nur eine rolle, bei der farbanzahl und der zu wählenden auflösung, und das war ja widerrum nur abhängig von der menge des lokalen speichers der graka.

Ich merke schon du hast damals keine SVGA Karte programmiert. Es geht dabei weniger um eine Limitierung als um das Problem das ganze überhaupt zum laufen zu bekommen. Das Umschalten in eine bestimmte Auflösung und Farbtiefe war bei jedem Chip anders. Auch die Verwaltung des Speichers hatte unterschiede aufzuweisen. Von den Spezialfunktionen einger Chips hat man besser gleich die Finger gelassen. Erst mit dem VESA-Standard wurde das dann besser.

[DrumDub]

Original geschrieben von Demirug

Der Vorteil von D3D (als Teil von DX) gegenüber OpenGL ist das es nur jeweils nur eine Schnittstelle für eine Funktion gibt. Programmtechnisch sind alle Pixelshader gleich zu behandeln. Bei OpenGL gibt es für den Pixelshader komplex viele unterschiedliche Schnitsttellen die jeweils nur mit einer bestimmten Menge von Chips funktionieren. Ein Alptraum für die Entwicklung.


und was ist mit glslang? soll das nicht ne vereinheitlichung bringen?

[Demirug]

Original geschrieben von DrumDub
und was ist mit glslang? soll das nicht ne vereinheitlichung bringen?

Im Prinzip Ja. Aber...

1. glslang erfordert mindestens eine Karte von der Art R3XX, NV3X, oder technologisch vergleichbar. Solange man noch ältere Chips unterstützen muss stellt glslang nur eine gradiele Verbesserung der Situation dar.

2. glslang fehlt die "Sicherheit der Lauffähigkeit". Ein glslang Shader kann muss aber nicht auf jeder Hardware einer Generation laufen. Es kann sogar passieren das ein Shader mit einem Treiber läuft und mit einem anderen abgelent wird. Diese Unsicherheit erhöht den Test und Entwicklungsaufwand gegenüber einer DX-Lösung. Zudem werden gerade kleine IHVs dadurch benachteiligt weil deren Karten von den Entwicklern in der Regel sowieso wenig Beachtung geschenkt wird.

[DrumDub]

Original geschrieben von Demirug
Im Prinzip Ja. Aber...

1. glslang erfordert mindestens eine Karte von der Art R3XX, NV3X, oder technologisch vergleichbar. Solange man noch ältere Chips unterstützen muss stellt glslang nur eine gradiele Verbesserung der Situation dar.

2. glslang fehlt die "Sicherheit der Lauffähigkeit". Ein glslang Shader kann muss aber nicht auf jeder Hardware einer Generation laufen. Es kann sogar passieren das ein Shader mit einem Treiber läuft und mit einem anderen abgelent wird. Diese Unsicherheit erhöht den Test und Entwicklungsaufwand gegenüber einer DX-Lösung. Zudem werden gerade kleine IHVs dadurch benachteiligt weil deren Karten von den Entwicklern in der Regel sowieso wenig Beachtung geschenkt wird.

ahh... danke für die info. dann hält ms mit d3d doch einige trümpfe in der hand, die opengl bzw. glslang in zukunft das leben weiterhin schwer machen werden.

[Exxtreme]

Original geschrieben von Demirug
2. glslang fehlt die "Sicherheit der Lauffähigkeit". Ein glslang Shader kann muss aber nicht auf jeder Hardware einer Generation laufen. Es kann sogar passieren das ein Shader mit einem Treiber läuft und mit einem anderen abgelent wird. Diese Unsicherheit erhöht den Test und Entwicklungsaufwand gegenüber einer DX-Lösung. Zudem werden gerade kleine IHVs dadurch benachteiligt weil deren Karten von den Entwicklern in der Regel sowieso wenig Beachtung geschenkt wird.
Errm, diese "garantierte Lauffähigkeit" hast du bei Direct3D aber auch nicht. :) Ein PS2.0-Shader wird kaum auf einer Riva128 laufen. :) Und wenn ein Treiber nicht DX9-konform ist, dann läuft der Shader normalerweise auch nicht, selbst wenn die HW selbst DX9-fähig wäre.

[Demirug]

Original geschrieben von Exxtreme
Errm, diese "garantierte Lauffähigkeit" hast du bei Direct3D aber auch nicht. :) Ein PS2.0-Shader wird kaum auf einer Riva128 laufen. :) Und wenn ein Treiber nicht DX9-konform ist, dann läuft der Shader normalerweise auch nicht, selbst wenn die HW selbst DX9-fähig wäre.

Du weisst doch wie es gemeint war, oder?

Kann ich einen HLSL Shader (das Gegenstück zu glslang) erfolgreich zu einem 2.0 Shader kompilieren ist damit sichergestellt das er auf jeder Karte welche die unterstützung von 2.0 Shadern meldet auch laufen muss. Tut er das nicht kann ich dem IHV in den Hintern treten und in bei MS anschwärzen. In diesem Umfeld kann ich die Anzahl der Shader die ich programmieren muss genau definieren.

Bei glslang sieht das leider nicht so schön aus. Es gibt keine möglichkeit ohne die Hardware+Treiber festzustellen ob ein Shader darauf laufen wird oder nicht. Man müsste also jeden Shader gegen jede mögliche Hardware+Treiber Kombination Testen und für einen Effekt solange Shader schreiben bis man jeweils lauffähige Varianten habe. Damit kann man aber nur Hardware abdecken die es bereits gibt über noch nicht verfügbare Hardware kann man keine Aussage machen.

Man hätte natürlich für alle Effekte Fallback Versionen die dann zum Einsatz kommen wenn der Treiber die hochwertigen Varianten nicht versteht. Man probiert dann eben von oben nach unten alle Varianten durch bis man eine findet welche dem Chip schmeckt. Ist aber irgendwie unbefriediegend wenn man dann wegen einer Kleinigkeit ein Chip gezwungen wird die schlechtere Variante zu nehmen.

Es sind einfach zu viele Unberechenbarkeiten in dem System.

Sobald es aber nur noch DX-Next Hardware gibt sollte das kein Problem mehr sein. Da diese ja unlimitierte Shader Resourcen beherschen müssen sollte auch jede Karte jeden beliebigen glslang Schader beherschen.

[Exxtreme]

Demirug,

ich habe es etwas überspitzt formuliert. :) Ja, der Shadercompiler erleichtert die Arbeit etwas aber gegen fehlerhafte Treiber etc. ist man auch mit DX nicht gefeilt. Es läuft im Endeffekt darauf hinaus, daß man trotz Shadercompiler mit verschiedenen Treiberversionen testen muss. Das Problem ist nämlich, daß man nicht davon ausgehen kann, daß die Kundschaft die neuesten Treiber hat, geschweige denn neue Treiber überhaupt installieren kann weil das Knowhow fehlt etc.

[Demirug]

Original geschrieben von Exxtreme
Demirug,

ich habe es etwas überspitzt formuliert. :) Ja, der Shadercompiler erleichtert die Arbeit etwas aber gegen fehlerhafte Treiber etc. ist man auch mit DX nicht gefeilt. Es läuft im Endeffekt darauf hinaus, daß man trotz Shadercompiler mit verschiedenen Treiberversionen testen muss. Das Problem ist nämlich, daß man nicht davon ausgehen kann, daß die Kundschaft die neuesten Treiber hat, geschweige denn neue Treiber überhaupt installieren kann weil das Knowhow fehlt etc.

Ich glaube wir reden immer noch aneinader vorbei. Die Tests sind natürlich immer notwendig.

Mir geht um die Content Erstellung im Allgemeinen bzw Shadererstellung im Speziellen. Das ist eine Aufgabe die Kurz bis Mittelfristig in die Hände des Designs übergehen soll. Wenn ich nun aber einen Designer einen Shader schreiben lasse so muss ich ihm auch eine Möglichkeit geben seine Arbeit zu validieren. Sonst hat man am Ende das Problem das sein schöner Shader nur mit der Grafikkarte läuft die er auch bei der Entwicklung im Rechner hatte. Bei DX jagt man das Teil einmal durch den Shadercompiler und wenn dieser sein OK gibt dann ist es auch OK für alle Karten die diese Version unterstützen. Diese Validierungen kann man leicht automatisieren und schnell durchführen. Bei glslang wird das aber leicht zu Horrorjob. Man müsste jeden Shader gleich bei der Erstellung gegen eine Vielzahl von Karten/Treiber testen um dann sagen zu können ob man diesen Effekt so benutzten kann oder in doch noch überarbeiten muss weil er eben nur mit ganz bestimmten Karten/Treiber läuft. Zudem fängt jedesmal wenn ein Treiber einen Shader ablehnt die Suche nach den Gründen an. Schaft es die Karte überhaupt nicht? Optimiert der Treiber nicht gut genug? Ist es ein Fehler im Treiber? Oder läuft der Shader nur mit dieser einen Karte weil diese am Ende einen Bug im Treiber hat?