S3 Grafikkarte [Archiv] - 3DCenter Forum

stickedy

2002-08-04, 03:03:59

S3 und Diamond gibts schon lange nimmer... Das was früher Diamond Multimedia war heißt jetzt SonicBlue und das was fürher S3 war gehört jetzt zu VIA und nennt sich S3 Graphics. Und S3 Graphics entwickelt sehr wohl noch Grafikchips... Aber SonicBlue wird wohl keine Grafikkarten mehr verkaufen...

Der Savage XP sollte irgendwann bald erhältlich sein. Erwarte aber keine Wunder von diesem Chip! Ich würde ihn bestenfalls auf GF4-MX440-Niveau schätzen, eher aber MX420...
Der Chip wird S3TC natürlich beherrschen. Alles andere zum Chip findest du hier: http://www.s3graphics.com/prod_frame_SavageXP.htm

Preed

2002-08-04, 03:27:06

Ok..geb ja zu das die News etwas älter war...

Ikon

2002-08-04, 12:17:09

Originally posted by Cooli Kann sie dann auch S3TC?

S3TC war schon Teil der DX6-Spezifikation und ich kann mir nicht vorstellen, dass heute noch ein Chip ohne S3TC-Support released wird.

Cooli

2002-08-04, 12:59:18

Mir reicht es wenn die Grafikkarte ne Geschwindigkeit von einer GeForce 4 MX hat, die käm dann nur bei mir in den Zweitrechner, an dem zock ich dann eh nur selten. Und S3TC wär halt gut für UT.

mirage

2002-08-04, 13:19:45

Hi,

mal was anderes, könnt ihr euch noch an die Guten Alten Zeiten erinnnern??? Ich war damals so stolz auf meine Diamond Stealth S540 mit 32MB-RAM, das waren noch Zeiten, hmm.

Sorry, war jetzt a bisl Offtopic

Ikon

2002-08-04, 14:57:07

Originally posted by Cooli
Und S3TC wär halt gut für UT.

Um es anders auszudrücken: jede Graka seit mind. 3 Jahren unterstützt S3TC.

HOT

2002-08-04, 15:08:10

Aber keine kommt an die Qualität der Savage Chip ran. Und kein Chip profitiert derart dadurch.

2002-08-04, 16:04:54

Originally posted by HOT
Aber keine kommt an die Qualität der Savage Chip ran. Und kein Chip profitiert derart dadurch.

Wie ist denn das zu verstehen mit dem Profitieren?

StefanV

2002-08-04, 16:09:59

Originally posted by ow
Wie ist denn das zu verstehen mit dem Profitieren?

War auf S3TC bezogen.

Er meinte:

Bei keinem Chip sieht S3TC besser aus und bei keinem Chip ist der Leistungsunterschied größer (außer vielleicht der Power VR Serie3)

2002-08-04, 16:28:38

Originally posted by Stefan Payne

War auf S3TC bezogen.

Er meinte:

Bei keinem Chip sieht S3TC besser aus und bei keinem Chip ist der Leistungsunterschied größer (außer vielleicht der Power VR Serie3)

Gibt´s auch Quellen, die das beides belegen?

StefanV

2002-08-04, 16:34:48

Originally posted by ow
Gibt´s auch Quellen, die das beides belegen?

Irgendwo hab ich das mal gelesen...

Gab mal 'ne Seite, die das Gebencht hat, versuch mal Savage Fan Sites und Digilife...

zum selbst fälschen hab ich gerad keine lust :)

Radeonator

2002-08-04, 17:13:23

Eine "Quelle" nennt sich Erfahrung...;)
Hatte seiner Zeit auch die Savage4 Extrem und da sah S3TC(vor allem ist es in Hardware) wirklich besser aus als das heutige FXT1/DXT1-x
S3TCvsFXT1 (http://www.digit-life.com/articles/reviews3tcfxt1/)
Archive (http://217.160.31.24/news/2000-08/19-1.php)

Quasar

2002-08-04, 17:26:48

Nach dem Vergleich von Digit-Life zu urteilen, sieht S3TC wirklich besser aus, als DXTC-1. Nur gibt's genau wegen dieser Artefakte eben die Auswahl zwischen mehreren Verfahren bei DXTC und FXTC. Mich würde nicht wundern, wenn S3TC selbiges intern auch durchführt...

2002-08-04, 17:37:31

Originally posted by Radeonator
Eine "Quelle" nennt sich Erfahrung...;)
Hatte seiner Zeit auch die Savage4 Extrem und da sah S3TC(vor allem ist es in Hardware) wirklich besser aus als das heutige FXT1/DXT1-x
S3TCvsFXT1 (http://www.digit-life.com/articles/reviews3tcfxt1/)
Archive (http://217.160.31.24/news/2000-08/19-1.php)

Ob die Kompression in HW besser aussieht als in SW kann man bezweifeln (HW T&L sieht ja auhc nicht besser aus als Sw T&L). Und bei vorkomprimierten Texturen ist es eh egal.

Thx für die Links.:)

zeckensack

2002-08-05, 01:41:04

Originally posted by Radeonator
Eine "Quelle" nennt sich Erfahrung...;)
Hatte seiner Zeit auch die Savage4 Extrem und da sah S3TC(vor allem ist es in Hardware) wirklich besser aus als das heutige FXT1/DXT1-xEigentlich sind S3TC und DXTx aber das gleiche Verfahren.
(FXT1 ist anders, aber mittlerweile wohl nicht mehr relevant)
Kann natürlich sein, daß dem einen oder anderen Hersteller ...
*nhuust*
die Hardwaredekompression nicht immer ganz perfekt gelungen ist.
Dann würde ich aber sagen, der Chip kann das besser, nicht S3TC ist besser ;)

vogel

2002-08-05, 02:45:51

Originally posted by Ikon
Um es anders auszudrücken: jede Graka seit mind. 3 Jahren unterstützt S3TC.
*cough* Kyro II *cough*

-- Daniel, Epic Games Inc.

Ikon

2002-08-05, 06:40:31

Originally posted by vogel
*cough* Kyro II *cough*

-- Daniel, Epic Games Inc.

Das soll wohl nein heißen ... aber DXTC beherrscht er offensichtlich. Schon etwas seltsam, PVR war wohl zu faul S3TC zu lizensieren ...

Quasar

2002-08-05, 06:43:45

Ja, aber Kyro kann nur eines der DXTC verfahren, entweder DXTC1 oder DXTC3, ich weiß aber nicht mehr genau welches...

Ikon

2002-08-05, 06:47:18

Hab' gerade eine Liste der vom Kyro unterstützten Texturformate gefunden:

RGB565
RGB555
RGB1555
RGB4444
RGB8332
RGB8888
ALPHA8
LUMA88
BUMP565
BUMP88
DXT1

Ebenfalls seltsam: DXT3, DXT5, etc. scheint PVR auch "vergessen" zu haben ... und wofür sind dieser ganzen RGBxxxx-Formate?

vogel

2002-08-05, 06:49:36

DXTC == S3TC

Kyro kann DXT 1 aber nicht DXT 2-5.

-- Daniel, Epic Games Inc.

Quasar

2002-08-05, 07:09:50

Originally posted by Ikon
und wofür sind dieser ganzen RGBxxxx-Formate?

Das sind die "normalen" unkomprimierten Texturformate. Je nachdem, auf welchen Kanal man eine besonders gute Farb-Auflösung benötigt, kann man für red,green,blue und alpha unterschiedliche (5650) oder gleiche (8888) Bittiefen pro Kanal wählen. Wenn z.B. gar kein alpha-Kanal vorhanden ist, spart man Bandbreite, indem man einfach ein "RGB"-Format ohne "a" wählt. Für den vollen Farbraum nimmt man einfach überall 8Bit (RGBA8888).

Ikon

2002-08-05, 08:01:07

Thx @ Quasar

Dennoch seltsam, dass der Kyro nur ein komprimiertes Texturformat unterstützt, und dann noch 16bit *iiek*

HOT

2002-08-05, 10:07:42

PowerVR HAT S3TC lizensiert, sonst wäre es unter OpenGL nicht nutzbar.
Für DX ist Lizenz über M$ kostenlos.
PowerVR reichte anscheinend DXT1, die anderen DXT Formate werden ja auch so gut wie garnicht benutzt (ausser vielleicht in der 3DMark ;))

2002-08-05, 10:12:43

HOT:

Fuer transparente Texture kann man kein DXT1 gebrauchen, also wie soll das PVR 'reichen'?

ALLE anderen Chip unterstuetzen DXTC/S3TC komplett, nur das ist wirklich sinnvoll.

Fehlendes DXT2-5 ist uebrigens etwas, was ich am K2SE bemaengele.
Volle DXTC Unterstuetzung haette diese Chip-Neuauflage schon aufgewertet.

HOT

2002-08-05, 11:20:16

Theoretisch ja. Aber da in der Praxis nur DXT1 relevant ist, hat PowerVR mit der Series3 architektur absolut recht.

2002-08-05, 12:11:06

???

In der Praxis sind alle DXTC Formate relevant. S.a. UT2003, das DXT3 benutzen wird.

Ich versteh deine Argumentation nicht.

Radeonator

2002-08-05, 13:41:55

Aber die meisten unterstützen AFAIK in Emuliert/Software oder???

HOT

2002-08-05, 14:02:56

UT 2003 ist auch so neu, dass die Serie3 Architektur sowieso aus dem letzten Loch pfeift. Für die Zeit, in der der Chip relevant war, war DXT1 angesagt, nix anderes.

zeckensack

2002-08-05, 14:56:34

Originally posted by Radeonator
Aber die meisten unterstützen AFAIK in Emuliert/Software oder??? Geht nicht wirklich. Ist ein ähnliches Problem wie bei den Pixel Shadern. Eine Sache, die so weit hinten in der Pipeline gemacht werden muß, kann man nur dann vernünftig 'emulieren', wenn man alles in Software rendert.
Der Treiber könnte natürlich die Textur einfach in ein (unkomprimiertes) Texturformat umwandeln, das der Chip direkt verarbeiten kann. Dann ist aber der Vorteil der Texturkompression wieder weg.

Bandbreite wird nur dann gespart, wenn der Chip direkt beim Texturieren die Dekompression 'on the fly' durchführen kann. Ansonsten läuft es eben auf ein unkomprimiertes Texturformat raus, was das Spiel aber dann auch gleich selbst machen kann. Emulation lohnt sich einfach nicht.

2002-08-05, 16:46:10

Originally posted by HOT
UT 2003 ist auch so neu, dass die Serie3 Architektur sowieso aus dem letzten Loch pfeift. Für die Zeit, in der der Chip relevant war, war DXT1 angesagt, nix anderes.

Achso, PVR hatte also die besten Hellseher, um schon waehrend der Entwicklungszeit des Kyro zu wissen, das nur DXT1 genutzt wird.;)
Was ja so auch gar nicht stimmt. Es wird auch DXT3 genutzt, zB. im 3DMark.

AFAIK darf ein Chip unter D3D auch nur dann TC-Unterstuetzung (cpas bits) melden, wenn DXTC komplett unterstuetzt wird. Also unterstuetzt der Kyro offiziell kein DXTC.

Wie's unter OGL ist weiss ich nicht.

Zeckensack, du weisst das doch bestimmt.:)
Um die TC-Extensions (GL_EXT, GL_ARB) zu unterstuetzen, welche TC-Formate muss ein Chip beherrschen??

Demirug

2002-08-05, 16:52:13

Originally posted by ow
AFAIK darf ein Chip unter D3D auch nur dann TC-Unterstuetzung (cpas bits) melden, wenn DXTC komplett unterstuetzt wird. Also unterstuetzt der Kyro offiziell kein DXTC.

Bei DX gibt es kein TC Caps bit die unterstützten Texturformate werden einzeln gemeldet.

2002-08-05, 16:59:25

Na wenn das so ist, dann nehme ich meine Behauptung zurueck.

Die TC Formate werden also wie auch die unkomprimierten einfach der Applikation gemeldet?
So in der Art: "ich kann RGB888, ARGB8888,DXT1, ..."

Da frage ich mich, warum der Kyro unter den Treiberoptionen sowas hat wie "export DXTC caps" (ich glaube so hiess das, muss spaeter mal nachschauen).

zeckensack

2002-08-05, 17:22:35

Originally posted by ow
Zeckensack, du weisst das doch bestimmt.:)
Um die TC-Extensions (GL_EXT, GL_ARB) zu unterstuetzen, welche TC-Formate muss ein Chip beherrschen?? Jau, ich weiß das :D

Grundsätzlich muß der Chip eigentlich überhaupt nichts können, um GL_ARB_texture_compression zu melden ;)
Kann irgendwas bekanntes sein (S3TC), irgendwas völlig anderes (FXT1) oder eben auch garnichts. GL_ARB_texture_compression ist nur ein allgemeines 'Framework', ohne auf spezielle Verfahren Rücksicht zu nehmen.
Natürlich wird diese Extension nur angeboten, wenn mindestens ein (irgendwie geartetes) komprimiertes Format unterstützt wird, ansonsten wär's Unsinn. Dieses Format kann aber (ich sag's so geren) alles mögliche sein.
In der Praxis ist's trotzdem meist S3TC, weil die Consumer-Chips ja auch mit D3D (und den da vorherrschenden anders tickenden Uhren) zurecht kommen sollen.

Da kann man dann noch andere Extensions obendrauf setzen, muß man aber nicht:
Extensions wie GL_S3_s3tc sagen dem Programm erstens, daß der Treiber dieses Format überhaupt kennt (dh die Tokens GL_COMPRESSED_RGB_S3TC_DXTx können ohne Fehlermeldungen genutzt werden), und zweitens, daß Texturen auch bereits in diesem Format vorkomprimiert an den Treiber übergeben werden dürfen.

Die Texturverwaltung unter OpenGL läuft nämlich immer so ab, daß man dem Treiber sagt, in welchem Format man die Textur übergibt (zB unkomprimiert GL_RGB8), und welches interne Format man denn gerne hätte (zB GL_COMPRESSED_RGB_S3TC_DXT1, es gehen aber auch völlig generische Angaben wie GL_COMPRESSED_RGB :o ). Der macht dann sein eigenes Ding, im Rahmen seiner Möglichkeiten soll aber die geforderte Farbauflösung mindestens eingehalten werden.
Unter OpenGL gibt es keine vom Programm durchgeführte Schreib/Lesezugriffe auf den Texturspeicher, deswegen kann alles in alles andere konvertiert werden (vom Treiber), so wie's halt gerade am besten paßt.

2002-08-05, 19:15:50

wow, ich bin beeindruckt

thx:)
Und wieder eine Menge gelernt.

Wenn ich das recht verstanden habe, kann man auch GL_ARB_texture_compression und zB. GL_S3_s3tc gleichzeitig nutzen.
Macht das Sinn? Wenn doch GL_ARB_texture_compression alle Kompressionsverfahren unterstützt? Oder gehen vorkomprimierte Texturen nur mit GL_S3_s3tc oder auch GL_EXT_texture_compression_s3tc (falls das nicht dasselbe ist?)
(In Dronezmark lassen sich beide Verfahren (GL_ARB_ und GL_EXT_) getrennt einstellen)

Lässt sich herausfinden, was ein Chip nutzt anhand von Tests?

HOT

2002-08-05, 19:30:30

Um nochmal auf die Kristallkugel zurückzukommen:
PowerVR dachte eben, dass DXT1 in der Zeit, in der der Kyro "aktiv" ist, ausreichen würde. Damit stützten sie sich auf Erfahrungen, die S3 und NVidia zu dem Zeitpunkt gemacht haben.
Man bedenke hierbei auch noch, dass Der K2 so von Imagetech niemlas geplant war, sondern nur das original.

zeckensack

2002-08-05, 19:47:07

Originally posted by ow
Wenn ich das recht verstanden habe, kann man auch GL_ARB_texture_compression und zB. GL_S3_s3tc gleichzeitig nutzen.Jein. ARB_blub bildet das Framework, das die Extensions zu spezifischen Verfahren mitbenutzen. Wer S3TC benutzt, kann garnicht anders, als die ARB-Extension auch zu benutzen.

EXT_texture_compression_s3tc (http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt)
ARB_texture_compression (http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt)
Name

EXT_texture_compression_s3tc

Name Strings

GL_EXT_texture_compression_s3tc

<...>

Dependencies

OpenGL 1.1 is required.

GL_ARB_texture_compression is required.

This extension is written against the OpenGL 1.2.1 Specification.

Btw, die Spec für S3_s3tc ist nicht mehr zu bekommen. Weg, futsch :|
Ist wahrscheinlich aufgeteilt worden in zwei Extensions, einmal das ARB-Framework und die obige EXT.

Macht das Sinn? Wenn doch GL_ARB_texture_compression alle Kompressionsverfahren unterstützt? Oder gehen vorkomprimierte Texturen nur mit GL_S3_s3tc oder auch GL_EXT_texture_compression_s3tc (falls das nicht dasselbe ist?)
(In Dronezmark lassen sich beide Verfahren (GL_ARB_ und GL_EXT_) getrennt einstellen) Vorkomprimierte Texturen gehen natürlich nur dann, wenn sich Treiber und Applikation über das Kompressionsverfahren einig sind.
-> man braucht dafür die spezielle S3TC-Extension
"Beides getrennt" geht nicht ... es geht halt Hand in Hand.

Wenn nur die ARB-Extension vorhanden ist, hat man keine Kontrolle über das genaue Kompressionsverfahren und kann auch keine vorkomprimierten Texturen nutzen. Ich schätze mal, daß DroneZ im Zweifelsfall darauf ausgelegt ist, auch unbekannte (zukünftige) Kompressionstechniken nutzen zu können, und deswegen eine 'getrennte' Einstellmöglichkeit für die ARB-Extension hat. IMO wird das Kind dann einfach nicht mehr bein Namen (S3TC) genannt, anders kann ich mir das auch nicht vorstellen.

Zudem, ein Treiber, der nur die S3TC-Extension meldet, nicht aber das ARB-Framework, darf eigentlich nicht existieren.
edit: Oder er ist zu alt für sowas, dann gibt's aber auch nur die mittlerweile wieder abgeschaffte S3_s3tc.
Lässt sich herausfinden, was ein Chip nutzt anhand von Tests? Wenn man die Grenzen der Verfahren genau kennt, dann ja. Ich mag jetzt aber nicht :D

2002-08-05, 20:17:22

Originally posted by HOT
Um nochmal auf die Kristallkugel zurückzukommen:
PowerVR dachte eben, dass DXT1 in der Zeit, in der der Kyro "aktiv" ist, ausreichen würde. Damit stützten sie sich auf Erfahrungen, die S3 und NVidia zu dem Zeitpunkt gemacht haben.
Man bedenke hierbei auch noch, dass Der K2 so von Imagetech niemlas geplant war, sondern nur das original.

Das ist aber nicht sehr vorausschauend gedacht.

Wieso sollte der K2 nie geplant gewesen sein?
Gibts´ den nicht auf alten PVR Roadmaps?
PVR musste doch klar sein, dass man nicht über Jahre mit einem Chip auskommt.

2002-08-05, 20:19:49

thx:) @zeckensack

Demirug

2002-08-05, 20:22:38

Originally posted by ow
Na wenn das so ist, dann nehme ich meine Behauptung zurueck.

Die TC Formate werden also wie auch die unkomprimierten einfach der Applikation gemeldet?
So in der Art: "ich kann RGB888, ARGB8888,DXT1, ..."

Da frage ich mich, warum der Kyro unter den Treiberoptionen sowas hat wie "export DXTC caps" (ich glaube so hiess das, muss spaeter mal nachschauen).

Die Liste muss man schon noch selbst aufbauen in dem man über DX den Treiber fragt ob er für das gewünschte Backbufferformat auch das entsprechede Texturformat unterstützt.

Unregistered

2002-08-06, 12:09:19

Originally posted by ow
Das ist aber nicht sehr vorausschauend gedacht.

Wieso sollte der K2 nie geplant gewesen sein?
Gibts´ den nicht auf alten PVR Roadmaps?
PVR musste doch klar sein, dass man nicht über Jahre mit einem Chip auskommt.

Wiedermal zu Erinnerung: PowerVR stellt keine Grafikchips her!! PowerVR entwickelt jediglich die Technik und den 3D-Kern. Was der jeweilige Lizenznehmer (in diesem Fall STMicro) mit dem Kern anstellen ist ihre Sache. STMicro hatte sich entschlossen dem kyro mit 115 MHz noch eine auf 0,18 µ geshrinkte Version mit 175 MHz folgen zu lassen. Technisch sind beide identisch (Unterschiede bei AGP). Und jetzt haben sie mit dem K2SE nochmal nachgelegt (wieder technisch keine Unterschiede bis auf AGP)...
Ich glaube nicht, daß das von PowerVR so geplant war! Ursprünglich sollte ja der STG5000, also Series4, mit ca. 166 MHz Anfang/Mitte 2001 kommen! Dieser wurde aber dann gestrichen und dafür sollte gleich der STG5500 Ende 2001/Anfang2002 erscheinen (afaik gleiche Technik wie der STG5000, nur Die-Shrink)...
D.h. das usprünglich die Technik des Kyro I eigentlich spätestens Mitte 2001 ad acta gelegt werden sollte... Das erklärt imho die Sache mit DXT1

2002-08-06, 12:31:35

Originally posted by Unregistered

Wiedermal zu Erinnerung: PowerVR stellt keine Grafikchips her!! PowerVR entwickelt jediglich die Technik und den 3D-Kern. Was der jeweilige Lizenznehmer (in diesem Fall STMicro) mit dem Kern anstellen ist ihre Sache. STMicro hatte sich entschlossen dem kyro mit 115 MHz noch eine auf 0,18 µ geshrinkte Version mit 175 MHz folgen zu lassen. Technisch sind beide identisch (Unterschiede bei AGP). Und jetzt haben sie mit dem K2SE nochmal nachgelegt (wieder technisch keine Unterschiede bis auf AGP)...

Der K2 ist aber nicht nur eine geshrinkte Version des K1. Immerhin hat er 3Mio Transistoren mehr.
Von wem kommen denn die Folien zur Produktion? PVR oder STM??

Ich glaube nicht, daß das von PowerVR so geplant war! Ursprünglich sollte ja der STG5000, also Series4, mit ca. 166 MHz Anfang/Mitte 2001 kommen! Dieser wurde aber dann gestrichen und dafür sollte gleich der STG5500 Ende 2001/Anfang2002 erscheinen (afaik gleiche Technik wie der STG5000, nur Die-Shrink)...
D.h. das usprünglich die Technik des Kyro I eigentlich spätestens Mitte 2001 ad acta gelegt werden sollte... Das erklärt imho die Sache mit DXT1

Die Sache mit DXT1 ist IMO nicht zu erklaeren. S3 hatte zu dem Zeitpunkt schon Chips mit kompletter DXTC Unterstuetzung auf dem Markt.

Unregistered

2002-08-06, 13:16:05

Originally posted by ow

Der K2 ist aber nicht nur eine geshrinkte Version des K1. Immerhin hat er 3Mio Transistoren mehr.
Von wem kommen denn die Folien zur Produktion? PVR oder STM??

Doch ist er! STMicro hat die zusätzlichen Transisoren hinzugefügt um höhere Taktraten zu erzielen. Anosnsten sind die Chips identisch! Wenn du Kyro I und Kyro II mit der gleichen Taktrate vergleichst erhälst du im Rahmen der Meßgenauigkeit identische Ergebnisse!!
Welche Folien meinst du? Meinst du die Produktions-Masken? Die kommen natürlich von STM!

Die Sache mit DXT1 ist IMO nicht zu erklaeren. S3 hatte zu dem Zeitpunkt schon Chips mit kompletter DXTC Unterstuetzung auf dem Markt.
Und? Nvidia hatte zu dem Zeitpunkt Chips mit Hardware T&L auf dem Markt... Was ist das für ein Vergleich mit S3? Wichtig ist, was benötigt wurde und damals war kein DXT > 1 nötig... Man konnte während der Entwicklung nicht damit rechnen das die Series3 ca. zwei Jahre länger als gedacht am Markt ist...

Ikon

2002-08-06, 13:20:31

Originally posted by Unregistered
Und? Nvidia hatte zu dem Zeitpunkt Chips mit Hardware T&L auf dem Markt... Was ist das für ein Vergleich mit S3? Wichtig ist, was benötigt wurde und damals war kein DXT > 1 nötig... Man konnte während der Entwicklung nicht damit rechnen das die Series3 ca. zwei Jahre länger als gedacht am Markt ist...

Also dass 2001 noch 16bit-Farbtiefe Standard war (auch bei der Texturenkompression), kann man wirklich nicht sagen, aber genau das ist es was du implizierst. Das erinnert ja schon fast an Voodoo-Zeiten ...

2002-08-06, 13:29:41

Originally posted by Unregistered

Doch ist er! STMicro hat die zusätzlichen Transisoren hinzugefügt um höhere Taktraten zu erzielen. Anosnsten sind die Chips identisch! Wenn du Kyro I und Kyro II mit der gleichen Taktrate vergleichst erhälst du im Rahmen der Meßgenauigkeit identische Ergebnisse!!
Welche Folien meinst du? Meinst du die Produktions-Masken? Die kommen natürlich von STM!

Also ist STM fuer das Chiplayout verantwortlich wenn ich das richtig verstanden habe.

Und? Nvidia hatte zu dem Zeitpunkt Chips mit Hardware T&L auf dem Markt... Was ist das für ein Vergleich mit S3? Wichtig ist, was benötigt wurde und damals war kein DXT > 1 nötig... Man konnte während der Entwicklung nicht damit rechnen das die Series3 ca. zwei Jahre länger als gedacht am Markt ist...

Das hoert sich wieder sehr hellseherisch an. Ich habe das oben schon mal kommentiert.

Wie kann man einfach annehemen, das nicht ueberwiegend DXT3 benutzt wird, weil nur das fuer transparente Texturen taugt??

Radeonator

2002-08-06, 14:21:03

Schaut mal bitte hier (http://www.s3graphics.com/) und erklärt mir ob ihr daraus schlau werdet, was dort zu SavageXP an infos steht...

Ikon

2002-08-06, 14:23:36

Originally posted by Radeonator
Schaut mal bitte hier (http://www.s3graphics.com/) und erklärt mir ob ihr daraus schlau werdet, was dort zu SavageXP an infos steht...

Whats the Problem? Leseschwäche?

Radeonator

2002-08-06, 14:36:43

Originally posted by Ikon

Whats the Problem? Leseschwäche?

Ehm, ja genau...:bonk:

Nein, blos stand in diversen Previews zu lesen "keine HW PS/VS" da steht aber

"Hardware Vertex Geometry Processing:

Hardware Transform and Lighting fully compatible with
Microsoft DX7 and DX8 requirements
Compatible with DX8 and DX8.1 Vertex and Pixel Shader implementations
Support up to 8 lighting sources
Per Vertex Lighting computation
Hardware Support for Indexed Vertex Cache
"...
das meinte ich ;)

Ikon

2002-08-06, 14:44:03

Naja, da steht auch nix von HW VS/PS. Das sind wohl die "schwammigen" Specs von denen vor kurzen in den 3DC-News zu lesen war. Aber eigenlich ist es auch egal, da der Chip mit den restlichen Eckdaten höchstens den Titel "DX8-Schnecke" verdiesen würde.

Radeonator

2002-08-06, 14:51:59

Die wollen sich auch nur mit der untersten GF4MX Garde messen, wen wunderts...;)

zeckensack

2002-08-06, 15:14:35

Originally posted by Radeonator
Schaut mal bitte hier (http://www.s3graphics.com/) und erklärt mir ob ihr daraus schlau werdet, was dort zu SavageXP an infos steht... Definitiv DX7-T&L.

Begründung:
http://www.s3graphics.com/prod_savagexp_features.htm
3 Graphics Transform & Lighting - S3Graphics provides hardware accelerated second generation Transform and Lighting fully compatible with Microsoft DX7 and DX8. The 3D engine is designed for AGP texturing from system memory and provides peak performance with full 3D feature set enabled including tri- linear filtering, specular and diffuse lighting, perspective correction and fogging. The geometry processing and high throughput pixel pipeline allows for an optimal balance of hardware acceleration supported by host optimized Vertex Shader implementations.

Second generation -> besser als im Savage2000 ;)
Vergleich mit Geforce2GTS

host = Wirt, in diesem Fall das System in dem die Graka läuft, aber eben nicht die Graka selber. Ergo die CPU.

zeckensack

2002-08-06, 15:24:18

Stutzig macht mich dieses:
http://www.s3graphics.com/prod_savagexp_specs.htm
Compatible with DX8 and DX8.1 Vertex and Pixel Shader implementationsErstmal sagt 'compatible' überhaupt nichts, das ist ganz wichtig.

Mein Netzteil ist durchaus kompatibel zu einem Handelsüblichen Zigarettenanzünder, eine Spezifikation, auf die sich die großen Autohersteller geeinigt haben. Schließlich kommt (unter anderem) 12Volt Gleichstrom raus. Womit aber nicht ausgesagt wird, daß der Zigarettenanzünder bereits integriert ist ;)

Daß der Chip zu DX8.1 'vertex shader implementations' kompatibel ist, wundert mich überhaupt nicht, bedeutet aber auch nichts. Es besagt lediglich, daß die DX8.1-Softwarelösung für Vertex Shader in Verbindung mit diesem Chip genutzt werden kann. Jede RivaTNT kann das selbstredend auch.

Aber das mit den Pixel Shadern ... :|

Entweder verkauft S3 hier Software-Rendering als 'Kompatibilität', was seehr dreist wäre, aber nicht ausgeschlossen werden kann.
Oder sie haben tatsächlich Hardware-Pixel Shader und müssen an ihren Formulierungen arbeiten (das müssen sie eigentlich so oder so).

Unregistered

2002-08-06, 15:30:01

Originally posted by ow

Also ist STM fuer das Chiplayout verantwortlich wenn ich das richtig verstanden habe.

Das richtig! Deswegen hat PowerVR keinen direkten Einfluß auf das Release von Grafikchips.
Und außerdem kann deswegen auch nicht einfach ein neuer Series4 Grafikchip kurzfristig in Produktion gehen, weil der STG5500 geistiges Eigentum von STM ist. Ein neuer Lizenznehmer müßte erst nen neuen Chip um den 3D-Kern von PowerVR entwickeln.

Das hoert sich wieder sehr hellseherisch an. Ich habe das oben schon mal kommentiert.

Wie kann man einfach annehemen, das nicht ueberwiegend DXT3 benutzt wird, weil nur das fuer transparente Texturen taugt??

Keine Ahnung! Aber finde die um ein vielfaches verlängerte Lebenszeit der Series3 erklärt diesen Umstand.
Und da PowerVR diekt nichts mit dem K2 und dem K2SE zu tun hat, wurde dies in diesem Chip auch nicht mehr verändert...

2002-08-06, 16:41:42

Thx @ Unreg :)

Ich denke, jetzt ist mir die Beziehung zwischen PVR und STM klarer.
Das erklaert natuerlich einiges...

Radeonator

2002-08-06, 17:12:59

Originally posted by zeckensack
Aber das mit den Pixel Shadern ...

Das macht mich eben auch stutzig.Vielleicht sowas ähnliches wie dieses schrott enTL bei der KyroIISE, so ne SW PS Emulation.Das wäre dreist...
Diese Formulierung von S3Graphics lässt zuviel Raum für Spekulationen offen, ist aber natürlich Absicht, kennt man ja von anderen Herstellern auch ;)

Ikon

2002-08-06, 18:45:07

Originally posted by Radeonator
... so ne SW PS Emulation.

PS lässt sich im Gegensatz zum VS nicht sinnvoll über die CPU emulieren (außer man macht gleich komplettes SW-Rendering, was auch wenig sinnvoll ist).

zeckensack

2002-08-06, 21:20:05

Originally posted by Ikon

PS lässt sich im Gegensatz zum VS nicht sinnvoll über die CPU emulieren (außer man macht gleich komplettes SW-Rendering, was auch wenig sinnvoll ist). Genau das meinte ich damit. Wenn man etwas 'ganz hinten' in der Pipeline emulieren will, dann muß man alles andere auch emulieren. Und das nennt man dann Software-Rendering. Daß dies mit dem SavageXP 'compatible' ist, zweifle ich keine Sekunde lang an, aber auch dieses würde ebensogut auf einer RivaTNT laufen ;)

Wäre schön, wenn die Damen und Herren bei S3 ihre Wischiwaschi-Formulierungen durch handfeste Infos ersetzen könnten ...