Archiv verlassen und diese Seite im Standarddesign anzeigen : Software-Rendering
Kürzlich überlegte ich, ob in 3D-Demos die Nutzung einer 3D-Karte nicht eigentlich "cheaten" ist. Wer was als Coder auf sich hält, sollte eigentlich alles selbst machen wollen – also auch den Renderer selbst schreiben. Nun wurde kürzlich ich hierauf aufmerksam gemacht: http://www.golem.de/0510/41136.html. Da gibts einen Renderer, der zwar nicht den Umfang vom Refrast bietet, aber dafür Echtzeitperformance.
Und Max Payne läuft damit tatsächlich. Klar, in 640x480 bei lausiger Framerate, ohne AA und AF. Aber es läuft. Würde man nun ein Projekt gleich von vornherein auf Software-Rendering auslegen, wäre es sicher noch schneller.
Was kann man damit nun machen? Erstens könnte man APIs für Hardware, die es nicht mehr gibt, in Software nachbilden – so dass im Emulator alte Anwendungen weiterhin laufen. Man könnte auch auf die Idee kommen, gerade im anbrechenden Zeitalter von Dual-CPUs, Spiele ohne 3D-Karte laufen zu lassen. Ich bin ja seit einiger Zeit der Meinung, dass der PC als Spiele-Plattform denkbar ungeeignet ist – mehr dazu vielleicht bald in einer Kolumne.
DrumDub
2005-10-21, 13:32:08
der link geht net...
tombman
2005-10-21, 13:32:53
die Seite gibts nimmer
Doch, es fehlte nur ein Buchstabe.
micki
2005-10-21, 14:03:33
wenn man eh eine 3d-karte im rechner hat, weil es nichts anderes aktuelles gibt (oder kennt jemand eine nicht-3d-karte?) und wenn selbst ne GeForce256 jeden softwarerasterizer schlägt, wieso sollte man dann die rechenpower der cpu fürs softwarerasterizing verschwenden?
deswegen macht man das bei demos auch mit der graka, es geht bei demos schliesslich darum das best möglichste rauszukitzeln und nicht darum alles auf der cpu zu machen, selbst auf dem c64 hat man hardwarekomponenten zweckentfremdet um mehr leistung rauszubekommen.
heutzutage gibt es nur sehr sehr wenige anwendungen für SR, der hauptgrund dass man das macht dürfte wohl lern-/spasseffekt sein oder primitive hardware (handy/gameboy usw), auf dualcore kann man auch fix mal occlusionculling durchführen, aber bestimmt nicht als normalen renderer. und falls man ein anderes api emulieren möchte, dann emuliert man das api indem man das nötigste auf ein neues api übersetzt.
es wäre schon sinnvoller auf multicore cpus raytracing durchzuführen, aber eher werden GPUs flexibel genug um das zu machen als dass cpus schnell genug bzw in ausreichender coreanzahl auftauchen.
cpus sind halt nur datenpusher und notbehelfs. :D
MfG
micki
Wow, das klingt echt interessant. Da werden sich einige Leutchen mit Pixel-Shader-losen Karten freuen.
Was kann man damit nun machen? Erstens könnte man APIs für Hardware, die es nicht mehr gibt, in Software nachbilden – so dass im Emulator alte Anwendungen weiterhin laufen.
Denkst Du da gerade auch an 3dfx' Glide-API? Oder S3s MeTal. Das wäre was, jo. Wobei es zumindest für ersteres ja schon nette Emulatoren gibt.
MfG,
Raff
Demirug
2005-10-21, 14:17:10
Zum Thema PCs als Spiele Maschine verweise ich mal auf diesen Thread: http://www.forum-3dcenter.de/vbulletin/showthread.php?t=253751
aths, das ganze ging aus dem ehemaligen Open Source Projekt swShader hervor. Das es im Vergleich zum Refrast schneller ist muß nun wirklich nicht verwundern weil dieser nie als Ersatz für eine echte Grafikkarte Gedacht war. Den letzten echten Softwarerenderer von Microsoft gab es für DX6.1 oder DX7. Ich behaupte jetzt mal frech das man DX9 aber noch schneller hinbekommt.
Desweiteren gibt es schon länger einen DX kompatiblen Software Renderer: http://www.radgametools.com/pixomain.htm. Unterstützt allerdings keine Shader.
Für einen IM Renderer sind Dualcores nicht gerade Ideal weil die Batchgrößen in der tendenziel zu klein sind. Ein DR könnte da schon besser funktionieren.
micki, APIs emulieren kann echt übel sein. DX6/DX7 auf DX9 biegen macht keinen Spass. Ansonsten stimme ich dir aber zu das sich GPUs wohl zu mächtigen Coprozessoren weiterentwickeln werden die vielleicht auch irgendwann mit in die CPU wandern.
wenn man eh eine 3d-karte im rechner hat, weil es nichts anderes aktuelles gibt (oder kennt jemand eine nicht-3d-karte?) und wenn selbst ne GeForce256 jeden softwarerasterizer schlägt, wieso sollte man dann die rechenpower der cpu fürs softwarerasterizing verschwenden?
deswegen macht man das bei demos auch mit der graka, es geht bei demos schliesslich darum das best möglichste rauszukitzeln und nicht darum alles auf der cpu zu machen, selbst auf dem c64 hat man hardwarekomponenten zweckentfremdet um mehr leistung rauszubekommen.3D-Grafikkarten können Dreiecke füllen, und das sehr schnell. Ein anspruchsvoller 3D-Coder will vielleicht mehr. Bevor jemand "Pixelshader!" ruft, der Shader hat keinen freien Zugriff auf den Speicher.
Demirug
2005-10-21, 14:22:48
3D-Grafikkarten können Dreiecke füllen, und das sehr schnell. Ein anspruchsvoller 3D-Coder will vielleicht mehr. Bevor jemand "Pixelshader!" ruft, der Shader hat keinen freien Zugriff auf den Speicher.
Noch nicht...
Demirug,
mein Ansatz ist, dass der PC als System mit auswechselbaren Komponenten per se schlecht für fehlerfreie und performante Programmierung geeignet ist, und dass für den PC keine befriedende Massenspeicher-Lösung gefunden wurde, von der man "on the fly" spielen kann. Dieser Zwang zur Installation eines Spiels ist für mich ein Spaßkiller. Der PC hat als Pluspunkt lediglich vorzuweisen, dass er weit verbreitet ist, und man keine Extra-Anschaffung machen muss. Es sei denn, man möchte aktuelle 3D-Spiele in voller Qualität spielen. Aber es gibt ja keine Grafikkarte, die alles sehr gut kann.
Bei Spielen hängt der Entwickler an dem, was die Zielhardware kann. Die CPU kann vereinfacht gesagt alles, nur eben nicht so schnell. Trotzdem bleibt für mich die Frage, ob es immer 3D-Beschleunigung sein muss. Eine einfache 3D-Umgebungen kann auch mit der (ohnehin meist sehr starken) CPU erzeugt werden. Ob nun mit Rendering à la SGI oder Raycasting. Klar kann ein Software-Renderer aktuelle 3D-Hardware nicht ersetzen, aber er könnte neue Gebiete erschließen, und Effekte möglich machen, die uns 3D-Karten heute noch verwehren. Aber das beste: Der SW-Renderer läuft immer, egal ob eine Radeon, GeForce oder Volari eingebaut ist.
zeckensack w/o cauquille
2005-10-21, 14:33:04
Kürzlich überlegte ich, ob in 3D-Demos die Nutzung einer 3D-Karte nicht eigentlich "cheaten" ist. Wer was als Coder auf sich hält, sollte eigentlich alles selbst machen wollen – also auch den Renderer selbst schreiben.Da ist die Frage zu welchem Zweck diese Demos denn dienen sollen.
Bei eigentlich allen Arbeiten zu (Echtzeit-)Renderingtechniken liegt ein ganz klarer Schwerpunkt auf der Implementierbarkeit auf der entsprechenden Hardware. Ein Software-Renderer ist nicht nur viel Arbeit, und auch noch langsam, sondern er nützt rein garnichts wenn man demonstrieren will dass Tolle Neue Schattentechnik XY mit verfügbaren Grafikkarten harmoniert, und somit in alle möglichen Echtzeitengines integrierbar ist.
Forschung im Grafikbereich ohne Hardwarebeschleunigung wirst du nur für Offline-Renderer überhaupt verlangen können -- und selbst da erweisen sich neuere Grafikkarten schon als bedrohliche Konkurrenz zur puren Software.
Der selbe Gast
2005-10-21, 14:34:07
Ach fuck, es sollte natürlich "couquille" sein. Grmpf.
Ich behaupte jetzt mal frech das man DX9 aber noch schneller hinbekommt.Ich denke nicht. Ich "kenne" den Entwickler von swShader ein wenig von flipcode.
Er erzeugt aus den Pixel- und Vertexshadern direkt SSE-Code per runtime Assembler.
Demirug
2005-10-21, 14:49:09
Demirug,
mein Ansatz ist, dass der PC als System mit auswechselbaren Komponenten per se schlecht für fehlerfreie und performante Programmierung geeignet ist, und dass für den PC keine befriedende Massenspeicher-Lösung gefunden wurde, von der man "on the fly" spielen kann. Dieser Zwang zur Installation eines Spiels ist für mich ein Spaßkiller. Der PC hat als Pluspunkt lediglich vorzuweisen, dass er weit verbreitet ist, und man keine Extra-Anschaffung machen muss. Es sei denn, man möchte aktuelle 3D-Spiele in voller Qualität spielen. Aber es gibt ja keine Grafikkarte, die alles sehr gut kann.
Spezialisierte Systeme (Konsolen) sind universellen (PC) auf ihrem Gebiet immer überlegen. Trotzdem gibt es einen Markt für die Lösungen auf dem Universellen System. Es würden sich jedoch viele Probleme (z.B. Installation) durch entsprechenden Vorkehrungen lösen lassen. Ich kann da im Moment allerdings nicht ins Detail gehen.
Bei Spielen hängt der Entwickler an dem, was die Zielhardware kann. Die CPU kann vereinfacht gesagt alles, nur eben nicht so schnell. Trotzdem bleibt für mich die Frage, ob es immer 3D-Beschleunigung sein muss. Eine einfache 3D-Umgebungen kann auch mit der (ohnehin meist sehr starken) CPU erzeugt werden. Ob nun mit Rendering à la SGI oder Raycasting. Klar kann ein Software-Renderer aktuelle 3D-Hardware nicht ersetzen, aber er könnte neue Gebiete erschließen, und Effekte möglich machen, die uns 3D-Karten heute noch verwehren. Aber das beste: Der SW-Renderer läuft immer, egal ob eine Radeon, GeForce oder Volari eingebaut ist.
Das Problem wird sich mit Vista stark reduziert. Ich habe kein Problem mit einem Softwarerendere solange er sich an die gebräuchliche APIs hält. Aber selbst Tim Sweeney ist ja inzwischen von seiner „Die CPU wird wieder alles machen“ These abgerückt.
Demirug
2005-10-21, 14:51:02
Ich denke nicht. Ich "kenne" den Entwickler von swShader ein wenig von flipcode.
Er erzeugt aus den Pixel- und Vertexshadern direkt SSE-Code per runtime Assembler.
Ich kenne ihn auch und weiß wie es arbeitet. Trotzdem behauptet ich das es noch schneller geht.
Ich kenne ihn auch und weiß wie es arbeitet. Trotzdem behauptet ich das es noch schneller geht.Was für Ideen hättest du da noch?
Demirug
2005-10-21, 14:57:51
Was für Ideen hättest du da noch?
Einen DR anstelle eines IMs. Bei einer CPU sollte das einiges bringen. Zudem lässt sich das leichter SMP tauglich machen. Zudem könnte für PS bis 1.3 MMX durchaus schneller als SSE sein. Aber da ist zeckensack eher der Fachmann.
Würde DR ohne dedizierte Raycast-HW nicht ziemlich lahm sein?
Demirug
2005-10-21, 15:06:58
Würde DR ohne dedizierte Raycast-HW nicht ziemlich lahm sein?
Raycast? Komm mir jetzt nicht mir Kyro. Die arbeiten auch mit einem Z-Buffer HSR.
micki
2005-10-21, 15:34:48
Einen DR anstelle eines IMs. Bei einer CPU sollte das einiges bringen. Zudem lässt sich das leichter SMP tauglich machen. Zudem könnte für PS bis 1.3 MMX durchaus schneller als SSE sein. Aber da ist zeckensack eher der Fachmann.
bei meinen software rasterisern mußte ich feststellen, dass das langsammste der speicher ist. bei PS muss man zwar mehr rechnen, aber die rechenkosten sind in relation zu den kosten für das schaufeln der datenmenge die man bei DR hätte günstiger.
was bei mir sehr viel gebracht hat, war ein "hierarchischer" zbuffer bei dem ich zwei ebenen hatte ( eine hatte 8bit und 1/8 breite und die andere 16bit vollauflösung), weil damit die kleine ebene komplet in den cache passte. f2b war das ganze dann ca 8mal schneller., obwohl da natürlich viel mehr verwaltungsaufwand entstand. (z-only rasterizer fürs occlusionculling)
ich glaube mit mmx wäre es um einiges schwerer sowas wie rcp zu implementieren, aber er könnte natürlich erstmal nen mmxshader bauen und bei spezialfällen sse. der ganze aufwand für sowas ist dann aber noch höcher als so schon.
MfG
micki
Demirug
2005-10-21, 15:40:31
bei meinen software rasterisern mußte ich feststellen, dass das langsammste der speicher ist. bei PS muss man zwar mehr rechnen, aber die rechenkosten sind in relation zu den kosten für das schaufeln der datenmenge die man bei DR hätte günstiger.
was bei mir sehr viel gebracht hat, war ein "hierarchischer" zbuffer bei dem ich zwei ebenen hatte ( eine hatte 8bit und 1/8 breite und die andere 16bit vollauflösung), weil damit die kleine ebene komplet in den cache passte. f2b war das ganze dann ca 8mal schneller., obwohl da natürlich viel mehr verwaltungsaufwand entstand. (z-only rasterizer fürs occlusionculling)
PS verbrauchen durch die Texturezugriffe auch eine Menge Bandbreite. Zudem würde bei einem DR der Z-Buffer für eine Tile in den Cache der CPU passen. Man muss natürlich möglichst kompakt binnen. Man könnte sogar noch VS arbeit bei einem DR sparen.
ich glaube mit mmx wäre es um einiges schwerer sowas wie rcp zu implementieren, aber er könnte natürlich erstmal nen mmxshader bauen und bei spezialfällen sse. der ganze aufwand für sowas ist dann aber noch höcher als so schon.
MfG
micki
Ich schränkte das MMX ja schon auf die 1.X Pixelshader ein. Aber mehr kann das Teil im Moment ja sowieso nicht.
tombman
2005-10-21, 15:43:51
Aber selbst Tim Sweeney ist ja inzwischen von seiner „Die CPU wird wieder alles machen“ These abgerückt.
Naja, kommt drauf an was man als "cpu" definiert :)
Wenn cpus mal ein budget von mehreren Milliarden Transistoren haben, dann kann man ja massig spezialisierte "Bereiche" einbauen, so wie ne Art Zellhaufen die bestimmte Aufgaben erledigen ;)
micki
2005-10-21, 15:46:22
3D-Grafikkarten können Dreiecke füllen, und das sehr schnell. Ein anspruchsvoller 3D-Coder will vielleicht mehr. Bevor jemand "Pixelshader!" ruft, der Shader hat keinen freien Zugriff auf den Speicher.
ein anspruchsvoller coder will vorallem das beste rundum ergebnis. deswegen wird er eher möglichst viel die graphikkarte machen lassen.
zudem hat der pixelshader genug zugriff, mach einfach genug volumetextures auf mit 256^3 floats auf, dir geht eher die performance als der speicher aus wenn du darin rumsamplest.
ich weiß ja was du meinst, sowas wie "Outcast" war/wäre ja supergeil, aber die meisten dinge sind mit GPUs realisierbar und das was man sich extra wünschen würde wie z.b. diffusereflections, radiosity, usw. kann man einigermassen gut faken, approximieren und täuschen. die cpu kann man nun wirklich für bessere dinge nutzen. wenn ich 2cores als mindestanforderung nehmen dürfte, würd ich darauf allerlei dinge machen die die gpu unterstützen und effizienter machen, statt sie ersetzen zu wollen. dazu zählt optimierung von culling, besseres resourcemanagement (z.b. on-the-fly decompression von daten), optimierung von renderjobs-lists, input verarbeitung usw.
MfG
micki
MfG
micki
micki
2005-10-21, 15:59:04
PS verbrauchen durch die Texturezugriffe auch eine Menge Bandbreite. Zudem würde bei einem DR der Z-Buffer für eine Tile in den Cache der CPU passen. Man muss natürlich möglichst kompakt binnen. Man könnte sogar noch VS arbeit bei einem DR sparen.
die extra speicherzugriffe hättest du an anderer stelle, für jede texel das du dir zu lesen ersparst,schreibst du deren coordinaten in den DR-Framebuffer.
oder meinst du mit DR-renderer, dass ein vorheriger z-pass durchgegangen wird?
btw. tilebased lösungen würden wirklich schlecht performen, das ganze culing/clipping das du pro triangle durchführen müßtest würde ziemlich auf die performance drücken denk ich mir.
Ich schränkte das MMX ja schon auf die 1.X Pixelshader ein. Aber mehr kann das Teil im Moment ja sowieso nicht.
ps.1_1 hat rcp, ich glaube das geht mit mmx nicht so schnell.
MfG
micki
Raycast? Komm mir jetzt nicht mir Kyro. Die arbeiten auch mit einem Z-Buffer HSR.Jeder erzählt mir da was anderes. In den meisten Artikeln die ich darüber las steht zumindest was von Raycasting.
Raycast? Komm mir jetzt nicht mir Kyro. Die arbeiten auch mit einem Z-Buffer HSR.
Ermitteln den Z-Wert aber mit Ray/Plane-Intersection.
btw. tilebased lösungen würden wirklich schlecht performen, das ganze culing/clipping das du pro triangle durchführen müßtest würde ziemlich auf die performance drücken denk ich mir.
Welches Culling/Clipping meinst du?
Monger
2005-10-21, 16:51:51
Das Problem wird sich mit Vista stark reduziert. Ich habe kein Problem mit einem Softwarerendere solange er sich an die gebräuchliche APIs hält. Aber selbst Tim Sweeney ist ja inzwischen von seiner „Die CPU wird wieder alles machen“ These abgerückt.
Gabs da nicht mal so Bestrebungen, das Betriebssystem entscheiden zu lassen was wo wie gerechnet wird?
Das Betriebssystem würde sich logischerweise immer den besten Ort für die derzeitige Aufgabe raussuchen, aber aus Programmsicht würde es keinen Unterschied mehr machen ob jetzt etwas per Grafikkarte oder CPU berechnet wird.
Ich seh das so: solange sich im Bereich Grafik noch so viel bewegt, wird es auch keinen Platz für integrierte Lösungen geben. Die gesamte PC Architektur ist ja nur ein Kompromiss, weil es das perfekte System noch nicht gibt, und man deshalb relativ flexibel bleiben muss.
Und ich bin auch nicht sicher, ob wir jemals das voll integrierte System sehen werden. Dass die Grafik näher an die CPU rückt macht Sinn, aber ich sehe nicht, dass sich die Produktionsverfahren nennenswert verbessern würden. Und wesentlich größere DIEs sind einfach unbezahlbar.
Ne ne, das ist schon richtig wie es derzeit ist.
Demirug
2005-10-21, 16:53:46
die extra speicherzugriffe hättest du an anderer stelle, für jede texel das du dir zu lesen ersparst,schreibst du deren coordinaten in den DR-Framebuffer.
oder meinst du mit DR-renderer, dass ein vorheriger z-pass durchgegangen wird?
Nein ich meine schon das Kyro Konzept.
btw. tilebased lösungen würden wirklich schlecht performen, das ganze culing/clipping das du pro triangle durchführen müßtest würde ziemlich auf die performance drücken denk ich mir.
Was hat das mt Tilebase zu tun? Culen muss ich so oder so.
ps.1_1 hat rcp, ich glaube das geht mit mmx nicht so schnell.
MfG
micki
Im Textureteil. Den macht man besser sowieso mit FlotingPoint.
Demirug
2005-10-21, 16:54:58
Ermitteln den Z-Wert aber mit Ray/Plane-Intersection.
Das wäre doch viel zu umständlich.
Demirug
2005-10-21, 16:57:11
Gabs da nicht mal so Bestrebungen, das Betriebssystem entscheiden zu lassen was wo wie gerechnet wird?
Das Betriebssystem würde sich logischerweise immer den besten Ort für die derzeitige Aufgabe raussuchen, aber aus Programmsicht würde es keinen Unterschied mehr machen ob jetzt etwas per Grafikkarte oder CPU berechnet wird.
Das war mal bei DirectDraw so. Bei Direct3D macht das nicht mehr so viel Sinn.
Ich seh das so: solange sich im Bereich Grafik noch so viel bewegt, wird es auch keinen Platz für integrierte Lösungen geben. Die gesamte PC Architektur ist ja nur ein Kompromiss, weil es das perfekte System noch nicht gibt, und man deshalb relativ flexibel bleiben muss.
Und ich bin auch nicht sicher, ob wir jemals das voll integrierte System sehen werden. Dass die Grafik näher an die CPU rückt macht Sinn, aber ich sehe nicht, dass sich die Produktionsverfahren nennenswert verbessern würden. Und wesentlich größere DIEs sind einfach unbezahlbar.
Ne ne, das ist schon richtig wie es derzeit ist.
Ich sehe das vorallem im Bereich der günstigen Desktop Systeme. Ich kann mir hier durchaus voratellen das der ganze Chipsatz und die GPU zusammen mit der CPU in einen Chip wandern.
Shink
2005-10-21, 17:16:19
Naja, das hatten wir ja schon mal. Cyrix hat darauf gesetzt, was wohl (neben der Übernahme) ihr Untergang war. Die hatten fürs vorige Millenium sogar einen Prozessor mit eingebautem 3D-Core in der Roadmap stehen.
Ich frag mich eh, wie die Performance vom MediaGX für damalige Verhältnisse war (kein Cache, aber Speichercontroller auf der CPU, Grafik- und Soundlogik auf der CPU...)
zeckensack
2005-10-21, 18:51:33
Zudem könnte für PS bis 1.3 MMX durchaus schneller als SSE sein.Wäre eine interessante Studie, aber ich glaube nicht wirklich dass MMX schneller sein kann.
Hauptproblem ist die Multiplikation. Bei MMX kann man zwar vier 16Bit-Integer parallel multiplizieren, aber man muss dann zwangsläufig immer einen Bitshift draufsetzen um das Ergebnis wieder in das gewünschte Format zu bringen. Bei FP32 braucht man das nicht. Und für Shader ist Multiplikation einfach unendlich wichtig.
MMX hat allerdings Vorteile beim Durchsatz (vier Komponenten pro Takt vs zwei bei aktuellen SSE-Implementationen bei ~gleichen Ausführungslatenzen), ebenso wie Integer-Formate den eindeutigen Bandbreitenvorteil haben. Ich glaube nur nicht dass das ausreicht um am Ende schneller zu sein.
Ich bin aber trotzdem überzeugt dass es noch besser geht. Softwire nutzen alleine bringt noch keinen performanten Code, geschweige denn ein flexibel einsetzbares System. Dafür braucht man noch so viel mehr ...
Wenn ich mit meinem Krempel hier endlich mal aus dem Urschleim komme, werde ich's diesen Kaulquappen aber ganz gewaltig zeigen =)
Hoffe ich.
zeckensack
2005-10-21, 18:55:41
Was hat das mt Tilebase zu tun? Culen muss ich so oder so.Er wird wohl Clipping meinen, immer schön alle Dreiecke gegen die Tile-Umrisse clippen wäre wohl sehr teuer. Ich glaube allerdings nicht dass das Clippen konvexer Polygone noch wirklich Stand der Technik ist.
Ich meine mich zu erinnern dass Simon Fenney irgendwann auf B3D mal schrieb dass Kyro mit Guardbands arbeitet, nie geometrisch clippt und stattdessen die Geometrie einfach nur (an seeehr weit außerhalb des Bildes liegenden Grenzen) clampt.
Das wäre doch viel zu umständlich.Soweit ich weiß ist das aber wirklich so.
Übrigens bin ich mir nichtmal so sicher, das Nick kein MMX für PS1.x benützt.
Ich bin aber trotzdem überzeugt dass es noch besser geht. Softwire nutzen alleine bringt noch keinen performanten Code, geschweige denn ein flexibel einsetzbares System. Dafür braucht man noch so viel mehr ...Dynamische Registerallokation etc. ist alles drin. Nick weiß was er macht, da bin ich überzeugt.
ein anspruchsvoller coder will vorallem das beste rundum ergebnis. deswegen wird er eher möglichst viel die graphikkarte machen lassen.
zudem hat der pixelshader genug zugriff, mach einfach genug volumetextures auf mit 256^3 floats auf, dir geht eher die performance als der speicher aus wenn du darin rumsamplest.Ein anspruchsvoller Coder will zeigen was er kann.
ich weiß ja was du meinst, sowas wie "Outcast" war/wäre ja supergeil, aber die meisten dinge sind mit GPUs realisierbar und das was man sich extra wünschen würde wie z.b. diffusereflections, radiosity, usw. kann man einigermassen gut faken, approximieren und täuschen. die cpu kann man nun wirklich für bessere dinge nutzen.Speziell an Outcast hatte ich gar nicht gedacht, obwohl das natürlich ein gutes Beispiel ist.
Mir gehts nicht nur darum, dem Fotorealismus nahezukommen. Dann führt kein Weg an dedizierter 3D-Beschleunigung vorbei. Ich bin auch ausdrücklich nicht dafür, generell alles die CPU machen zu lassen, obwohl ich mir durchaus vorstellen kann, dass (wie Demirug schon sagte) die CPU mit Chipsatz und GPU für preiswerte Rechner dereinst in einem einzelnen Chip daherkommen könnten. Wenn ein integrierter Grafikchipsatz endlich eine vernünftige Speicheranbindung bekommt, kann er viel übliche 3D-Grafik sehr, sehr viel schneller erzeugten als ein noch so performance-optimierter Softwarerenderer. Selbst die verkrüppelten integrierten Chipsätze dürften noch ein bis zwei Größenordnungen schneller sein.
Nun das "Aber". Sowohl das originale Unreal als auch die aktuelle UT-Version bietet auch Software-Rendering. Warum nicht? Quake2 bietet im Software-Modus sogar zusätzliche Effekte, zum Beispiel eine Bildverzerrung wenn man unter Wasser ist. Dies könnte man heute auch mit 3D-Karten machen. Aber wenn man das generalisiert: 3D-Karten können nur das, wofür sie gedacht sind. Mit Software-Rendering ist man weniger eingeschränkt. Gerade bei Grafikdemos sehe ich Beschränkungen. Eine tolle Demo die spezielle Features nutzt mit läuft dann nur auf wenigen Karten. Der Coder muss sonst unterschiedliche Pfade implementieren, und hat weniger Ressourcen, seine Ideen umzusetzen.
Heute gibts immer noch Grafikchipsätze, die keinen DirectX9-Support bieten, zum Beispiel in bestimmten Laptops. Warum nicht Direct3D per Software rendern? (In OpenGL ist das soweit ich weiß von Anfang auch als Option vorgesehen worden.) Damit das performant genug ist, darf natürlich nicht jedes Feature in diesem Modus genutzt werden, die Minimalsettings (bzw. speziellen SW-Rendering-Settings) müssten das berücksichtigen. Dann aber läuft jene 3D-Applikation auch überall (jedenfalls überall, wo auch Windows läuft.)
Würde es so sein, dass bestimmte 3D-Funktionalität mit einer bestimmten Mindestperformance in jedem PC vorhanden wäre, würde die Sache etwas anders aussehen. Ich wäre ohnehin dafür, der CPU spezielle Rechenwerke zu spendieren die speziell für Streamdaten-Verarbeitung mit 4D-Vektoren ausgelegt sind.
Demirug
2005-10-21, 19:22:17
Wenn ich mit meinem Krempel hier endlich mal aus dem Urschleim komme, werde ich's diesen Kaulquappen aber ganz gewaltig zeigen =)
Hoffe ich.
Wenn du dich wirklich auf die böse Geschäft der D3D Emulation einlassen willst kann ich dir noch ein paar Tips bezüglich des "korrekten" Verhaltens des Referenzcountings geben. Das ist stellenweise merkwürdig.
Demirug
2005-10-21, 19:25:42
Er wird wohl Clipping meinen, immer schön alle Dreiecke gegen die Tile-Umrisse clippen wäre wohl sehr teuer. Ich glaube allerdings nicht dass das Clippen konvexer Polygone noch wirklich Stand der Technik ist.
Ich meine mich zu erinnern dass Simon Fenney irgendwann auf B3D mal schrieb dass Kyro mit Guardbands arbeitet, nie geometrisch clippt und stattdessen die Geometrie einfach nur (an seeehr weit außerhalb des Bildes liegenden Grenzen) clampt.
ATI könnte aufgrund des engen Guardbands noch Clippen. Aber selbst wenn clippt man auch beim Tilebase maximal am Guardbandrand.
Demirug
2005-10-21, 19:32:58
aths, bei D3D war am Anfang auch Softwarerendering vorhanden. Das wurde dann aber entfernt bzw nicht mehr gepflegt weil der Leistungsunterschied zwischen CPU und GPU einfach zu groß wurde. Es gibt sogar heute noch bei D3D9 eine Schnittstelle um einen Softwarerender einzubinden. Allerdings wurde das nie dokumentiert. Funktionieren muss es aber weil der Refrast über die Schnittstelle arbeitet.
Ja, Final Reality im Software-Modus ist kriechend lahm.
Dass man Max Payne mit Abstrichen heute aber per SW-Rendering spielen könnte, erstaunt dann doch. Spezielle SW-Renderer für spezielle Einsätze könnten eben schon Dinge realisieren, die die 3D-Graka heute noch nicht anbietet. In einem "Haus-SW-Renderer" à la Unreal-Engine könnte der Entwickler schon mal Dinge einfügen, für die es noch keine Hardware gibt.
Mir geistert schon länger im Kopf herum, dass die Entwicklung von SW-Renderengines scheinbar aufgegeben wurde – warum eigentlich? Tomb Raider 3 oder 4 (weiß ich nicht mehr genau) bot z. B. auch noch einen SW-Modus, der gar nicht mal so schlecht aussah. Hätte man die Schiene des SW-Renderings weiter verfolgt, wäre man heute sicherlich schon weiter, und CPUs vielleicht etwas besser dafür geeignet. Natürlich würden sie nie und nimmer die 3D-Leistung von GPUs bringen, aber das ist ja auch nicht das Ziel.
Demirug
2005-10-21, 20:04:53
Dass man Max Payne mit Abstrichen heute aber per SW-Rendering spielen könnte, erstaunt dann doch. Spezielle SW-Renderer für spezielle Einsätze könnten eben schon Dinge realisieren, die die 3D-Graka heute noch nicht anbietet. In einem "Haus-SW-Renderer" à la Unreal-Engine könnte der Entwickler schon mal Dinge einfügen, für die es noch keine Hardware gibt.
Du weißt aber das Epic sich eine DX kompatible SW Renderengine für das aktuelle UT eingekauft hat? Da ist keine Eigenentwicklung.
Mir geistert schon länger im Kopf herum, dass die Entwicklung von SW-Renderengines scheinbar aufgegeben wurde – warum eigentlich? Tomb Raider 3 oder 4 (weiß ich nicht mehr genau) bot z. B. auch noch einen SW-Modus, der gar nicht mal so schlecht aussah. Hätte man die Schiene des SW-Renderings weiter verfolgt, wäre man heute sicherlich schon weiter, und CPUs vielleicht etwas besser dafür geeignet. Natürlich würden sie nie und nimmer die 3D-Leistung von GPUs bringen, aber das ist ja auch nicht das Ziel.
Es hat sich wie gesagt nicht mehr gelohnt. Es war einfacher Fallbacks für schwache Grafikkarten einzubauen. Um es interesant zu halten hätte MS eine anbieten müssen.
Ein anspruchsvoller Coder will zeigen was er kann.Und das mit möglichst geringem Aufwand. Das wirst du schon noch irgendwann begreifen ;)
micki
2005-10-21, 20:19:39
Er wird wohl Clipping meinen, immer schön alle Dreiecke gegen die Tile-Umrisse clippen wäre wohl sehr teuer. Ich glaube allerdings nicht dass das Clippen konvexer Polygone noch wirklich Stand der Technik ist.
Ich meine mich zu erinnern dass Simon Fenney irgendwann auf B3D mal schrieb dass Kyro mit Guardbands arbeitet, nie geometrisch clippt und stattdessen die Geometrie einfach nur (an seeehr weit außerhalb des Bildes liegenden Grenzen) clampt.
ich hatte culling/clipping geschrieben, da man ja vermutlich nur wenige triangles pro tile clipping müßte und die meisten verwerfen/cullen würde. guardbands sind zwar nett, das aber auch nur mit dafür dedizierter hardware, für einen software rasterizer wäre das vermutlich noch unperformanter als clipping.
MfG
micki
zeckensack
2005-10-21, 20:20:17
Wenn du dich wirklich auf die böse Geschäft der D3D Emulation einlassen willst kann ich dir noch ein paar Tips bezüglich des "korrekten" Verhaltens des Referenzcountings geben. Das ist stellenweise merkwürdig.Nein.
Über D3D5/6/7/8/9-Emulation habe ich mal ernsthaft nachgedacht, aber das ist ein juristisches Minenfeld von Weltkriegsausmaßen mit ausgerechnet Microsoft auf der Gegenseite, und man würde ihnen auch jede Menge Motivation zum Einstampfen geben. Das werde ich sicher nicht machen.
Ich bin anders wahnsinnig.
Demirug
2005-10-21, 20:30:48
Nein.
Über D3D5/6/7/8/9-Emulation habe ich mal ernsthaft nachgedacht, aber das ist ein juristisches Minenfeld von Weltkriegsausmaßen mit ausgerechnet Microsoft auf der Gegenseite, und man würde ihnen auch jede Menge Motivation zum Einstampfen geben. Das werde ich sicher nicht machen.
Ich bin anders wahnsinnig.
Warum Motivation zum Einstampfen?
Mit einem DX kompatiblen Software renderer hat MS kein Problem. Sie erwähnen inzwischen ja sogar einen im SDK.
Es gab ja sogar mal ein kommerzielles DX Projekt für den Mac. Das wurde aber wegen mangelnden wirtschaftlichen Erfolg nicht weiter entwickelt.
Das was Transgaming gemacht hat könnte allerdingw irklich zu Problemen führen weil man die Demos aus dem SDK nicht so einfach weiterverberiten darf. Allerdings hat das nichts mit dem D3D Interface zu tun.
micki
2005-10-21, 20:30:52
Nein.
Über D3D5/6/7/8/9-Emulation habe ich mal ernsthaft nachgedacht, aber das ist ein juristisches Minenfeld von Weltkriegsausmaßen mit ausgerechnet Microsoft auf der Gegenseite, und man würde ihnen auch jede Menge Motivation zum Einstampfen geben. Das werde ich sicher nicht machen.
Ich bin anders wahnsinnig.
ich glaube man bekommt den source zum refras sogar mit um damit rumzuspielen, außerdem sind die jungs vom dx support ziemlich nett, schreib denen ne mail, ob du das machen darfst, gibt sicherlich ne antwort ;)
MfG
micki
Demirug
2005-10-21, 20:33:11
ich hatte culling/clipping geschrieben, da man ja vermutlich nur wenige triangles pro tile clipping müßte und die meisten verwerfen/cullen würde. guardbands sind zwar nett, das aber auch nur mit dafür dedizierter hardware, für einen software rasterizer wäre das vermutlich noch unperformanter als clipping.
MfG
micki
Das hängt davon ab wie man seinen Linewalker baut. Es gibt Verfahren mit denen man ein unendliches Guardband bekommt das auf jeder CPU implementiert werden kann.
Demirug
2005-10-21, 20:35:46
ich glaube man bekommt den source zum refras sogar mit um damit rumzuspielen, außerdem sind die jungs vom dx support ziemlich nett, schreib denen ne mail, ob du das machen darfst, gibt sicherlich ne antwort ;)
MfG
micki
Refrast Sourcen gibt es seit DX8 nur noch für Treiberentwickler die eine NDA unterschreiben. Hat irgendwas mit Codeteilen zu tun die sie nicht öffentlich machen dürfen.
micki
2005-10-21, 20:41:28
Das hängt davon ab wie man seinen Linewalker baut. Es gibt Verfahren mit denen man ein unendliches Guardband bekommt das auf jeder CPU implementiert werden kann.
natürlich kann man, das bezweifle ich auch nicht, mein gba rasterizer hat sogar einen (siehe link unten), das aber auch nur weil es kein div auf der cpu gibt, trotzdem ist ein guardband nicht so performant wie es clippng meistens ist und das auf tiles angewand gibt enormen overhead, da wäre ein fixer rasterizer eventuell schöner.
MfG
micki
micki
2005-10-21, 20:43:21
Refrast Sourcen gibt es seit DX8 nur noch für Treiberentwickler die eine NDA unterschreiben. Hat irgendwas mit Codeteilen zu tun die sie nicht öffentlich machen dürfen.
wuste nicht, dass das nicht jeder auf platte liegen hat... :-/, hab nicht vermutet, dass da was tolles drinne wäre, da eh alles bekannt ist.
zeckensack
2005-10-21, 20:49:19
Warum Motivation zum Einstampfen?Glaubst du MS fände das lustig wenn's einen D3D9=>OpenGL-Wrapper auf Windows gäbe?
... der auch noch schneller ist als die D3D-Runtime?
Demirug
2005-10-21, 20:51:51
wuste nicht, dass das nicht jeder auf platte liegen hat... :-/, hab nicht vermutet, dass da was tolles drinne wäre, da eh alles bekannt ist.
Bist du sicher das du einen DX9 Refrast im Sourcecode hast und nicht nur die DX7 Version? Das wurde schon öfter verwechselt.
Demirug
2005-10-21, 20:58:40
Glaubst du MS fände das lustig wenn's einen D3D9=>OpenGL-Wrapper auf Windows gäbe?
... der auch noch schneller ist als die D3D-Runtime?
Den gab es doch schon und MS hat das nicht sonderlich gekümmert.
Unter Vista wirst du die Runtime aber nicht mehr schlagen können weil das Performancesloch da nicht mehr vorhanden ist. Unter XP könnte es durchaus noch hinhauen. Allerdings ist das eine Heidenarbeit wie man ja auch bei Transgameing sieht.
micki
2005-10-21, 21:05:21
Bist du sicher das du einen DX9 Refrast im Sourcecode hast und nicht nur die DX7 Version? Das wurde schon öfter verwechselt.
hmm... ich hab kein dx7 sdk auf meinem rechner in der arbeit, deswegen also...
Demirug
2005-10-21, 21:22:50
hmm... ich hab kein dx7 sdk auf meinem rechner in der arbeit, deswegen also...
Der Refrast Source war noch nie im SDK sondern immer nur im DDK und da war der DX7 Code noch drin als es eigentlich schon nicht mehr aktuell war.
Das wäre doch viel zu umständlich.
Ist aber so. Natürlich ist es so vereinfacht, dass es für 32 Pixel parallel ablaufen kann (was bei Kyro einer Tile-Zeile entspricht). Darum braucht man auch überhaupt kein Clipping gegen Tile-Ränder, wozu auch?
Demirug
2005-10-22, 07:26:24
Ist aber so. Natürlich ist es so vereinfacht, dass es für 32 Pixel parallel ablaufen kann (was bei Kyro einer Tile-Zeile entspricht). Darum braucht man auch überhaupt kein Clipping gegen Tile-Ränder, wozu auch?
Beim Clipping sind wir uns doch sowieso einig.
Was den Z-Test angeht haben ich das ganze allerdings etwas anders gehört. Die Tiefenprozessoren sollen wie eine Art Schieberegister gekoppelt sein und ein Dreiecksfragment wird dabei immer von einem zum nächsten geschoben. Auf diese Weise muss beim Übergang immer nur eine Addition beim Z-Wert durchgeführt werden.
Du weißt aber das Epic sich eine DX kompatible SW Renderengine für das aktuelle UT eingekauft hat? Da ist keine Eigenentwicklung.Ok, ich dachte, das wäre die weiterentwickelte SW-Engine von UT.
Es hat sich wie gesagt nicht mehr gelohnt. Es war einfacher Fallbacks für schwache Grafikkarten einzubauen. Um es interesant zu halten hätte MS eine anbieten müssen.Einen DX-kompatiblem SW-Renderer? Final Reality ist mit dem MS SW-Renderer langsamer als Max Payne mit der "SwiftShader"-Umsetzung. MS hat in Dingen SW-Rendering einfach eine zu langsame Umsetzung geboten, die dann natürlich auch unattraktiv wird.
Demirug
2005-10-22, 10:54:05
Ok, ich dachte, das wäre die weiterentwickelte SW-Engine von UT.
UT benutzt Pixomatic (http://www.radgametools.com/pixomain.htm)
Einen DX-kompatiblem SW-Renderer? Final Reality ist mit dem MS SW-Renderer langsamer als Max Payne mit der "SwiftShader"-Umsetzung. MS hat in Dingen SW-Rendering einfach eine zu langsame Umsetzung geboten, die dann natürlich auch unattraktiv wird.
Sollte man nicht Äpfel mit Äpfel vergleichen? Solange man nicht weiß wie sich SwiftShader bei Final Reality schlägt sagt das ja nicht viel aus.
Beim Clipping sind wir uns doch sowieso einig.
Was den Z-Test angeht haben ich das ganze allerdings etwas anders gehört. Die Tiefenprozessoren sollen wie eine Art Schieberegister gekoppelt sein und ein Dreiecksfragment wird dabei immer von einem zum nächsten geschoben. Auf diese Weise muss beim Übergang immer nur eine Addition beim Z-Wert durchgeführt werden.
Z ist aber nicht linear, 1/Z ist es. Du brauchst allerdings auch einen Anfangswert pro Scanline, ebenso wie z.B. die Koeffizienten der Ebenengleichung, um festzustellen ob das Pixel überhaupt innerhalb des Dreiecks liegt. Kyro berechnet ja stur ganze Scanlines innerhalb der Tiles.
Demirug
2005-10-22, 12:22:49
Z ist aber nicht linear, 1/Z ist es. Du brauchst allerdings auch einen Anfangswert pro Scanline, ebenso wie z.B. die Koeffizienten der Ebenengleichung, um festzustellen ob das Pixel überhaupt innerhalb des Dreiecks liegt. Kyro berechnet ja stur ganze Scanlines innerhalb der Tiles.
Natürlich werden die Koeffizienten berechnet aber nur einmal pro Dreieck. Das immer eine ganze Scanline berechnet wird kommt daher das das Dreieck ja immer durch alle Z-Prozessoren durchgeschoben wird. Das ist zwar eigentlich eine Verschwendung von Rechenleistung aber dadurch wird das Design einfacher was das mehr als ausgleicht.
Ailuros
2005-10-22, 12:28:58
Etwas OT aber MBX hat eigentlich nur noch Anteile was die TMUs und die Anzahl der Z/stencil Einheiten betrifft gemeinsam mit Serie3. Oder anders selbst da sind es immer noch 16z/stencil fuer jede "pipeline".
Natürlich werden die Koeffizienten berechnet aber nur einmal pro Dreieck.
Ich glaube wir reden aneinander vorbei. Ich meinte jene Koeffizienten, die man in die Ebenengleichung einsetzt, um einen Punkt auf der Ebene zu erhalten. Mit denen man prüfen kann, ob ein bestimmter Punkt auf der Ebene auch innerhalb eines Dreiecks liegt.
Das immer eine ganze Scanline berechnet wird kommt daher das das Dreieck ja immer durch alle Z-Prozessoren durchgeschoben wird. Das ist zwar eigentlich eine Verschwendung von Rechenleistung aber dadurch wird das Design einfacher was das mehr als ausgleicht.
Das weiß ich ja, das ändert aber nichts daran dass du einen Anfangswert für jede Zeile brauchst.
zeckensack
2005-10-22, 20:25:14
Den gab es doch schon und MS hat das nicht sonderlich gekümmert.Wo? Und was konnte der alles (nicht)?
Unter Vista wirst du die Runtime aber nicht mehr schlagen können weil das Performancesloch da nicht mehr vorhanden ist.Wozu brauche ich Vista? Wozu brauchen Spieler Vista?
WGF, und damit Vista, braucht keine Sau, wenn die Performance-Behinderung von DXG eliminiert werden kann.
zeckensack
2005-10-22, 20:27:37
Z ist aber nicht linear, 1/Z ist es.Sicher? IMO nein, bestenfalls ist es "undefined". Z':=z/w gilt pro Vertex.
Wo? Und was konnte der alles (nicht)?
Wozu brauche ich Vista? Wozu brauchen Spieler Vista?
WGF, und damit Vista, braucht keine Sau, wenn die Performance-Behinderung von DXG eliminiert werden kann.WGF bietet ja nicht nur bessere Performance sondern auch deutlich mehr Features. Ich denke nicht dass da OGL so schnell aufschließen wird.
Demirug
2005-10-22, 20:37:34
Wo? Und was konnte der alles (nicht)?
Keine Ahnung ob ich das Ding noch finde. War IIRC DX8 kompatibel aber was alles ging weiß ich beim besten Willen nicht mehr.
Edit: Habe es gefunden: http://www.realtech-vr.com/directx/index.html
Sehr weit war man scheinbar wirklich noch nicht. Allerdings habe sie die richtige rechtliche Absicherung auf der Seite:
Direct X is © 2001 Microsoft Corporation. All rights reserved. Terms of Use.
Direct X Port is based upon the DirectX 8 Specification from Microsoft and is not based upon a reverse engineering or disassembling of the Direct X code source.
Direct X Port is not developed / endorsed / supported by Microsoft.
Wozu brauche ich Vista? Wozu brauchen Spieler Vista?
WGF, und damit Vista, braucht keine Sau, wenn die Performance-Behinderung von DXG eliminiert werden kann.
Ob du Vista brauchst muss du selbst entscheiden.
Ich jedenfalls will D3D10 haben und D3D9EX ist auch nicht schlecht. Zudem gefällt mir Virtual Video Ram auch nicht schlecht.
Monger
2005-10-22, 20:53:20
Ich jedenfalls will D3D10 haben und D3D9EX ist auch nicht schlecht. Zudem gefällt mir Virtual Video Ram auch nicht schlecht.
Von dir höre ich auffallend viel positives über D3D10. Wird es denn wirklich ein so dramatischer Sprung? Ach ja richtig, die Veröffentlichung kommt ja erst mit der Beta 2 :D
Demirug
2005-10-22, 21:04:23
Von dir höre ich auffallend viel positives über D3D10. Wird es denn wirklich ein so dramatischer Sprung? Ach ja richtig, die Veröffentlichung kommt ja erst mit der Beta 2 :D
Genau. Mein PCGH Artikel führt auch die bereits öffentlich bekannten Nachteile auf. Die betreffen mich aber nur als Kaufmann nicht als Technophiler.
Kinman
2005-10-22, 22:12:02
Sogar UT2004 besitzt noch ein Software Rendering. Kann man mithilfe der UT2004.ini aktivieren (leider weiß ich nicht auswendig wie). Aber als mein Laptop am eingehen war (VRAM kaputt) hatte ich einige Zeit im Software Rendering gespielt (XP-M2500+, auf 512x384). Das ging sogar mit ~50fps. Details waren natürliche alle abgeschalten.
Ich müsste mal nachschaun wie man das einstellt und mal mit dem A64 testen, wie das performt.
mfg Kinman
Sicher? IMO nein, bestenfalls ist es "undefined". Z':=z/w gilt pro Vertex.
Ja, sicher. Und ich meine naturlich nach der homogenen Division.
Denk dir das zweidimensional in der XZ-Ebene. Die Sichtstrahlen für jeden Pixel gehen vom Ursprung aus und schneiden die Projektionsgerade in gleichen Abständen. Die Geradengleichungen des Strahls durch den k-ten Pixel lautet also:
r(k, s) = (k*const, 1) * s
Statt mit einem Polygon schneiden wir die Sichtstrahlen nun mit einer Gerade:
g(t) = P + t * A
mit Punkt P = (px, pz), Richtung A = (ax, az)
Schnittpunkt erhält man durch gleichsetzen:
(k*const, 1) * s = P * t + A
zerlegt in Komponenten:
(k*const) * s = px + t * ax
s = pz + t * az
Um t zu eliminieren, multipliziert man die zweite Gleichung mit -ax/az und addiert dann:
s * (k*const - ax/az) = px - pz * ax/az
s = (px - pz * ax/az) / (k*const - ax/az)
Nach der Gleichung für die Sichtstrahlen ist s gleich dem gesuchten Z-Wert für Pixel k. Bildet man den Kehrwert der obigen Gleichung, so sieht man, dass 1/s (und somit der Z-Wert) linear von k abhängt. Also verläuft 1/Z im Screenspace linear.
Kinman
2005-10-23, 23:06:24
So habs wieder... ut2004.exe -software
Mit 512x384 (volle Details) und meiner Hardware (sig) und einem bot flüssig spielbar ;)
http://the-assassines.com/ut_software.jpg
mfg Kinman
Also verläuft 1/Z im Screenspace linear.Sonst hätte man auch ein ziemliches Problem 1/Z einfach so über das Polygon linear zu interpolieren ;)
Pro Pixel (Quad?) wird dann schön die RCP davon genommen und man hat den Z-Wert.
micki
2005-10-24, 08:27:55
Der Refrast Source war noch nie im SDK sondern immer nur im DDK und da war der DX7 Code noch drin als es eigentlich schon nicht mehr aktuell war.
steht: Microsoft DirectX DDK Version 9.0.0900.1 in der dxddkver.txt, gibt es immer noch ne chance dass es nur dx7 code ist? ;)
wieso wird 3dnow und mmx nicht unterstützt. wenn nur fehlende features in software errechnet oder der komplette renderprozess. so dürfte bei ner shader losen t&l karte zu ps1.1 doch nicht sowie leistung gefressen werden, so müßte man das programmieren und nicht kpl. in software
Neomi
2005-11-20, 18:35:11
wieso wird 3dnow und mmx nicht unterstützt. wenn nur fehlende features in software errechnet oder der komplette renderprozess. so dürfte bei ner shader losen t&l karte zu ps1.1 doch nicht sowie leistung gefressen werden, so müßte man das programmieren und nicht kpl. in software
Eine solche Teilberechnung kannst du vergessen. Ein Programm kann sich nicht an beliebiger Stelle in die Berechnung einklinken.
Allgemein kann man sich auf drei Möglichkeiten beschränken:
a) alles in Hardware
b) VS in Software und PS in Hardware
c) alles in Software
... Erstens könnte man APIs für Hardware, die es nicht mehr gibt, in Software nachbilden ...
Ist zwar ein bisschen OT,aber mich würde an dieser Stelle interessieren was für APIs bei speziellen RealTime CGs (Konsolen,Spielautomaten) angewendet werden.
Ich stelle diese Frage deshalb weil Hardwarenahe Programmierung einer GPU imo vergleichbar ist mit solchen Geschichten wie Softwarerender.Hab da grade das 64kb Zoom3 Demo im Kopf:)
Sega beispielsweise gab nun Daten zur Lindbergh AC Hardware bekannt.
P4BlaBla + Nvidia (spz.G70er??) GPU!! Nun,welche API benutzen die?
Ich kann mir vorstellen wenn die KEIN DX9 o. 10? benutzen(bitte bitte), daß so eine GK endlich einmal ausgenutzt wird.Wir werden auf dem PC Markt, was diesen Punkt betrifft, besonders verarscht.
Wäre es also "möglich" eine eigene (SCHNELLE) API zu coden,also die GK mit einbeziehen??Und Games sehen schöner aus und wären schneller,zumindest in meinen Träumen:)
(hab von Programmierung leider keine Ahnung)
So schlecht wie du denkst ist DirectX lange nicht.
Demirug,
mein Ansatz ist, dass der PC als System mit auswechselbaren Komponenten per se schlecht für fehlerfreie und performante Programmierung geeignet ist, und dass für den PC keine befriedende Massenspeicher-Lösung gefunden wurde, von der man "on the fly" spielen kann. Dieser Zwang zur Installation eines Spiels ist für mich ein Spaßkiller. Der PC hat als Pluspunkt lediglich vorzuweisen, dass er weit verbreitet ist, und man keine Extra-Anschaffung machen muss. Es sei denn, man möchte aktuelle 3D-Spiele in voller Qualität spielen. Aber es gibt ja keine Grafikkarte, die alles sehr gut kann.
Bei Spielen hängt der Entwickler an dem, was die Zielhardware kann. Die CPU kann vereinfacht gesagt alles, nur eben nicht so schnell. Trotzdem bleibt für mich die Frage, ob es immer 3D-Beschleunigung sein muss. Eine einfache 3D-Umgebungen kann auch mit der (ohnehin meist sehr starken) CPU erzeugt werden. Ob nun mit Rendering à la SGI oder Raycasting. Klar kann ein Software-Renderer aktuelle 3D-Hardware nicht ersetzen, aber er könnte neue Gebiete erschließen, und Effekte möglich machen, die uns 3D-Karten heute noch verwehren. Aber das beste: Der SW-Renderer läuft immer, egal ob eine Radeon, GeForce oder Volari eingebaut ist.
Ein sehr sehr interessanter Ansatz,worüber ich mir auch schon in ähnlicher Weise gedanken gemacht habe.
Wie wäre es mit dieser Lösung:Standard Effekte sagen wir mal bis DX8.1 (hat jeder!)werden von der GK (mit spezieller API:) ) gerendert,und darüber hinaus greift dann noch ein zusätzlicher SR ein!
Den Sinn hinter dem Ganzen sehe ich darin das endlich eine Vereinheitlichung der PC HW auf einen kleinsten gemeinsamen Nenner vorhanden wäre!
Somit hätten es die Entwickler leichter Games zu Produzieren ohne Kompatibilitäts Probs.
Also wenn auf der Packung eine Mindestanforderung steht , wie zB:"mind.CPU 3000,GPU mind.GF3/Radeon8500 mit 64MB,512 MB Ram(333),bei 1280*1024+Vsync@75Hz".Dann sollten die Games auf entsprechender HW -/+ gleichschnell laufen.
Mittels des zusätzlichen SRs hätten die Entwickler viel mehr Freiheiten,und wären nicht so arg auf DX limitiert.
Wäre so etwas möglich?
Wie wäre es mit dieser Lösung:Unsinnig, weil die CPU als Rasterizer gerade dann nicht taugt, wenn die Effekte irgendwelche Pixelshader verlangen.
So schlecht wie du denkst ist DirectX lange nicht.
Aber langweilig und Einheitsbrei,sorry.
Und wieso ist Serious Sam unter OGL (bei NV zumindest) schneller?
Dreamcast Spiele sahen zu jener Zeit viel schöner aus als PC Spiele,war wohl kein DX:)
Unsinnig, weil die CPU als Rasterizer gerade dann nicht taugt, wenn die Effekte irgendwelche Pixelshader verlangen.
Schade...
micki
2005-11-21, 09:20:37
Aber langweilig und Einheitsbrei,sorry.
Und wieso ist Serious Sam unter OGL (bei NV zumindest) schneller?
Dreamcast Spiele sahen zu jener Zeit viel schöner aus als PC Spiele,war wohl kein DX:)
und ich dachte da wäre ne art windows drauf (und dx?)
und ich dachte da wäre ne art windows drauf (und dx?)
WindowsCE ist auf der Dreamcast drauf. Aber ob da DirectX mit drinnen ist?
Aber langweilig und Einheitsbrei,sorry.
Und wieso ist Serious Sam unter OGL (bei NV zumindest) schneller?
Dreamcast Spiele sahen zu jener Zeit viel schöner aus als PC Spiele,war wohl kein DX:)Das hat mit der API nichts zu tun.
Ein sehr sehr interessanter Ansatz,worüber ich mir auch schon in ähnlicher Weise gedanken gemacht habe.
Wie wäre es mit dieser Lösung:Standard Effekte sagen wir mal bis DX8.1 (hat jeder!)werden von der GK (mit spezieller API:) ) gerendert,und darüber hinaus greift dann noch ein zusätzlicher SR ein!
Den Sinn hinter dem Ganzen sehe ich darin das endlich eine Vereinheitlichung der PC HW auf einen kleinsten gemeinsamen Nenner vorhanden wäre!
Somit hätten es die Entwickler leichter Games zu Produzieren ohne Kompatibilitäts Probs.
Also wenn auf der Packung eine Mindestanforderung steht , wie zB:"mind.CPU 3000,GPU mind.GF3/Radeon8500 mit 64MB,512 MB Ram(333),bei 1280*1024+Vsync@75Hz".Dann sollten die Games auf entsprechender HW -/+ gleichschnell laufen.
Mittels des zusätzlichen SRs hätten die Entwickler viel mehr Freiheiten,und wären nicht so arg auf DX limitiert.
Wäre so etwas möglich?Nein. Eher das Gegenteil wäre mittelfristig denkbar: Bis DX8.1 wird auch ein SW-Renderer geboten, darüber hinaus muss Hardware vorliegen.
Das hat mit der API nichts zu tun.Das hat schon was mit der API zu tun. Der Batch-Overhead von OpenGL ist geringer.
Aber mit DirectX 10 fällt auch der Vorteil von OpenGL weg.
Demirug
2005-11-21, 14:55:18
Das hat schon was mit der API zu tun. Der Batch-Overhead von OpenGL ist geringer.
Aber mit DirectX 10 fällt auch der Vorteil von OpenGL weg.
Eigentlich fällt der Vorteil unter Windows Vista weg. Das betrift auch schon DX9.
Das ist ja noch erfreulicher. Da werden sich aber einige wundern, dass ein neues Windows auch mal bessere Performance bringt ;)
Das hat schon was mit der API zu tun. Der Batch-Overhead von OpenGL ist geringer.
Aber mit DirectX 10 fällt auch der Vorteil von OpenGL weg.Der Dreamcast hatte eine vernünftige Grafikeinheit, das sehe ich als wichtiger als die verwendete API. DirectX mit dem traditionellen Overhead würde auf einer Konsole ohnehin nicht genutzt werden.
Ach und die Grafikchips für den PC sind nicht vernünftig, oder wie darf ich das verstehen?
Demirug
2005-11-21, 15:35:59
Nein. Eher das Gegenteil wäre mittelfristig denkbar: Bis DX8.1 wird auch ein SW-Renderer geboten, darüber hinaus muss Hardware vorliegen.
Was für ein Softwarerenderer? Selbst für DX 8.1 reicht die CPU doch nicht wirklich.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.