Archiv verlassen und diese Seite im Standarddesign anzeigen : Neue Präsentationen von ATi geleakt
Simon Moon
2003-09-28, 20:52:28
Original geschrieben von ow
30-50 fps kommen eher hin.
Ich kann bestätigen, dass mit einer GF2MX noch alles spielbar ist.
Naja, je nachdem was Spielbar heisst ... hatte selbst bis vor ner Woche ne MX (210/205, also gut 20% mehr Takt ggü Orig) und klar, laufen tuts noch. Vll. sogar im schnitt mit 30 - 50fps, aber bei UT2k3 brichts eben sehr stark ein. Wenn genug Bots da sind, beginnt schon ordentlich zu ruckeln. Also kann man sagen, solang ich ne Wand anstarr, kann ich sehr gut mit meiner MX spielen - oder solang ich nix fps intensives zock (was eigentlich der einzige grund war, wieso sie nicht schon längst geflogen ist) ...
StefanV
2003-09-28, 22:52:01
Original geschrieben von ow
Gerade bei den relativ schwachen CPUs hilft HWTL ja enorm, da die HWTL Leistung ja praktisch unabhängig von der CPU-Leistung ist.
Das Problem ist nur, daß du dich im Kreis drehst *eg*
Bedenke auch die Entwicklungszeiten der Spiele.
StefanV
2003-09-28, 22:52:12
Original geschrieben von LovesuckZ
Wie hat denn Nvidia die "Branche" bei ihrer Entwicklung gehemmt?
Hm, EMBM...
Original geschrieben von Stefan Payne
Das Problem ist nur, daß du dich im Kreis drehst *eg*
Bedenke auch die Entwicklungszeiten der Spiele.
???
Worauf war Quake3 seinerzeit besser spielbar, K6-400 ohne HWTL Graka oder K6-400 mit HWTL Graka??
Original geschrieben von Stefan Payne
Hm, EMBM...
Hmm.. DOT3, HWTL, VS/PS1.x.....scheint eher als ware NV gehemmt worden durch die anderen, meinste nicht??
Original geschrieben von ow
Hmm.. DOT3, HWTL, VS/PS1.x.....scheint eher als ware NV gehemmt worden durch die anderen, meinste nicht?? Dot3 ist weniger flexibel als EMBM, HWTnL brauchte der Gamer anno 1999 und 2000 noch nicht, auch Rampage hätte VS und PS 1.0 gehabt (hätte sich 3dfx vorher nicht noch schnell in die Pleite manövriert...)
Radeon hatte (vor der GF3) schon einen "fast" 1.0-er PS (nicht sogar auch einen Fast-VS?) aber MS ließ sich zulange Zeit mit DX8 und setzte nachträglich die Specs hoch.
Original geschrieben von ow
b) cg und HLSL sind (für DirectX) praktisch dasselbe, nur das NV etwas schneller war als MS.
NV hat hier mit die Entwicklung zu Hochsprachen vorangetrieben. NV hat das aus reinem Eigennutz getan http://www.aths.net/files/smilies/smile.gif weil MS' HLSL zunächst für ATI optimiert war. Afaik ist das jetzige für NV optimierte HLSL-Modell für Pixelshader sogar besser als Cg.
Original geschrieben von LovesuckZ
Und MS hat mit HLSL quasi ein "Hochsprachenmonopol" unter DX. Also solltest du das verdammen, tust natuerlich...MS hat sogar auf das gesamte DX ein Monopol...
Quasar
2003-09-29, 14:48:59
Original geschrieben von aths
Dot3 ist weniger flexibel als EMBM, HWTnL brauchte der Gamer anno 1999 und 2000 noch nicht,[...]
Wenn HW TnL erst 2001 (bräuchte der Gamer es dann??) in den Markt eingeführt worden wäre, wäre die erforderliche Sättigung um massiv auf dieses Feature zu setzen eben erst um zwei Jahre später eingetreten usw.
Die Katze beißt sich hier irgendwie in den Schwanz, meinst du nicht?
StefanV
2003-09-29, 14:50:14
Original geschrieben von ow
???
Worauf war Quake3 seinerzeit besser spielbar, K6-400 ohne HWTL Graka oder K6-400 mit HWTL Graka??
Hm, vermutlich mit 2 V2 im SLI und entsprechender 3DNow! anpassung :naughty:
Original geschrieben von ow
Hmm.. DOT3, HWTL, VS/PS1.x.....scheint eher als ware NV gehemmt worden durch die anderen, meinste nicht??
Ja und wo war EMBM, welches man eigentlich recht einfach implementieren konnte??
Außerdem gabs anno 99 schon Spiele, die EMBM nutzten...
Ganz ab davon gabs EMBM schon ~1Jahr vor den G-Forces...
@aths
Afaik war der 'kleine Vertexshader' Fixed TnL + Matrix Skinning, was übrigens auch die G550 beherrscht, nur aus irgendeinem Grunde stellt MGA das nur ihrem Headcasting zur Verfügung :|
Demirug
2003-09-29, 14:51:40
Original geschrieben von aths
NV hat das aus reinem Eigennutz getan http://www.aths.net/files/smilies/smile.gif weil MS' HLSL zunächst für ATI optimiert war. Afaik ist das jetzige für NV optimierte HLSL-Modell für Pixelshader sogar besser als Cg.
Zu dem Zeitpunkt als nVidia damit angefangen hat war das doch noch gar nicht abzusehen das der MS Compiler Code erzeugt der ATI karten besser gefällt.
nVidia braucht Cg für OpenGL und in gewiesser Weise auch um den Workflow geschlossen zu bekommen.
betasilie
2003-09-29, 16:01:50
Original geschrieben von Demirug
Zu dem Zeitpunkt als nVidia damit angefangen hat war das doch noch gar nicht abzusehen das der MS Compiler Code erzeugt der ATI karten besser gefällt.
nVidia braucht Cg für OpenGL und in gewiesser Weise auch um den Workflow geschlossen zu bekommen.
Du meinst also nicht, dass NV primär vor hatte cg als Standard duchzuboxen, um sich dann Vorteile gegenüber der Konkurrenz zu erzwingen? :spock:
Demirug
2003-09-29, 16:46:16
Original geschrieben von betareverse
Du meinst also nicht, dass NV primär vor hatte cg als Standard duchzuboxen, um sich dann Vorteile gegenüber der Konkurrenz zu erzwingen? :spock:
Nein, die Syntax wurde von Anfang an mit MS zusammen entwickelt. Ich bezog mich nur auf das 2.0 Profil des MS-Compilers.
Und wie soll man sich einen Vortiel erzwingen wenn man von Anfang an jedem die Möglichkeit gibt eigene Profile zu ergänzen?
Original geschrieben von Stefan Payne Ja und wo war EMBM, welches man eigentlich recht einfach implementieren konnte??So einfach ist das nicht, da man dependend texture reads braucht.
Original geschrieben von Quasar
Wenn HW TnL erst 2001 (bräuchte der Gamer es dann??) in den Markt eingeführt worden wäre, wäre die erforderliche Sättigung um massiv auf dieses Feature zu setzen eben erst um zwei Jahre später eingetreten usw.
Die Katze beißt sich hier irgendwie in den Schwanz, meinst du nicht? Ausgerechnet bei T&L eben nicht http://www.aths.net/files/smilies/lol.gif Man kann "HW T&L" per SW emulieren. Oder man kann DX einfach sagen, ob HW oder SW T&L zum Einsatz kommen soll. Einmal vorbereitet, ist die Aktivierung der HW-Unterstützung unproblematisch. Beim Pixelshader, das nicht praktisch nutzbar emulierbar sind, sieht es anders aus.
Natürlich ist es egal, welches Jahr man schreibt, eine Karte mit HW T&L wäre einer genau gleichen Karte ohne HW T&L vorzuziehen. Trotzdem: Nvidias "Grass"-Demo in Ehren, der Polygoncount der Spiele anno 1999 und 2000 erforderte kein T&L. Die Grakas hatten damals auch zuwenig Bandbreite, um die durch mehr Dreiecke allgemein erhöhte Last zu packen. (Was nützt T&L, wenn man auf 640x480 runtergehen muss? FSAA als Konkurrenz-Feature böte da ja wenigestens noch eine gewisse Kompensation...)
Quasar
2003-09-29, 17:00:56
Original geschrieben von aths
Ausgerechnet bei T&L eben nicht [...]
Schade, du hast mich nicht verstanden.
Ich mach's mal etwas leichter (damit man nicht am Ende noch pro-nV argumentieren müsste):
Wie schaut's aus, hätten wir schon Games wie TRAOD, GunMetal, HL2 (bald?) etc. wenn ATI nicht letztes Jahr im Sommer die erste DX9-Karte auf den Markt gebracht hätte?
Ohne Karten, die den Markt ausreichend durchdrungen haben, ist kein fortgeschrittenes Feature realisierbar, da es Geld kostet, es zu implementieren und im Gegenzug kein oder kaum Geld wieder reinkommt, wenn's kaum jemand nutzen kann.
P.S.:
Viel Spass mit einer 600MHz-CPU TnL-Hardware zu emulieren...
StefanV
2003-09-29, 19:12:03
Original geschrieben von aths
So einfach ist das nicht, da man dependend texture reads braucht.
Hm, da hab ich wohl irgendwie die Hälfte weggelassen :|
Meinte in diesem Fall eher auf Softwareseite...
Original geschrieben von aths
Radeon hatte (vor der GF3) schon einen "fast" 1.0-er PS (nicht sogar auch einen Fast-VS?) aber MS ließ sich zulange Zeit mit DX8 und setzte nachträglich die Specs hoch.
MS lies sich zulange Zeit?
In welchen Abständen hättest du denn gerne neue Dx Verionen?
btw. das mit der Radeon ist ein Märchen, da fehlt viel zu viel zur VS/PS Tauglichkeit. Frag mal Demirug, der kann dir das besser erklären.
Exxtreme
2003-09-30, 23:14:11
Also gut Mädelz,
die komplette Präsentation ist geleakt. :up:
diese gibt es hier:
http://www.notforidiots.com/ATIDR/
mapel110
2003-09-30, 23:28:53
Original geschrieben von Exxtreme
Also gut Mädelz,
die komplette Präsentation ist geleakt. :up:
diese gibt es hier:
http://www.notforidiots.com/ATIDR/
ab page6 gehts los, und ab page9 kommt richtig spass auf :D
StefanV
2003-09-30, 23:35:20
Original geschrieben von Exxtreme
Also gut Mädelz,
die komplette Präsentation ist geleakt. :up:
diese gibt es hier:
http://www.notforidiots.com/ATIDR/
*aufplattespeicher*
PS: Welcher *insertword* hat diese Bilder so online gestellt??
Hätte er die nichtmal ordentlich drehen können, so daß man das nicht mit die Hand machen muss?!?!
askibo
2003-09-30, 23:37:05
Original geschrieben von Stefan Payne
*aufplattespeicher*
PS: Welcher *insertword* hat diese Bilder so online gestellt??
Hätte er die nichtmal ordentlich drehen können, so daß man das nicht mit die Hand machen muss?!?!
Besser hätte ich es auch nicht ausdrücken können ;)
askibo
2003-10-01, 00:45:10
Original geschrieben von mapel110
ab page6 gehts los, und ab page9 kommt richtig spass auf :D
hehe. page 9 ist wirklich gut :D
-"Nvidia is walking arround with big bags of cash buying logo space with publishers"
ATI macht sowas natürlich nicht ;)
Page 12:
-"ATI logo/animation used in demos and games for opening and/or exit splash screen."
-"ATI advertisement displayed in demos and games on exit"
-" ATI logo on retail boxes and web site"
:D
Hm, also ich weiss net was ihr habt. Ob auf den Papern jetzt ATI oder nVidia steht - so macht man das in Marketingbesprechungen halt nunmal. Das macht jede Firma :ratlos:
Die Seminare die ich was dieses Thema angeht absolviert habe sprechen genau die gleiche Sprache: Unser Produkt ist besser als das der Konkurrenz. Wenn man selber nicht davon überzeugt ist, ja was will man denn dann schon erreichen?
betasilie
2003-10-01, 01:17:56
Seite 6 und 7 gefallen mir persönlich.
Ich habe ja auch schon immer die Parallele gezogen zwischen Cg und Glide, da NV Cg als "proprietäre" Hochsprache etablieren wollte, um sich dauerhaft einen unfairen Vorteil gegenüber der Konkurrenz zu verschaffen.
Naja, ATI sieht es jedenfalls genauso wie ich. :bäh:
Original geschrieben von Quasar
Schade, du hast mich nicht verstanden.
Ich mach's mal etwas leichter (damit man nicht am Ende noch pro-nV argumentieren müsste):
Wie schaut's aus, hätten wir schon Games wie TRAOD, GunMetal, HL2 (bald?) etc. wenn ATI nicht letztes Jahr im Sommer die erste DX9-Karte auf den Markt gebracht hätte? Sache ist, T&L in GF256 (und GTS) brachte eben nicht in relativ kurzer Zeit entsprechende Spiele. Daraus folgere ich, dass T&L so geil nicht gewesen sein kann.
Quasar
2003-10-01, 08:30:18
Original geschrieben von aths
Sache ist, T&L in GF256 (und GTS) brachte eben nicht in relativ kurzer Zeit entsprechende Spiele. Daraus folgere ich, dass T&L so geil nicht gewesen sein kann.
Ah so.
Ich folgere aus den Implikationen deines Beitrages eher, daß sich viele für DX8 in der Mache befindlichen Spiele recht einfach zusätzlich mit ein bissel* DX9 aufpeppen liessen, während dies bei TnL nicht der Fall war.
Außerdem gibt es ja nun seit zwei Jahren DX8-Hardware, die zumindest per einfachem Fallback unterstützt werden kann. Und genau das schien mit TnL eben nicht möglich zu sein: Entweder man hat den Poly-Count und richtet seine Models und Level darauf aus, oder man läßt es sein. Mit ein paar Spiegelungen und Wassereffekten ist es einfacher und wirkt eher wie aus einem Guß (Gegensatz dazu: Quecksilber-Pfützen in ansonsten DX7-Games à la Morrowind), wenn man sie mit DX9-HW ein wenig realistischer hinbekommt als mit DX8-Hardware fällt das nicht so stark auf. Auch die mittlerweile beliebte DOF ist nicht kritisch, wenn man sie einfach wegläßt.
*Ein bissel im Sinn von "Möglichkeiten von DX9", nicht unbedingt anzahl der Shader oder behandelte Pixel per Frame.
Quasar
2003-10-01, 08:32:03
Original geschrieben von Exxtreme
Also gut Mädelz,
die komplette Präsentation ist geleakt. :up:
diese gibt es hier:
http://www.notforidiots.com/ATIDR/
Da hat sich der Praktikant aber mächtig Zeit gelassen, die Präsentation nochmal Öffenlichkeitswirksam zu überarbeiten. ;D
edit:
Am geilsten sind die Shipping Dates auf Seite 14.
Schade, daß ich Deus Ex2 nicht in Q2 '03 kaufen konnte. ;D ;D X-D
Demirug
2003-10-01, 08:59:20
Original geschrieben von Quasar
Ah so.
Ich folgere aus den Implikationen deines Beitrages eher, daß sich viele für DX8 in der Mache befindlichen Spiele recht einfach zusätzlich mit ein bissel* DX9 aufpeppen liessen, während dies bei TnL nicht der Fall war.
Außerdem gibt es ja nun seit zwei Jahren DX8-Hardware, die zumindest per einfachem Fallback unterstützt werden kann. Und genau das schien mit TnL eben nicht möglich zu sein: Entweder man hat den Poly-Count und richtet seine Models und Level darauf aus, oder man läßt es sein.
Jap, einen DX8 Shader gegen einen DX9 Shader zu tauschen ist eine Kleinigkeit.
Aber wenn man bisher nur Lowpoly Modele gebaut hat bekommt man nicht schnell irgendwo die Modele mit mehr Polys her. Ein weit verbreiter Irtum bezüglich HT&L ist das mehr Polygone mehr Lowpoly-Objekte bedeuten. HT&L bedeutet eher mehr Polygone pro Objekt. Erschwerden kommt eben noch hinzu das zu dem Zeitpunkt als HT&L eingeführt wurde viele Engines noch so gebaut waren das sie um jedes Dreick das sie der API übergeben gekämpft haben. Eine Sünde in Verbindung mit HT&L.
egdusp
2003-10-01, 14:32:50
Original geschrieben von askibo
hehe. page 9 ist wirklich gut :D
-"Nvidia is walking arround with big bags of cash buying logo space with publishers"
ATI macht sowas natürlich nicht ;)
Page 12:
-"ATI logo/animation used in demos and games for opening and/or exit splash screen."
-"ATI advertisement displayed in demos and games on exit"
-" ATI logo on retail boxes and web site"
:D
Ja, das ist echt klasse ;D
mfg
egdusp
LovesuckZ
2003-10-01, 17:56:46
Original geschrieben von betareverse
Ich habe ja auch schon immer die Parallele gezogen zwischen Cg und Glide, da NV Cg als "proprietäre" Hochsprache etablieren wollte, um sich dauerhaft einen unfairen Vorteil gegenüber der Konkurrenz zu verschaffen.
Ja, wo jeder nen eignes Profil schreiben kann...
Ach und das es mit MS entwickelt wurde, macht es doch gleich viel "teuflischer".
Wann verstehst du es endlich, dass Cg keine eigene Hochsprache ist.
Radeonator
2003-10-01, 18:33:33
Jo lustig ist die Presentation ja wirklich, allerdings ists echt merkwürdig das vermeindlich erwachsene Menschen so einen Kinderkram Presentation nennen ??? So etwas hätte ich eher als Fun auf einer Fanboy seite erwartet...erstaunlich :lol:
betasilie
2003-10-01, 19:31:18
Original geschrieben von Demirug
Nein, die Syntax wurde von Anfang an mit MS zusammen entwickelt. Ich bezog mich nur auf das 2.0 Profil des MS-Compilers.
Und wie soll man sich einen Vortiel erzwingen wenn man von Anfang an jedem die Möglichkeit gibt eigene Profile zu ergänzen?
Wenn NV sich keine Vorteile erzwingen wollte, frage ich mich, wieso man nicht eine echte Kooperation eingegangen ist und Synergieeffekte mit anderen Firmen genutzt hat.
Wer glaubt, dass NV im Endeffekt den anderen Herstellern keine Steine in den Weg geschmissen hätte, ist imo ziemlich naiv. Fragt mich jetzt nicht konkret wie NV die Konkurrenz benachteiligt hätte, wenn sich Cg durchgesetzt hätte, aber solange Cg NV gehört, können sie letztlich machen was sie wollen.
Razor
2003-10-01, 20:01:46
Original geschrieben von betareverse
Wenn NV sich keine Vorteile erzwingen wollte, frage ich mich, wieso man nicht eine echte Kooperation eingegangen ist und Synergieeffekte mit anderen Firmen genutzt hat.
Wer glaubt, dass NV im Endeffekt den anderen Herstellern keine Steine in den Weg geschmissen hätte, ist imo ziemlich naiv. Fragt mich jetzt nicht konkret wie NV die Konkurrenz benachteiligt hätte, wenn sich Cg durchgesetzt hätte, aber solange Cg NV gehört, können sie letztlich machen was sie wollen.
Ich hab' zwar die letzten 5 Seiten (noch) nicht gelesen... aber das ist doch Murks.
Cg ist 'ne Übergangslösung gewesen. Das kam raus, als von HLSL noch nix zu sehen war. Nun hat man den DX-Teil im M$-SDK unterbringen können und stellt nun langsam die Arbeit daran ein.
Wo ist hier das Problem ?
???
Und von welchen 'Synergie-Effekten' redest Du hier ?
Gibt es noch eine einzige andere Hardware auf Erden, die FP24 unterstützt ?
Also echt...
Razor
Demirug
2003-10-01, 20:09:34
Original geschrieben von betareverse
Wenn NV sich keine Vorteile erzwingen wollte, frage ich mich, wieso man nicht eine echte Kooperation eingegangen ist und Synergieeffekte mit anderen Firmen genutzt hat.
Man hat sich doch zusammengearbeitet. Es waren nV Leute bei MS und umgekehrt.
Wer glaubt, dass NV im Endeffekt den anderen Herstellern keine Steine in den Weg geschmissen hätte, ist imo ziemlich naiv. Fragt mich jetzt nicht konkret wie NV die Konkurrenz benachteiligt hätte, wenn sich Cg durchgesetzt hätte, aber solange Cg NV gehört, können sie letztlich machen was sie wollen.
Natürlich hat nV den Cg Compiler so gebaut das er beim Code erzeugen keine Rücksicht auf andere Chips nimmt. Wer etwas anderes erwartet hat war wirklich naiv.
Vom Cg Compiler gehören nV nur die Backends für die vorhandenen Profilen. Die Syntax gehört keinen und das Frontend des Compilers steht unter einer Opensource Lizenz. Und die Backends will sowieso kein anderer IHV haben. Hätte sich Cg durchgesetzt hätten die anderen IHVs eben auch einen Compiler anbieten müssen aber MS war ja so nett und übernimmt die Aufgabe jetzt für alle.
Die ganze Cg Geschichte wird heiser gehandelt als sie eigentlich ist.
betasilie
2003-10-01, 20:42:33
Original geschrieben von Demirug
Vom Cg Compiler gehören nV nur die Backends für die vorhandenen Profilen. Die Syntax gehört keinen und das Frontend des Compilers steht unter einer Opensource Lizenz. Und die Backends will sowieso kein anderer IHV haben. Hätte sich Cg durchgesetzt hätten die anderen IHVs eben auch einen Compiler anbieten müssen aber MS war ja so nett und übernimmt die Aufgabe jetzt für alle.
Interessant. ...
Ob die Developer allerdings wirklich gerne mit zig Compilern arbeiten, sei mal dahingestellt. Daher bestand schon die Gefahr, dass die Mehrheit der Developer ausschließlich auf Cg setzen und andere IHVs stiefmütterlich behandeln, weil sie deren Compiler nicht wollen.
Also ich finde es für die IHVs am besten, wenn sich M$ mit HLSL um das Problem kümmert. Die frage bleibt jetzt nur, wie sich die Sache für oGL und insbesondere für oGL2.0 entwickelt.
Original geschrieben von Razor
Ich hab' zwar die letzten 5 Seiten (noch) nicht gelesen... aber das ist doch Murks.
Cg ist 'ne Übergangslösung gewesen. Das kam raus, als von HLSL noch nix zu sehen war. Nun hat man den DX-Teil im M$-SDK unterbringen können und stellt nun langsam die Arbeit daran ein.
Wo ist hier das Problem ?
???
Und von welchen 'Synergie-Effekten' redest Du hier ?
Gibt es noch eine einzige andere Hardware auf Erden, die FP24 unterstützt ?
Also echt...
Razor
Mit Synergieeffekt meinte ich, dass sich die IHVs zusammentun sollten, um eine Alternative zu HLSL zu entwickeln, die auch für oGL zu gebrauchen ist.
Razor
2003-10-01, 20:49:38
Original geschrieben von betareverse
Nichts, aber mit der Mindestanforderung von 96bit klappt es halt nicht so gut. ;)
Nicht einmal der RefRast kann was mit Deiner 'Mindestanforderung' anfangen...
;-)
Razor
Demirug
2003-10-01, 20:49:39
Original geschrieben von betareverse
Interessant. ...
Ob die Developer allerdings wirklich gerne mit zig Compilern arbeiten, sei mal dahingestellt. Daher bestand schon die Gefahr, dass die Mehrheit der Developer ausschließlich auf Cg setzen und andere IHVs stiefmütterlich behandeln, weil sie deren Compiler nicht wollen.
Solange die Compiler sich leicht einbauen lassen hätte ich da kein Problem gesehen.
Also ich finde es für die IHVs am besten, wenn sich M$ mit HLSL um das Problem kümmert. Die frage bleibt jetzt nur, wie sich die Sache für oGL und insbesondere für oGL2.0 entwickelt.
Wie soll sich das für OpenGL 2.0 (jetzt 1.5) entwickeln? Jeder IHV baut eben einen Compiler in den Treiber ein und gut ist. Ich habe da aber ja schon mehrfach bedenken geäussert ob die Idee wirklich so gut ist.
Mit Synergieeffekt meinte ich, dass sich die IHVs zusammentun sollten, um eine Alternative zu HLSL zu entwickeln, die auch für oGL zu gebrauchen ist.
Der Zug ist abgefahren nV hat ja vorgeschlagen das man für OpenGL 2.0 (jetzt 1.5) den gleichen Syntax wie HLSL/Cg benutzten sollte um eine bessere austauschbarkeit zu erreichen. Die Idee hat aber dem ARB nicht gefallen.
Razor
2003-10-01, 20:54:11
Original geschrieben von Demirug
PS: Für alle die es noch nicht mitbekommen haben das neue SDK ist inzwischen verfügbar. Jup.
Microsoft® DirectX® 9.0 SDK Update (Summer 2003)
last update 9/10/2003
Welcome
This is Microsoft's DirectX 9.0 Software Development Kit (SDK) Update (Summer 2003) final release. Because this is an Update, we have changed the structure of this readme. Much of the information will remain as it was for the release of DirectX 9.0. However there have been some additions and modifications. We have made note of this where necessary.
Primary areas of concentration for this Summer Update have been with the Direct3D Extension Library (D3DX), Graphics Samples, Tools and documentation. The included developer runtimes and the DirectX Redistributable have also been updated to include the latest updates (DirectX 9.0b).
After installing, those new to DirectX should start with the DirectX 9.0 documentation. More seasoned developers may also want to view the "What's New" section. Professional DirectX developers should refer to the "KNOWN ISSUES" section prior to raising concerns.
Nicht wahr ?
;-)
Razor
Razor
2003-10-01, 20:55:54
Original geschrieben von betareverse
Mit Synergieeffekt meinte ich, dass sich die IHVs zusammentun sollten, um eine Alternative zu HLSL zu entwickeln, die auch für oGL zu gebrauchen ist.
Hmmm...
Da scheinst Du aber ein merkwürdiges Verständnis von 'unserer' Marktwirtschaft entwickelt zu haben.
(um es gelinde auszudrücken ;-)
Razor
zeckensack
2003-10-01, 21:04:02
Original geschrieben von betareverse
Also ich finde es für die IHVs am besten, wenn sich M$ mit HLSL um das Problem kümmert. Die frage bleibt jetzt nur, wie sich die Sache für oGL und insbesondere für oGL2.0 entwickelt.Unter GL gilt momentan weiterhin, daß es keine herstellerübergreifende Shadersprache für den Techlevel <R300/NV30 gibt.
Für oben drüber gibt es eine herstellerübergreifende ASM-Lösung (ARB_fragment_program), wobei NV dies zwar unterstützt, aber nebenher noch eine Extrawurst auf dem Feuer hat (NV_fragment_program).
Cg ist jedenfalls für ernsthafte Arbeit nicht zu gebrauchen. Der erzeugte Code ist geradezu stümperhaft schlecht (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1243791#post1243791) (auch und gerade für NV3x).
Ein weiteres Projekt in Richtung Hochsprachencompiler ist Ashli (http://www.ati.com/developer/ashli.html), was aber auch nicht herstellerneutral ist (kommt von ATI). Nutzt die Renderman-Syntax.
OpenGL-Entwickler müssen im Prinzip vier Zielarchitekturen direkt unterstützen (ARB_texture_env_combine~=DX7-Techlevel; NV_register_combiners/NV_texture_shader>=PS1.3; ATI_fragment_shader=PS1.4; ARB_fragment_program~=PS2.0).
GL2 integriert einen Hochsprachencompiler direkt in die Treiber, womit sich das Problem dann in Wohlgefallen auflösen dürfte - nur eben nicht für die derzeit den Markt dominierenden Karten.
edit: Link eingefügt
betasilie
2003-10-01, 21:15:02
Thanks @ zeckensack and Demirug für die Infos bzgl. OpenGL.
StefanV
2003-10-01, 21:29:08
Original geschrieben von Demirug
Wie soll sich das für OpenGL 2.0 (jetzt 1.5) entwickeln? Jeder IHV baut eben einen Compiler in den Treiber ein und gut ist. Ich habe da aber ja schon mehrfach bedenken geäussert ob die Idee wirklich so gut ist.
Die Idee ist eigentlich ganz gut, nur ists am Anfang 'etwas' mühsam bzw wird ziemliche Startschwierigkeiten haben.
Der Vorteil wäre, daß die Hersteller besser optimieren könnten, Nachteil wäre die ev. recht hohe CPU Last...
zeckensack
2003-10-01, 21:35:16
Original geschrieben von Stefan Payne
Die Idee ist eigentlich ganz gut, nur ists am Anfang 'etwas' mühsam bzw wird ziemliche Startschwierigkeiten haben.
Der Vorteil wäre, daß die Hersteller besser optimieren könnten, Nachteil wäre die ev. recht hohe CPU Last... Shader-Kompilierung ist vergleichsweise langsam, aber das gleiche gilt für das Hochladen von Texturen. Wenn man das 'en bloc' beim Laden eines Levels oä macht, dann ist es nicht mehr performancekritisch.
Original geschrieben von zeckensack
Ein weiteres Projekt in Richtung Hochsprachencompiler ist Ashli (http://www.ati.com/developer/ashli.html), was aber auch nicht herstellerneutral ist (kommt von ATI). Nutzt die Renderman-Syntax.
Ja, die ashli-Demos sind teilweise schon interessant. Merkwürdig nur, daß alle völlig Neutralen hier im Forum da noch nicht aufgeschrien haben, ATi wolle sich den Markt unter den Nagel reissen und die weitere Entwicklung proprietär gestalten.
Ach ja, ganz vergessen: nV hat ja angefangen.
;) ;) ;)
(^^ Smileys beachten!!)
Radeonator@work
2003-10-02, 09:29:31
An diese Form der "Neutralität" gewöhnt man sich... ;)
zeckensack
2003-10-02, 12:17:35
Original geschrieben von q@w
Ja, die ashli-Demos sind teilweise schon interessant. Merkwürdig nur, daß alle völlig Neutralen hier im Forum da noch nicht aufgeschrien haben, ATi wolle sich den Markt unter den Nagel reissen und die weitere Entwicklung proprietär gestalten.
Ach ja, ganz vergessen: nV hat ja angefangen.
;) ;) ;)
(^^ Smileys beachten!!) Schon recht :)
Ashli wurde IMO hier im Forum nicht so aufgegriffen wie Cg.
Wenn du die Kollegen Richthofen und Razor konsultierst, sollte Cg angeblich
a)NVIDIA zu einer stärkeren Marktstellung, dank ISV-Bindung verhelfen
b)Performance auf NV-Karten verbessern, mithin "vergleichbar" machen
Ashli ist ein wenig anders gelagert. Es konkurriert nicht direkt mit dem HLSL-Compiler von MS (ganz andere Syntax). Das interessante an Ashli ist das Multipass-Splitting, ansonsten gilt das gleiche wie für Cg: es ist schlicht nicht notwendig, um Shadercode zu erzeugen. Es vereinfacht lediglich die Arbeit für die Leute, die keinen Plan von/keine Lust auf Shader-ASM haben.
Der Mangel an Kontroversen bzgl Ashli sollte IMO Beweis genug dafür sein, daß es nicht aggresiv vermarktet und mit allzu blumigen Versprechen verknüpft wurde :)
Original geschrieben von zeckensack
Wenn du die Kollegen Richthofen und Razor konsultierst, sollte Cg angeblich
a)NVIDIA zu einer stärkeren Marktstellung, dank ISV-Bindung verhelfen
b)Performance auf NV-Karten verbessern, mithin "vergleichbar" machen
Wus ?
ad a) :
Das mit der Marktstellung mag sein... allerdings nur dadurch, dass früher 'schöne Effekte' mit DX8/9 geproggt werden, es den Entwicklern hier also einfacher gemacht wird
ad b) :
Wie soll "Performance verbessert" werden, wenn es überhaupt kein Alternativ-Produkt zu Cg gab ? Ich glaube kaum, dass Cg als Konkurrenz-Produkt zu HSLS gedacht war, zumal damals davon ja überhaupt nichts zu sehen war. Auch ist Cg auch noch OpenSource und kann von jedem so genutzt werden, wie er beliebt (von dem für andere IHV's 'eh nutzlosen Backend mal abgesehen ;-).
Also irgendwie...
Razor
DrumDub
2003-10-02, 14:45:17
Original geschrieben von r@w
Auch ist Cg auch noch OpenSource und kann von jedem so genutzt werden, wie er beliebt (von dem für andere IHV's 'eh nutzlosen Backend mal abgesehen ;-).
glide ist auch opensource... ;)
Original geschrieben von DrumDub
glide ist auch opensource... ;)
Und ?
Was soll jetzt bitte das eine mit dem anderen zu tun haben ?
???
Razor
DrumDub
2003-10-02, 15:05:04
Original geschrieben von r@w
Und ?
Was soll jetzt bitte das eine mit dem anderen zu tun haben ?
???
Razor
es soll zeigen, das opensource von einem hersteller nicht funktioniert.
wenn dann müssen sich schon alle zusammensetzen und sich auf einen standard einigen.
LovesuckZ
2003-10-02, 15:06:21
Original geschrieben von DrumDub
glide ist auch opensource... ;)
aber erst, als es nicht mehr "funktionierte"?...
Original geschrieben von zeckensack
Der Mangel an Kontroversen bzgl Ashli sollte IMO Beweis genug dafür sein, daß es nicht aggresiv vermarktet und mit allzu blumigen Versprechen verknüpft wurde :)
Scho' recht =)
Man könnte es aber auch anders auffassen. ;)
Nunja,
Wie lange gibt es ashli eigentlich schon? Erst zu Zeiten der R9800 oder schon vorher? Ich weiß es ehrlich gesagt nicht mehr so genau.
'Multipass-Splitting' hört sich ja fast wie eine F-Buffer-Emulation an... :naughty:
Mich würde nach wie vor brennend interessieren, ob der F-Buffer 'CPU-assisted' läuft (um mal die Formulierung aus dem Bezug von TruForm zu gebrauchen), oder ob es wirklich ein echtes HW-Feature ist.
Performance-Seitig dürfte da kein allzugroßer Unterschied sein, denke ich, wenn man die Komplexität der Shader bedenkt, für die der F-Buffer erst notwendig wäre.
Nichtsdestotrotz liessen sich hier sicherlich auch künstlich Shader generieren, die einen meßbaren Unterschied zwischen 'on-Chip' Berechnung und einem 'Umweg' aufzeigten.
Bevor hier wieder jemand ankommt und konkrete Beispiele haben will: Man beachte den Konjunktiv!
DrumDub
2003-10-02, 17:17:54
Original geschrieben von LovesuckZ
aber erst, als es nicht mehr "funktionierte"?...
richtig, aber es war eben auch ne properitäre lösung eines ihvs. und da hilft opensorce auch nicht mehr ums populär zu machen. nur wenn man nen quasi-monopol wie m$ hat, siehts anders aus...
LovesuckZ
2003-10-02, 17:19:24
Original geschrieben von DrumDub
richtig, aber es war eben auch ne properitäre lösung eines ihvs.
Cg ist aber keine "properitäre lösung". Denn der erzeugte Shader lief auch auf anderen DX9 faehigen Karten. Der Vergleich mit Glide ist also völlig deplaziert.
DrumDub
2003-10-02, 17:34:43
Original geschrieben von LovesuckZ
Cg ist aber keine "properitäre lösung". Denn der erzeugte Shader lief auch auf anderen DX9 faehigen Karten. Der Vergleich mit Glide ist also völlig deplaziert.
theoretisch ja, wie es in der praxis hingegen aussieht, weiß bisher noch keiner. der compiler selbst ist ja opensource, aber die frage ist doch, ob der erzeugte code auf anderen als nv-karten "optimal" ist. andererseits hat ja zecki schon in einem thread drauf hingewiesen, dass der cg-compiler sehr ineffizient ist, was den erzeugten code betrifft...
wenn man auf die cg-shadres-site geht, stellt man auch fest, dass sich schon länger keiner mehr die mühe gemacht hat neue besipeiel zu veröffentlichen:
http://www.cgshaders.org/shaders/
also scheint hier doch ein problem in der vermittlung des nutzens von cg seitens nvidia vorhanden zu sein.
glide ist da sicherlich extremer gewesen, da vollständig properitär, aber es gab damals ja auch noch keinen quasi-standard wie directx. opengl als herstellerunabhängiges api hat 3dfx ja auch arge probelme bereitet und nicht unwesentlich zum aufstieg von nv beigetragen...
Crushinator
2003-10-02, 17:50:51
Original geschrieben von LovesuckZ
Cg ist aber keine "properitäre lösung". Denn der erzeugte Shader lief auch auf anderen DX9 faehigen Karten. Der Vergleich mit Glide ist also völlig deplaziert. Man bezeichnet so ziemlich alles mit "properitär" wenn es effektiv nur von einem Hersteller unterstützt wird bzw. nur auf einer Plattform (Hardware oder Software) des jeweiligen Herstellers läuft. Solange CG nicht von mindestens einem anderen Vendor lizensiert und benutzt wird, bleibt es properitär. Es ist auch jetzt egal, ob nun nV oder sonst wer an dieser Tatsache Schuld sind, denn das ist numal für einen Hardwarehersteller nicht so einfach eine Software zum Standard zu erklären und dann noch zu erwarten, daß die Konkurrenz darauf einspringt. Besonders schwierig ist es übrigens, wenn der Hardwarehersteller schon ziemlich mächtig ist. JAVA hat sich z.B. nur deshalb so erfolgreich behauptet, weil es weder von Microsoft noch von IBM kam, sondern von einem relativ kleinen Vendor.
LovesuckZ
2003-10-02, 17:52:54
Original geschrieben von DrumDub
theoretisch ja, wie es in der praxis hingegen aussieht, weiß bisher noch keiner. [...] aber die frage ist doch, ob der erzeugte code auf anderen als nv-karten "optimal" ist.
Ob er für andere Karten optimal oder nicht optimal sei, steht nicht zur Debatte. Denn das/der erste Compiler - Profil im HLSL war für Nvidia Karten auch nicht optimal, da redet aber keiner, dass HLSL eine "properitäre lösung" waere.
Tomb Raider 6 zeigt, dass die Shader auch auf ATi karten laufen, eben langsamer.
andererseits hat ja zecki schojn in einem thread drauf hingewiesen, dass der cg-compiler sehr ineffizient ist, was den erzuegten code betrifft...
Nicht ausweichen :)
Razor
2003-10-03, 03:39:25
Original geschrieben von DrumDub
es soll zeigen, das opensource von einem hersteller nicht funktioniert.
wenn dann müssen sich schon alle zusammensetzen und sich auf einen standard einigen.
Was hat bitte hat 'OpenSource' mit 'Standard' zu tun ?
'OpenSource' bedeutet lediglich, dass der Sourece-Code für jeden einseh- und veränderbar ist.
Man spielt also mit offenen Karten.
'Standard' ist so etwas wie die ARB von OpenGL.
Und da setzen sich viele (nicht alle ;-) zusammen und 'einigen' sich auf irgendwas.
Offensichtlich bringst Du da irgendetwas durcheinander...
Razor
Razor
2003-10-03, 03:50:06
Original geschrieben von DrumDub
theoretisch ja, wie es in der praxis hingegen aussieht, weiß bisher noch keiner. der compiler selbst ist ja opensource, aber die frage ist doch, ob der erzeugte code auf anderen als nv-karten "optimal" ist. andererseits hat ja zecki schon in einem thread drauf hingewiesen, dass der cg-compiler sehr ineffizient ist, was den erzeugten code betrifft...
Noch einmal:
- Cg war vor HLSL da !
- der mit Cg erzeugte Maschinen-Code ist auch auf fremder Hardware lauffähig
- jedem IHV steht es frei, eigene Compiler zu bauen (da OpenSource)
- Cg-Shader-SourceCode kann 1:1 vom M$-Compiler compiliert werden
Wo ist also Dein Problem ?
Ich kann unter Cg entwickeln und das Zeug nehmen und es durch den M$-Compiler jagen, um es dann auf ATI-Hardware zu compilieren (zu 'optimieren' ;-).
Und wenn ich (als IHV ;-) Cg als Universal-Tool nutzen möchte, braucht's eben einen eigenen Compiler, der von der Entwicklungsumgebung unterstützt wird, muss ihn also selber bauen (das sog. Backend). Und das ist auch kein Problem, weil's ja weder Lizenzgebühren kostet, noch extern entwickelt werden muss, da ich ja frei an die Sourcen für Cg komme...
Im Prinzip eigentlich eine hübsche Angelegenheit, vor allem wenn man bedenkt, dass es damals noch kein HLSL von M$ gab und auch sonst nix in der Richtung verfügbar war.
- jeder kann machen, was er will.
- jede Hardware kann individuell unterstützt werden.
Was also soll dieser völlig an den Haaren herbei gezogene Vergleich zu GLIDE ?
???
Razor
Razor
2003-10-03, 03:57:06
Original geschrieben von crushinator
Man bezeichnet so ziemlich alles mit "properitär" wenn es effektiv nur von einem Hersteller unterstützt wird bzw. nur auf einer Plattform (Hardware oder Software) des jeweiligen Herstellers läuft.
Trifft beides nicht auf Cg zu...
Original geschrieben von crushinator
Solange CG nicht von mindestens einem anderen Vendor lizensiert und benutzt wird, bleibt es properitär.
Es braucht nicht lizensiert werden.
Du gehst auf die Seite und lädst es Dir herunter.
Und Du darfst es sogar ganz legal für Deine Zwecke benutzen...
Was bitte ist daran 'proprietär' ?
(was im übrigen die richtige Schreibweise hierfür ist ;-)
Zu dem Rest sag' ich lieber nichts...
Nur eine Frage noch: Wo bitte hat nVidia CG "zum Standard" erklärt ?
???
Razor
zeckensack
2003-10-03, 14:05:48
Original geschrieben von r@w
Wus ?a) war auf Richthofen gemünzt, b) auf die Erwartungshaltung bzgl Cg bei zB Tomb Raider: AoD (letztere ist ja dann geplatzt; der MS-Compiler ist für ATI und NV die bessere Wahl, in diesem Spiel).
Suchfunktion ahoi :(
zeckensack
2003-10-03, 14:12:42
Original geschrieben von Razor
Noch einmal:
- Cg war vor HLSL da !
- der mit Cg erzeugte Maschinen-Code ist auch auf fremder Hardware lauffähig
- jedem IHV steht es frei, eigene Compiler zu bauen (da OpenSource)
- Cg-Shader-SourceCode kann 1:1 vom M$-Compiler compiliert werden
Wo ist also Dein Problem ?
Ich kann unter Cg entwickeln und das Zeug nehmen und es durch den M$-Compiler jagen, um es dann auf ATI-Hardware zu compilieren (zu 'optimieren' ;-).
Und wenn ich (als IHV ;-) Cg als Universal-Tool nutzen möchte, braucht's eben einen eigenen Compiler, der von der Entwicklungsumgebung unterstützt wird, muss ihn also selber bauen (das sog. Backend). Und das ist auch kein Problem, weil's ja weder Lizenzgebühren kostet, noch extern entwickelt werden muss, da ich ja frei an die Sourcen für Cg komme...
Im Prinzip eigentlich eine hübsche Angelegenheit, vor allem wenn man bedenkt, dass es damals noch kein HLSL von M$ gab und auch sonst nix in der Richtung verfügbar war.
- jeder kann machen, was er will.
- jede Hardware kann individuell unterstützt werden.
Was also soll dieser völlig an den Haaren herbei gezogene Vergleich zu GLIDE ?
???
Razor Ack.
Cg ist ein Toolkit (http://www.nvidia.com/view.asp?IO=cg), das auf Standard-APIs aufgelegt werden kann, und ohne diese überhaupt nicht funktionieren würde.
Glide ist ... naja, eine API, die noch dazu eigentlich nur auf 3dfx-Hardware richtig implementierbar ist. Es lag nie im Interesse der 'anderen' IHVs, Glide zu unterstützen, einfach weil's überhaupt nicht zu halbwegs normaler Hardware paßt.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.