PureBoard

auf kleinem speicher mit geringen taktzahlen kann ich kein globales klimamodell darstellen...

ein schnell gerechnetes system mit kleinen zellen ist flexibel genug,
man kann extremste Differnziale als mehrdimensionale einzelzellen-interferenzen berechnen.

...im endeffekt dienten diese komplexen Differenziale nur dazu,
die grenzen von speicher und geschwindigkeit zu überwinden...
man hat abertausende auf einander einwirkende faktoren in eine irrsinnig komplexe formel gepackt,
die ans maximum der verfügbaren rechner angepasst war,
weil der maximale rechner nicht alle faktoren für sich einzeln aufs tablett packen konnte.

was meinst du, wie man die wirbelströme um die tragflächen eines jets berechnen kann,
wenn man druck und temperatur und deren interaktion für milliarden tausendstel-kubikmillimeter-kleine
raumkuben in mehrfacher echtzeit berechnen kann?
dann muss man sich keine hunderte komplexen differenziale um die ohren schlagen für ein globales klimamodell....

fein solche vereinfachungen zu haben, wie deine kubus-engine...
mit genügend speicher und tempo kann man daraus auch ne anständige globale simulation machen,
wo man wirklich achtzig tage um die welt braucht, weil sie so scheiße groß ist.

also, konsolen schön und gut... aber in diesem fall sag ich doch mal nicht "think pink" sondern "think HUGE"...


[EDIT];----------------------------------------------------------------

Emily hat geschrieben:Die Farbtiefe der Grafikkarte hat nichts mit der Bitweite des Prozessors zu tun, abgesehen von der Kleinigkeit, dass reine Softwareoperationen auf einem 16Bit system bei 32bit Farbtiefe zwei Kopieroperationen pro pixel bräuchten.
Die aktuellen Grafikkarten können iirc intern inzwischen 128Bit Farbtiefe, was man nur deswegen macht, damit es bei längeren shaderprogrammen weniger/keine Präzisionsverluste durch akkumulierte Ungenauigkeiten und konvertierungen auf den Farbpuffern gibt. Zum Schluss wird das ganze dann natürlich nach Desktopfarbtiefe konvertiert.

sorry, den Beitrag am Seitenende hätte ich fast übersehen, wurde erstellt wärend ich schrieb.
völlig korrekt und informationsdicht wie immer.... sag mal, magst du mich heiraten....?
höhere Farbformate gibt es gegen die verfälschungen, nicht weil irgendein Dritter Schimpanse es sehen könnte...
die argumentation für höhere registerbreite ist vor allem der immens höhere speicherzugriff und die höhere rechengenauigkeit bei dingen, wo es drauf ankommt.
wellenlängen sind da schon interessant, aber dann eher das gesamte spektrum, nicht das sichtbare licht.
für die meisten menschen genügen 256 farben, die meisten können eh nicht mehr als 16 benennen.

Was hat denn die Farbtiefe der Grafikkarten mit der breite der Speicheranbindung zutun?

@dllfreak2001:
Naja, die meisten 16Bit CPUs waren doch sicher über 16bit Datenbusse verbunden, oder? Ich kenne mich da nicht so sehr aus, das war vor meiner Zeit
Ich hab allerdings mal VGA Code gesehen, da wurde in den Framebuffer mit der CPU geschrieben. Also müsste bei 32bit Farbtiefe so eine 16bit CPU doch zwei Schreibzugriffe pro Pixel brauchen oder betrachte ich das ganze jetzt zu naiv?

@Kaeru Gaman:

hehe, ich bin leider noch zu jung um heiraten zu können... die Leute tuscheln schon schlimme sachen wegen meiner Freundschaft zum alten Zaphod (grins)

Ich kenne mich jetzt mal überhaupt nicht mit Grafikarchitekturen aus.
Würde mal aber tippen, dass die Farbwerte nicht so breit verarbeitet werden wie die Speicherbandbreite der Grafikkarte ist.
Ein 32Bit-Farbwert ist in der Grafikkarte auch 32-Bit groß, alles andere ist Speicherverschwendung. Da kommen einfach nur mehrere Farbwerte auf einmal an. Bei einer Grafikkarte die stark prallelisiert arbeiten kann sicher kein Problem. Und GPU intern rechnen die wohl mit 128Bit aber nur um entsprechende Präzision bei der Berechnung von 3D-Daten zu erlangen. Solche Sachen wie AA und AF könnten auch davon profitieren.
NV hat mal mit den FX-GPUs versucht 64Bit aufm Desktop einzuführen und hatten damit keinen Erfolg, zurecht!
Ich wüsste jetzt auch garnicht was man mit mehr Bits bei einem 32Bit-Farbwert machen sollte, aller höchstens haben die noch eine Alphamap.

Ob das jetzt stimmt weiß ich nicht, ich würde es mir aber so denken.
Ansonsten kann ich ja mal im 3D-Center anfragen.

Naja, ich denke sehr parallelisiert waren Grafikkarten zu 16bit-CPU zeiten noch nicht

Ich hab so ein bisschen mit Grafikprogrammierung auf dem Framebuffer in Software gemacht und war erstaunt wie langsam schon 16bit Farbmodi da sind.
Auf einem 800MHz Rechner war mit 1024*768*16bit kaum was Spielbares zu erreichen, vielleicht hab ich mich aber auch einfach nur dumm angestellt. ^^

Mit Hardwarebeschleunigung ist es natürlich was anderes.

Wahrscheinlich sind heutige Karten eben auf 32-Bit optimiert...
Ist mit PB nicht anders.

Aber die Farbtiefe künstlich zu erhöhen erscheint mir nicht logisch.

Ich glaube wir haben da auch aneinander vorbei geredet. Klar bringt auf dem Bildschirm am ende mehr als 24Bit überhauptnichts, nicht nur weil ein Mensch garnicht mehr sehen kann, sondern auch weil außer sehr teuren Grafikermonitoren so ein TFT kaum 12bit farbtiefe erreicht.

Intern rechnen neuere Grafikkarten aber häufig mit sehr hohen farbtiefen um genau wie bei den 3D Daten keine (weniger) ungenauigkeiten auflaufen zu lassen, was bei vielem übereinanderzeichnen von Transparenten Texturen und shader wohl recht schnell passiert. Ich hab mich nicht so viel mit OpenGL beschäftigt, aber gab es da nicht sogar optional floating point Farben?

Das hat bei modernen Karten auch glaube ich überhauptnichts mit der Speicherbandbreite zu tun, aber ich denke das war früher mit puren softwarezeichenfunktionen schon sehr wichtig und auch der Grund weswegen spiele auch auf SVGA karten noch in 8bit Farbtiefe liefen.

die 8bit farbtiefe hat vor allem mit dem speicherverbrauch von tausenden prerendered animation-frames zu tun.
das problem wurde durch das life-renderung von 3D-models obsolet...
wenn man trotzdem mit prerendered arbeitet, wird man bei 32bit grafiken spott für den speicherverbrauch
ernten, das ist Stargate bei seiner ersten veröffentlichung seines DUNE passiert....

anständige RayTracer rechnen intern mit 64bit bis 128bit floatingpoint farbwerten,
um die ungenauigkeiten zu minimieren.
ja du hast recht, tausende verschiedene transparenzen und reflexionen machen sowas nötig.
wenn also auf ner grafikkarte "128bit" steht, bin ich mir eigentlich sicher, dass sie mit floats arbeitet.
(vergewissert hab ich mich nicht, aber anders wäre unsinn)

früher war sowas tatsächlich ein speichergrößen-problem, und auch ein busbreiten-problem,
weil komplexe vektor-operationen von der CPU vorgenommen werden mussten.
auch das ist obsolet, weil die GPU durchschnittlicher karten heute besser ist, als damalige 16bit CPUs.

Die Bit-Angabe an den Grafikkarten bezeichnet nur die Breite Speicheranbindung. So gibt es von 128 - 512 Bit im Heimsektor alles mögliche am Markt. Glaube kaum, dass die da auch Unterschiedliche
Farbtiefen haben (zumal es teilweise die gleichen GPUs sind).
Sicher arbeiten Gafikkarten massiv mit floats (zB. für 3D-Darstellung),
dachte nur bei den Farbwerten würden die anders vorgehen.
Hätte jetzt nicht gedacht, dass die sogar die Farben per Floatingpoint berechnen, interessant.

also, für Grafikkarten hab ich nich so den plan, hätte jetzt gedacht,
dass die angegebenen bits die interne verrechnung bedeuten, weniger die speicheranbindung.
oder meinst du die interne speicheranbindung, also mit wieviel bits die GPU auf ihr GMEM zugreifen kann.....
weil die Busbreite is ja durch den slot definiert, AGP is AGP bei der Busbreite, egale wie schnell....

mein persönlichen farbwerte-erfahrungen liegen vor allem im RayTracing-bereich,
wo intern dementsprechend in maximalen floats gerechnen wird,
und ausgaben in 64bit farben (also 16bit prokanal incl. alpha) selbstverständlich ist.
musst nur das richtige ausgabeformat eingeben.

für 3D grafikkarten kann ich das weder bestätigen noch verneinen,
aber warum sollten die eine der übernehmbarsten techniken nicht übernehmen.
sie haben ja ansonsten nur die simple polygon-darstellung übernommen,
richtige polynome Körper sind unmöglich.