Havok Cloth usw für OpenCL-fähige GPUs

[deekey777]

Ja, die Diskussion wird auch im Stream-Thread geführt, aber dieser Thread ist der allgemeine "Havok@OpenCL"-Thread.
Havok, AMD demo OpenCL-based physics at GDC (http://techreport.com/discussions.x/16640)
Of course, since Havok is using OpenCL, it doesn't seem to be strictly targeting AMD graphics processors. The announcement states plainly, "Havok will enable game developers to offer improved performance and interactivity across a broad range of OpenCL capable PCs." In case you missed the memo, both AMD and Nvidia plan to offer early OpenCL driver support in the first half of this year. That means Havok could also run on GeForce GPUs and compete head-to-head with Nvidia's PhysX.

Dass Havok Cloth für GPUs auf AMD-GPUs gezeigt wurde, hat rein politische Gründe. Man darf nicht vergessen, dass HavokFX zuerst auch auf Geforce 7 gezeigt wurde, was zur Meinung führte, dies sei Nvidias Konkurrenz zu ATis Plänen über Physikberechnungen auf GPUs (R520 usw). Den nur wenige Monate später wurde HavokFX auch auf X1900ern gezeigt.

Was sind eigentlich OpenCL-fähige GPUs? Nun, aktuell sieht es so aus, dass das die Geforce 8 und neuer sowie die HD4000-Serie sind. Indizien dafür sind insbesondere das Memory-Modell von OpenCL, das Local-Memory kennt (Nvidias Shared Memory bzw. LDS bei HD4000), was die HD2000 und HD3000 gerade nicht kennen.
http://forum.beyond3d.com/showthread.php?p=1280212#post1280212
Yes, we were running Havok cloth demos on multi-core CPU as well as GPU via OpenCL, all with the same OpenCL code underneath the Havok API. As was said above, there is no visible difference between the OpenCL code on either the CPU or the GPU and Havok's native code. The dancer dances off screen if you don't have the camera follow enabled, but the camera follow has a "bob" to it that makes some people sick after watching it for awhile. ;-)

We had a few demos we were cycling between. All OpenCL with no specific AMD functions or native code. I'm still partial to the Powdertoy demo and I have probably spend more time than I should playing with it. All in the name of debugging and optimizations. ;-)

I really hope Andrew's talk (EA) gets posted soon (the slides should all go up in not too long) as I think it's pretty cool that he was able to extract the Ropa cloth code used in Skate, port to OpenCL, and throw his code at AMD and Nvidia after developing on a different platform, and have AMD showing multi-core CPU and GPU and Nvidia showing GPU, side by side on alpha implementations. OpenCL is a real thing and the implementations are getting there. This year is going to be interesting and some of us are going to be very busy. ;-)


http://www.youtube.com/watch?v=daZoXzBGea0

Auch wenn der pöhse Carsten die Präsentation nicht rausrücken will, so will ich die PCGH-Meldung nicht vorenthalten: GDC 2009: AMD und Havok zeigen Physik-Videos und kündigen GPU-Beschleunigung an (http://www.pcgameshardware.de/aid,679934/GDC-2009-AMD-und-Havok-zeigen-Physik-Videos-und-kuendigen-GPU-Beschleunigung-an/Technologie/News/)

[Coda]

Ich hoffe echt das ganze CUDA- und CAL-Zeug und irgendwelche Machtspielchen was das angeht in Bezug auf Physik sind bald durchgestanden...

Das sehen wohl auch viele Entwickler so.

[LovesuckZ]

Ich hoffe echt das ganze CUDA- und CAL-Zeug und irgendwelche Machtspielchen was das angeht in Bezug auf Physik sind bald durchgestanden...

Das sehen wohl auch viele Entwickler so.

Wäre es schon längst, wenn AMD PhysX adoptiert hätte. Immerhin scheinen sie ja kein Problem zu haben Havok per OpenCL über CAL laufen zu lassen - dann hätte sie auch das selbe für Cuda machen können.

[Coda]

Wäre es schon längst, wenn AMD PhysX adoptiert hätte.
Das können sie aus sehr vielen Gründen nicht.

Überhaupt ist es auch Quatsch für eine Middleware einen "Standard" zu erheben. Physik ist nunmal eine individuell angepasste Middleware-Sache und keine Hardware-API.

dann hätte sie auch das selbe für Cuda machen können.
Das würde ihnen nichts nützen, solange PhysX CUDA sowieso nur auf NVIDIA-Karten erlaubt. Es gäbe auch lizensrechtliche Probleme und man müsste NVIDIA die ganze Zeit hinterheerimplementieren. Überhaupt ist CUDA auf NVIDIA-Karten exakt zugeschnitten, OpenCL ist viel allgemeiner. Aber das verstehst du ja anscheinend immer noch nicht.

CUDA ist schlicht und einfach auch keine Alternative für ATI und war es auch nie. Den schwarzen Peter ATI zuschieben zu wollen was PhysX angeht ist einfach lächerlich und verblendet.

[deekey777]

Wäre es schon längst, wenn AMD PhysX adoptiert hätte. Immerhin scheinen sie ja kein Problem zu haben Havok per OpenCL über CAL laufen zu lassen - dann hätte sie auch das selbe für Cuda machen können.
Nur weil OpenCL CUDA sehr ähnlich sieht, heißt dass noch lange nicht dass es darauf basiert.

Die Grundlagen zu CUDA und OpenCL wurden schon vorher an mehreren Unis entwickelt, nicht von NVIDIA. CUDA hat im wesentlichen nur mehr low-level-Zugriff auf GeForce spezifische Funktionalität.

Nur so ein Gedanke.

[reunion]

Ich hoffe echt das ganze CUDA- und CAL-Zeug und irgendwelche Machtspielchen was das angeht in Bezug auf Physik sind bald durchgestanden...

Das sehen wohl auch viele Entwickler so.

AMD hat CAL doch schon längst aufgegeben und offen zugegeben sich für OpenGL/ComputeShader stark zu machen.

[BlackBirdSR]

Wäre es schon längst, wenn AMD PhysX adoptiert hätte. Immerhin scheinen sie ja kein Problem zu haben Havok per OpenCL über CAL laufen zu lassen - dann hätte sie auch das selbe für Cuda machen können.

Musst du eigentlich jeden Tag, in jedem Thread das selbe (bereits zig mal als fehlerhaft dargestellten) Zeugs posten?
Wie oft müssen Leute wie Deeky und Coda noch schreiben, dass das so nicht geht,?

[LovesuckZ]

Musst du eigentlich jeden Tag, in jedem Thread das selbe (bereits zig mal als fehlerhaft dargestellten) Zeugs posten?
Wie oft müssen Leute wie Deeky und Coda noch schreiben, dass das so nicht geht,?

Dann erkläre dochmal den Unterschied zwischen HavokFX und PhysX auf in Bezug auf Berechnung auf der GPU. nVidia verwendet Cuda und AMD openCL - und AMD soll also nicht in der Lage für PhysX das selbe zu implentieren? Cuda und OpenCL sind auch nur eine API, die benötigt wird.

Nur so ein Gedanke.

Habe ich gesehen. Und er sagt doch genau das, was auch Triolet ausgedrückt hat: Die Ähnlichkeiten zwischen Cuda und OpenCL sind sehr groß. Demnach sollte es für AMD keine Probleme geben eine OpenCL APi für PhysX zuschreiben.

[AnarchX]

AMD kann einen OpenCL-Treiber für ihre Karten liefern.

Aber um ein entsprechendes OpenCL-Backend für PhysX zu schreiben, welches PhysX-Befehle in OpenCL-Befehle wandelt, benötigen sie Resourcen, in welche eben nur NV Einsicht hat. Und selbst wenn sie es hinbekommen würden, dann könnte NV es mit einer veränderten PhysX-Version ganz schnell inkompatibel machen.

Nvidia ist der einzig, welcher AMD bzw. Herstellern mit anderen OpenCL-fähigen Produkten einen Zugang zu PhysX erlauben kann.

[LovesuckZ]

Nvidia ist der einzig, welcher AMD bzw. Herstellern mit anderen OpenCL-fähigen Produkten einen Zugang zu PhysX erlauben kann.

Das kann genauso auch bei HavokFX passieren.
Nur ändert es nichts an der Tatsache, dass AMD keine Absicht zeigt sich für PhysX zu interessieren und will selbst eine Middleware einführen, die wohl gerade mal einen 10% Marktanteil haben wird - im Gegensatz zu PhysX.

[AnarchX]

Warum sollte Intel sein Havok mit AMD-spezifischen Extension ausstatten?
Langfristig wird dieses mit dem OpenCL-Backend wohl auch auf Larrabee oder eben kommenden GMA-IGPs(vor allem die in den CPUs ;)) laufen. Und gerade wenn man keinen hohen Marktanteil hat, wird man diesen wohl kaum noch durch solche HW-Bindungen einschränken.

Da scheinst du wohl die Verhältnisse von NV und PhysX und AMD und Havok nicht korrekt einschätzen zu können.

[=Floi=]

die idee mit dem physx in der igp ist nicht schlecht, aber diese ist dafür zu leistungsschwack. bei einem flächendeckendem einsatz von physik braucht man auch dafür (viel) mehr rechenleistung.

[reunion]

Das kann genauso auch bei HavokFX passieren.
Nur ändert es nichts an der Tatsache, dass AMD keine Absicht zeigt sich für PhysX zu interessieren und will selbst eine Middleware einführen, die wohl gerade mal einen 10% Marktanteil haben wird - im Gegensatz zu PhysX.

Warum sollte es nur 10% Marktanteil haben? Havok verwendet OpenCL und ist damit zu allen OpenGL-fähigen Grafikchips von AMD, Nvidia, S3 oder Intel voll kompatibel. PhysX hingegen gibt es aktuell nur mit CUDA-Schnittstelle, wobei ich jede Wette eingehe das auch nV hier über kurz oder lang OpenCL unterstützen wird müssen und damit PhysX auch für alle zugänglich wird.

Die einzigen die mal wieder auf Stur schalten sind nV. Wie sollte sich AMD für PhysX interessieren wenn nV den Laden dicht hält und nur eine CUDA-schnittstelle anbietet? Na du hast Vorstellungen.

[AnarchX]

@=Floi=
Zu schwach würde ich nicht unbedingt sagen(bei NV sollen die nächsten IGPs auf dem Niveau einer 9500GT sein), das Problem ist eher die Skalierbarkeit und das auch übergreifend auf die CPU, hier sind aktuelle APEX-basierende Applikationen äußerst bescheiden, obwohl man in den Marketingtexten optimale Skalierbarkeit im Bezug auf verfügbare Rechenleistung und aber Leistungsbedarf der implementierten Effekte verspricht...

Im Bezug auf die Skalierung auf die verfügbare Rechenleistung könnte wohl ein OpenCL-Backend eine wichtige Rolle einnehmen.

[deekey777]

AMD hat CAL doch schon längst aufgegeben und offen zugegeben sich für OpenGL/ComputeShader stark zu machen.
Natürlich hat AMD CAL nicht aufgegeben. CAL ist eine Schnittstelle, über die Programme auf Grafikkarte ausgeführt werden können. Gleiches gilt für Nvidia, da nennt es sich CUDA API.

[reunion]

Natürlich hat AMD CAL nicht aufgegeben. CAL ist eine Schnittstelle, über die Programme auf Grafikkarte ausgeführt werden können. Gleiches gilt für Nvidia, da nennt es sich CUDA API.

Du weißt genau was ich gemeint habe. Dann haben sie eben Brook aufgegeben. Man muss sich ja nicht immer über Begrifflichkeiten streiten. Das man die Schnittstelle weiter braucht sollte völlig klar sein.

[LovesuckZ]

Warum sollte es nur 10% Marktanteil haben? Havok verwendet OpenCL und ist damit zu allen OpenGL-fähigen Grafikchips von AMD, Nvidia, S3 oder Intel voll kompatibel. PhysX hingegen gibt es aktuell nur mit CUDA-Schnittstelle, wobei ich jede Wette eingehe das auch nV hier über kurz oder lang OpenCL unterstützen wird müssen und damit PhysX auch für alle zugänglich wird.

Genau als ob S3 oder Intel irgendeine eine Bedeutung hätten. Intel schreibt nichtmal vernünftige Treiber für ihre IGPs, da sollen sie jetzt auch OpenCL implementieren? Logisch. :rolleyes:


Die einzigen die mal wieder auf Stur schalten sind nV. Wie sollte sich AMD für PhysX interessieren wenn nV den Laden dicht hält und nur eine CUDA-schnittstelle anbietet? Na du hast Vorstellungen.

OpenCL ist Cuda nichtmal ebenbürtig zur Zeit. nVidia war nicht stur, sie haben nur wesentlich früher angefangen und da war Cuda die einzige Möglichkeit. Es ist nicht nVidia's Problem, dass es keinen Standard gab - und selbst dieser ist nichtmal auf dem Niveau von Cuda.

[deekey777]

Du weißt genau was ich gemeint habe. Dann haben sie eben Brook aufgegeben. Man muss sich ja nicht immer über Begrifflichkeiten streiten. Das man die Schnittstelle weiter braucht sollte völlig klar sein.
Lieber sollte man den Meldungen gewisser Theos (http://www.tgdaily.com/content/view/38764/140/) keinen Glauben schenken.
AMD Drives Adoption of Industry Standards in GPGPU Software Development (http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~127451,00.html)
“Industry standards are essential to unlocking the compute potential of GPUs and driving broad adoption of this capability in mainstream applications,” said Rick Bergman, senior vice president and general manager, Graphics Product Group, AMD. “GPGPU is now moving past the era of closed and fully proprietary development chains. With the advent of DirectX 11 and OpenCL, C/C++ programmers worldwide will have standardized and easier ways of leveraging the GPU’s computational capabilities.”

AMD will also continue to enhance and support the Brook+ programming language, providing programmers a stable, high-performance platform for accelerating their applications.
Gerade wurde Brook+ wiedermal aufgebohrt. Selbst wenn OpenCL Brook+ in den meisten Bereichen verdrängen wird (nicht weil OpenCL so gut ist, sondern weil Brook+ bisher nicht das Niveau des Konkurrenz hat), wird Brook+ nur dann aufgegeben, wenn es nicht effizient ist.

[BlackBirdSR]

Dann erkläre dochmal den Unterschied zwischen HavokFX und PhysX auf in Bezug auf Berechnung auf der GPU. nVidia verwendet Cuda und AMD openCL - und AMD soll also nicht in der Lage für PhysX das selbe zu implentieren? Cuda und OpenCL sind auch nur eine API, die benötigt wird.

.

Und das ist genau der Punkt, der schon -zig-Mal erklärt wurde und den du anscheinend nicht verstehen willst.

Solange es keine OpenCL-Schnittstelle für PhysX gibt, bleibt AMD nur die Adaption von CUDA, bzw. ein Übersetzer von CUDA. Selbst mit totaler Ablehnung jeglicher Tatsachen, dürfte man logisch folgern können, dass dies einen Performancenachteil = Wettbewerbsnachteil bedeutet. Case Closed. Jetzt erklär ich es aber nicht nochmal und du kannst weiter so tun, als wär es dir nicht klar.

[deekey777]

Meine Meinung:
Wenn Nvidia es geschafft hat, PhysX-Zeug auf CUDA zu portieren, und AMD geschafft hat, Havok-Zeug zu portieren, dann kann man davon ausgehen, dass es irgendwo so uberskilled Nerds und Geeks gibt, die vor 6-9 Monaten geschafft hätten, PhysX-Zeug auf Stream zu portieren.

Nur gibt es eine Meinung, dass diese Geeks und Nerds bei AMD beschäftigt sein müssen, womit es AMDs Aufgabe sei, das Produkt PhysX (welches Nvidia gehört) auf eigenen Grafikkarten lauffähig zu machen. Und genau das kann ich nicht ab, denn AMD hat schon im Juni 2008 gesagt, dass sie nichts machen werden, indem sie die Zusammenarbeit mit Havok bekräftigt haben.

Ergo: Wenn der Inhaber von PhysX (= Nvidia) wünscht, dass PhysX auch auf Radeons läuft, dann soll er Zeit und Geld in die Portierung investieren.

[Coda]

Dann erkläre dochmal den Unterschied zwischen HavokFX und PhysX auf in Bezug auf Berechnung auf der GPU.
AMD hat keinen Zugang zum PhysX-Source-Code. Sie können weder PhysX selber auf OpenCL anpassen, noch CUDA adaptieren.

OpenCL ist Cuda nichtmal ebenbürtig zur Zeit. nVidia war nicht stur, sie haben nur wesentlich früher angefangen und da war Cuda die einzige Möglichkeit. Es ist nicht nVidia's Problem, dass es keinen Standard gab - und selbst dieser ist nichtmal auf dem Niveau von Cuda.
Das ist lustig. Dann bring doch mal ein paar Fakten warum du glaubst das dem so ist. Und bitte keine Null-Argumente wie "CUDA gibt es schon länger".

Technische Fakten oder stfu. Nachplappern was einem gefällt kann ja jeder.

[_DrillSarge]I[]

OpenCL is being created by the Khronos Group with the participation of many industry-leading companies and institutions including 3DLABS, Activision Blizzard, AMD, Apple, ARM, Barco, Broadcom, Codeplay, Electronic Arts, Ericsson, Freescale, HI, IBM, Intel, Imagination Technologies, Kestrel Institute, Motorola, Movidia, Nokia, NVIDIA, QNX, RapidMind, Samsung, Seaweed, Takumi, Texas Instruments and Umeå University.
was nun? ;D
X-D

[deekey777]

AMDs Pressemitteilnung ist da:
AMD Demonstrates Optimized Executions of Havok Middleware on AMD platforms (http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~130759,00.html)

[Botcruscher]

I[;7197197']was nun? ;D
X-D

? Glaubst du ernsthaft NV würde bei sowas wichtigem nicht mitmachen?

[_DrillSarge]I[]

? Glaubst du ernsthaft NV würde bei sowas wichtigem nicht mitmachen?
das war eine "antwort" auf das "opencl-gebashe" von LS ;)

[LovesuckZ]

I[;7197453']das war eine "antwort" auf das "opencl-gebashe" von LS ;)

Wo bashe ich OpenCL? :confused:

[_DrillSarge]I[]

Wo bashe ich OpenCL? :confused:
hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7196951#post7196951
+in diversen weiteren "gpgpu"-threads
(würde mich nicht weiter stören, wäre es das erste mal, will das hier im fred nicht weiter diskutieren)

€: nochmal
(würde mich nicht weiter stören, wäre es das erste mal, will das hier im fred nicht weiter diskutieren)

[LovesuckZ]

I[;7197714']hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7196951#post7196951
+in diversen weiteren "gpgpu"-threads
(würde mich nicht weiter stören, wäre es das erste mal, will das hier im fred nicht weiter diskutieren)

Dort ist kein bash. Also nochmal: Wo bashe ich OpenCL? :rolleyes:

[DaBrain]

Physikberechnung über eine offene, nicht an IHVs/OS-gebundene Schnittstelle?

Super, damit hat AMD die Nase vorn. Cuda hin oder her, so gut es auch ist, es kann sich nicht durchsetzen. (Genau wie CAL.)

Wird Nvidia nachziehen und PhysX auch über OpenCL anbieten?

Wenn Intel auch auf Havok setzt(GPGPU), muss Nvidia PhysX komplett fallen lassen?

Und was passiert wenn Bullet erstmal mit OpenCL funktioniert?
Dann kann auf einmal praktisch jedes Spiel GPGPU Physik haben.

[deekey777]

3DMark Vantage hat auch eine Cloth-Simulation (und GPU-Partikel), die über D3D läuft. Was ist der genaue Vorteil dieser Lösungen? Umgehung gewisser Beschränkungen von D3D?
Physikberechnung über eine offene, nicht an IHVs/OS-gebundene Schnittstelle?

Super, damit hat AMD die Nase vorn. Cuda hin oder her, so gut es auch ist, es kann sich nicht durchsetzen. (Genau wie CAL.)

Wird Nvidia nachziehen und PhysX auch über OpenCL anbieten?

Wenn Intel auch auf Havok setzt(GPGPU), muss Nvidia PhysX komplett fallen lassen?

Und was passiert wenn Bullet erstmal mit OpenCL funktioniert?
Dann kann auf einmal praktisch jedes Spiel GPGPU Physik haben.
Eigentlich müsste man jetzt Valve nerven, ob sie nicht vorhaben, ein Testlevel mit Havoks Spielereien zu veröffentlichen. Gerade Episode 2 hat mehrere Stellen, die für so eine Demonstration geeignet sind.

[BlackBirdSR]

Wenn Intel auch auf Havok setzt(GPGPU), muss Nvidia PhysX komplett fallen lassen?


Nicht zwangsläufig. PhysX ist eine sehr potente Physik-Engine, die in einer breiten Massen an prominenten Spielen zum Einsatz kommt. Darunter eben auch alle UE3 Spiele auf allen Konsolen. PhysX selbst ist ja unabhängig von GPUs.

Solange also niemand auf die Idee kommt, Spielphysik per GPU zu beschleunigen (weil es zu wenige Karten können, weil zu wenig schnell genug sind, weil es Multiplayerprobleme geben würde), solange muss Nvidia auch nicht auf Havok setzen. Man könnte Havok über CL sogar ganz ignorieren und auf seinen Standard pochen.

[Gast]

Physikberechnung über eine offene, nicht an IHVs/OS-gebundene Schnittstelle?
Häh? Seit wann gehört Havok nicht Intel? Ohne die entsprechenden Solver hast du absolut nicht mehr als einen Haufen Code, der dir für Physik erstmal gar nichts nutzt. Ob dieser nun über OpenCL, Cuda, C++ oder meinetwegen Fortran oder direkt in Assembler programmiert ist, ist völlig wurscht.

Am besten noch das ganze in Copy-and-Past-Module verpacken, wie es Intel und Nvidia machen und dann hast du auch eine Chance bei den kostensparenden ISVs.

[AnarchX]

Nvidia considers porting PhysX to OpenCL (http://www.bit-tech.net/news/hardware/2009/03/27/nvidia-considers-porting-physx-to-opencl/1)
Mohammad revealed that he wasn’t against the idea at all. “In the future it’s a possibility that we could use OpenCL,” Mohammad told us, but added that “at the moment CUDA works great.” Mohammad also pointed out that although Nvidia currently uses CUDA to accelerate PhysX on GPUs, the company’s “architecture allows for acceleration by other things like OpenCL.”

Interessant wird es doch werden, wenn man ein OpenCL-Backend für das gesamte PhysX besitzt und nicht nur die Palette an Effekten aus APEX, welche momentan von der GPU beschleunigt werden können.

[BlackBirdSR]

Gewinnen können in diesem Fall nur die User, wenn dann wirklich jede aktuelle GPU jede Physikengine beschleunigen kann.

Wäre nur noch interessant, wie man das
a) benchmarken soll/kann
b) ob die GPUs generell schnell genug sind, damit auch viele Hersteller auf HW-Physik setzen.

[Coda]

Eigentlich müsste man jetzt Valve nerven, ob sie nicht vorhaben, ein Testlevel mit Havoks Spielereien zu veröffentlichen. Gerade Episode 2 hat mehrere Stellen, die für so eine Demonstration geeignet sind.
Valves Physik basiert auf einer uralten, aber stark modifizierten Havok-Engine. Das geht glaube ich gar nicht.

Interessant wird es doch werden, wenn man ein OpenCL-Backend für das gesamte PhysX besitzt und nicht nur die Palette an Effekten aus APEX, welche momentan von der GPU beschleunigt werden können.
GPU-Physik mit Player-Feedback is nicht so einfach möglich.

[Gast]

LS blubbert oft aber hiermit hat er auch Recht. Man sollte fähig sein den Leuten da Recht geben wo sie auch Recht haben.
"nVidia war nicht stur, sie haben nur wesentlich früher angefangen und da war Cuda die einzige Möglichkeit. Es ist nicht nVidia's Problem, dass es keinen Standard gab"

Valves Physik basiert auf einer uralten, aber stark modifizierten Havok-Engine. Das geht glaube ich gar nicht.


GPU-Physik mit Player-Feedback is nicht so einfach möglich.Erstmal: Havok = Spiele. So richtig, aber wie rennt das dann? Wieviel Physik ist befriedigend? Wieviel FPS verliert man wenn man das auf der CPU rechnet und wieviel wenn man die GPU damit beschäftigt? Was sind die Schwerpunkte? Mal CPU, mal GPU. Je nach Spiel. Also?

Wäre Valve-Havok nochmals optimiert nicht genug für ein Spile auf in der Leistungsklasse eines X2 5000+ aufwärts? Haben die ganzen ewig überzeichneten Effekte in den Aushängeschildern von PhysX/CUDA etwas mit der Realität zu tun? Worüber geht es bei solchen Spielereien?

Die "Transporter" sind zwar nett aber lachen wir wirklich so gut über die ganzen schwachsinnigen Effekte? Oder "Taxi"?

Was ist der wirklich unterhaltsame Nutzen und was der totale Schwachsinn? Ich war mit der Physik in HL2 extrem zufrieden. Es war da wo ich es erwartet habe und es war nicht mehr davon als ich merken könnte. Ich habe weder Zeit noch irgendwie Lust beim Spielen minutenlang auf Vorhänge zu schiessen und zusehen wie sie davon rumflattern.

Den Typen fällt sonst nichts ein damit wir noch schnellere Grakas kaufen. Werden wir dabei von schwachsinniger Effekthascherei überflutet? Ich hoffe nicht.
Es gab eine Zeit in der Blooming an jeder Stelle zu finden war. Meist da wo es garnicht hingehörte und in solchen Massen als wenn normal wäre und jeder im RL einen Katarakt hätte. Sowas nervt nach einer kurzen Zeit nur noch.

Intels Probleme sind die gleichen. Früher fieberte man jeder neuen Ankündigung entgegen. Heute schaut man sich mit einem E8600 @3.8Ghz entspannt um. Man könnte mehr, müßen muß man aber eigentlich selten. Intel hat mit Havok auf AVX bestimmt einiges vor und der Krieg ist mit OpenCL bestimmt nicht zu ende. Genaugenommen fängt er damit erst richtig an.

Was der User dabei alles gewinnt wird sich noch herausstellen. Das Bullen um die Investitionspriorität zwischen Intel und ATI/NV geht nur in die nächste Runde. Von einer Erlösung für den User kann ich noch nichts erkenne.

Nacht.

[_DrillSarge]I[]

mich würde mal interessieren, was die physx-engine vor dem nvidia aufkauf für eine schnittstelle/technik genutzt hat, um mit der ageia-ppu zusammenzuarbeiten. und wie weit "weg" der cuda-port dann davon war/ist.

GNAAA! falscher thread. sry *del plz*

[Coda]

LS blubbert oft aber hiermit hat er auch Recht. Man sollte fähig sein den Leuten da Recht geben wo sie auch Recht haben.
"nVidia war nicht stur, sie haben nur wesentlich früher angefangen und da war Cuda die einzige Möglichkeit. Es ist nicht nVidia's Problem, dass es keinen Standard gab"
Ich verstehe seine Äußerungen hier im Thread ganz anders.

Ich war mit der Physik in HL2 extrem zufrieden.
Habe ich irgendwo etwas anderes behauptet? Du zitierst mich völlig aus dem Kontext gerissen.

Ich habe bloß angemerkt, dass ein der Source-Engine wohl nicht so einfach auf eine Havok-Engine mit OpenCL-Unterstützung möglich ist - mehr nicht.

Kann doch nicht so schwer sein das zu verstehen.

[Gast]

Habe ich irgendwo etwas anderes behauptet? Du zitierst mich völlig aus dem Kontext gerissen.:| Ist das nur hier so? Es muß doch nicht sein daß man nur dann etwas zitiert wenn man einer gegensätzlichen Meinung ist. Was ist das den? ich hab zu deinen Gedankengängen meine rangehängt und in meine Denkrichtung weitergeführt.

Auf die Art die du hier vermuten möchtest wiederspricht dir niemand.

[Aquaschaf]

Den Typen fällt sonst nichts ein damit wir noch schnellere Grakas kaufen. Werden wir dabei von schwachsinniger Effekthascherei überflutet? Ich hoffe nicht..

Ich freue mich z.B. durchaus darauf nicht mehr (mehr oder weniger) an die Körper von Charakteren angeklebte Kleidung zu sehen und eine bessere Darstellung der Kopfbehaarung. "Notwendig" ist das nicht; aber das ist fast nichts bei der grafischen Darstellung.

[Gast]

I[;7197197']was nun? ;D
X-D

Ist der Leiter der OpenCL Gruppe nicht sogar ein NVIDIA Mitarbeiter? Irgendwo hab ich das doch mal gelesen...

[=Floi=]

das ist sicherlich kein nachteil!

[Tarkin]

http://game.amd.com/us-en/community_articles.aspx?id=AMD000000049

hier gibts ein dickes, fettes Video von der Demonstration...

kleine Warnung.... das Video ist recht kurz, hat eine relativ niedrige Auflösung (dafür dass es 700MB groß ist) und zeigt nichts neues

[Gast]

Ist der Leiter der OpenCL Gruppe nicht sogar ein NVIDIA Mitarbeiter? Irgendwo hab ich das doch mal gelesen...

Nvidia stehe laut Mohammad auch hinter dem OpenCL-Standard und halte ihn für exzellent. Diese Anmerkung wundert nicht, da Neil Trevett die Khronos Group leitet, welche OpenCL weiterentwickelt. Trevett arbeitet für Nvidia.

http://www.hartware.net/news_46640.html

[Ailuros]

http://www.hartware.net/news_46640.html

Trevett leitet die Khronos group schon seit langem, auch u.a. als ARM mit Imagination Technologies die OpenGL_ES1.0 Spezifikationen in einer 1:1 Session festlegten.

Anders die Tatsache dass Trevett Praesident vom Khronos Group ist hat nichts im geringsten damit zu tun dass er auch parallel bei NVIDIA arbeitet. Seine Funktion innerhalb der Khronos Gruppe ist so objektiv und unabhaengig wie sie sein sollte. Wenn es anders waere wuerde er nie bei jeder Khronos relevanten Ankuendigung bei IMG als Beispiel positiv fuer IMG's Initiativen kommentieren:

Says Neil Trevett, president of the Khronos Group: “With OpenVG, Khronos has created a low-level, Bezier-based API to streamline how high-quality, scalable 2D graphics software can take advantage of graphics hardware. OpenVG and OpenGL ES will be often used together to deliver a rich diversity of graphically rich applications and user interfaces with high-interactivity and low power levels. Imagination Technologies is to be congratulated on delivering solutions which deliver both OpenVG and OpenGL ES conformance, as well as its new dedicated OpenVG core.”

http://www.imgtec.com/News/Release/index.asp?NewsID=441

Hoert bitte auf jeglichen Mist unendlich weiterzuplappern wenn Ihr schon keine Ahnung habt wie manche Sachen vor sich gehen und was fuer eine Funktion in A, B oder C hat. Nach etlichen Malen dass ich den gleichen Mist sehen muss, hab ich so langsam die Nase voll davon.

Zum Thema: nettes demo; dekkey hat uebrigens recht man braucht nicht unbedingt physics fuer cloth simulations.

[Showtime]

http://game.amd.com/us-en/community_articles.aspx?id=AMD000000049

hier gibts ein dickes, fettes Video von der Demonstration...

kleine Warnung.... das Video ist recht kurz, hat eine relativ niedrige Auflösung (dafür dass es 700MB groß ist) und zeigt nichts neues

Ich kann ja verstehen, dass sie versuchen wollen, die maximal mögliche Qualität zu erhalten, aber ein wenig Videokompression bei einen 700 MB Video mit einer Länge von 17(!) Sekunden wäre doch nicht schlecht gewesen...

[deekey777]

Aus dem Interview mit Dave Baumann (http://www.guru3d.com/article/interview-with-ati-dave-baumann/4):
It should be noted that the demonstrations we have done to date have had zero impact on the Havok toolset itself. In other words, in this case the developer does not need to change anything from their point of view to enable GPU acceleration; it is entirely transparent.