Ich denke Cycles auf Metal ist nicht so dramatisch. Eher das OGL 3.x Zeug:
- GUI
- klassischer Viewport
- Eevee
Posts from RexRetro in thread "Apple Macs mit ARM-Prozessoren"
-
-
oder explodieren?
Wie beim MS Internet Exploder?
Der ist doch lange out. Oder implodiert?
MS hat sich doch schon voll auf Edge Computing vorbereitet, mit MS Edge.
Oder ist das die Kante, wo man hinten über fällt?
-
...vielleicht explorieren oder explodieren?
-
Ich sehe Kompatibilität mit alten APIs und ISAs als zweischneidiges Schwert. Als Kunde will ich natürlich meine bestehende Software weiter nutzen können. Vor allem wenn ich viel bezahlt habe und es mir von der Leistung reicht.
Und das Update kann kosten, neue Bugs und Inkompatibilitäten haben oder gar nicht kommen.
Von der Entwicklerseite sehe ich auch den Vorteil, die Altlasten irgendwann zu entfernen. Alles andere führt Wartungstechnisch irgendwann zu extremem Aufwand und bremst die Weiterentwicklung.
Auf jeden Fall! Software immer wieder zu entschlacken und Dinge, die man nicht mehr unbedingt braucht rauszuwerfen macht die Wartung einfacher. Die wächst nämlich leider nicht linear mit der Menge der Features, sondern eher potentiell, da man Features ja auch kombinieren kann und man eigentlich alle Permutationen testen muss.
Es wächst nicht nur 'potentiell', sondern eher 'exponentiell'. Aber vielleicht meinte Claus das ja.
Und bei den Permutationen von Feature-Kombinationen könnte es noch schlimmer sein: Fakultät wächst noch schneller...
-
Please login to see this link.
Der 3D-Renderer hat erst letzten Sommer den Weg auf den Mac (inkl. Metal-Unterstützung) gefunden, jetzt ist die Beta-Phase beendet und die Software auch M1-kompatibel.
Ui. Octane war lange Zeit CUDA only. Hat zwar immer mal wieder OpenCL-Support angekündigt, aber ich glaube, das kam nie wirklich.
Aber wahrscheinlich haben die für RTX/OptiX eh ein ordentliches Refactoring gebraucht und dann gleich versucht, es möglichst Backend-agnostisch zu machen.
-
Mit Rosetta passiert es aber als JIT/AOT in Software für eine völlig andere ISA, die nicht mit Hinblick auf optimale x86-Emulation entworfen wurde.
[...] Weil im Prinzip damit jede dahergelaufene Firma mit ARM-Architektur-Lizenz (wie Samsung, Qualcomm und diverse andere) eine CPU bauen könnte, die mit nur geringem Verlust X86-Code ausführen könnte – ohne ein einziges Intel-Patent zu verletzten. Das wäre doch quasi das Horror-Szenario für einen CPU-Entwickler, wie Intel, oder? Milliarden von Dollars in IP stecken und dann nützt das alles nichts.
Wobei die meiste IP wohl nicht in der ISA stecken dürfte. Die ist ja eh nur Kraut-und-Rüben, oder besser gesagt: historischer Wildwuchs und von Anfang an ohne Konzept
Mir ist eh etwas schleierhaft, wie man sowas triviales wie eine ISA, was ja nur eine ziemlich banale Hardware-Schnittstellendefinition ist, rechtlich schützen kann. Patente setzen ja eine Erfindungshöhe voraus.
Also dass man sich etwas Schlaues dabei gedacht hat. Bei vielem in der x86 Architektur fragt man sich, ob da irgendwer überhaupt irgendwas gedacht hat, ausser: "Wie zum Teufel bekomme ich das irgendwie schnell zum laufen?"
Das A20-Gate lässt grüßen!
BTW: der Prof, bei dem ich techn.Info und Rechnerarchitektur hatte, hat immer erzählt, dass er damals AMD geholfen hat, das Patent für orthogonale Segmentierung/Paging beim 386 Protected Mode zu kippen. Er hatte da prior art.
Dann hat er sich immer darüber ausgelassen, dass das beim 386er auch noch dilettantisch implementiert wurde...
-
Ich denke, dass hier doch eher eine Kombination aus CPU- und GPU-Cores gemessen wird, oder? Macht bei Textur-Dekompression auch irgendwie Sinn, dass die CPU das nicht (alleine) macht.
Bei Texturen braucht man auf der GPU wahlfreien Zugriff in konstanter Zeit, daher kommen da fest Blockkompressionen zum Zuge, die auch in Hardware in den Texture-Units implementiert sind.
Aber die komprimieren nicht so gut, dass sie auch für Netzwerk-Transfer oder Speicherung auf dem Trägermedium gut wären.
Im dümmsten Fall komprimiert man also z.B. JPEG für Transport/Medium, dekomprimiert dann mit CPU in RAM ( oder auch GPU in VRAM), hat dann aber wieder plain RGB und muss es wieder für die GPU-Kompressionsmethoden rekomprimieren.
Das ist natürlich ein unsinniges Hin- und Her.
Daher hätte man gerne starke Komprimierung für Transport/Speicherung, die sich direkt in GPU-komprimierte Texturen entpacken lassen. Im Idealfall auch direkt auf der GPU.
Das Please login to see this link. ist gerade so ein Versuch von Khronos, da einen Texture Supercompression Standard zu schaffen.
-
Da geht es um Texturkompression, und die macht auf der GPU wenig Sinn
Sorry. Ja es geht darum die Texturen zu komprimieren. Z.B. um Speicher bei der Übertragung für WebGL zu sparen, oder Platz auf dem Trägermedium.
Da in modernen Spielen riesige Level mit Texturen völlig zugekleistert werden, muss man da was tun.
-
Please login to see this link.
Kennt die noch jemand? Hab das damals verfolgt, als Linus Torvalds dort gearbeitet hat.
Ja, konnte damals aber halt auch nicht mit Intel mithalten. Glaube nur der Stromverbrauch war etwas besser als bei den damaligen x86 Mobile CPUs. Aber die Performance dafür eben zu schwach.
-
x64 Maschinencode ist auch nur noch ein (seltsamer) "Bytecode".
Das ist schon seit dem NexGen Nx586, AMD K6 und Intel Pentium Pro so, das sind eigentlich RISC-CPUs, die erstmal x86-Code auf ihre interne Architektur übersetzen.
Das ist klar. Aber das passiert dynamisch in Hardware, davon sieht das OS nichts (mal abgesehen von Transmete).
Ausserdem haben die x86 CPU-Hersteller ihre "internen RISC" ISAs sicher dem angepasst, was für x86 am meisten gebraucht wird.
Auch Probleme mit unterschiedlicher Endianess wird es nicht geben.
Mit Rosetta passiert es aber als JIT/AOT in Software für eine völlig andere ISA, die nicht mit Hinblick auf optimale x86-Emulation entworfen wurde.
Wenn man bedenkt, dass Intel selbst es damals beim Itanium nicht geschafft hatte, eine performante x86 "HW-Emulation" umzusetzen, ist das schon cool, wie Rosetta2 performt.
-
Zahlen zur M1 Performance bei der Textur-Dekompression:
Please login to see this link.
Dass der M1 im Mac Mini nicht mit einem Core i9 als echtem 8 Kerner + Hyperthreading mithalten kann ist ok.
Was aber wirklich beeindruckt ist, wie nah x64-Code mit Rosetta2 an die native ARM64 Performance kommt.
Es gilt anscheinend nun für die x64 ISA, was auch für VM-basierte Sprachen mit JIT und AOT-Compilern erreicht wird: der Overhead ist verkraftbar.
x64 Maschinencode ist auch nur noch ein (seltsamer) "Bytecode".
-
Die x86 Emulation des M1 hat mich wirklich überrascht, und das konnte man auch kaum vorraussehen, weil es ja sowas auf den iDevices nicht gab.
Aber schon als ich die Geekbench5-Werte des iPhone 12 sah, konnte ich kaum glauben, was da für die single-thread Performance stand.
Da war schon zu erkennen, dass ein passiv gekühlter Mobile-Chip in dieser Hinsicht mit den neusten Intel Core ix-11xxxx und AMD Ryzen 5xxx mithalten konnte.
Dinger die TDPs von >100 Watt und aufwändige Kühlsysteme haben.
-
Objektive Performance Vergleiche zwischen unterschiedlichen Renderern (schon auf der gleichen Hardware) sind extrem schwer, weil sich der Output und seine "Qualität" massiv unterscheidet und die Renderer mal auf die eine, mal auf die andere Hardware hin unterschiedlich gut optimiert wurden. [...]
Im Grunde kann ein Anwender nur schauen: kann der Renderer alles was ich brauche und ist er erträglich schnell dabei (und läuft er auf der HW die ich habe...)
Es wäre halt schön, wenn einem "das Internet" die Recherche ein wenig erleichtern könnte. Angenommen, ich kaufe mir nicht die Hardware passend zur Software, sondern möchte meinen vorhandenen Rechner nutzen. Dann wäre es eigentlich ganz schön, wenn ich nicht erst alle Software kaufen muss (Cinema kostet ja z.B. Geld), sondern vorab erfahren könnte, welche Render-Software auf CPU X mit GPU Y die beste Performance erzielt. Den Funktionsumfang kann ich notfalls über Specsheets in Erfahrung bringen aber über die Performance wird kein Wort verloren. Außerdem gibt es für die Software-Hersteller auch wenig Anreiz, die Hardware und APIs optimal auszunutzen, wenn es keine Vergleichsmöglichkeiten gibt.
Was spräche dagegen, einige Szenerien (wie die aus typischen Blender-Filmen, wie Big Buck Bunny) mit anderen 3D-Softwares nachzubauen (teilweise wird man Geometrien ja auch übernehmen können) und dann mit "ähnlichen" Qualitätseinstellungen zu rendern. Nur damit man ein Gefühl dafür bekommt, wie unterschiedlich schnell die Renderer arbeiten. Vielleicht tun die sich ja alle nicht viel, vielleicht ist einer aber auch 5 Mal so schnell (auf einer gegebenen Hardware) – niemand weiß es.
Klar wäre das schön. Aber wer soll das machen und aktuell halten ? Wer soll den Aufwand bezahlen?
Es gibt durchaus einige Youtuber, die immer mal wieder versuchen verschiedene Renderer (meist in Blender) miteinander zu vergleichen. Die basteln eine Szene, konvertieren sie und rendern mit ihrer Kiste.
Sowas wie Please login to see this link.. (PS: aber der Tester hat keine Ahnung, wie er in Cycles Fireflys wegclampen kann und dreht nur die Samples übermäßig hoch)
Aber das über verschiedenste kommerzielle Packages zu machen, ist halt noch mehr Aufwand und teuer (viele EULAs von Demoversionen verbieten ja kommerzielles Benchmarking).
Als Endanwender kann man aber selbst natürlich mit den Demo-Versionen der DCC Packages und Renderer erstmal ausprobieren, was einem gefällt.
Tests in Fachzeitschriften (Digital Production, 3D World Magazine, 3D Artist, Develop 3D) sind auch ein Anhaltspunkt, aber meist sind das keine großen Performance-Vergleiche. Da steht dann doch nur Larifari wie "Fühlte sich auf unserem Testsystem recht flott an."
Der Markt ist halt auch extrem groß. Please login to see this link. mal nur ein Survey über gängige Renderer im ArchViz Umfeld.
Die "Digital Production" hatte in Please login to see this link. mal einen Please login to see this link.
-
Meine Intention ist, das ich am Pi Model kann, wären mein Hauptrechner z.b. ein Video Encodiert und unter vollast läuft.
Die Frage ist halt, ob so ein Usecase so gängig ist, dass es sich für die Entwickler lohnt, deswegen ein aktuelles Blender auf den Pi zu bringen.
Blender ist Open Source und Freeware. Es lohnt sich für die Entwickler nur, wenn:
- sie es selbst unbedingt haben wollen
- jemand es über den Developer Fund sponsort
-
Gibt es eigentlich Testverfahren, mit denen man die Render-Performance von 3D-Suiten benchmarken kann? Die Hardware kann man ja mit Cinebench und Co. gut testen aber mich würde z.B. interessieren wie effektiv Blender gegenüber z.B. Cinema 4D die jeweilige Hardware ausreizt.
Bin nicht sicher, ob ich Dich da richtig verstehe: willst Du die Auslastung der GPU durch einen Echtzeit-Renderer testen? Oder die Benutzung der möglichen Grafikfeatures?
Objektive Performance Vergleiche zwischen unterschiedlichen Renderern (schon auf der gleichen Hardware) sind extrem schwer, weil sich der Output und seine "Qualität" massiv unterscheidet und die Renderer mal auf die eine, mal auf die andere Hardware hin unterschiedlich gut optimiert wurden.
Selbst den gleichen Code auf unterschiedlichen GPUs des gleichen Herstellers - ja sogar auf der gleichen GPU mit verschiedenen Treiberversionen oder Treibersettings - kann mal deutlich besser, mal schlechter laufen.
Eine Grafikpipeline optimal auszulasten ist schwierig. Irgendeine Stufe ist immer das Bottleneck. Dazu ist oft unklar, wo die Shader-Compiler (im Treiber) wie viel optimieren.
Und das Betriebssystem kann auch noch mit reinspielen. Such mal YT Videos zu "Blender Cycles auf Windows vs. Linux" ( wobei auch noch der CPU Compiler da einen Einfluss hat - msvc vs gcc vs clang).
Desweiteren ist immer die Frage, wie sehr man sich an eine Hardware oder einen Hersteller binden will, indem man dessen Toolchain und Libraries nutzt. Stichwort: CUDA vs. OpenCL vs. Compute Shader, Intel Embree, icc, NV OptiX, AMD FireRays, etc.
Und auch OpenGL und Vulkan haben herstellerspezifische Extensions, die mehr oder weniger Vorteile bringen, dafür aber die Bindung an eine Hardware erhöhen oder entsprechende Abstraktionsschichten brauchen, um flexibel die konkurrierenden Erweiterungen verschiedener Hersteller nutzen zu können.
Blender Cycles hat ja zum Beispiel folgende Backends: CPU C++ mit und ohne Embree, CUDA C++ mit und ohne OptiX und noch OpenCL. Und wenn ich es richtig im Kopf habe noch Hybrid CPU C++/GPU CUDA C++.
Und nicht jeder Modus unterstützt alle Render Features. Und dann gibt es ja noch die experimentellen Features, die noch "wählerischer" sind.
Im Grunde kann ein Anwender nur schauen: kann der Renderer alles was ich brauche und ist er erträglich schnell dabei (und läuft er auf der HW die ich habe...)
-
Blender 2.9 auf Pi400 dürfte an der GPU mit veraltetem OpfenGL 2.1 eher scheitern, als an der ARM CPU.
Ist es nicht sogar nur OpenGL ES, welches von den Pis unterstützt wird? Aber es soll ja, ganz neu, auch Vulkan-Unterstützung für den Raspi geben.
Ich dachte lange auch, dass der RasPi nur OGL ES 2 oder 3 hat (je nach Modell).
Aber laut Please login to see this link. der Entwickler des Grafiktreibers kann der 4er mit VideoCoreVI neben ES3.2 auch OGL 2.1 (aber nicht mehr).
Vulkan wird für Blender noch keine Option sein. Man hat für 2.8 mit Eevee ja gerade erst viel Aufwand in einen neuen Viewport Renderer gesteckt, der minimal OGL 3.3 braucht.
-
Blender 2.9 auf Pi400 dürfte an der GPU mit veraltetem OpfenGL 2.1 eher scheitern, als an der ARM CPU.
-
Früher oder später macht es doch immer „Puff“. Immer wenn ich meine Rechner an den Starkstrom hänge, damit sie mal ordentlich Power bekommen , riecht es dann so komisch und nichts geht mehr.
-
PS: wahrscheinlich hat Apple schon Mafia-Killer auf den Typ angesetzt - oder schlimmer noch: Patent- und Copyright-Anwälte.
-
Ich dachte erst, Apple veröffentlicht offene Treiber oder wenigstens Specs. Aber hier reverse engineered eher eher einer die M1 GPU für OSS Grafiktreiber.
HDL Code für die Chips vom Hersteller Apple selbst wäre „M1 open sourced“.
Klingt unrealistisch, aber haben Sun/Oracle, IBM und ImaginationTechnology ja schon mal mit Sparc, Power und MIPS32 CPUs gemacht,und ist in Zeiten des aufsteigenden RiscV-ISA Standards ja nicht völlig abwegig.
Aber Apple und ARM/NVidia stehen halt für möglichst vernagelte Systeme.
„Tyrant Devices“ wie Stallman sie nennt.
