Kyro3 mit eDram

[Liszca]

Das gäbe doch wohl ein geschoss, bandbreitenschonendes rendersystem von der kyro III und dabei einen bandbreitenüberfluss wie ihn die avalanche haben würde wenn (wenn wenn das wörtechen wenn nicht wäre) sie auf dem markt wäre! das gäbe ein kracher! Und dazu noch die recht ausgereiften treiber von nvidia was will man dann noch mehr?

[ActionNews]

Das wäre sicher genial :D! Ist aber eher unwahrscheinlich! Obwohl....hmm...wenn BitBoys jetzt tatsächlich mit NEC zusammenarbeiten bei ihrem neuen Chip, dann könnte es in Zukunft irgendwann was werden, da PowerVR und NEC schon länger recht gute Kontakte haben und Chips miteinander entwickeln (siehe Dreamcastchip) ;););)! Naja...ist ein bischen weit hergeholt :D.....

CU ActionNews

[Quasar]

Klingt aber wirklich nett....hoffen darf man ja wohl noch, oder? ;)

[Ceiser Söze]

Der Kyro braucht keinen eRAM, da es ihm (wie man am KyroII sieht) zuerst an Füllrate und danach an Bandbreite mangelt. Schneller DDR-Ram ist problemlos in der Lage, die Füllratenanforderungen eines TBDR's zu erfüllen.
Ausserdem macht eRAM eigentlich auch gar keinen Sinn: Z-Buffer Zugriffe entfallen völlig und der bandbreitenfressende Teil des Frambuffers (bei einem immediate Renderer der gesamte Backbuffer, bei einem TBDR der Tile-Cache) ist ja bereits im Chip eingebettet...

[Quasar]

Aber so ein bis zwei MB an TexturCache sollten auch einem TBR noch ein bißchen auf die Sprünge helfen....

[Liszca]

Originally posted by Ceiser Söze
Ausserdem macht eRAM eigentlich auch gar keinen Sinn: Z-Buffer Zugriffe entfallen völlig und der bandbreitenfressende Teil des Frambuffers (bei einem immediate Renderer der gesamte Backbuffer, bei einem TBDR der Tile-Cache) ist ja bereits im Chip eingebettet...

Kannst du mir das mal ein klein wenig genauer erklären warum es nicht nötig wär technisch gesehen?

Habe ich das richtig verstanden und der chip könnte eher ein paar rendereinheiten vertragen?

[loewe]

Originally posted by Quasar
Aber so ein bis zwei MB an TexturCache sollten auch einem TBR noch ein bißchen auf die Sprünge helfen....

Wieso, wer hat gesagt KYRO hat keinen TextureCache?
:)

[loewe]

Originally posted by Liszca


Kannst du mir das mal ein klein wenig genauer erklären warum es nicht nötig wär technisch gesehen?

Habe ich das richtig verstanden und der chip könnte eher ein paar rendereinheiten vertragen?

zu 1.) Lies mal http://www.3dconcept.net/reviews/3dprophet4500/5.htm

Es dürfte gegenwärtig kaum eine Technologie geben, die noch weniger Bandbreite braucht.

zu 2.) Genau das ist das Problem! Mit 350 MPixel/sec Füllrate liegt KYRO II wirklich auf dem niedrigsten denkbaren Niveau und erreicht hier wirklich Werte dei wir sonst heute bei keinem Chip mehr haben. Da diese aber sehr effektiv genutzt werden geht es oft trotzdem recht gut.
KYRO III wird dieses Probelm durch die Verdoppelung der Anzahl der Rendereinheiten erstmal weitgehend lösen. Durch ein DDR RAM Interface wird auch die für diese 4 Rendereinheiten notwendige Bandbreite vorhanden sein, so dass KYRO III bis 1600x1200 nicht mehr Bandbreitenlimitiert sein dürfte. Die Geschwindigkeit an sich sollte nicht das Problem sein, die weiteren Feature des Chips sind das große Geheimnis. :)

[Unregistered]

eDRAM macht bei einem deferred Renderer sehr wohl Sinn!

Man braucht es zwar nicht, um die Z-buffer - Zugriffe zu beschleunigen, aber für eine effiziente Zwischenspeicherung der Vertex-Daten / Modelldaten und eine Beschleunigung des HSR ist es sehr wohl nützlich.

Es würden aber max. 8MB dafür reichen (schließlich reserviert der KyroII nur ca. 3MB für die Vertex-Buffer im VideoRAM ).


Manfred

[Quasar]

Originally posted by loewe


Wieso, wer hat gesagt KYRO hat keinen TextureCache?
:)

Keine Ahnung, ich jedenfalls nicht....

[Thowe]

Zum Thema noch aus dem White Paper von PowerVR:

It may be argued that memory bandwidth issues can be resolved by using on-chip DRAM for frame buffer,
z buffer and textures. However the drive for higher resolutions, increased colour and depth accuracy and
increased texture space means that on chip DRAM cannot satisfy the demand for memory in the
foreseeable future. For example a graphics device which supports resolutions up to 1920x1440 pixels
would require (1920x1440x2x4) bytes for a double buffered frame buffer, (1920x1440x4) bytes for the zbuffer,
as well as texture memory, i.e. nearly 32MB of memory plus texture memory. A tile based renderer
can use on-chip DRAM for texture caching alone.

[Ceiser Söze]

Die ganze Display-List auf dem Chip unterzubringen, würde tatsächlich Sinn machen. Allerdings ist die Grösse der Displaylist ja sehr applikationsabhängig (genauer: Je mehr Polygone, desto grösser die Display-List) und daher - im Gegensatz zum Tile Buffer - keine feste Grösse. Und dann treten mit Sicherheit häufig folgende zwei Situationen auf:
-Der eRAM ist unterfordert, da die Display-List sehr klein ist und nur einen Bruchteil des Speichers verwendet (wenn man zuviel eRAM verbaut).
-Der eRAM ist überfordert - das Spiel ist also ein echter "Polygon-Pusher".
Zum einen müsste man da also ziemlich genau abschätzen, wie viel eRAM heute und in den kommenden 2 Jahren für die Display-List benötigt wird und genau soviel und nicht mehr verbauen, denn sonst wird der Chip zu teuer. Zum zweiten wäre es dann noch nett, wenn überschüssiger eRAM als Texturencache verwendet werden könnte...
In meinen Augen ist dies jedenfalls eine ziemlich wackelige Sache, die v.A. PowerVRs Philosophie von einem möglichst guten Preis/Leistungsverhältnis widerspricht. Halte ich daher für unwahrscheinlich...

[Thowe]

Originally posted by Ceiser Söze
Halte ich daher für unwahrscheinlich...

Ich auch.

[Liszca]

Originally posted by Ceiser Söze
Die ganze Display-List auf dem Chip unterzubringen, würde tatsächlich Sinn machen. Allerdings ist die Grösse der Displaylist ja sehr applikationsabhängig (genauer: Je mehr Polygone, desto grösser die Display-List) und daher - im Gegensatz zum Tile Buffer - keine feste Grösse. Und dann treten mit Sicherheit häufig folgende zwei Situationen auf:
-Der eRAM ist unterfordert, da die Display-List sehr klein ist und nur einen Bruchteil des Speichers verwendet (wenn man zuviel eRAM verbaut).
-Der eRAM ist überfordert - das Spiel ist also ein echter "Polygon-Pusher".
Zum einen müsste man da also ziemlich genau abschätzen, wie viel eRAM heute und in den kommenden 2 Jahren für die Display-List benötigt wird und genau soviel und nicht mehr verbauen, denn sonst wird der Chip zu teuer. Zum zweiten wäre es dann noch nett, wenn überschüssiger eRAM als Texturencache verwendet werden könnte...
In meinen Augen ist dies jedenfalls eine ziemlich wackelige Sache, die v.A. PowerVRs Philosophie von einem möglichst guten Preis/Leistungsverhältnis widerspricht. Halte ich daher für unwahrscheinlich...

Was könnte die Kyro den eher gebrauchen? (jetzt sag nicht T&L oder irgend so ein shader dingnsbums!)

[Ceiser Söze]

Ganz klar mehr Füllrate, denn daran krankt es beim KyroII. Bandbreite hat er genug und auch bei höher getakteten, mit 4 Pipelines versehenen Chips wird man dieses Problemlos zur Verfügung stellen können. Aber wenn man das anisotrope Filtern auf dem KyroII aktiviert, dann weiss man sofort, woran es primär mangelt.
Und Multisampling-AA wäre auch nicht schlecht, denn dieses ist afaik auf einem Tiler praktisch gratis (und die Füllrate, die sonst für das Super Sampling AA draufgehen würde, kann man dann schön für anisotropes Filtern nutzen :) ).
Kurz gesagt: Der neue Kyro braucht folgendes und zwar in dieser Reihenfolge:
-Füllrate
-Füllrate
-Füllrate
-Multisampling AntiAliasing
;)

[Thowe]

Originally posted by Ceiser Söze
-Füllrate
-Füllrate
-Füllrate

- Multisampling AntiAliasing for free
- anisotropische Filterung for free

:D so sieht meine Traum IIIer aus.

Vertex und Pixelshader würde ich als Dreingabe sehen, aber mit der Kyro 4 am Ende des Jahres würde ich es schon verlangen. Natürlich mit HyperThreading und sie ist natürlich 100% DX9 entsprechend.(Zur Erinnerung, wird sind im SpekuForum, somit darf ich das)

[Legolas]

Originally posted by Thowe

Zur Erinnerung, wird sind im SpekuForum, somit darf ich das
:D:D

[Pussycat]

[quote](schließlich reserviert der KyroII nur ca. 3MB für die Vertex-Buffer im VideoRAM ).[&quote]

6 MB. Tilers and high polygon counts (http://www.powervr.org.uk/articles/tilerpoly/hpcat.htm)

[Unregistered]

Originally posted by Thowe

[...] Natürlich mit HyperThreading und sie ist natürlich 100% DX9 entsprechend.(Zur Erinnerung, wird sind im SpekuForum, somit darf ich das)


ich verzichte auch dx9 und hätte gerne full openGL 2.0 + ne Menge Kyro openGL extensions :P ;)

[Thowe]

Originally posted by Unregistered



ich verzichte auch dx9 und hätte gerne full openGL 2.0 + ne Menge Kyro openGL extensions :P ;)

Ok, beides. :)

[Unregistered]

Originally posted by Pussycat
[quote](schließlich reserviert der KyroII nur ca. 3MB für die Vertex-Buffer im VideoRAM ).[&quote]

6 MB. Tilers and high polygon counts (http://www.powervr.org.uk/articles/tilerpoly/hpcat.htm)

Na eigentlich 2x4mb= 8mb mit den letzten Treiberversionen. Binning space wurde leicht aufgepumpt, und die registry Variablen sind dafuer verschwunden. Man kann sie aber trotzdem noch anwenden, ich kann mich nur nicht erinnern wieviel ram man dafuer einsetzten kann (es gibt eine obere Grenze seit AGP texturing eingesetzt wurde).

Ausser DroneZ sah ich eigentlich nie einen nenneswerten Unterschied wenn man binning space vergroessert. Und selbst dann nur ein paar fps.

Display list im chip unterzubringen sollte eigentlich die beste Loesung sein, aber im Notfall waere ein externer Speicher nicht so schlecht.

Wenn man Dave's Artikel/Aussagungen nachgeht sind im schlimmsten Fall 24mb kein Problem wenn's um 128mb ram Karten geht und natuerlich kombiniert mit effizienter Texturkomprimierung.

[Voodoo3Killer]

Originally posted by Thowe


Ok, beides. :)

...beides?!?!

ALLES!!!!!

:D:D

[Pussycat]

Viel sinn würde eRAM auch für den polygonencache niecht machen. Es ist jetzt also 8 MB gross, wegen zukunfstsicherheit wäre 12 MB sicher nötig lieber noch viel mehr).
Bei 100 fps geben 12 MB polygonen 1.2 GB traffic. Dies ist mit (1200*1024*1024*8)/(64*1000000) = 157 MHz 64-bit speicher zu schaffen. Dieser kostet nichts. 12 MB eRAM kosten MINDESTENS (Bei 1T-eRAM) 12*8*1024*1024/1000000 = 101 M transistoren. Und die sind teuer.

Und für ein kleiner Teil der Texturen lohnt sicht das eRAM auch nicht. Högstens die front/-backbuffer könnten rein, und bräuchten 2*(2048*1536*32)/(8*1024*1024)=24 MB. Also 201 transistoren. (Bin mit übrigens nicht sicher, ob der frontbuffer auch rein muss)

Also: Viele Transistoren, wenig Leistung.

[Voodoo3Killer]

...also am Ende heißt das doch, dass eDram teuer wäre und nur in bestimmten Situationen, bei genauer Planung auch wirklich etwas bringen würde...

Ich glaub nicht an sowas...

[Pussycat]

Bei ein Tiler wäre es sinnlos, nicht jedoch bei ein traditional renderer.

[Abadon]

Man kann Binning Space durch die Registry vergroessern.

Jemand muss nur unter HWSettings PMXKERN finden und die folgenden strings hinzufuegen:

FBObjSpace "0x00600000"
FBPtrSpace "0x00600000"

Von 55mb video ram/7mb AGP aendert es sich dann nach einem reboot auf 51mb video ram/11mb AGP.

Es hilft mir zur Zeit mit F1 2001. Es soll bei 32bit bis zu 75mb Texturen durchschieben. Selbst mit 16bits wird's da kritisch und eine raeumigere display list hilft mehr als man glauben wuerde. ;)