Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
News Nvidia bringt ersten OpenCL-Treiber
- Ersteller Wolfgang
- Erstellt am
- Zur News: Nvidia bringt ersten OpenCL-Treiber
IC3M@N FX
Lieutenant
- Registriert
- Sep. 2004
- Beiträge
- 717
Wo steht das geschreiben nur weil die mehr Streamprozessoren schneller sein soll als das Nvidia Pendat sonst wären ja die Karten im schnitt 2 mal so schnell wie Geforce karten bei Games was nicht der fall ist sogar im gegenteil die GTX 285 immer noch schneller in den meisten Games als Ati HD 4890 und das obwohl die weniger Streamprozessoren hat.
Stadtlohner
Lt. Commander
- Registriert
- Aug. 2008
- Beiträge
- 1.227
Rein theoretisch müsste dien die 5D shader der ATI karten schneller sein. Allerdings muss es erstmal eine Software geben, die diese technik nutzen kann. Solange es diese nicht gibt, ist ATI im nachteil, da die ersten wenger Shadereinheiten haben (Achtung 5D Shadern bei ATI sind nicht 1D Shader, wie bei Nvidia) die voll genutz werden.
LG stadtlohner
LG stadtlohner
@IC3M@N FX
Streamprozessoren sind für Spiele nicht so entscheidend. Daran kannst du deren Leistungsfähigkeit jedenfalls nicht ablesen. Wie gut sich die Shader Architektur im GPGPU Bereich schlägt, kann man nur erahnen. Plausibel wäre es aber, dass Radeons gegenüber GeForces nochmal ein gutes Stück zulegen.
Streamprozessoren sind für Spiele nicht so entscheidend. Daran kannst du deren Leistungsfähigkeit jedenfalls nicht ablesen. Wie gut sich die Shader Architektur im GPGPU Bereich schlägt, kann man nur erahnen. Plausibel wäre es aber, dass Radeons gegenüber GeForces nochmal ein gutes Stück zulegen.
dürfte auf jedenfall so kommen, das die ati karten schneller sein werden, kommt aber ganz auf den code an.
ati ist in den spielen unter anderem langsamer weil die meisten spiele recht wenig shader einsetzen, bzw. sehr kurze. liegt den unabhängigen shader auf nv karten wohl eher als den 160 5D einheiten bei ati.
bis zu einer gewissen shaderlänge werden die ati karten wohl zunehmend skalieren, während die nv karten einbrechen, selbes gilt umgereht für ati karten im hinblick auf texturfilterung etc.
ati ist in den spielen unter anderem langsamer weil die meisten spiele recht wenig shader einsetzen, bzw. sehr kurze. liegt den unabhängigen shader auf nv karten wohl eher als den 160 5D einheiten bei ati.
bis zu einer gewissen shaderlänge werden die ati karten wohl zunehmend skalieren, während die nv karten einbrechen, selbes gilt umgereht für ati karten im hinblick auf texturfilterung etc.
KlawWarYoshi
Cadet 3rd Year
- Registriert
- Dez. 2008
- Beiträge
- 40
Ned Flanders schrieb:Man kann damit im Grunde alles berechen was sich beliebig parallelisieren lässt.
Im Grunde sehe ich das ganze als den Killer der High End Prozessoren. Alles was nicht parallelisierbar ist profitiert nicht von Mehrkern CPUs und ist in der Regel auch nicht Performance kritisch, alles was sich parallelisieren lässt wird in Zukunft über die GPUs berechnet.
Die meißten Leute die sich für Videobearbeitung interessieren geben aktuell unsummen für High-End Prozessoren wie den Core i7 940 aus, dabei ginge das über eine 100€ Grafikkarte Energieeffizienter und sogar schneller.
Wer das mal testen will und eine aktuelle Nvidia Grafikkarte hat empfehle ich mal Badaboom als Testversion zu ziehen. Da tun sich ganz andere Welten auf.
Gruss Ned
ich denkae auch da gibt es eine Ausnahme : komplexe berechnungen!
wie zum beispiel Windows..
die sind prinzipell auch multi-core fähig
ob man dafür einen high-end-sorössling braucht ist was anders..
Lübke
Fleet Admiral
- Registriert
- Aug. 2007
- Beiträge
- 21.162
ich glaube, hier haben einige überhaupt keine ahnung, was es mit den shadern auf sich hat.
ati hat nicht mehr shader als nv sondern andere.
gtx275 hat 240 1d shadereinheiten
4890 hat 160 5d shadereinheiten
5d-shadereinheiten bringen mehr leistung bei niedrigerer effiziens. und zwar funktioniert das so:
ein 1d-shader kann immer nur eine operation gleichzeitig ausführen, die auslastung liegt dabei aber bei 100%
ein 5d-shader kann bis 5 operationen zeitgleich ausführen, aber er ist so lang komplett belegt, bis die letzte operation ausgeführt ist. wenn also eine lange und vier kurze operationen zu berechnen sind, sind alle 5 recheneinheiten solange belegt, bis die längste operation durchgeführt wurde, wärend bei 5 1d-shader 4 shader bereits mit den nächsten operationen begonnen haben.
eine 100% auslastung von 5d-shadern ist nur theoretisch möglich, somit kann die auslastung defakto nicht wirklich 100% betragen. man kann auch nicht so progarmmieren, dass ein programm nur aus identischen operationen besteht. die auslastung der 5d-shader ist quasi reine glückssache.
ati hat nicht mehr shader als nv sondern andere.
gtx275 hat 240 1d shadereinheiten
4890 hat 160 5d shadereinheiten
5d-shadereinheiten bringen mehr leistung bei niedrigerer effiziens. und zwar funktioniert das so:
ein 1d-shader kann immer nur eine operation gleichzeitig ausführen, die auslastung liegt dabei aber bei 100%
ein 5d-shader kann bis 5 operationen zeitgleich ausführen, aber er ist so lang komplett belegt, bis die letzte operation ausgeführt ist. wenn also eine lange und vier kurze operationen zu berechnen sind, sind alle 5 recheneinheiten solange belegt, bis die längste operation durchgeführt wurde, wärend bei 5 1d-shader 4 shader bereits mit den nächsten operationen begonnen haben.
eine 100% auslastung von 5d-shadern ist nur theoretisch möglich, somit kann die auslastung defakto nicht wirklich 100% betragen. man kann auch nicht so progarmmieren, dass ein programm nur aus identischen operationen besteht. die auslastung der 5d-shader ist quasi reine glückssache.
Kasmopaya
Banned
- Registriert
- Mai 2007
- Beiträge
- 12.285
An alle Programmierer da draußen: Programmiert bis die Tastatur schmilzt, bei der massiven Rechenleistung als Basis lohnt es sich.
https://www.computerbase.de/forum/t...it-der-gpu-rechnen.426771/page-2#post-5398995
Das Amdahlsche Gesetz erklärt recht gut warum. Nicht alles lässt sich unendlich parallelisieren und mit steigender Corezahl sinkt die Auslastungseffizienz exponenziell.
http://de.wikipedia.org/wiki/Amdahlsches_Gesetz
Probiert auch mal ArcSoft TotalMedia™ Theatre aus. DVDs erstrahlen in neuen Glanz, in HD Qualität. Würd keine DVD mehr anschauen ohne die Echzeitaufwertung.
https://www.computerbase.de/forum/t...it-der-gpu-rechnen.426771/page-2#post-5817617
https://www.computerbase.de/forum/threads/programme-die-mit-der-gpu-rechnen.426771/#post-4303110
MfG Kasmo
https://www.computerbase.de/forum/t...it-der-gpu-rechnen.426771/page-2#post-5398995
Darum nennt man es auch theoretische Rechenleistung.Dann bedeuten die theoretischen 1,2 Gigaflops der 4870 eher wenig.
Das Amdahlsche Gesetz erklärt recht gut warum. Nicht alles lässt sich unendlich parallelisieren und mit steigender Corezahl sinkt die Auslastungseffizienz exponenziell.
http://de.wikipedia.org/wiki/Amdahlsches_Gesetz
Probiert auch mal ArcSoft TotalMedia™ Theatre aus. DVDs erstrahlen in neuen Glanz, in HD Qualität. Würd keine DVD mehr anschauen ohne die Echzeitaufwertung.
https://www.computerbase.de/forum/t...it-der-gpu-rechnen.426771/page-2#post-5817617
https://www.computerbase.de/forum/threads/programme-die-mit-der-gpu-rechnen.426771/#post-4303110
MfG Kasmo
Zuletzt bearbeitet:
Eisenfaust
Banned
- Registriert
- Feb. 2007
- Beiträge
- 1.212
Mir ist auch noch immer nicht ganz klar, ob AMD/ATi Graphikkarten wirklich unter GPGPU-Einsatz 'massiver' arbeiten können als nVidias Produkte. Weiter oben wurde die Hardware ja ein wenig erklärt, nun liegt es an den Herstellern, inwieweit sie diese Eigenaschfaten nutzbar machen.
Ein weiterer großer Irrtum, aber immer wieder werbeträchtig als Leistungsmarker vorgebracht, ist, daß man große Sprünge mit den einfach genau rechnenden Rechenwerken machen könnte. Solange die 'Singleprecision' Operationen (per definitionem 32 Bit breit) ausreichend sind, läßt sich auch das Argument 1d/5d-Shader ins Feld führen. Aber im naturwissenschaftlichen Bereich sind heute die wenigsten(!) Modellrechnungen noch mit SP Rechnungen zu bewältigen. Dort, wo es wirklich auf Leistung ankommt, wird doppelte Genauigkeit oder gar vierfache Genauigkeit verlangt (wenn man auf einer Abbildung der Genauigkeit auf die Hardware/Register zur geschwindigkeitssteigerung in betracht zieht und nicht Bibliotheken mit umständlichen beliebigen Genauigkeiten verwendet). Klimamodelle, Strahlungsmodelle (Atmosphären), Bahndynamik, Trajektorien von Planeten, Kleinkörpern oder vor allem kernphysikalische Prozesse (Sonne, Fusion, Nuklearwaffen). Und hier, so habe ich mir einmal erklären lassen, würden AMDs Karten theoretisch besser punkten können, weil sie pro Shader-Cluster auch eine Recheneinheit mit doppelter Genauigkeit zur Verfügung stellen würden. Das tun nVidias Chips zwar auch, aber sie haben deutlich weniger Cluster! Leider werden diese DP-Rechenwerke im Moment kaum berücksichtigt!
Die nächste große Unbekannte scheint aber zu sein, was OpenCL und CUDA wirklich miteinander verbindet - zumindest habe ich den Eindruck. OpenCL definiert lediglich den Sprache, die Syntax, mit der letztlich unabhängig vom verwendeten Chipsatz ein Problem formuliert werden kann. Da OpenCL sehr ähnlich zu C ist, gibt es da keine großen Probleme. Im Moment versuche ich, etwas verzweifelt und unter den gegebenen Umständen völlig sinnlos, wie es scheint, einige mathematische Bibliotheksfunktionen der Numerical Recipes von Bress und anderen sowohl in einer C- als auch OpenCL-Fassung abzulegen. Und nun kommen wir dem Problem schon etwas näher, nämlich CUDA. Um überhaupt aus dem Quelltext ein lauffähiges Programm erzeugen zu können, benötigt man das, was man gemeinhin einen Compiler nennt. Mit OpenCL alleine kann man nur etwas 'formell' behandeln. Compilerbau ist schon eine Weile bei mir her, also nicht gleich schimpfen, wenn die Terminologie nicht mehr ganz stimmig ist.
CUDA benötigt einen proprietären Treiber und einen speziellen Compiler, um aus einem OpenCL-Quelltext dann ein Programm zu machen, das auf der GPU ausgeführt werden kann und die Ergebnisse dann wieder in den 'Adreßraum' des Prozessors bringt. Und genau hier sehe ich den Knackpunkt - und im Grunde keine wirklichen Fortschritte, auch wenn nVidia oder ATi das gerne anders sehen. Beide laborieren nach wie vor beim Backend mit ihren eigenen Treibern für die Karten und eigenen Schnittstellen für die Compiler. Von OpenSource kann einfach nicht die Rede sein. Wer nicht Frickel-Linux mit seinen Ati- und nVidia BLOB-treibern einsetzt, sondern völlig offenene BSD-UNIXe, hat verloren! Hier gibt es keine Treiber für die Graphikchips, die es ermöglichten, einen OpenCL-Compiler zu bauen. Bei ATi war durch die angebliche Offenlegung der 2D/3D Funktionen llvm im Gespräch, da man mit llvm relativ problemlos OpenCL im Frontend einsetzen könnte und im Backend einen auf die jeweilige Graphikhardware adaptierte Compiler/Linker/Assembler-Einheit. Aber ohne Spezifikationen geht das leider nicht.
Im wissenschaftlichen Sektor will, muß und soll man frei und unabhängig sein, es ist einfach zu oft gar nicht gewünscht, daß man 'vorgefertigte' Programmpakete verwendet. Viele Probleme müssen sehr basal gelöst werden, sogenannte Universallöser von DGL oder FEM Systeme sind reiner Overkill und oftmals wertlos, da man keinen Einblick in die genauen Rechenmodalitaten gewinnt. Dann kann man natürlich auch gleich die Fehlerschätzung und Güte einer Modellrechnung knicken! Nüchtern betrachtet ist also nVidias 'OpenCL'-Geklapper wieder einmal nur PR.
Ein weiterer großer Irrtum, aber immer wieder werbeträchtig als Leistungsmarker vorgebracht, ist, daß man große Sprünge mit den einfach genau rechnenden Rechenwerken machen könnte. Solange die 'Singleprecision' Operationen (per definitionem 32 Bit breit) ausreichend sind, läßt sich auch das Argument 1d/5d-Shader ins Feld führen. Aber im naturwissenschaftlichen Bereich sind heute die wenigsten(!) Modellrechnungen noch mit SP Rechnungen zu bewältigen. Dort, wo es wirklich auf Leistung ankommt, wird doppelte Genauigkeit oder gar vierfache Genauigkeit verlangt (wenn man auf einer Abbildung der Genauigkeit auf die Hardware/Register zur geschwindigkeitssteigerung in betracht zieht und nicht Bibliotheken mit umständlichen beliebigen Genauigkeiten verwendet). Klimamodelle, Strahlungsmodelle (Atmosphären), Bahndynamik, Trajektorien von Planeten, Kleinkörpern oder vor allem kernphysikalische Prozesse (Sonne, Fusion, Nuklearwaffen). Und hier, so habe ich mir einmal erklären lassen, würden AMDs Karten theoretisch besser punkten können, weil sie pro Shader-Cluster auch eine Recheneinheit mit doppelter Genauigkeit zur Verfügung stellen würden. Das tun nVidias Chips zwar auch, aber sie haben deutlich weniger Cluster! Leider werden diese DP-Rechenwerke im Moment kaum berücksichtigt!
Die nächste große Unbekannte scheint aber zu sein, was OpenCL und CUDA wirklich miteinander verbindet - zumindest habe ich den Eindruck. OpenCL definiert lediglich den Sprache, die Syntax, mit der letztlich unabhängig vom verwendeten Chipsatz ein Problem formuliert werden kann. Da OpenCL sehr ähnlich zu C ist, gibt es da keine großen Probleme. Im Moment versuche ich, etwas verzweifelt und unter den gegebenen Umständen völlig sinnlos, wie es scheint, einige mathematische Bibliotheksfunktionen der Numerical Recipes von Bress und anderen sowohl in einer C- als auch OpenCL-Fassung abzulegen. Und nun kommen wir dem Problem schon etwas näher, nämlich CUDA. Um überhaupt aus dem Quelltext ein lauffähiges Programm erzeugen zu können, benötigt man das, was man gemeinhin einen Compiler nennt. Mit OpenCL alleine kann man nur etwas 'formell' behandeln. Compilerbau ist schon eine Weile bei mir her, also nicht gleich schimpfen, wenn die Terminologie nicht mehr ganz stimmig ist.
CUDA benötigt einen proprietären Treiber und einen speziellen Compiler, um aus einem OpenCL-Quelltext dann ein Programm zu machen, das auf der GPU ausgeführt werden kann und die Ergebnisse dann wieder in den 'Adreßraum' des Prozessors bringt. Und genau hier sehe ich den Knackpunkt - und im Grunde keine wirklichen Fortschritte, auch wenn nVidia oder ATi das gerne anders sehen. Beide laborieren nach wie vor beim Backend mit ihren eigenen Treibern für die Karten und eigenen Schnittstellen für die Compiler. Von OpenSource kann einfach nicht die Rede sein. Wer nicht Frickel-Linux mit seinen Ati- und nVidia BLOB-treibern einsetzt, sondern völlig offenene BSD-UNIXe, hat verloren! Hier gibt es keine Treiber für die Graphikchips, die es ermöglichten, einen OpenCL-Compiler zu bauen. Bei ATi war durch die angebliche Offenlegung der 2D/3D Funktionen llvm im Gespräch, da man mit llvm relativ problemlos OpenCL im Frontend einsetzen könnte und im Backend einen auf die jeweilige Graphikhardware adaptierte Compiler/Linker/Assembler-Einheit. Aber ohne Spezifikationen geht das leider nicht.
Im wissenschaftlichen Sektor will, muß und soll man frei und unabhängig sein, es ist einfach zu oft gar nicht gewünscht, daß man 'vorgefertigte' Programmpakete verwendet. Viele Probleme müssen sehr basal gelöst werden, sogenannte Universallöser von DGL oder FEM Systeme sind reiner Overkill und oftmals wertlos, da man keinen Einblick in die genauen Rechenmodalitaten gewinnt. Dann kann man natürlich auch gleich die Fehlerschätzung und Güte einer Modellrechnung knicken! Nüchtern betrachtet ist also nVidias 'OpenCL'-Geklapper wieder einmal nur PR.
Mister79
Banned
- Registriert
- Apr. 2008
- Beiträge
- 4.489
Naja ob jetzt Leute viel Geld für den I7 ausgeben oder nicht, tut nix zur Sache. Bis die Technik bereit ist und voll genutzt werden kann, ist der I7 schon Vergangenheit. Sicher wird es viel geben was über die GPU berechnet werden kann aber dann muss auch Windows umgeschrieben werden. Eine GPU rechnet kein X86 und da Windows darauf programmiert ist...
Es gibt genug Anwendungen die eine Grafikkarte nicht berechnen kann. Nur weil sie in sekunden WLan Codes knacken kann, weil sie die Videoanwendungen schneller berechnen kann usw? Naja was ist mit den Anwendungen die sie nicht kann? Der Umstieg vom XP Kern zu Vista und W7 dauert ja schon ewig und einige hier regen sich auf das Programe von 95 nicht mehr laufen. Also was soll werden wenn jetzt gleich mal alles so auf GPU laufen soll? Keine Spiele mehr die laufen, kein Windows, nur noch ganz ganz neues. Da könnten sich die Leute aufregen aber so...
Es gibt genug Anwendungen die eine Grafikkarte nicht berechnen kann. Nur weil sie in sekunden WLan Codes knacken kann, weil sie die Videoanwendungen schneller berechnen kann usw? Naja was ist mit den Anwendungen die sie nicht kann? Der Umstieg vom XP Kern zu Vista und W7 dauert ja schon ewig und einige hier regen sich auf das Programe von 95 nicht mehr laufen. Also was soll werden wenn jetzt gleich mal alles so auf GPU laufen soll? Keine Spiele mehr die laufen, kein Windows, nur noch ganz ganz neues. Da könnten sich die Leute aufregen aber so...
Lübke
Fleet Admiral
- Registriert
- Aug. 2007
- Beiträge
- 21.162
windows wird sicher nicht umgeschrieben. eine gpu kann der cpu viel rechenarbeit abnehmen, sie ersetzen kann sie aber nicht. eine gpu nach heutigem stand ist nicht in der lage, die hardware zu steuern, somit kann sie auch nicht das os ausführen. es fehlen die grundlegenden eigenschaften.
allerdings kann zur systemsteuerung auch eine billige cpu herangezogen werden, wenn das gros der rechenlast durch die gpu übernommen wird. somit hätte intel ein problem, wenn selbst ein alter p4 oder amd athlon fürs os ausreicht und die leistung nur noch von der gpu abhängt.
allerdings kann zur systemsteuerung auch eine billige cpu herangezogen werden, wenn das gros der rechenlast durch die gpu übernommen wird. somit hätte intel ein problem, wenn selbst ein alter p4 oder amd athlon fürs os ausreicht und die leistung nur noch von der gpu abhängt.
TheGreatMM
Captain
- Registriert
- Mai 2008
- Beiträge
- 3.086
mag man nicht mehr DirectX?
Ähnliche Themen
- Angepinnt
- Antworten
- 125
- Aufrufe
- 35.175
- Antworten
- 35
- Aufrufe
- 10.022
- Antworten
- 60
- Aufrufe
- 10.889
- Antworten
- 69
- Aufrufe
- 17.280