Neues (und nicht so neues) aus der Speicherküche

[Demirug]

Wenn man sich im Moment ein bischen bei Samsung (http://www.samsung.com/) im Grafikkartenspeicher Bereich (http://www.samsung.com/Products/Semiconductor/GraphicsMemory/index.htm) umsieht so entdeckt man dort einiges:

Bei den normalen DDR 128M bit Chips hat man die 400 MHz erreicht was die Chips mit geringere Taktung preislich interesanter machen sollte.

Auch 256M Bit DDR Chips sind nun zu haben. Diese sind wichtig für Consumerkarten mit 256 MByte RAM. Das verbauen von 16 Chips wie auf der 256MB FireGL Karte ist im Consumermarkt nicht interesant. Die 256M bit DDR Chips haben allerdings ein Problem. Es gibt sie nur bis maximal 300 MHz.

Die grosse Überraschung (für mich) ist allerdings die vorankündigung von 256M Bit DDR-II Chips. Das sie kommen würden war ja schon länger klar. Das Interesante ist aber das man hier unter 500 MHz gar nicht anfängt und das Topmodel sogar etwas über 700 MHz erreichen soll. Zur verfügbakeit sei gesagt das Samsung plant im zweiten Quartal die Hersteller mit Testchips zu beliefern.

[Crazytype]

zwischen der lieferung erster engineering sample und der endfertigungs sind aber doch große lücken(3-6Monate?), oder? Naja die r400/nv40 wird bestimmt was nettes.

[Spake]

Originally posted by Demirug
Die grosse Überraschung (für mich) ist allerdings die vorankündigung von 256M Bit DDR-II Chips. Das sie kommen würden war ja schon länger klar. Das Interesante ist aber das man hier unter 500 MHz gar nicht anfängt und das Topmodel sogar etwas über 700 MHz erreichen soll. Zur verfügbakeit sei gesagt das Samsung plant im zweiten Quartal die Hersteller mit Testchips zu beliefern.
diue würden doch bestimmt erst mit anfangen so etwas zu produzieren wenn neue grafikchips so was auch brauchen werden
aber ich glaube nicht dass der nv35 solche chips brauchen wird

schätze an bandbreite wird es uns nie merh wieder mangeln ;D

[robbitop]

??? wie kommst du auf den schluss?

das dachte man vor dem GF2 GTS auch.

Schau mal was in naher zukunft möglich ist.
Sagen wir 800Mhz sind bei DDr2 vorerst oberes Segment bei 256bit DDR wäre das 51,2GB/s reale Bandbreite. Mit Bandbreitenschonder Technik ist man imho beim IMR auch soziemlich am ende der Fahnenstange.
Die PipelineFlxibilität wird kommen, dass man ohne grossartig Transistoren zu verbrauchen die Bandbreite nach oben schieben kann.
Was wird in der Zeit bei Chips an Füllrate machbar sein. Bei 0,09µ denk ich wird man 0,8-1Ghz hinbekommen und sehr effektive 16-32TMU oder ähnliche Einheiten haben. Damit wären wir bei 10-32GTex an Füllrate. Dort dürfte die Bandbreite sehr wohl zum limitierenden Faktor werden. So sehe ich das mittelfristig. Lösung?? FB on Die oder TBDR...beim letzteren iwrd auch massig Füllrate gespart und ein sehr gutes FAA wäre möglich. Also letztendlich hoffe ich dass ein grosser IHV auf TBDR umstellen wird, denn das dürfte mal wieder einen gewaltigen schub nach vorn geben...


sorry nur ein kleines fiktivies Zahlenspiel...

[Spake]

Originally posted by robbitop
??? wie kommst du auf den schluss?

das dachte man vor dem GF2 GTS auch.

Schau mal was in naher zukunft möglich ist.
Sagen wir 800Mhz sind bei DDr2 vorerst oberes Segment bei 256bit DDR wäre das 51,2GB/s reale Bandbreite. Mit Bandbreitenschonder Technik ist man imho beim IMR auch soziemlich am ende der Fahnenstange.
Die PipelineFlxibilität wird kommen, dass man ohne grossartig Transistoren zu verbrauchen die Bandbreite nach oben schieben kann.
Was wird in der Zeit bei Chips an Füllrate machbar sein. Bei 0,09µ denk ich wird man 0,8-1Ghz hinbekommen und sehr effektive 16-32TMU oder ähnliche Einheiten haben. Damit wären wir bei 10-32GTex an Füllrate. Dort dürfte die Bandbreite sehr wohl zum limitierenden Faktor werden. So sehe ich das mittelfristig. Lösung?? FB on Die oder TBDR...beim letzteren iwrd auch massig Füllrate gespart und ein sehr gutes FAA wäre möglich. Also letztendlich hoffe ich dass ein grosser IHV auf TBDR umstellen wird, denn das dürfte mal wieder einen gewaltigen schub nach vorn geben...


sorry nur ein kleines fiktivies Zahlenspiel...
denk mal nach was ich gesagt habe:
ich habe mich auf alle chips bis zum nv40 bezogen und dort wird es wohl keine bandbreitenprobleme geben oder?
allein schon 500 Mhz DDr2 wäre beim nv40 der,overkill
wieso:
übertakte mal bei einer R300 abwechselnd den Ram und den Core wa glaubst du bringt mehr 20 Mhz mehr beim Core oder 20 Mhz mehr beim RAM

erwartest du wirklich dass grafikchiphersteller in den nächsten 1 1/2Jahren den schritt zu 0.09 machen
wäre wohl schon sehr komsich wenn intel den schritt erst ende des jahres macht und AMD erst ende des nächsten jahres

[robbitop]

ich meinte eher mittelfristig. und es wird wohl 1,5-2 Jahre noch dauern. Bis zum Nv40-45 und ATi Pentdants hast du aber Recht ;-)

[Spake]

ob dass wirklich so schnell gehen wird mit der speicherbandbreite
werden wohl eher 3-4 Jahre (hoffe ich)

Frage:
im graka markt müsste man doch relativ schnell und einfach QDR_ram einführen können
liegt der nciht vorhande bestand solcher chips an zu hohen kosten für die chips oder an etwas anderem

[robbitop]

die diskussion hatten wir schonmal. QDR ist unsinig für Grakas, sinnig auf Mobos mit geringeren Kosten da weniger Datenleitungen

[Ailuros]

Also letztendlich hoffe ich dass ein grosser IHV auf TBDR umstellen wird, denn das dürfte mal wieder einen gewaltigen schub nach vorn geben...

Ich bin froh wenn ich endlich einen high end TBDR in meine Finger bekomme; wenn Du nur wuesstest wie lange ich schon auf so n' Ding warte :(

Mit Bandbreitenschonder Technik ist man imho beim IMR auch soziemlich am ende der Fahnenstange.

Robbitop,

Meiner Meinung nach ist die sogesagte IMR-bandwidth-wall ein altes Maerchen, dass sich bis jetzt nie realisiert hat und immer noch nicht darauf hin deutet.

Speicher und Busbreiten sind nicht die einzigen Loesungen oder Moeglichkeiten Bandbreite einzusparen, sowie es auch nicht unbedingt noetig ist fuer IHV's direkt auf eine volle TBDR Architektur umzusteigen. Wenn Du einen TBDR mit einem IMR mit gleichen Spezifikationen vergleichst und die Vor- und Nachteile jedes chips durch den Durchschnitt schneidest, sind die Unterschiede nicht so gross wie man sich vorstellen koennte.

Dabei gibt es noch so manche Moeglichkeiten die Effizienz von Pipelines auf IMR's umso einiges zu erhoehen, HSR wird staendlich weiterentwickelt, adaptive on chip Tesselation kommt auch so langsam und edram auf die eine oder andere Art und Weise koennen in der absehbaren Zukunft helfen, sowie auch weitere Techniken/Optimierungen.

Einzige Aussnahme so wie ich das sehe koennten PDA/mobile/wireless gaming chips darstellen, wenn es zur Bandbreite kommt. Aber das sind da eher Spezialfaelle.

[robbitop]

wieder mal dazu gelernert ;-)

aber sagmal was könnte man denn noch zur Bandbreitenschonung machen (rein theoretisch)?

das mit der Tesslation wird eigendlich erst ab VS3.0 richtig gut.
Und ich habe mal gelesen dass dieses später in DX10 oder 1 noch weiter entwickelt werden sollte...

[Ailuros]

Vielleicht hilft der Thread hier:

http://www.beyond3d.com/forum/viewtopic.php?t=1024&highlight=

Es posten mehr als nur einer engineers in diesem Thread die grosse Erfahrung mit TBDR haben ;)

Auch sehenswert:

http://www.beyond3d.com/forum/viewtopic.php?t=2786&highlight=

The point is that there is a great deal of inefficiency yet in today's hardware. Improving the rendering efficiency provides a route to improving performance that does not necessarily require costly new processes, large numbers of pipelines, etc. Not that these aren't great to have, they are. Just that there is also still plenty of low hanging fruit that can come from improving rendering efficiency.

As an example, you might simply added 8k of frame/depth buffer cache to a standard IMR (about a 32x32 pixel tile's worth) , then recommend that developers sort their render in roughly tile order and roughly front to back within a tile region. Older titles that did not do this would still see some benefit from the cache while developers that took full advantage of it would get tiler-like performance with a standard IMR. For those developers that wanted to use application driven deferred rendering they could still render the scene twice, once without shading (to set the depth buffer) and then again with shading.

Hierarchical z buffering would add even more benefit, especially if the upper levels were cached on the chip. I would recommend up to 5 levels (for quick elimination of large stencil polys, bounding volume occlusion checks, etc.).

Providing for the use of z occlusion culling using bounding volumes to eliminate unnecessary hidden vertex and pixel processing. This becomes an ever increasing issue as triangle rates and scene complexity increase. It think it important to provide this capability as a standard feature across all 3d hardware vendors and APIs. Z occlusion culling works particularly well with 5 or more levels of hierarchical z to quickly determine the visibility of the bounding volumes.

Using more efficient multisampling AA techniques such as Z3 or other coverage mask approach and sparse grid sampling, could provide 16x or even 32x near stocastic AA with little performance impact. It would correctly handle implicit edges and order independent transparency sorting to boot.

There are still some improvements both in performance and quality that can be made in anisotropic filtering as well. Some of the ideas in the Feline approach would be useful.

There are, of course, many other possibilities. Improving rendering efficiency has just begun to be tapped and offers all the vendors the opportunity for a great deal of performance improvement in the near term.

Nur Vorschlaege und Moeglichkeiten...

edit:

das mit der Tesslation wird eigendlich erst ab VS3.0 richtig gut.
Und ich habe mal gelesen dass dieses später in DX10 oder 1 noch weiter entwickelt werden sollte...

Die Idee bei VS3.0 (da dieser bis zu 4 Texturen zur gleichen Zeit auflegen kann), ist dass man hardware displacement mapping einlegen kann. Natuerlich wird es weiterentwickelt.

Wenn Du noch nicht Matrox's Displacement Mapping pdf gelesen hast und interessiert bist, ist eine gute Lektuere.

[Demirug]

Bei der ganzen VS 3.0 Geschichte bitte nicht vergesen das es sich dabei nur um die Displacment Teil des DM handelt. Die Tesselation muss immer noch vor dem Vertexshader gemacht werden und gerade in diesem Teil sehe ich noch einiges an flexibilisierungbedarf da DX9 hier nach wie vor nur recht stare Verfahren zur verfügung stellt.

[Ailuros]

Tja leider ist es der einzige Schritt naeher an Matrox's DM. Waere es falsch zu spekulieren dass wenn HOS irgendeine Zukunft haben sollten, DM der beste Kandidat sein koennte?

[Demirug]

Originally posted by Ailuros
Tja leider ist es der einzige Schritt naeher an Matrox's DM. Waere es falsch zu spekulieren dass wenn HOS irgendeine Zukunft haben sollten, DM der beste Kandidat sein koennte?

Was das reine Displacement angeht übersteigt VS 3.0 die Fähigkeit des DM von Matrox ja bei weitem. Als Tesselationsverfahren kommt bei Matrox nur N-Patch zum Einsatz. Und genau an dieser Stelle liegt IMO die nächste Herausforderung für die Hardwarehersteller. Ein Programmierbarer HOS-Shader muss her.