nVidia und DX9... [Archiv]

Demirug

2003-04-21, 21:07:16

Alle DX Features sind optional bis auf ganz wenige Ausnahmen. Ohne diese Funktionen wäre eine Karte aber keine 3d karte.

WHQL erfordert lediglich das wenn Features unterstützt werden diess auch korrekt unterstützt werden (dafür gibt es entsprechende Tests) und das entsprechende DX DDK Interface komplett unterstützt wird.

Wenn man es daruaf anlegt kann man auch einen WHQL konformen DX9-Treiber für eine Voodoo oder Kyro oder was auch immer schreiben.

Unregistered

2003-04-21, 21:14:19

Originally posted by Demirug
Alle DX Features sind optional bis auf ganz wenige Ausnahmen. Ohne diese Funktionen wäre eine Karte aber keine 3d karte.

WHQL erfordert lediglich das wenn Features unterstützt werden diess auch korrekt unterstützt werden (dafür gibt es entsprechende Tests) und das entsprechende DX DDK Interface komplett unterstützt wird.

Wenn man es daruaf anlegt kann man auch einen WHQL konformen DX9-Treiber für eine Voodoo oder Kyro oder was auch immer schreiben.

Das kommt aber in dem Thread ein bisschen anders rüber. Sind ja auch nicht alles ganz unbedeutende Sachen.

Tiamat

2003-04-21, 21:26:55

Was zur Hölle geht eigentlich bei Nvidia ab ? ?-)

Demirug

2003-04-21, 21:38:10

Originally posted by Unregistered

Das kommt aber in dem Thread ein bisschen anders rüber. Sind ja auch nicht alles ganz unbedeutende Sachen.

Ich weis ja nicht was du in dem Thread gelesen hast aber das was da derzeit nicht unter DX zur Verfügung gestellt wird (unter OpenGL komischerweise schon) sind bei weitem keine Pflicht Features.

Im grossen und ganzen geht es um FP Formate für Texturen, Rendertargets und Framebuffer.

Für den Framebuffer sind die FP Formate bei allen DX9-Chips die es im Moemnt gibt relative nutzloss weil beim Einsatz von FP-Framebuffer eine ganze menge nicht mehr geht (unter anderem AA).

Bei den Rendertargets und Texturen gibt es genauso eine Menge Einschränkungen. Für machen Effekte währe die höhere Genauigkeit aber möglicherweise ganz nützlich wobei man den Performanceverlust auf allen Chips deutlich spüren wird.

Unregistered

2003-04-22, 00:21:37

Und so geht ein weiterer NVIDIA-Bash von den FanATIkern, mit Hilfe von Fachlicher Kompetenz, den Bach runter.

Aber guter Versuch ;)

Next try please...

StefanV

2003-04-22, 00:40:45

Hm, nichtmal FP Texturen kann die NV30 ?? :|

Xmas

2003-04-22, 03:33:04

Originally posted by Stefan Payne
Hm, nichtmal FP Texturen kann die NV30 ?? :|
Doch, aber unter D3D noch nicht.

nagus

2003-04-22, 12:22:19

Originally posted by Unregistered
Und so geht ein weiterer NVIDIA-Bash von den FanATIkern, mit Hilfe von Fachlicher Kompetenz, den Bach runter.

Aber guter Versuch ;)

Next try please...

erklär mir das mal bitte, mr. unreg.

Nvidia hat keine vernünftigen DX9 treiber. daran kann auch demirug nix ändern.

Frank

2003-04-22, 13:11:22

Originally posted by nagus

erklär mir das mal bitte, mr. unreg.

Nvidia hat keine vernünftigen DX9 treiber. daran kann auch demirug nix ändern. Was ist daran nicht zu verstehen?

Zudemzum Thema: Welcher Durchschnitts User braucht jetzt gerade aktuell alle!! DX9 Features im Treiber?

Demirug

2003-04-22, 13:20:37

Originally posted by nagus

erklär mir das mal bitte, mr. unreg.

Nvidia hat keine vernünftigen DX9 treiber. daran kann auch demirug nix ändern.

Definiere mal bitte "vernünftigen DX9 Treiber".

Ich finde es ehrlich gesagt immer wieder sehr amüsant wie man sich über fehleden (nicht freigegebe) Treiberfeatures aufregen kann. Vorallem wenn es noch keine reale Anwendung gibt die davon überhaupt gebrauch macht.

Da könnte ich mich jetzt auch darüber aufregen das die DX9 Treiber von ATI nur 2048*2048 Texturen zulassen oder das maximal 64K Polys funktionieren. Das währe aber vollkommen sinnloss. Das ist nun mal eine Begrenzung im Treiber und oder Hardware und gut ist.

Mir persönlich ist es lieber wenn man Features nacheinader freigibt als Dinge plötzlich wieder rauszuwerfen (RT-Patchs)

Virtual

2003-04-22, 14:57:06

@Demirug:
Nagus meinte sicher "Nicht WHQL-konformen" Treiber.
Dennoch steht weiterhin die Frage im Raum, weshalb NVidia nicht Treiber mit WHQL-Zertifikat unter Volk bringt. Sowohl NVidia als auch ATI, um gleich lähmenden Bashing (nicht von dir) vorzubeugen, legen doch großen Wert auf alles, was dem Marketing dienlich sein könnte. ATI jedenfalls nutzt das Label für Werbezwecke. Ist NVidia das MS-Zertifikat als Mittel des Marketing soooo wenig wert oder weshalb will?/kann? NV nicht konform sein. Gibt es vielleicht doch eine technische Motivation?

G.
V.

StefanV

2003-04-22, 15:02:01

Originally posted by Demirug

Definiere mal bitte "vernünftigen DX9 Treiber".

Ich finde es ehrlich gesagt immer wieder sehr amüsant wie man sich über fehleden (nicht freigegebe) Treiberfeatures aufregen kann. Vorallem wenn es noch keine reale Anwendung gibt die davon überhaupt gebrauch macht.

Da könnte ich mich jetzt auch darüber aufregen das die DX9 Treiber von ATI nur 2048*2048 Texturen zulassen oder das maximal 64K Polys funktionieren. Das währe aber vollkommen sinnloss. Das ist nun mal eine Begrenzung im Treiber und oder Hardware und gut ist.

Mir persönlich ist es lieber wenn man Features nacheinader freigibt als Dinge plötzlich wieder rauszuwerfen (RT-Patchs)

Naja, das mit den 2k*2k Texturen ist IMO eine 'kleinigkeit', während die FP Texturformate (auch wenn man sie nicht filtern kann) IMO nicht ganz unwichtig sind und gerade die Einführung dieser Formate nicht gerade unwichtig ist...

das ganze wird sich wohl so wie damals 32bit Farbtiefe und Texturen verhalten

Demirug

2003-04-22, 15:21:04

Originally posted by Stefan Payne

Naja, das mit den 2k*2k Texturen ist IMO eine 'kleinigkeit', während die FP Texturformate (auch wenn man sie nicht filtern kann) IMO nicht ganz unwichtig sind und gerade die Einführung dieser Formate nicht gerade unwichtig ist...

das ganze wird sich wohl so wie damals 32bit Farbtiefe und Texturen verhalten

ganz unwichtig sind die FP Formate nicht aber derzeit überwiegen die Nachteile so sehr das kaum jemand auf die Idee kommen wird FP Texturen zum Speichern von Farbinformationen zu benutzten.

Neben der fehleden Möglichkeit des Filtern währen da noch:
- FP16 braucht den doppelten Speicherplatz und Bandbreite bringt aber lediglich 2 Bit mehr pro Farbkanal (Exponet ist bei Farbtexturen relative nutzloss)
- Bei FP32 ist es dann sogar die 4 fache Speicherplatz und Bandbreite
- Nicht komprimierbar

IMO ist es also nach wie vor besser bei den "normalen" Farb-Texturen auf die 32 Bit formate zu setzten da man bei den FP-Formaten derzeit zuviel an Leistung verliert.

Für wenige Spezialfälle sind FP-Texturen aber durchaus interesant aber solange die Chips nicht durchgängig (Texture filter, Framebuffer mit AA, Alpha Blending, ...) FP tauglich sind kann man leider wenig damit anfangen.

2003-04-22, 15:21:37

Mr. Lolman

2003-04-22, 15:32:52

Gibts überhaupt schon ein Spiel mit 2048² Texturen. So wies aussieht, dürften neue Engines sowieso wieder kleinere Texturen verwenden (siehe DOOM3)

______________________
Trotzdem geht es in dem Thread eigentlich darum, aus welcher Motivation heraus es NV nicht zuwege bringt die Treiber WHQL zertifiezieren zu lassen.

2003-04-22, 15:36:19

Originally posted by Mr. Lolman
Gibts überhaupt schon ein Spiel mit 2048² Texturen. So wies aussieht, dürften neue Engines sowieso wieder kleinere Texturen verwenden (siehe DOOM3)

______________________
Trotzdem geht es in dem Thread eigentlich darum, aus welcher Motivation heraus es NV nicht zuwege bringt die Treiber WHQL zertifiezieren zu lassen.

???

was willst du denn mit kleineren Texturen erreichen??

2048*2048 werden afaik in einigen Engines in Verbindung mit Texturkompression genutzt.

/edit: btw. wie so sind auf einmal alle so geil auf WHQL?
Hat doch frueher auch niemanden interessiert und die Hauptsache ist doch, ob etwas funktioniert oder nicht.
btw. untersagt die WHQL-Zertifizierung afaik ein erzwungenes VSync off und natuerlich jede OC-Moeglichkeiten im Treiber. Nicht umsonst gibt's die "coolbits" bei NV.

StefanV

2003-04-22, 15:44:16

Originally posted by ow

???

was willst du denn mit kleineren Texturen erreichen??

2048*2048 werden afaik in einigen Engines in Verbindung mit Texturkompression genutzt.

/edit: btw. wie so sind auf einmal alle so geil auf WHQL?
Hat doch frueher auch niemanden interessiert und die Hauptsache ist doch, ob etwas funktioniert oder nicht.
btw. untersagt die WHQL-Zertifizierung afaik ein erzwungenes VSync off und natuerlich jede OC-Moeglichkeiten im Treiber. Nicht umsonst gibt's die "coolbits" bei NV.

1. mehr Detailtreue ??
Ich sehe kein Problem mit kleineren Texturen, dann zerlegt man sie einfach, und ??
Oder man nimmt kleinere Polys.

2. toll, die Frage ist, ob sich größere Texturen überhaupt noch durchsetzen werden oder ob man dafür gleich FP Texturen nimmt...

3. vielleicht wegen 'diverser' Geschichten mit Futuremark ??
Vielleicht weil man eingesehen hat, daß WHQL doch nicht so schlecht ist ??

Nicht umsonst hat ATI das Panel aus dem Treiber ausgegliedert...

2003-04-22, 15:47:30

@SP

Mach dir wenigstens die Muehe zu verstehen, was Demi da oben ueber FP-Texturen geschrieben hat.

FP-Texturen = KEINE Texturfilterung. Sagt dir das was?

Und btw. was hat die Textergroesse mit dem Format (Int/FP) zu tun??

Mr. Lolman

2003-04-22, 15:48:03

@ow

Ich meinte, wenn sich Bumpmapping flächendeckend durchsetzt, dann geht selbst bei 1024² Texturen schon jeder FX die Puste aus.

2003-04-22, 15:49:58

Originally posted by Mr. Lolman
@ow

Ich meinte, wenn sich Bumpmapping flächendeckend durchsetzt, dann geht selbst bei 1024² Texturen schon jeder FX die Puste aus.

Meinst du vielleicht Cubemapping? Da stimmt das.
Kann man iirc mit einem der DX9SDK Samples rumspielen. Da halbieren sich fast die fps bei jeder Vergroesserung der Cubmap ab 128*128.:D

Exxtreme

2003-04-22, 15:51:35

Originally posted by ow
/edit: btw. wie so sind auf einmal alle so geil auf WHQL?
Hat doch frueher auch niemanden interessiert und die Hauptsache ist doch, ob etwas funktioniert oder nicht.
btw. untersagt die WHQL-Zertifizierung afaik ein erzwungenes VSync off und natuerlich jede OC-Moeglichkeiten im Treiber. Nicht umsonst gibt's die "coolbits" bei NV.

Sehe ich auch so. Ich glaube nicht, daß die WHQL-Zertifizierung irgendwas bringt. Ich habe schon oft Non-WHQL-Treiber installiert und irgendwelche Nachteile hatte ich deswegen nie. Ich denke bei der WHQL-Zertifizierung eher an einen Placebo-Effekt. Hänschen Klein kann dann wohl wieder beruhigt schlafen weil der Treiber ein Zertifikat hat. :)

Demirug

2003-04-22, 15:54:32

Originally posted by Stefan Payne
1. mehr Detailtreue ??
Ich sehe kein Problem mit kleineren Texturen, dann zerlegt man sie einfach, und ??
Oder man nimmt kleinere Polys.

Wie zerlegen? den Schrott hat man mal bei den Voodoos gemacht. Das Zerlegen von texturen ist der reinste Performance Killer. In den Performancesguides wird eher zum gegenteil geraten. Also aus 4 texturen eine zu machen.

2. toll, die Frage ist, ob sich größere Texturen überhaupt noch durchsetzen werden oder ob man dafür gleich FP Texturen nimmt...

Wenn ich die Wahl habe vorzugsweise die grössere Texture. Mehr Details sind besser als mehr Bits pro Farbe.

Demirug

2003-04-22, 16:05:30

Originally posted by ow

Meinst du vielleicht Cubemapping? Da stimmt das.
Kann man iirc mit einem der DX9SDK Samples rumspielen. Da halbieren sich fast die fps bei jeder Vergroesserung der Cubmap ab 128*128.:D

Welches Sample meinst du denn? Ich kenne nur CubeMap und dort ist die grösse der Cubemap fest auf 256 Pixel.

2003-04-22, 16:25:20

Originally posted by Exxtreme

Sehe ich auch so. Ich glaube nicht, daß die WHQL-Zertifizierung irgendwas bringt. Ich habe schon oft Non-WHQL-Treiber installiert und irgendwelche Nachteile hatte ich deswegen nie. Ich denke bei der WHQL-Zertifizierung eher an einen Placebo-Effekt. Hänschen Klein kann dann wohl wieder beruhigt schlafen weil der Treiber ein Zertifikat hat. :)

Das Zertifikat bedeutet ja auch nicht, dass ein Treiber fehlerfrei arbeitet, und genausowenig bedeutet Nicht-Zertifiziereung, dass ein Treiber viele Fehler hat.

Das mit dem Placebo-Effekt wird´s wohl recht gut treffen.;)

Und btw. wird für Win9x eh nicht mehr zertifiziert und dennoch läuft´s.:D

2003-04-22, 16:34:08

Originally posted by Demirug

Welches Sample meinst du denn? Ich kenne nur CubeMap und dort ist die grösse der Cubemap fest auf 256 Pixel.

Mein Fehler, das 'iirc' war also fehl am Platz.
Ist eine d3d Demo von 'tomohidekano', errinnert aber doch irgendwie ans SDK.;)

und btw. ist´s auch noch die Envmap, die man von 64*64 (242fps, GF4) bis auf 512*512 (111fps) variieren kann.

Shot:

Demirug

2003-04-22, 16:42:04

Originally posted by ow

Mein Fehler, das 'iirc' war also fehl am Platz.
Ist eine d3d Demo von 'tomohidekano', errinnert aber doch irgendwie ans SDK.;)

und btw. ist´s auch noch die Envmap, die man von 64*64 (242fps, GF4) bis auf 512*512 (111fps) variieren kann.

Shot:

ja sieht auf dem erstem Blick wie ein SDK sample aus. Wenn es die EnvMap ist wundert es aber nicht wirklich das es langsamer wird den diese wird ja sehr wahrscheinlich für jeden Frame neu berechnet.

2003-04-22, 16:48:06

Originally posted by Demirug

ja sieht auf dem erstem Blick wie ein SDK sample aus. Wenn es die EnvMap ist wundert es aber nicht wirklich das es langsamer wird den diese wird ja sehr wahrscheinlich für jeden Frame neu berechnet.

Ja, hat mit Cubemaps wohl nix zu tun, mein Irrtum.

Noch eine Frage: Wer berechnet die Envmap pro Frame neu, die CPU oder die GPU?

/edit:
btw. sind´s noch satte ~190fps bei 256*256, erst bei 512*512 erfolgt der starke Einbruch auf ~112fps (640x480x32, window).

Demirug

2003-04-22, 17:03:06

Originally posted by ow

Ja, hat mit Cubemaps wohl nix zu tun, mein Irrtum.

Noch eine Frage: Wer berechnet die Envmap pro Frame neu, die CPU oder die GPU?

/edit:
btw. sind´s noch satte ~190fps bei 256*256, erst bei 512*512 erfolgt der starke Einbruch auf ~112fps (640x480x32, window).

Die GPU. Das ganze ist eine Render To Texture Geschichte. Bis 256*256 ist das ganze wohl CPU/Geometrie limiert. Erst bei 512*512 reicht dann wohl die Fillrate nicht mehr.

zeckensack

2003-04-22, 17:03:51

Originally posted by ow

Ja, hat mit Cubemaps wohl nix zu tun, mein Irrtum.

Noch eine Frage: Wer berechnet die Envmap pro Frame neu, die CPU oder die GPU?

/edit:
btw. sind´s noch satte ~190fps bei 256*256, erst bei 512*512 erfolgt der starke Einbruch auf ~112fps (640x480x32, window). Mal ins blaue geschossen würde ich sagen das ist Render to texture, und damit GPU-Arbeit.
(wenn's kein Render to texture wäre, wäre es überhaupt keine Arbeit pro Frame ;))

Ups, wieder zu langsam :|

2003-04-22, 17:07:07

..and the winner in this race is.....demirug.:D;)

Dank euch beiden für die Info.:)

Frank

2003-04-22, 17:26:30

Originally posted by ow
2048*2048 werden afaik in einigen Engines in Verbindung mit Texturkompression genutzt.
Flashpoint Resistance nutzt zum Beispiel bis 4096x4096. :D

aths

2003-04-22, 19:04:30

Originally posted by ow
FP-Texturen = KEINE Texturfilterung. Sagt dir das was?Filterung ist afaik mit PixelShader machbar.

Demirug

2003-04-22, 19:11:54

Originally posted by aths
Filterung ist afaik mit PixelShader machbar.

Ja aber das wird richtig langsammmmmmm.

für ein ein einfaches bi-Sample muss man:

-4 Texturkoordinaten erzeugen (mindestens 3 Anweisungen)
-4 mal sampeln
-Die 4 Werte verrechnen (mindestens 3 Anweisungen)

um aus 2 Bi Sampeln ein tri Sampel zu machen das ganze 2 mal und dann noch eine zusätzliche Anweisung

Von AF möchte ich jetzt gar nicht anfangen. Solange man in den Pixelshader keine Dynamischen Branches hat muss man dann immer voll durchfiltern.

über Texturefilter in den Pixelshadern können wir wieder reden wenn wir 2 GHZ GPUs mit 32 Pipelines haben

StefanV

2003-04-22, 19:13:24

Originally posted by Demirug
Wenn ich die Wahl habe vorzugsweise die grössere Texture. Mehr Details sind besser als mehr Bits pro Farbe.

Für größere Texturen kann man (notfalls) einen Fallback nehmen, in dem man die Texturen zerlegt.

Wenn ein Chip keine FP Texturen nutzt, dann hat man halt pech gehabt, dann 'darf' man 'normale' Texturen nutzen,.

StefanV

2003-04-22, 19:15:22

Originally posted by ow
FP-Texturen = KEINE Texturfilterung. Sagt dir das was?

Und jetzt stell dir mal 'nen Voodoo Graphics (meinetwegen auch Rendition Verieté 1000) vor, der 'versucht' FSAA und AF zu machen...

Dieses 'Problem' wird sich 'irgendwann' auch erledigt haben...

StefanV

2003-04-22, 19:17:06

Originally posted by Demirug
Ja aber das wird richtig langsammmmmmm.

für ein ein einfaches bi-Sample muss man:

-4 Texturkoordinaten erzeugen (mindestens 3 Anweisungen)
-4 mal sampeln
-Die 4 Werte verrechnen (mindestens 3 Anweisungen)

um aus 2 Bi Sampeln ein tri Sampel zu machen das ganze 2 mal und dann noch eine zusätzliche Anweisung

Von AF möchte ich jetzt gar nicht anfangen. Solange man in den Pixelshader keine Dynamischen Branches hat muss man dann immer voll durchfiltern.

über Texturefilter in den Pixelshadern können wir wieder reden wenn wir 2 GHZ GPUs mit 32 Pipelines haben

1. momentan, was 'bald' sein wird wissen wir nicht, noch nicht.

2. ist es bei 'normalen' Texturen nicht ähnlich ?? :|

3. nun reden wir mal über einen Voodoo Graphics, der Anisotrop Filtert, das ganze auch noch mit FSAA ;)
Dürfte sich in etwa ähnlich verhalten, oder ?? ;)

Pirx

2003-04-22, 19:18:20

Originally posted by Demirug

Ja aber das wird richtig langsammmmmmm.

für ein ein einfaches bi-Sample muss man:

-4 Texturkoordinaten erzeugen (mindestens 3 Anweisungen)
-4 mal sampeln
-Die 4 Werte verrechnen (mindestens 3 Anweisungen)

um aus 2 Bi Sampeln ein tri Sampel zu machen das ganze 2 mal und dann noch eine zusätzliche Anweisung

Von AF möchte ich jetzt gar nicht anfangen. Solange man in den Pixelshader keine Dynamischen Branches hat muss man dann immer voll durchfiltern.

über Texturefilter in den Pixelshadern können wir wieder reden wenn wir 2 GHZ GPUs mit 32 Pipelines haben

Würde das eigentlich erkennbar besser aussehen, oder würde man die ganze Leistung für beinahe nichts verbraten?

Exxtreme

2003-04-22, 19:20:02

Originally posted by Demirug

Ja aber das wird richtig langsammmmmmm.

für ein ein einfaches bi-Sample muss man:

-4 Texturkoordinaten erzeugen (mindestens 3 Anweisungen)
-4 mal sampeln
-Die 4 Werte verrechnen (mindestens 3 Anweisungen)

um aus 2 Bi Sampeln ein tri Sampel zu machen das ganze 2 mal und dann noch eine zusätzliche Anweisung

Von AF möchte ich jetzt gar nicht anfangen. Solange man in den Pixelshader keine Dynamischen Branches hat muss man dann immer voll durchfiltern.

über Texturefilter in den Pixelshadern können wir wieder reden wenn wir 2 GHZ GPUs mit 32 Pipelines haben
Hehe, dann könnte man ja dann gleich auf SSAA machen. :)

Demirug

2003-04-22, 19:23:16

Originally posted by Stefan Payne
Für größere Texturen kann man (notfalls) einen Fallback nehmen, in dem man die Texturen zerlegt.

Stefan das funktioniert nicht. Wenn man anfängt aus einer Texture 4 zu machen muss man auch die Geometrie spliten die Texturekorrdinaten neu berechnen und aus einem Draw Call 4 machen. Und die Drawcalls sind es die heute die CPUs killen. auf einer 1 GHZ CPU kann man ca 25000 Drawcalls durchführen. Wenn man die Geometrie splitten muss sind es effektiv nur noch 6250. Die CPU limitierung lässt grüssen.

Der Fallback wenn die Texture zu gross ist und bleibt eine kleinere Texture zu benutzten.

Wenn ein Chip keine FP Texturen nutzt, dann hat man halt pech gehabt, dann 'darf' man 'normale' Texturen nutzen,.

Ja das ist der Fallback für diesen Fall.

Demirug

2003-04-22, 19:32:13

Originally posted by Stefan Payne

1. momentan, was 'bald' sein wird wissen wir nicht, noch nicht.

man kann aber einigermassen hochrechnen. Sobald es FP-TMUs gibt (wenn es sie jemals geben wird) sieht die Sache besser aus.

2. ist es bei 'normalen' Texturen nicht ähnlich ?? :|

Ja die rechnungen sind identisch. Eine TMU ist aber so gebaut das sie all diese Rechnungen durchführt und trotzdem pro Takt ein Bi-Sample liefert und das zusammenrechnen für tri und AF nebenbei auch noch gleich mit gemacht wird.

3. nun reden wir mal über einen Voodoo Graphics, der Anisotrop Filtert, das ganze auch noch mit FSAA ;)
Dürfte sich in etwa ähnlich verhalten, oder ?? ;)

Nein in Summe ist das weniger arbeit. Da ja zum Beispiel das Zusammenrechnen vom AA durchgeführt wird. Die Texturekoordinaten werden vom Trisetup erzeugt kosten mich also im "Pixelshader" auch keine Leistung.

Demirug

2003-04-22, 19:35:20

Originally posted by Pirx

Würde das eigentlich erkennbar besser aussehen, oder würde man die ganze Leistung für beinahe nichts verbraten?

Bei reinen Farbtexturen ist der optische Gewinn gegenüber einer normalen 32bit Texture so gering das es sich der Aufwand IMHO dafür nicht lohnt vorallem solange man keinen entsprechenden Framebuffer hat.

Doomtrain

2003-04-22, 19:43:06

Originally posted by Frank
Flashpoint Resistance nutzt zum Beispiel bis 4096x4096. :D

Ja, aber wie groß ist die Textur? 100x100 Meter? *eg*

2003-04-22, 20:00:05

Originally posted by Doomtrain

Ja, aber wie groß ist die Textur? 100x100 Meter? *eg*

Nö. 4096x4096 Pixel.:D

Also 16-fache Bildschirmfläche bei einer gedachten Auflösung von 1024x1024 und einem Pixel/Texel-Verhältnis von 1.

Aquaschaf

2003-04-22, 21:21:59

auf so einer großen Textur werden sicherlich "zusammengelegt" die Texturen für viele Objekte liegen .

Mr. Lolman

2003-04-22, 21:54:37

Warum verwendet man eine 4096² Textur. (Ja klar, für den Boden) Aber IIRC können nur die FX Karten so hohe Texturen Auflösen. Und das bisschen an zusätzlicher Geometrie hätte 'Resistance' auch nicht viel langsamer gemacht, jedoch allen Besitzern die Möglichkeiten gegeben in den Genuss besserer Grafik zu kommen.

Wenn GF4 Karten doch so hohe Texturen packen, dann war mein Posting bullshit :stareup:

Demirug

2003-04-22, 22:01:32

Originally posted by Mr. Lolman
Warum verwendet man eine 4096² Textur. (Ja klar, für den Boden) Aber IIRC können nur die FX Karten so hohe Texturen Auflösen. Und das bisschen an zusätzlicher Geometrie hätte 'Resistance' auch nicht viel langsamer gemacht, jedoch allen Besitzern die Möglichkeiten gegeben in den Genuss besserer Grafik zu kommen.

Wenn GF4 Karten doch so hohe Texturen packen, dann war mein Posting bullshit :stareup:

4096² geht ab NV20

zeckensack

2003-04-22, 22:42:36

Originally posted by Demirug

4096² geht ab NV20 ... und auf keiner anderen Hardware* :bäh:

*im Sinne von 'nicht-NVIDIA'

Demirug

2003-04-22, 23:18:57

Originally posted by zeckensack
... und auf keiner anderen Hardware* :bäh:

*im Sinne von 'nicht-NVIDIA'

Wildcat VP (zumindestens unter OpenGL, ich habe leider kein DX Capsfile für diese Karten)

und der gute Glaze3d (RIP)