PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Swiftshader 2.0 - D3D9 @ CPU


AnarchX
2008-04-04, 09:03:59
Transgaming kündigte neue SwiftShader-Version an (http://www.golem.de/0804/58776.html)

Transgaming hat eine neue Version seines Software-3D-Renderers SwiftShader angekündigt. Mit der Version 2.0 soll die Kompatibilität zu DirectX 9 verbessert worden sein und es werden nun die Vorteile von Mehrkernprozessoren ausgenutzt. Gedacht ist SwiftShader für Entwickler.

Schon bei der Vorstellung der ersten Version bewarb Transgaming seinen Software-3D-Renderer als schnellsten seiner Art. Nicht nur Microsofts Direct3D-Referenz-Rasterizer sollte die Software demnach ausstechen, sondern auch an die Leistung von Low-End-Grafikkarten herankommen. Für SwiftShader 2.0 verspricht der Anbieter nun, das Shader Model 2.0 ebenso zu unterstützen wie Floating-Point-Rendering. Ferner wurde die Kompatibilität zu DirectX 9 verbessert. Die neue Version nutzt außerdem Mehrkern-CPUs, was zu einer weiteren Leistungssteigerung führen soll. [...]

B3D, die wohl gerade offline sind, haben schon ein paar Tests gemacht:
It can run (albeit slowly) many modern games and it makes a dual-core Penryn perform similarly to the GeForce FX5600/5700 in 3DMark05.

A demo is now available on TransGaming's website, with which we ran 3DMark05 and obtained a score of ~400 on a stock Core 2 Duo E8400. That's still not mind-blowingly fast, but keep in mind Direct3D's reference rasterizer would likely score in the single digits and the SGX-based IGP in Intel's upcoming Silverthorne-based Menlow platform for UMPCs/MIDs is claimed to only score ~150. It would also be much more than enough to run Vista's Aero interface smoothly.
http://www.beyond3d.com/content/news/618

Wer selber testen will:
http://www.transgaming.com/products/swiftshader/technology/

Durchaus beeindruckend, da kann man ja in etwa erahnen, was ein Larrabee mit seinen 1TFLOPs (C2D E8400 ~24GFLOPs) und einen wohlmöglich noch fortgeschritteneren SW-Rasterizer bzw. teilweise vorhandener FF-Logik erreichen könnte.:eek:

Shink
2008-04-04, 09:31:32
Hab mich schon länger gefragt was aus dem Projekt geworden ist. Wäre wahrscheinlich sogar sinnvoll für Notebooks mit SiS-Chipsätzen (falls es da welche mit Dual Core gibt) und natürlich ist es auch interessant.
Übrigens: Der IGP im Intel 945 liefert knapp unter 500 3DMarks

Ich hoffe dass es mit der Kompatibilität nun besser aussieht.

Coda
2008-04-04, 11:36:06
Nick ist ein Gott. Verdammt geil.

AnarchX
2008-04-04, 11:47:24
Im VR-Zone-Forum scheint einer der Entwickler(c0d1f1ed) unterwegs zu sein und gibt noch ein paar zusätzliche Einblicke zum Projekt und seiner Zukunft:
http://forums.vr-zone.com/showthread.php?t=258177

misterh
2008-04-04, 13:15:52
Far Cry Demo 1024x768 @ SwiftShader 2.0
http://666kb.com/i/axihxvopre43930vo.jpg

AnarchX
2008-04-04, 13:18:30
Crysis läuft jedenfalls:
http://img85.imageshack.us/img85/4633/crysisez4.jpg
http://forums.vr-zone.com/showpost.php?p=5119844&postcount=11

Vielleicht HDR aktiviert oder die CPU nicht fehlerfrei übertaktet?

misterh
2008-04-04, 13:21:06
Vielleicht HDR aktiviert oder die CPU nicht fehlerfrei übertaktet?

mit LOW sieht bei mir auch nicht sauber aus und hab CPU nicht OC grad. also Standard.

Coda
2008-04-04, 16:39:58
Im VR-Zone-Forum scheint einer der Entwickler(c0d1f1ed) unterwegs zu sein und gibt noch ein paar zusätzliche Einblicke zum Projekt und seiner Zukunft:
http://forums.vr-zone.com/showthread.php?t=258177
"Nick" auf Beyond3D und auf devmaster.net

Nightspider
2008-04-04, 17:17:24
Schon jemand die Auslastung bei QuadCores getestet ?

tombman
2008-04-04, 17:34:53
Schon jemand die Auslastung bei QuadCores getestet ?
Kommt gleich ;)

Dolphin sample @ quadcore: ~70% ;) (@~90fps bei highres ;D;D)

Wenn Intel das Teil kauft und ne Monster Cpu darauf optimiert, braucht man echt keine Graka mehr- wäre aber dann kein Raytracing mehr ;)

Edit:
3dm2001 SE, Car Chase HIGH, default: 14.1 fps (Auslastung ~70%)

Edit 2:
3dm2001 SE, NATURE (!), default: 11.8 fps (Auslastung ~90% !!!)

Edit 3:
3dm2001, HIGH POLYGON COUNT WITH 8 LIGHTS (ja, jetzt wirds pöhse;)): ~6fps (Auslastung 95%!!!)

Edit 4:
Advanced Pixel Shader: 29.7 fps (!!)

AnarchX
2008-04-04, 17:45:59
Wenn Intel das Teil kauft und ne Monster Cpu darauf optimiert, braucht man echt keine Graka mehr- wäre aber dann kein Raytracing mehr ;)

Wer sagt, dass Intel nur Raytracing will? ;) Ein paar Leute für SW-Rasterisierung sollen sie wohl auch schon auf der Gehaltsliste stehen haben.

Coda
2008-04-04, 17:49:56
Dazu brauchen sie aber keine Software. Larrabee hat natürlich einen Hardware-Rasterizer.

tombman
2008-04-04, 17:56:44
3dm06, firefly forrest: 0.669 fps (;D;D)

Die HDR/SM3 Tests kann ich ned auswählen mit dem swiftshader- haben die da was versaut? Ist das nicht Teil von DX9?

AnarchX
2008-04-04, 17:58:06
Die HDR/SM3 Tests kann ich ned auswählen mit dem swiftshader- haben die da was versaut? Ist das nicht Teil von DX9?
Swiftshader untersützt momentan maximal SM2.0.

tombman
2008-04-04, 17:59:25
Swiftshader untersützt momentan maximal SM2.0.
Ach so.

Aber die Auslastung haben sie gut hinbekommen. Bei den "teuren" Sachen in 3dm06 >90% !.

Cpu bei meinen Tests war ein 4Ghz Yorkfield.

2x GTX sind ca Faktor 100 schneller.

Also, Intel, wo ist eure 400 Core Cpu? ;D (Milchmädchen FTW)

Demirug
2008-04-04, 17:59:54
Swiftshader untersützt momentan maximal SM2.0.

SM 2.B (getestet mit einem nicht näher bezeichneten Spiel).

Coda
2008-04-04, 18:16:35
Hat Swiftshader nen dependent texture lookup limit? Würde mich wundern.

Gast
2008-04-04, 18:22:23
Dazu brauchen sie aber keine Software. Larrabee hat natürlich einen Hardware-Rasterizer.
quelle?

Coda
2008-04-04, 18:37:06
Da braucht man keine Quelle. Wollen sie konkurrenzfähig sein müssen sie das machen aus vielen Gründen.

AnarchX
2008-04-04, 18:50:26
Hinter dem oft in den Larrabee-Schaubildern angedeuteten FF-Block wird definitiv etwas sein.

Aber wenn Larrabee auch sehr stark im HPC-Bereich, als auch unter Raytracing sein soll, wird wohl Intel nur das verbaut haben was nötig ist.
Das dürften wohl an erster Stelle TMUs sein, deren SW-Emulation doch ziemlich aufwendig sein sollte, wie auch SwiftShaders Fill-rate Werte es zeigen oder?

Demirug
2008-04-04, 19:01:30
Wie oft den noch? Larrabee != Raytraceing. Die Software für Larrabee wird von Rasterizer Experten geschrieben.

Nakai
2008-04-04, 19:21:42
Oh Fuck, das sit wirklich geil.

Wär ja ein Grund für Octacores oder Höher.



mfg Nakai

Gast
2008-04-04, 19:48:04
Wie oft den noch? Larrabee != Raytraceing. Die Software für Larrabee wird von Rasterizer Experten geschrieben.
trotz
Dazu brauchen sie aber keine Software. Larrabee hat natürlich einen Hardware-Rasterizer.?
Die sitzen doch nicht alle nur daran einen Shaderrecompiler oder Treiber zu schreiben.

=Floi=
2008-04-04, 19:58:50
wie verhällt es sich hier eigentlich mit der auflösung und dem AA im bezug auf die fps?

danke @tombman für die benches (kompletter 01er score wäre noch nett)

Demirug
2008-04-04, 22:25:20
Die sitzen doch nicht alle nur daran einen Shaderrecompiler oder Treiber zu schreiben.

Der Begriff Rasterizer ist doppeldeutig. Zum einen ist damit das ganze Verfahren gemeint zum anderen aber auch nur der Hardwareblock der für das zerlegen der Dreiecke in Pixel/Sample verantwortlich ist.

Coda
2008-04-04, 22:38:25
wie verhällt es sich hier eigentlich mit der auflösung und dem AA im bezug auf die fps?
Das Ding kann kein AA. Auflösung sollte linear in die Performance einfließen.

Gast
2008-04-04, 23:40:15
Der Begriff Rasterizer ist doppeldeutig. Zum einen ist damit das ganze Verfahren gemeint zum anderen aber auch nur der Hardwareblock der für das zerlegen der Dreiecke in Pixel/Sample verantwortlich ist.
Das beantwortet die Frage nicht.
Du sagst: " Die Software für Larrabee wird von Rasterizer Experten geschrieben." Er sagt: " Larrabee hat natürlich einen Hardware-Rasterizer."

Was ist denn nun sache? Versteh ich falsch, dass da ein Widerspruch ist; oder erzählt Coda mal wieder.

Coda
2008-04-04, 23:42:06
Was soll ich da "erzählen". Wenn man den Rasterizer in x86 macht, dann verliert man für immer die gleiche Aufgabe sehr viel Performance. Da lässt man lieber nen Core weg und implementiert das in Hardware.

Das ist doch wohl logisch. Sie wollen das Ding schließlich als GPU verkaufen, und da sie es anscheinend jetzt doch nichmal selber fertigen haben sie noch nicht mal nen Fertigungsvorteil gegenüber NVIDIA und ATI. Da hat man keinen Spielraum für solche Dinge in Software wenn man mithalten will.

Gast
2008-04-05, 00:12:23
Was soll ich da "erzählen". Wenn man den Rasterizer in x86 macht, dann verliert man für immer die gleiche Aufgabe sehr viel Performance. Da lässt man lieber nen Core weg und implementiert das in Hardware.

Das ist doch wohl logisch. Sie wollen das Ding schließlich als GPU verkaufen, und da sie es anscheinend jetzt doch nichmal selber fertigen haben sie noch nicht mal nen Fertigungsvorteil gegenüber NVIDIA und ATI. Da hat man keinen Spielraum für solche Dinge in Software wenn man mithalten will.
Und wieso kauft Intel soviel Rasterizer Experten ein die laut Demirug die Software schreiben? Die haben nicht viel den Compiler und Treiber Experten im Vorteil, wenn sie was anderes als Rasterizer schreiben würden.

Zudem wüste ich gerne wie du genau zu dem Schluss kommst, dass sie eine Hardware dafür brauchen und es nicht in Software könnten. Hast du das nachgerechnet, es selber schon implementiert, hast du jemanden von Intel gesprochen oder woher?

Raff
2008-04-05, 00:24:33
Oh Fuck, das sit wirklich geil.

Wär ja ein Grund für Octacores oder Höher.



mfg Nakai

Schädelpfad, anyone?

Das Ding kann kein AA. Auflösung sollte linear in die Performance einfließen.

Sollte – tut sie aber oft nicht. Zwischen 1680x1050 und 800x600 liegt oft "nur" eine Halbierung der Frames.

MfG,
Raff

Coda
2008-04-05, 00:30:08
Ja gut, das liegt dann wohl daran, dass der Rasterizer und das Triangle-Setup viel Zeit braucht bei einem Softwarerenderer

Coda
2008-04-05, 00:31:42
Und wieso kauft Intel soviel Rasterizer Experten ein die laut Demirug die Software schreiben?
Er meinte Leute die sich mit Treibersoftware für Rasterizer auskennen, ganz einfach.

Zudem wüste ich gerne wie du genau zu dem Schluss kommst, dass sie eine Hardware dafür brauchen und es nicht in Software könnten. Hast du das nachgerechnet, es selber schon implementiert, hast du jemanden von Intel gesprochen oder woher?
Nein, das liegt ganz einfach daran, dass egal wie man einen Software-Rasterizer schreibt das Triangle-Setup und der Rasterizer sau viel Zeit kostet die eine normale GPU "for free" nebenhermacht. Und nein das saug ich mir nicht aus den Fingern.

Und ja ich habe schon selber einen Software-Rasterizer implementiert. Und wenn du es mir nicht glaubst, dann frag einfach Nick, der wird dir exakt das gleiche erzählen.

Demirug
2008-04-05, 00:52:56
Er meinte Leute die sich mit Treibersoftware für Rasterizer auskennen, ganz einfach.

Zum Teil. Soweit ich Larrabee verstehe braucht der Chip durchaus eine Runtime Software welche die fixed function Blöcke koordiniert und die restlichen Teile als Software implementiert. So wird ja zum Beispiel auch PhysX mit einer runtime software geladen. Nur so konnte man die Chip mit neuen Engine Versionen auch neue Dinge beibringen.

Gast
2008-04-05, 00:54:11
Er meinte Leute die sich mit Treibersoftware für Rasterizer auskennen, ganz einfach.
Achso, nun gut. Ich dachte sie hätten neben den ganzen Treiberentwicklern die Firmen mit Softwarerasterizern wegen der Rasterizer, nicht wegen dem Treiber gekauft. Die News wurde hier im Forum verlinkt.

Nein, das liegt ganz einfach daran, dass egal wie man einen Software-Rasterizer schreibt das Triangle-Setup und der Rasterizer sau viel Zeit kostet die eine normale GPU "for free" nebenhermacht. Und nein das saug ich mir nicht aus den Fingern.
Schade, dass es beim Larrabee nicht for Free ist, weil du ja einen Core dafür opfern willst. Dabei dachte ich, dass gerade die paar Skalarprodukte für das Triangle-Setup perfekt für ein SIMD-Monster wären. Aber nun gut, du bist ja hier der Profi.


Und ja ich habe schon selber einen Software-Rasterizer implementiert. Und wenn du es mir nicht glaubst, dann frag einfach Nick, der wird dir exakt das gleiche erzählen.
Dann bin ich jetzt offiziel beeindruckt, dass die EDGE lib auf einer SPU so schnell skinnt und rasterisiert, dass es am Ende auf der RSX schneller ist, als wenn die RSX selbst das ganze übernimmt. Jedenfalls behauputen das ein paar Leute vom Beyond3D Forum.

Demirug
2008-04-05, 01:02:42
Dann bin ich jetzt offiziel beeindruckt, dass die EDGE lib auf einer SPU so schnell skinnt und rasterisiert, dass es am Ende auf der RSX schneller ist, als wenn die RSX selbst das ganze übernimmt. Jedenfalls behauputen das ein paar Leute vom Beyond3D Forum.

Ich könnte mich täuschen aber soweit mir bekannt wird bei EDGE das rasterizieren nicht auf den SPUs gemacht. Das Ganze ist wohl mehr sowas wie ein Geometrieshader Ersatz.

Coda
2008-04-05, 01:03:02
Und wie willst du dann Hier-Z, Multisampling usw. implementieren? Auch in Software. Alles klar...

Wart's einfach ab.

Schade, dass es beim Larrabee nicht for Free ist, weil du ja einen Core dafür opfern willst. Dabei dachte ich, dass gerade die paar Skalarprodukte für das Triangle-Setup perfekt für ein SIMD-Monster wären. Aber nun gut, du bist ja hier der Profi..
Ich habe gesagt, es wäre immer noch besser einen Core dafür zu opfern als es in Software zu machen. Die Die-Area dafür inkl. der ganzen Overdraw-Reduction usw. dürfte aber wirklich die Größe eines Cores haben.

Und ein Rasterizer ist mehr als bloß ein "paar Skalarprodukte". Mach dich doch nicht lächerlich. Allein den Algorithmus zu implementieren, dass die Quads die aus dem Rasterizer kommen in einer Texture Cache effizienten Reihenfolge hinten aus dem Rasterizer fallen ist in Software einfach nicht performant machbar.

Und deine Polemik kannst du dir auch sparen. Was genau hast du für ein Problem?

Dann bin ich jetzt offiziel beeindruckt, dass die EDGE lib auf einer SPU so schnell skinnt und rasterisiert, dass es am Ende auf der RSX schneller ist, als wenn die RSX selbst das ganze übernimmt. Jedenfalls behauputen das ein paar Leute vom Beyond3D Forum.
Den Satz versteh ich jetzt nich. Wie willst du RSX denn die Rasterisierung abnehmen? Keine Ahnung haben, aber laut rumpoltern und sich dann noch hinter nem anonymen Gast-Account verstecken weil man keine Eier hat. So haben wir das gern.

Und überhaupt: Was ein Geschwätz. Der Hardware-Rasterizer von RSX rennt Zirkel um alles was du auf Cell implementieren könntest. Sony hatte das am Anfang ja wirklich vor und hat es aus gutem Grund bleiben lassen.

Gast
2008-04-05, 01:17:37
Ich könnte mich täuschen aber soweit mir bekannt wird bei EDGE das rasterizieren nicht auf den SPUs gemacht. Das Ganze ist wohl mehr sowas wie ein Geometrieshader Ersatz.
Im Beyond3D-Forum hat einer geschrieben, dass sowohl zero-area als auch zero-pixel Dreiecke verworfen werden. Daraus schliesse ich, dass rasterisiert wird. Es ist zwar einfach rauszufinden, ob ein Dreieck Pixel verdeckt, aber ich kenne keinen Weg um zero-pixel rauszufinden, ohne das Dreieck zu zeichnen. Bis man sich entscheidet es zu zeichnen oder auch nicht zu zeichnen, ist das ganze Setup auch schon durchlaufen.


Und wie willst du dann Hier-Z, Multisampling usw. implementieren? Auch in Software. Alles klar...Hab ich in Software schon gesehen, aber ich glaube du willst hier sowieso nur Zynisch sein. Dann erspar ich mir die Regestrierung und bleibe im Beyond3D.

Ansonsten war es aber nett hier, ciao.

Gast
2008-04-05, 01:21:15
Und deine Polemik kannst du dir auch sparen. Was genau hast du für ein Problem?

Keine Ahnung haben, aber laut rumpoltern und sich dann noch hinter nem anonymen Gast-Account verstecken weil man keine Eier hat. So haben wir das gern.
Dieses Editieren voller Beleidigung hättest du dir echt sparen können. Du bist vielleicht unfreundlich, pha.

Coda
2008-04-05, 01:22:27
Im Beyond3D-Forum hat einer geschrieben, dass sowohl zero-area als auch zero-pixel Dreiecke verworfen werden. Daraus schliesse ich, dass rasterisiert wird.
Wird es nicht. Das kann Cell einfach gar nicht übernehmen. Ob ein Dreieck 0 Flächeninhalt hat kann man ja auch prüfen bevor man das Dreieck an die GPU übermittelt. Das ist wirklich nur ein Kreuzprodukt. Mehr wird da ganz sicher nicht gemacht.

Da steht eh genau was ich sage: http://forum.beyond3d.com/showpost.php?p=956489&postcount=196
Muss ich das dir jetzt alles einzeln auseinandernehmen?

Hab ich in Software schon gesehen
In Software ist alles machbar. Nur brauchst du für jedes weitere Sample nochmal das ganze Setup verschoben separat usw.

Das wird ganz sicher nicht in Software in Larrabee implementiert sein.

Dieses Editieren voller Beleidigung hättest du dir echt sparen können. Du bist vielleicht unfreundlich, pha.
Wenn man nichmal die absolut einfachsten Zusammenhänge versteht muss man sich das gefallen lassen wenn man in diesem Ton auftritt.

Demirug
2008-04-05, 01:27:14
Im Beyond3D-Forum hat einer geschrieben, dass sowohl zero-area als auch zero-pixel Dreiecke verworfen werden. Daraus schliesse ich, dass rasterisiert wird. Es ist zwar einfach rauszufinden, ob ein Dreieck Pixel verdeckt, aber ich kenne keinen Weg um zero-pixel rauszufinden, ohne das Dreieck zu zeichnen. Bis man sich entscheidet es zu zeichnen oder auch nicht zu zeichnen, ist das ganze Setup auch schon durchlaufen.

Das Tri Setup nur der erste Schritt. Dahinter kommt noch jede Menge.

Zero Pixel ist zudem relative einfach zu erkennen. Man ermittelt als letzten Schritt beim Vertex Processing noch die Bildschirm Position. Haben nun alle 3 Vertices des Dreiecks die gleiche Position ist es aufgrund der Rasterisation Rules ein Zero Pixel Dreieck.

Gast
2008-04-05, 01:33:15
Ich könnte mich täuschen aber soweit mir bekannt wird bei EDGE das rasterizieren nicht auf den SPUs gemacht. Das Ganze ist wohl mehr sowas wie ein Geometrieshader Ersatz.
Du glaubst? Nun enttäuschst du mich aber. ;)
Die Lib macht schon mehr als ein GS. Aber Rasterisierung macht sie tatsächlich nicht. Einfaches Culling ja, aber mehr auch nicht.

Demirug
2008-04-05, 01:36:07
Du glaubst? Nun enttäuschst du mich aber. ;)

Genau wissen darf ich es hier ja nicht. ;)

Gast
2008-04-05, 01:52:36
Zero Pixel ist zudem relative einfach zu erkennen. Man ermittelt als letzten Schritt beim Vertex Processing noch die Bildschirm Position. Haben nun alle 3 Vertices des Dreiecks die gleiche Position ist es aufgrund der Rasterisation Rules ein Zero Pixel Dreieck.
Du meinst Zero Area Dreieck.

Coda
2008-04-05, 02:05:10
Nein er meint Zero Pixel. Wenn du die Auflösung + Rasterization Rules kennst kannst du das auch ausrechnen.

misterh
2008-04-05, 02:09:03
Sollte – tut sie aber oft nicht. Zwischen 1680x1050 und 800x600 liegt oft "nur" eine Halbierung der Frames.

MfG,
Raff

und hier?

Team Fortress 2

Q6600 @ SwiftShader 2.0

640x480
Avg: 5.232 - Min: 1 - Max: 10

1024x768
Avg: 2.729 - Min: 1 - Max: 5

1920x1080
Avg: 1.490 - Min: 0 - Max: 3

BlackArchon
2008-04-05, 08:33:41
Wenn bei Swiftshader die Kommunikation zwischen den CPU-Kernen sehr wichtig ist, müsste dann hier nicht ein Phenom Vorteile haben? Ob mal jemand mit einem Phenom hier testen könnte?

easteregg
2008-04-05, 13:18:37
also ich hab das mal auf meinem dual opteron mit 4x2,2 ghz probiert, da habsch im 3dmark 181 punkte mit den standardsettings, ich werd das system gleich mal auf 2,7 hochziehen und nochmal probiern, mal sehen wie das übern takt sklaiert!

mit quad optis kannsch derzeit noch nicht dienen ;)

edit: mit 4x 2,75: 213 3dmarks!

Raff
2008-04-05, 15:59:32
Kann das Ding anisotrop filtern (lassen)? Der Standardfilter ist bilinear. AF müsste nochmal übelst auf die Fps gehen ...

MfG,
Raff

Coda
2008-04-05, 16:02:37
Nein AF und AA gibt's nicht.

Raff
2008-04-05, 16:19:10
Und wie schaut's mit trilinear aus?

Wäre es möglich, dass den Spaß jemand bei Rapidshare oder www.keepmyfile.com hochlädt? Die blöde Siffshader-Seite geht bei mir nicht mehr und ich mag das Teil trotzdem mal hier in der Heimat testen. Pentium-M ftw.

MfG,
Raff

Coda
2008-04-05, 16:48:58
http://rapidshare.com/files/105076319/swiftshader_v20_demo.zip.html

_DrillSarge]I[
2008-04-05, 17:05:24
dasselbe nochmal für alle die waitingshare ned mögen ;)
http://files.filefront.com/swiftshader+v20+demozip/;9953963;/fileinfo.html

AnarchX
2008-04-05, 17:21:03
Und wie schaut's mit trilinear aus?


Soll er laut Entwickler können, via ini und Configtool einstellbar.

Gast
2008-04-05, 19:15:56
3dmark2001

in einer VM (nur singlecore):

http://img395.imageshack.us/img395/2866/swiftshadervmzn2.png


direkt im hostsystem (dualcore):

http://img395.imageshack.us/img395/1216/swiftshadergg9.png

Raff
2008-04-05, 19:16:01
http://rapidshare.com/files/105076319/swiftshader_v20_demo.zip.html

I[;6409466']dasselbe nochmal für alle die waitingshare ned mögen ;)
http://files.filefront.com/swiftshader+v20+demozip/;9953963;/fileinfo.html

Vielen Dank! =)

MfG,
Raff

Gast
2008-04-05, 19:18:44
Wenn bei Swiftshader die Kommunikation zwischen den CPU-Kernen sehr wichtig ist, müsste dann hier nicht ein Phenom Vorteile haben?

eher sollte er seinen vorteil nicht ausspielen können. bei intel greifen eh alle kerne über den selben memory-controller auf den speicher zu, bei AMD kann es dagegen vorkommen dass ein kern über die andere cpu auf den speicher zugreifen muss.

Raff
2008-04-05, 20:17:46
Mal so nebenbei: Das Ding mag zwar kein AF können ... aber die erste erste Version konnte noch nicht einmal korrekt bilinear filtern:

http://666kb.com/i/axjtcu3kl181u393l.jpg

Das sah noch schwer nach "Software" aus. Das ist Version 2.0:

http://666kb.com/i/axjtddrneue8wb5xt.jpg

Perspektivisch korrekt interpoliert und MIP-mapped. Vermutlich ist das Teil deswegen auch auf dem einst so rasend schnellen Dothan langsamer (und sonst überall schneller)

MfG,
Raff

Gast
2008-04-05, 20:41:41
eigentlich müsste ein phenom mit ddr2-1066 ram deutliche vorteile haben, wo ist intel gerade? bei 333mhz fsb? macht quadpumped gerade mal dualchannel ddr2-667.

Gast
2008-04-05, 20:46:47
eigentlich müsste ein phenom mit ddr2-1066 ram deutliche vorteile haben, wo ist intel gerade? bei 333mhz fsb? macht quadpumped gerade mal dualchannel ddr2-667.

vergiss nicht, dass CPUs (insbesondere bei intel) sehr große caches haben, da spielt die externe bandbreite keine so große rolle. (bzw. ist intel zumindest teilweise bei FSB1600 angelangt)

Gast
2008-04-05, 20:52:08
gut is 400mhz bei intel also quadpumped 1600 dingsda, dann sinds immernoch nur ddr2-800

Gast
2008-04-05, 22:25:39
gut is 400mhz bei intel also quadpumped 1600 dingsda, dann sinds immernoch nur ddr2-800


ja, aber 100GB/s zu immerhin 4 bzw. 6MiB an cache, der fängt schon einiges ab.

Gast
2008-04-06, 10:11:16
und wie gut ist die kommunikation der beiden caches der intel quadcores?

am besten wäre mal ein benchmark zwischen phenom und intel quad

Gast
2008-04-06, 10:51:23
Schon beeindruckend was so eine kleine "Klitsche" da hinbekommen hat.

Was wohl jemand wie Intel da theoretisch noch rausholen könnte wenn sie ein paar hundert Leute dransetzten und ein Jahr lang für Nehalem optimieren würden (CPU-only, nicht Larrabee)?

Aquaschaf
2008-04-06, 11:09:03
Was wohl jemand wie Intel da theoretisch noch rausholen könnte wenn sie ein paar hundert Leute dransetzten und ein Jahr lang für Nehalem optimieren würden (CPU-only, nicht Larrabee)?

Sehr viel mehr vermutlich auch nicht.

Gast
2008-04-06, 11:52:48
Schon beeindruckend was so eine kleine "Klitsche" da hinbekommen hat.

eher beeindruckend, was GPUs leisten. heutige cpus erreichen damit nichtmal die leistung von GPUs vor 8 jahren (und das sogar bei schlechterer qualität)


Was wohl jemand wie Intel da theoretisch noch rausholen könnte wenn sie ein paar hundert Leute dransetzten und ein Jahr lang für Nehalem optimieren würden (CPU-only, nicht Larrabee)?

viel wird da wohl nicht drinnen sein, die neuen SSE-befehle im nehalem sind soweit ich es gesehen hab für rendering kaum zu gebrauchen und ansonsten dürfte es kaum mehr optimierungspotential geben.

Shink
2008-04-30, 21:36:15
eher beeindruckend, was GPUs leisten. heutige cpus erreichen damit nichtmal die leistung von GPUs vor 8 jahren (und das sogar bei schlechterer qualität)
Naja, GPUs benötigen auch viel mehr Strom und Transistoren als CPUs. Einfache GPUs (wie in IGPs) liefern ja auch keine bessere Leistung als die CPUs mit so einem Produkt.

Was ich mich frage: Könnte man das auch für OpenGL machen? Bei der Qualität vieler Linux-Treiber wäre das doch wesentlich sinnvoller denke ich. Immerhin ist Transgaming doch auch in dieser Welt zuhause...

Aquaschaf
2008-05-01, 00:52:47
Naja, GPUs benötigen auch viel mehr Strom und Transistoren als CPUs.

Es reicht ja schon eine Lowend-GPU um sehr viel besser zu sein als Software-Rendering.

LovesuckZ
2008-05-01, 01:07:01
Naja, GPUs benötigen auch viel mehr Strom und Transistoren als CPUs. Einfache GPUs (wie in IGPs) liefern ja auch keine bessere Leistung als die CPUs mit so einem Produkt.


Phenom hat genauso viele Transistoren wie ein G80.

Und der beste Phenom verbraucht ja auch schon fast 125 Watt - ohne Mainboard und Speicher.

IceKillFX57
2008-05-01, 01:57:12
kann man die Demo auch ohne Reg. irgendwie bekommen? -.-

AnarchX
2008-05-01, 09:50:06
http://www.transgaming.com/products/swiftshader/download/swiftshader_v20_demo.zip

IceKillFX57
2008-05-01, 12:38:09
wohin müssen die Files und ähm wie starte ich es dann?
Ich weiss steht alles in der readme aber will nix falsch machen.

Coda
2008-05-01, 16:39:34
Phenom hat genauso viele Transistoren wie ein G80.
Davon sind wohl fast 75% Cache. Das kannst du nicht vergleichen.