NV50 mit einheitlichen Shadercores?

[Demirug]

nVidia hat ja nun seit längerem den einen Cg Compiler im Treiber eingebaut. Lustigerweise auch im DX Treiber. Möglicherweise stellt er auch einen Teil des Shadercompilers dar. Aber darum soll geht es hier jetzt nicht.

Die Version im Treiber entspricht nicht der öffentlichen Version des Cg Compilers sondern scheint neuer zu sein. Darin findet man Verweise auf zwei neue Profile fp50 und vp50. Die 50 lässt auf einen NV50 schliessen. Interesant wird es nun aber bei der Zuweissung der Profile zu einer Kennung. Bisher verwendete nVidia "!!FPx.x" und "!!VPx.x". Also schön getrennt zwischen Vertex und Fragmentprocessing. Bei den NV50 Profile findet sich allerdings die Kennung "!!SPA1.0" beim Vertex und Fragmentprofil. Das lässt nun darauf schliessen das für beide Einheiten ein identischer Syntax benutzt wird. Vereinte Shadercores sind dabei ebenfalls nicht auszuschliessen.

[deLuxX`]

Klingt interessant. Was genau würde mir das als Programmierer bringen?
Kann ich, wenn ich z.B. in einer Szene mehr Pixel- als Vertexshaderleistung benötige, diese Cores dann dynamisch verwenden? Oder was muss ich mir darunter vorstellen?

[Coda]

Das macht wenn dann schon die Grafikkarte selber, bzw. der Treiber. Es soll ja nicht komplexer sondern einfacher werden.

[Quasar]

SPA = Shading Processor Architecture?

[Thanatos]

Also heist das, alle teile die sozusagen "faul rumliegen" können dann in sachen miteingespannt werden die sie vorher nicht gemacht hätten???

Also die Mutti für alles, oder wie??

[Demirug]

Also heist das, alle teile die sozusagen "faul rumliegen" können dann in sachen miteingespannt werden die sie vorher nicht gemacht hätten???

Also die Mutti für alles, oder wie??

Nur die Shadereinheiten. Wenn also gerade nicht so viele Verticen zu berechnen sind wird die Leistung den Pixel zugeschoben. Aber auch in die andere Richtung funktioniert das ganze.

[Demirug]

SPA = Shading Processor Architecture?

Ich würde eher auf Shader Programm Assembler tippen

[Godmode]

Kann man daraus jetzt was schließen ob der NV50 gecancelt wurde? Ist das der Treiber in dem auch Einträge für den NV48 drinnen sind?

[StefanV]

Kann man daraus jetzt was schließen ob der NV50 gecancelt wurde? Ist das der Treiber in dem auch Einträge für den NV48 drinnen sind?
Nochmal:
Der nV50 wurde _NICHT_ gecancelt, er wurde ge_CANNt_, was so viel wie Eingemottet bedeutet.

Man könnte auch sagen, das das Projekt auf Eis liegt, ev. gar nur TEMPORÄR.

Klartext:

Der nV50 kann noch kommen, nur halt z.B. ein Jahr später als geplant.

[Godmode]

Naja vielleicht bringen sie den NV50 erst mit WGF!

[Coda]

Ist zu vermuten, NV40 mit Detailverbesserungen reicht bis dahin noch aus.

[marco42]

wie werden dann aber Befehle wie dFdx implementiert im vertex shader, das geht AFAIK ja schlecht. Oder implementieren sie einen micropolygonrenderer ala renderman? :-)

[Xmas]

Nochmal:
Der nV50 wurde _NICHT_ gecancelt, er wurde ge_CANNt_, was so viel wie Eingemottet bedeutet.

Man könnte auch sagen, das das Projekt auf Eis liegt, ev. gar nur TEMPORÄR.
Abgesehen davon dass Fuad sowieso nicht zwischen canned und canceled unterscheidet, ist dies auch weiterhin nur ein unbestätigtes Gerücht.

[Gast]

Ist zu vermuten, NV40 mit Detailverbesserungen reicht bis dahin noch aus.

Vielleicht legen sie ihn entsprechend überarbeitet in 90nm noch mal auf.

[Godmode]

Ich denke der NV50 war sowiso für 90 nm geplant?

[Gast]

Es war vom NV40 in 90nm die Rede um eventuell die Zeit bis WGF und NV50 zu überbrücken.

[Gaestle]

Für meinen beschränkten Horizont (in technischer Hinsicht) wäre das logisch.

NV hat die DirectX-Technik bzw. Spezifikationen (nahezu) ausgereizt und den NV50 auf WFG (nun 2.0) getrimmt. Da dies aber erst später kommt, verschieben sie den WGF(2.0)-NV50 und schieben ein Speed-Upgrade der (definitiv) letzten DirectX-Architektur dazwischen, eventuell später auch schon mit WGF-Kompatibel beworben, dann aber WGF1.0 ...

Grüße

[robbitop]

vermutlich will keiner der beiden IHVs frühzeitig ein WGF2 Chip auf den Tisch packen. Wäre vieleicht ein taktischer Nachteil. Zumal ein neues Design immer Risiken birgt, die kein Hersteller mehr tragen will (ich erinnnere gern an NV30 und R400).
Wenn das mit NV50 stimmt, dann wird er wohl als Respin später herauskommen.
So wie ATI den R400 zurückggestellt hat. Manchmal sind Projekte einfach zu ambitioniert, um sie im Zeitrahmen so realisieren zu können, wie man es gern hätte...ohne große Restriktionen.

[DrumDub]

Für meinen beschränkten Horizont (in technischer Hinsicht) wäre das logisch.

NV hat die DX-Technik (nahezu) ausgereizt und den NV50 auf WFG (nun 2.0) getrimmt. Da dies aber erst später kommt, verschieben sie den NV50 und schieben ein Speed-Upgrade der letzten DX-Architektur dazwischen.

Grüße

ja, das klingt für mich auch plausibel. eine wgf-2.0-kompatible gpu auf den markt zu bringen bevor longhorn da ist, halt ich aus wirtschaftlicher und marketingtechnischer sicht für wahnsinn. schließlich kann man das potential in keinster weise demonstrieren. theoretisch ginge es ja über cg und opengl, aber damit spricht man nicht den umsatzstärksten markt an, nämlich die spieler. (abgesehen davon, dass m$ da sicherlich auch kein interesse darn hat.)

[q@w]

Ich weiß ja nicht, wie hoch die Marktanteile bzw. Nettogewinne jeweils sind, aber mit einem "unified shader"-Modell könnte man auch heute schon optimal Spiele- und CAD/Rendering-Bereich abdecken.

Ich hätte nichts dagegen, wenn meine 6800nu einen oder auch drei ihrer sechs VS in ein oder zwei zusätzliche Pixelquads umwandeln könnte - idealerweise kann ich das im RivaTuner abhaken, welche Einheit was tun soll.

Jemand, der viel CAD/CAM betreibt würde dagegen vermutlich lieber 16 VS haben.


Wie gesagt, ich denke nicht, daß es zu früh wäre - im Gegenteil, unified shader wären eine der wenigen Fortschritte, die vermutlich sofort nutzbar wären, IMO

[Godmode]

...ohne große Restriktionen.

Inwiefern? Fertigungstechnisch? oder weil es noch keine API gibt mit der man einen WGF2.0 Chip programmieren könnte?

[robbitop]

nein ich meinte das eher im Sinne von einer Beschränkung auf Leistung ODER Komplexität. Siehe NV30.
Ein sehr ambitioniertes Projekt, seiner Zeit auch deutlich voraus. Die Beschränkung lag allerdings in der Leistungsfähigkeit. Diese wurde erst mit NV40 aufgehoben, da die Fertigungstechnologie deutlich eher ausgereift war und man mehr Zeit hatte. (NV30 hat ja viel Vorarbeit zum NV40 Design geleistet)

[Demirug]

Ich weiß ja nicht, wie hoch die Marktanteile bzw. Nettogewinne jeweils sind, aber mit einem "unified shader"-Modell könnte man auch heute schon optimal Spiele- und CAD/Rendering-Bereich abdecken.

Ich hätte nichts dagegen, wenn meine 6800nu einen oder auch drei ihrer sechs VS in ein oder zwei zusätzliche Pixelquads umwandeln könnte - idealerweise kann ich das im RivaTuner abhaken, welche Einheit was tun soll.

Jemand, der viel CAD/CAM betreibt würde dagegen vermutlich lieber 16 VS haben.


Wie gesagt, ich denke nicht, daß es zu früh wäre - im Gegenteil, unified shader wären eine der wenigen Fortschritte, die vermutlich sofort nutzbar wären, IMO

Warum willst du das im RivaTuner einstellen? Bei echter unified Hardware macht das der Chip abhängig von der Last aleine.

Wobei ein VS != 1 Quad. Man müsste schon 4 VSen für einen Quad nehmen. Ich könnte mir aber durchaus auch vorstellen das man Mittelfristig den 3dlabs weg geht.

[TheGoD]

Wenn diese Lastenzuteilung ohnehin allein durch den Treiber geregelt wird, warum muss dann die darüberliegende API dieses Feature überhaupt unterstützen?

[q@w]

Warum willst du das im RivaTuner einstellen? Bei echter unified Hardware macht das der Chip abhängig von der Last aleine.

Wobei ein VS != 1 Quad. Man müsste schon 4 VSen für einen Quad nehmen. Ich könnte mir aber durchaus auch vorstellen das man Mittelfristig den 3dlabs weg geht.

Ja, wenn der Chip/Treiber das von Anfang an ordentlich kann - ansonsten hätte ich absolut nichts gegen einen Schieberegler zwischen Pixel- und Geometrieleistung einzuwenden.
Das RT-Beispiel war nur gewählt, weil man da ja jetzt schon in gewissen Grenzen Pixel- und Geometrieleistung variieren kann.
Daß man einen VS nicht gegen ein Pixel-Quad tauschen kann, war mir bewußt - ich hab's auf der arbeit leider etwas eiliger mit meinen Postings und kann mir nicht immer die zeit nehmen, die ich bräuchte, um ordentlich zu formulieren. Sieh' es als Beispiel an. ;)

[Demirug]

Wenn diese Lastenzuteilung ohnehin allein durch den Treiber geregelt wird, warum muss dann die darüberliegende API dieses Feature überhaupt unterstützen?

Für die Lastverteilung braucht man keine API Unterstützung. Mit dem vorhandensein von Unified Hardware geht jedoch auch einher das nun VS und PS das gleiche können. Um das zu nutzen braucht man die API Unterstützung.

[sepperator]

Hmm, lustig wirds dann bei Benchmarks ala 3DMark. (Spezielle Vertex-, Pixelshader Tests)

[JACKxBAUER]

mich interessiert der aufbau des R520, soll ja ne komplette neuentwicklung sein, vielleicht weis nvidia ja schon mehr über den r520 und haben dan gemerkt das sie mit ihrer technik entweder zu früh oder zu spät dran sind (eben wie z.b. wgf2) und dan haben sie eben den nv48 - nv50 so halb gecancelt !

[Ailuros]

mich interessiert der aufbau des R520, soll ja ne komplette neuentwicklung sein, vielleicht weis nvidia ja schon mehr über den r520 und haben dan gemerkt das sie mit ihrer technik entweder zu früh oder zu spät dran sind (eben wie z.b. wgf2) und dan haben sie eben den nv48 - nv50 so halb gecancelt !

NVIDIA hat gar nichts storniert. Zwischen deren WGF2.0 chip und NV40 erwartete ich stets einen Zwischenschieber der nichts anderes als ein schnellerer NV40 sein wird. Was fuer einen Codenamen der WGF2.0 chip nun traegt sollte wohl egal sein.

Der NV40-Nachfolger (und nicht WGF2.0 chip) wird genauso viel ein SM3.0 chip wie (hoffentlich) auch R520.

Verspaetet morgen Microsoft nun doch noch um sagen wir mal noch ein Jahr die WGF2.0 Veroeffentlichung werden auch logischerweise beide IHVs ihre roadmaps dementsprechend aendern. Nach momentanem Standpunkt sind WGF2.0 chips nicht vor dem 2.Halbjahr 2006 zu erwarten.

DX9.0

ATI = R3xx/SM2.0, R4xx/SM2.0_b, R5xx/SM3.0/2005, R6xx/WGF2.0/2006

NVIDIA = NV3x/SM2.0_a, NV4x/SM3.0, (SM3.0 Nachfolger)/2005, WGF2.0/2006

Ob man die beiden letzteren nun NV50 und NV60 oder auch NV47 und NV50 nennt, sollte im Grund eigentlich egal sein.

B3D August 2004:

In statement that echoed ATI's previous sentiments, NVIDIA are suggesting that due to chip complexities and lithography cycle times architectural innovation times will be pushed out to about 18 months. Although NVIDIA are suggesting similar things to ATI now, if we look at NVIDIA's NV2x and NV3x generations, they have been on greater than 12 month cycles for the past two generations anyway (taking into account that NV30 was launched in November 2002, which was probably close to its intended introduction). This being the case, given NV40's announcement and wide scale availability, it would suggest that the NV50 series will not be announced until late 2005 with possible wide scale availability in 2006. NVIDIA have already stated to their investors that the low end NV4x parts will last for up to 3 years, indicating that the NV5x range will remain the domain of the high end segments and that NV4x will stay around until "Windows Graphics Foundation" in Micorsofts next geneteration OS, Longhorn.

The release of Longhorn will also be critical to both NVIDIA and ATI's plans - given the timing and the fact that there are not to be any low end NV5x, this may suggest that NV5x is set to be an extended Shader 3.0 architecture, which would indicate that the further Longhorn moves into 2007 the better it would suit NVIDIA's architectural innovation cycle. Presently the expectation is that ATI will introduce their Shader 3.0 part, suggested to be primarily developed by the R300 architectural team, in mid 2005 - ATI may be a little off their 18 month cycle as they chose not to innovate as much this cycle in order to hit the PCI Express transition - and that would also suggest that "R600" based parts would come in the late 2006 / early 2007 period. Regardless of longterm exrapolated timescales, though, its likely that both vendors will attempt to hit as close to the introduction of Longhorn as possible.


B3D October 2004:

A couple of conflicting reports for NVIDIA have suggested that they may still be shopping around for their next process beyond 110nm. While IBM or TSMC may normally have been NVIDIA’s first port of call for next generation processes, NVIDIA’s reluctance to use TSMC’s 130nm low-k may be causing them to be a little leery of TSMC’s 90nm node as it is currently only offered with low-k dielectric materials. There have also been persistent reports over capacity and yield issues on IBM’s customer lines which, whilst improving, may well carry over to finer processes which could be another cause for concern. Rumours have suggested that NVIDIA’s next high end chip refresh to “NV47” may boost performance by increasing the number of internal pipelines whilst moving to 110nm, with a larger shift to 90nm later with the NV5x platform – ATI’s continued use of 150nm for R300, R350 and R360 was proof that continuing longer on a tried and tested process can still yield a performance advantage as whilst top end clock-speed may be limited in relation to the newer processes, a greater understanding can allow for larger die sizes with greater parallelism affording more performance per cycle.

Newsblurbs bei B3D werden stets aeusserst vorsichtig formuliert. Nirgends steht irgendwas von absoluten Fakten drin nur Moeglichkeiten. Inq Authoren sind eigentlich nur schlechte Abschreiber, die weder den Durchblick noch die Intelligenz haben wenn sie schon so schamlos den Papageien spielen wollen, dass es auch wenigstens dem Sinn der Originale auch folgt.

[Gast]

Was fehlt dem NV40 was ihn wirklich schneller machen würde? Nur mehr Takt, schnellerer Speicher und/oder mehr "Pipelines" können doch nicht alles sein, oder? Fehlt einfach eine "Optimierung" für ihn, zumindest unter OGL da sowas unter DX doch recht beschränkt ist, oder müsste er doch vom Design her stark geändert werden damit er fixer wird?

Nicht das ich ihn für langsam halte, aber was für Verbesserungen könnten ihn noch schneller machen?

[Demirug]

Was fehlt dem NV40 was ihn wirklich schneller machen würde? Nur mehr Takt, schnellerer Speicher und/oder mehr "Pipelines" können doch nicht alles sein, oder? Fehlt einfach eine "Optimierung" für ihn, zumindest unter OGL da sowas unter DX doch recht beschränkt ist, oder müsste er doch vom Design her stark geändert werden damit er fixer wird?

Nicht das ich ihn für langsam halte, aber was für Verbesserungen könnten ihn noch schneller machen?

Die IMHO beiden grössten Probleme sind die grossen Blöcke beim Branching und ein syncronisations Problem zwischen den Texturefiltern und den ALUs.

Das sind aber beides Dinge welche sind nicht mal so auf die schnelle ändern lassen.

[Gast]

Doof gefragt, was könnten diese Änderungen in %en bringen? Vorteile bei DX9 für Branching bestimmt, wie sieht es unter DX8 aus?

[Demirug]

Doof gefragt, was könnten diese Änderungen in %en bringen? Vorteile bei DX9 für Branching bestimmt, wie sieht es unter DX8 aus?

Wie man Branching auch bei <= DX8 Techniken einsetzten kann habe ich ja mal vor langer Zeit dort http://www.3dcenter.org/artikel/2004/03-31_a.php aufgeführt. Das gilt natürlich auch für DX9 Shader welche kein Branching von sich aus enthalten. Beim NV4X funktioniert das meiste davon aber nicht weil die Blöcke einfach zu gross sein.

Das Syncproblem wirkt sich vorallem beim Einsatz von AF in Verbindung mit aufwendigen Shadern aus.

Die Performancegewinne durch beseitigen der Probleme wären also sehr Situationsspezifisch.

[Gast]

Also bleibt vorerst nur mehr Takt, schnellerer Speicher und/oder Architekturverbreiterung übrig. Hmm schade, zumindest unter OGL könnte ich mir vorstellen das da richtig die Luzie abgeht.

Vielleicht sollte id für D3 auch ein paar "Nvidia Levels" bringen ;)

[Gast]

Frage zu deinem Artikel: Macht irgendein Treiber schon "Branching" bei <= DX8 oder ist das noch Wunschdenken? Ich gehe mal davon aus das der NV40 schon flott genug für ältere Spiele ist aber mehr Geschwindigkeit kann ja bekanntlich nie schaden :)

[robbitop]

um berücksichtigte man diese Probleme nicht im NV4x Design?
Transistorbudget?

[Gast]

Unterscheiden sich eigentlich DX9.0c und WGF1.0 irgendwie?

[Demirug]

Frage zu deinem Artikel: Macht irgendein Treiber schon "Branching" bei <= DX8 oder ist das noch Wunschdenken? Ich gehe mal davon aus das der NV40 schon flott genug für ältere Spiele ist aber mehr Geschwindigkeit kann ja bekanntlich nie schaden :)

IMHO nein weil die Blöcke zu gross sind um da was auf Verdacht zu machen. Wenn dann höchstens als Shaderreplacment.

[Demirug]

Unterscheiden sich eigentlich DX9.0c und WGF1.0 irgendwie?

Ja, zum einen auf der Treiberebene zum anderen noch ein paar details die aber nur in Verbindung mit dem 3D-Desktop relevant sind.

[mapel110]

375-400 million of transistor on 90-nm process
550-600 MHz core
1600 MHz 256Mb (Support for upto 512Mb) GDDR3
Graphics Core 256-bit
Memory Interface 256-bit
32 (24 real) pixels pipelines (on the Ultra model)
32 Vertex Shader Engines
51.2 GB/sec Bandwidth (GDDR 3)
Fillrate 12.8 billion texetls /sec.
Textures per Pixel 32 (maximum in a single redering pass)
Nvidia's LMA - IV
DirectX 9.0d UMI-23
Release date Q3 2005.
http://www.community.tomshardware.com/forum/showflat.m?Cat=&Board=comp_graphics&Number=572551&page=0&view=collapsed&sb=5

eigentlich nicht wirklich ein Posting wert, aber bevor es jemand anders tut .. :)

[Savay]

Graphics Core 256-bit
Memory Interface 256-bit


müsste das beides nicht 512bit sein?! vorallem ersteres...hmm sieht mir aber sonst doch alles eher nach wunschdenken aus :biggrin: :wink:

[deekey777]

375-400 million of transistor on 90-nm process
550-600 MHz core
1600 MHz 256Mb (Support for upto 512Mb) GDDR3
Graphics Core 256-bit
Memory Interface 256-bit
32 (24 real) pixels pipelines (on the Ultra model)
32 Vertex Shader Engines
51.2 GB/sec Bandwidth (GDDR 3)
Fillrate 12.8 billion texetls /sec.
Textures per Pixel 32 (maximum in a single redering pass)
Nvidia's LMA - IV
DirectX 9.0d UMI-23
Release date Q3 2005.
http://www.community.tomshardware.com/forum/showflat.m?Cat=&Board=comp_graphics&Number=572551&page=0&view=collapsed&sb=5

eigentlich nicht wirklich ein Posting wert, aber bevor es jemand anders tut .. :)


Da dachte sich einer:"Die Specs der R520er waren doch etwas übertrieben, die Specs NV50 werde ich also etwas vernünftiger aussehen lassen." ;(

Na ja, davor soll doch noch der NV47 erscheinen, oder?

[Ailuros]

ROFL genauso amuesant wie das theoretische 6 quad@700MHz Monstrum im anderen thread.... ;D

Na ja, davor soll doch noch der NV47 erscheinen, oder?

Falls der Codename auch stimmt, wird das wohl alles sein fuer 2005. Auf 90nm wuerde ich dieses Jahr nicht mehr hoffen und die 6 quads/16 ROPs/8VS Theorie klingt am wahrscheinlichsten. Was die Taktrate betrifft bei so hoher Komplexitaet, waere ich eher extrem konservativ.

[robbitop]

512 Bit DDR Interfaces werden sooo schnell nicht kommen.

[aths]

375-400 million of transistor on 90-nm process
550-600 MHz core
1600 MHz 256Mb (Support for upto 512Mb) GDDR3
Graphics Core 256-bit
Memory Interface 256-bit
32 (24 real) pixels pipelines (on the Ultra model)
32 Vertex Shader Engines
51.2 GB/sec Bandwidth (GDDR 3)
Fillrate 12.8 billion texetls /sec.
Textures per Pixel 32 (maximum in a single redering pass)
Nvidia's LMA - IV
DirectX 9.0d UMI-23
Release date Q3 2005.
http://www.community.tomshardware.com/forum/showflat.m?Cat=&Board=comp_graphics&Number=572551&page=0&view=collapsed&sb=5

eigentlich nicht wirklich ein Posting wert, aber bevor es jemand anders tut .. :)Grrr. Wieder solche "spekulativen" Specs. Da denkt sich irgendwer was aus und lacht sich ins Fäustchen. Und alle schreiben es ab, mit der Behauptung, es KÖNNTE ja vielleicht was wahres dran sein. Wer nicht verwirren möchte, sollte auf solche "Specs" nicht eingehen, und sie auch nicht weiterverbreiten.

[Ailuros]

aths,

Deine PM Box ist voll :P

[Hauwech]

512 Bit DDR Interfaces werden sooo schnell nicht kommen.

Wie sieht es mit 384 Bit DDR Interfaces aus? Irgendwo stand mal, das Samsung die 800MHz gestrichen hätte und man sieht und hört nicht viel von GDDR3 > 600MHz. Oder kommt was neues (Rambus?)?

Was soll dieses DX9.0d UMI-23 sein? Glaube nicht, das MS bis Longhorn da noch was nachschieben wird, abgesehen von der 64 Bit Version.

[Demirug]

Was soll dieses DX9.0d UMI-23 sein? Glaube nicht, das MS bis Longhorn da noch was nachschieben wird, abgesehen von der 64 Bit Version.

Alle 2 Monate gibt es ein neues SDK was in Zukunft wahrscheinlich auch jedesmal in einer neuen Runtime enden wird weil man die Verbesserungen am Shadercompiler an die Benutzer weitergeben will. Ist aber noch nicht entgültig beschlossen wie das alles ablaufen soll.

Eine 64 Bit DX Version gibt es doch schon.

EDIT: Aber mit dieser merkwürdigen Versionbezeichnung kann ich auch nichts anfagen.

[aths]

aths,

Deine PM Box ist voll :PDu kennst meine Mail-Adresse.

[Kladderadatsch]

für was der gerwaltige sprung von 6 auf 36 vertex shader?
ich dachte, die 6 würden für die momentanen geometrie-berechnungen noch lange nicht limitieren?

[HOT]

für was der gerwaltige sprung von 6 auf 36 vertex shader?
ich dachte, die 6 würden für die momentanen geometrie-berechnungen noch lange nicht limitieren?

Bei unified SM bedeuten vereinfacht 32Pixelpipelines=32Vertexpipelines, wobei die sich dann die Leistung teilen müssen ;)

[Leonidas]

für was der gerwaltige sprung von 6 auf 36 vertex shader?
ich dachte, die 6 würden für die momentanen geometrie-berechnungen noch lange nicht limitieren?



Ähm, ich glaube nicht, daß man bei Specs, die ganz offensichtlich falsch sind, nach Logik bzw. Erklärungen suchen sollte.