iMac Pro in Kooperation mit Vega 64 als eGPU unter Resolve

Das Trauerspiel geht weiter. Dieses mal in den Hauptrollen: ein 2018er iMac Pro eines Kollegen in Vollkonfiguration (okay, bei den SSDs war dann wohl Schluss, da mussten 1 TB reichen) in Gespann mit meiner eGPU-Lösung. Die Aufgabe: bessere, sprich performantere und plausiblere Ergebnisse zu Tage fördern als es bei mir der Fall war (ich berichtete).

Das Ergebnis: insgesamt das gleiche Trauerspiel. Während Raw-Workflows (getestet wurde hier Cine-Raw, was u.a. von der Phantom Flex 4k Highspeed-Kamera genutzt wird) deutliche Performance-Gewinne verzeichnen (zumindest bei der Konvertierung in DNxHD 36 / 8-bit in 1080p), gibt es bei ProRes und anderen komprimierten Codecs die gleichen unplausiblen Ergebnisse: mal gewinnt der Workflow keinerlei Performance (vlt. bremst hier ja die CPU als Decoder), mal behindert er sogar den Workflow (Renderzeiten im Vergleich zu einem Setup ohne eGPU verlängern sich, Playback leidet unter Mikro-Rucklern). Die eGPU als Wunderwaffe, um einen iMac Pro im täglichen Resolve-Workflow eines DITs performanter und damit auch nützlicher zu gestalten, geht somit also bis jetzt – ähnlich wie bei mir – in wenigen Fällen auf. Es scheint als würde Davinci Resolve zwar eGPUs unterstützen und bei Bedarf auch auf sie zurückgreifen können, das Ergebnis ist jedoch alles andere als eitel Sonnenschein.

Besonders auffällig: setzt man in Resolve die GPU-Auswahl auf „auto“ anstatt „manuell“ selbst zu wählen, wer alles Mitspielen darf, so läuft das Gespann insgesamt deutlich stabiler und manchmal auch etwas performanter ab. Wählt man hingegen nur die eGPU als Solo-Render-GPU aus, so ist die RX Vega64 sogar schneller als die intern verbaute Pro Vega 64 und das trotz Thunderbolt3-Bottleneck, sowie um die Hälfte reduzierten VRAM (8 GB müssen der RX-Variante des Vega-Chips reichen). Resolve kann also die eGPU durchaus komplett auslasten, aber anscheinend nicht im Gespann mit der intern verbauten GPU des iMac Pro. Es bleibt als die Hoffnung, dass Blackmagic Design hier schnellst möglich weiter optimiert und Apple für alle angewiesenen Anwender weiter an einer guten eGPU-Integration in weitere macOS-Instanzen arbeitet. Ich bliebe dran…

2013er Mac Pro und eine AMD Vega 64 als eGPU, oder wie ich lernte Resolve zu hassen

Dieses Blog ist tot, die DSGVO macht eh alle privaten Blogs zur abmahngefährdeten Achillesferse ihrer Besitzer und auch sonst, Internet außerhalb großer Social-Hubs wie Facebook, Instagram und Co. ist eh tot. Ein Niemansland, in das sich keiner mehr verirrt und wenn doch, hier nicht lange verweilen mag. Warum schreibe ich dann hier nach fünf Jahren wieder was und mach mir überhaupt die Mühe, das hier weiter zu betreiben. Tja, irgendwo muss der Gedankenmatsch ja nunmal hin, auch wenn er in diesem Fall mit dem Thema Videospielen nicht mehr viel gemein hat (nungut, der Begriff AMD Vega 64 dürfte Hardcore-PC-Gamern was sagen, das wars dann aber auch schon…). Nungut, here we go…

Das Gute: Mit macOS 10.13.4 untersützt Apple nun offiziell eGPUs am Mac. Einfach ein passendes Gehäuse kaufen (davon gibt es Unzählige, siehe hier), eine potente GPU als Herz darein verpflanzen und ab gehts. Mein MacPro ist schließlich aus dem biblischen Jahr 2013 entsprungen, und die in ihm verbauten D700er waren zwar damals HighEnd und so und mit 6 GB VRAM utopisch gut ausgestattet, heute hat das aber jede MidRange-Gamingkarte gepaart mit einer deutlich potenteren GPU. Um es also mit Jeremy Clarksons Worten zu sagen: „How hard can it be?“

Das Graue: High-Sierra ist immer noch ein ziemliches Bugfest, was u.a. das Festplattendienstprogramm immer mal wieder beweist und Apples „Plug&Play“-eGPU-Idee ist mit einigen Einschränkungen verbunden, die da wären:

  1. No Thunderbolt-3-Mac, no eGPU-Support. Wer also, wie ich, einen „alten“ MacPro mit Thunderbolt2-Ports zur Verfügung hat bzw. aufrüsten möchte, kann auch mit einem passenden Adapterm von TB3- auf TB2-Anschluss ofiziell keine eGPU fahren.
  2. No nVidia in da House, please. Team grün muss ofiziell draußen bleiben, unterstützt werden nur GPUs aus dem Hause AMD und da auch nur der neueste Shizzle. Wer noch ne alte R9 Fury rumliegen hat und die gerne weiter verwenden möchte, schaut ofiziell in die Röhre. Alle nVidia-Fans und somit alle Anwender, die auf CUDA angewiesen sind, erleiden das gleichen Schicksal. Apple setzt halt auf ihre eigene Metal-API bzw. Open-CL, da ist CUDA halt ungern gesehen. Kann man verstehen, muss man aber nicht.

Das Erfreuliche: Ofiziell mag vieles nicht gehen, inofiziell gibt es aber genügend findige Tüftler da draußen, die macOS das machen lassen, was Apple schlicht nicht will. Das Nachteil ist klar: Apples SIP (System Integrity Protection) muss auf jeden Fall weichen und jedes OS-Update sollte in wohler Rücksichtnahme aller Kernel-Patch-Kompatibilitäten erfolgen. Blindes Updaten um des Updates willen ist also nicht mehr unbedingt möglich, was man dafür gewinnt ist aber beträchtlich:

Die wunderbare Community von egpu.io stellt für jedes der oben beschriebenen Probleme einen wunderbaren Patch als Lösung zur Verfügung und das stehts aktuell und verständlich beschrieben. Vorher sollte man natürlich noch ein aktuelles TimeMachine-Backup von seinem System machen, safe ist sicher und so.

Mit wenigen Handgriffen lässt sich so auch auf alten Macs mit Thunderbolt-Schnittstellen der ersten und zweiten Generation der in 10.13.4 eingeführte ofizielle Support für aktuelle AMD-GPUs in externen Gehäusen aktivieren. Auch wer eine alte AMD-GPU weiter verwenden möchte, oder eine nVidia-GPU zwecks CUDA braucht findet im verlinkten Thread Lösungen. Bei mir liefen alle Patches ohne größere Probleme durch und nach zwei Neustarts schnurrte die Vega64 in Sonnets eGFX-550-Gehäuse ohne Probleme am Thunderbolt2-Port meines Mac Pros, den ja die meisten „liebevoll“ Trashcan oder Urne getauft haben. Tja, wenn Apple das wüsste…

Warum der ganze Aufwand? „Billisch is dat aber nich!“ Ja, umsonst bekommt man natürlich nichts und wenn es mit Thunderbolt und Apple zu tun hat, dann wirds schon mal absurd teuer. Die meisten Pro-User mit einer Urne können sich noch lebhaft an die Zeiten erinnern, wo eGPUs ein vager Traum und externe Thunderbolt-PCIe-Gehäuse, in die eine Grafikkarte passte, bei knappen 1000 Euro oder auch mal leicht darüber lagen. Da sind 350 Euro für Sonnets eGPU-Gefäß also durchaus als Schnäppchen zu betrachten und jeder, der beruflich viel mit Resolve zu tun hat, wird mir zustimmen, dass 950 Euro Gesamt-Investition auf jeden Fall lohnenswert sind, wenn sich Renderzeiten drastisch verkürzen und das Playback auch mit der x-ten Node noch flüssig auf dem Kundenmonitor läuft. Oder anders ausgedrückt: wer nicht gerade Technik-Enthusiast ist oder aus beruflichen Gründen mehr Leistung aus seiner Urne quetschen muss, dem ist von solcher Art Spielerein eher abzuraten: Kosten und Nutzen stehen selbst bei einem perfekt laufenden System in einem eher zwiespältigen Verhältnis zueinander.

Das Schlechte: „Perfekt laufendes System“ Tja, schön wärs. DaVinci Resolve und eGPU, das ist ein eher zweischneidiges Schwert. Wenn es läuft ist es schnell, stabil und gut, ansonsten kann dir der schöne neue GPU-Anhang aber schnell alles zerstören. Wo eben ein UHD-ProRes noch brav mit 90 FPS in ein DNxHR umgerechnet wurde behindert die eGPU auf einmal den ganzen Prozess und die Performance bricht auf lausige 30 FPS ein, obwohl theoretisch mehr Rechenpower zur Verfügung steht. Theoretisch bedeutet in diesem Fall, dass in den branchenüblichen Benchmarks wie Geekbench und Co. die eGPU so funktioniert wie sie soll und ordentlich FPS aufs Parkett bügelt. Nur DaVinci Resolve bekommt davon nichts mit, bzw. bekommt es in vielen Fällen (hier besonders bei komprimierten Intermediate-Codecs wie ProRes, DNxHD, h264 usw. usf.) nicht hin die eGPU auch nur Ansatzweise auszulasten. Nein schlimmer noch, auf einmal wird die eGPU zum Flaschenhals und bremst den kompletten Workflow aus. Dass es anders geht wird dann auf einmal bei der Bearbeitung von ARRI RAW deutlich, wo sich Rendergeschwindigkeiten von 60 FPS auf 90 FPS hochschrauben. Aber auch hier gilt: nicht jeder Zielcodec und jede Auflösung profitieren davon. Wer von einem 3.4k-ARRI-RAW in ein 1080p DNxHD 36/8-bit für den Offline-Schnitt konvertieren möchte, der darf sich über eine top Performance freuen. Wer dasselbe RAW-Format jedoch in ein 2160p DNxHR LB wandeln möchte,  darf die eGPU getrost abkoppeln, da arbeiten die beiden D700er alleine deutlich schneller. Warum, weshalb und wieso? Ich hab keine Ahnung! Mein Trouble-Shooting hat leider kein Erfolg gebracht, dabei hab ich alles versucht. Ja, wirklich alles, hier mein Weg:

  1. DaVinci Resolve mehrfach neu installiert, verschiedenste Versionen probiert: von 12.5 bis 15 beta 4 war alles dabei. Ab 14.2 ist die Perfomance identisch geblieben.
  2. Team Green ausprobiert und mit einer Titan X dasselbe Trauerspiel erlebt, nur dass jetzt die beiden D700er dank CUDA überhaupt keine Rolle mehr spielen konnten und alles noch langsamer wurde.
  3. Dasselbe Setup an einem 2016er MacBook Pro mit Thunderbolt3-Port ohne Adapter ausprobiert und die gleichen Phänomene betrachtet. Die limitierende Bandbreite des TB2-Ports ist somit also nicht Schuld an der Tragödie.
  4. Unterschiedliche Quell-Datenträger vom schnellen HDD-Raid über Thunderbolt bis hin zu PCIe-SSDs ausprobiert: keine Verbesserung in Sicht.
  5. Kabel und Adapter mit allem getaucht was mein Ersatzteil-Lager hergegeben hat (und das ist ne Menge). Auch das hätte ich mir sparen können.
  6. Mal die eGPU als Display-GPU mit angeschlossenem Monitor probiert, mal nur als Render-GPU ohne direkten Monitor-Kontakt. Fazit: als diskrete Render-GPU funktioniert sie deutlich stabiler und zumindest die anfangs auftretenden Mikroruckler im Playback waren verschwunden.

Kurzum: DaVinci Resolve und eGPU, das ist eine Kombination, die man sich zumindest am Mac egal ob nun mit Patch über Thunderbolt 2 oder ganz ohne Bastelei dank Thunderbolt 3 erstmal sparen kann: Zu inkonsistent sind die Ergebnisse, zu unblausibel plötzliche Performance-Einbrüche. Zurück bliebt die Erkenntnis, dass Apple dringend einen ordentlichen Mac-Pro-Nachfolger bringen muss und das Thema eGPU primär etwas für Gamer bleibt, die mit ihrem Notebook zocken möchten, da ihnen ein altmodischer Tower nicht mehr ins Haus kommt oder kommen kann.

Das Hässliche: Ein eGPU-Case, das aktuell zu nichts mehr taugt als ein 950-Euro-Briefbeschwerer auf meinem Schreibtisch zu sein plus die Erkenntnis, dass Blackmagic Design vielleicht die Engine von Resolve optimieren sollte anstatt das x-te Feature ins Programm zu stopfen (hallo Fusion, ick hör dir Trapsen).

Die Hoffnung: Dass irgendwo da draußen jemand mit demselben Problem geplagt war und erfolgreich eine Lösung gefunden hat.

Indieliebe: Prison Architect Alpha Folge 1

Wer sich, wie ich, gefragt hat, was die Entwickler bei Introversion eigentlich die ganze Zeit nach Defcon gemacht haben, der bekommt in meinem Video eine sehr gute Antwort darauf. Prison Architect ist eine wunderbare Hommage an alte Bullfrog-Klassiker wie Theme Park und Theme Hospital, nur dieses Mal leitet ihr halt mal ein Gefängnis. Klingt komisch, ist es irgendwie auch: Britischer Humor und spielerische Freiheit sorgen aber dafür, dass man es gerne spielt.

Hui & Pfui Vol. 3

Hui für die Konsumhuren unter uns: der Steam Summer Sale hat endlich angefangen, Pfui hingegen, dass Valve selbst im x-ten Jahr wohl immer noch Probleme mit der Standhaftigkeit seiner Software hat. Extrem gut gefallen haben mir hingegen Marcus Gedanken darüber, dass Videospiele weitaus mehr sein können und sollten als Entertainment. Pfui hingegen ist, wie schlecht EAs Geschäftsgebaren inzwischen sein muss. Sowohl unser Senior Gamer als auch Brain Diesel geben hierfür erschreckend gute Beispiele. Richtig gut, und ja auch Eigenlob muss mal erlaubt sein, gefällt mir dafür mein erster Podcast mit Manu bei Breakfast at Manu spielt’s. Sim City Social ist hingegen leider der beschriebene Rotz, Finger weg! Achja: unglaublich cheesy: der Headshot-Controller, den uns PEARL mit sehr fadenscheinigen Argumenten im schräg schrulligen Videoclip auf Youtube verkaufen will.

OUYA – Der Hype vs. die Realität

Jaja, alle reden davon. OUYA, das nächste große Ding auf Kickstarter. Die globale Gamergemeinschaft ist heiß, die Aufregung steigt und jeder ist sich sicher, dass OUYA der Shit werden wird! Doch die Wahrheit ist, dass keiner OUYA braucht.

Kommen wir erstmal zu den tollen Sachen: OUYA ist eine Open-Source-Konsole, basierend auf Andriod 4.0 als Betriebssystem und nVidias Tegra 3 als Hardwarebasis. OUYA ist mit 99 USD inklusive Gamepad billig. Es soll dafür HD-Auflösung, 1GB RAM, 8 GB Flash-Speicher, WiFi, Bluetooth 4.0 und einen kabellosen Controller bieten. Es soll für Entwickler keinerlei Lizenzkosten geben und SDKs sollen schweinebillig sein. Und um die Hure für jeden zu sein: Hacker, die das System „verbessern“ wollen, sind jederzeit willkommen. Man soll noch nicht einmal die Herstellergarantie verlieren, wenn man sich den Innerein der OUYA nähert. Das alles klingt nach einem wahren Paradies, einem feuchten Spieler-Traum. Ganz ehrlich, ich glaube da nicht dran.

Warum? Nicht nur, weil das Versprochene zu gut klingt, nein, sondern auch, weil die Realität sehr viel anders aussieht. Wie Ben Kuchera von Penny-Arcade hier so schön erkannt hat, gibt es bis auf einen Prototypen nichts vorzeigbares. Es gibt kein einziges Spiel für die Konsole (Minecraft soll erst dann kommen, so Entwickler Mojang, wenn sich OUYA als gutes, erfolgreiches System etabliert hat), der AppStore ist noch nicht fertig, ja selbst beim Controller handelt es sich um eine Designstudie (im Demovideo muss ein PS3-Controller als Ersatz herhalten). Wir wissen relativ wenig über OUYA, alle Angaben auf der Kickstarter-Seite sind sehr, sehr vage. Trotzdem soll uns bis März 2013 ein fertiges Produkt präsentiert werden. Na klar!

Der größte Hinkefuß für mich ist aber die Tatsache, dass niemand diese Konsole braucht. Weder Indieentwickler noch Spieler. Der Hersteller von OUYA führt gerne an, dass es für Indieentwickler extrem schwer sei, ihr Spiel über XBLA, PSN oder sogar Steam zu vertrieben. Das mag sein, nur braucht ein Indieentwickler deswegen OUYA als Plattform? Oder besser gesagt: hat sich jemand schon einmal wegen einem exklusiven XBLA-Indiegame eine Xbox-360 gekauft? Wer als kleiner Entwickler bei Steam und Co. nicht unterkommt, kann sein Spiel immer noch selbst vertrieben oder kleinere Verkaufsplattformen wie Desura bedienen. Und mal ehrlich: wer als Entwickler im Indie-Sektor ein breites Publikum erreichen will, der greift am besten zum PC: die Entwicklertools sind günstig und die Verbreitung der Plattform ist immens. Warum wird OUYA dann als DIE Plattform für Indiespiele verkauft? Ganz einfach: es hört sich gut an.

Klar, jetzt kommt der Einwandt, man hätte dank Andriod-Betriebssystem eine unglaublich große Auswahl an Spielen. Das mag sein, aber wie viele der wirklich guten und erfolgreichen Andriod-Spiele setzen auf einen klassischen Controller als Eingabemedium? Angry Birds? Tiny Wings? Doodle Jump? Slice It? Fruit Ninja? Draw me Something? Selbst klassische Umsetzungen wie Baphomets Fluch setzen stark auf den Touchscreen. Warum? Der mobile Spielemarkt lebt von der Andersartigkeit seiner Spiele. Sie setzen auf Touch-Steuerung, einen schnellen Einstieg und die Möglichkeit sie mal kurz zwischendurch zu spielen. OUYA will aber eine ausgewachsene Konsole sein, und da funktionieren solche Spiele nicht. Wer sich hinsetzt um zu Spielen der will das große Programm.

Und dann das Ding mit den Hackern. Man will also kleine Entwickler ansprechen; wäre ich Indie-Entwickler, dann würde ich niemals eine Plattform bedienen, die offen für Hacker ist. Egal, ob sie nun das System nur verbessern sollen dürfen. Welcher Hacker hält sich schon daran, was er soll oder darf? Der Indie-Markt ist heiß umkämpft, selbst erfolgreiche Vertriebsplattformen wie Steam oder der AppStore haben es nicht leichter gemacht. Also: warum zur Hölle soll ich für die OUYA entwickeln? Ihre Verbreitung ist nicht gesichert, ihre SDKs mir unbekannt, und dann will sie auch noch offen für Hacker sein? Bitte was!?

Achja, eine Zielgruppe muss man ja auch haben um zu verkaufen. Nur wer soll das sein? Gelegenheitsspieler? Klar, die kaufen sich auf jeden Fall eine unbekannte, von Geeks auf Kickstarter.com finanzierte Konsole, um darauf Angry Birds zu spielen. Vor allem, weil sie es auf ihrem iPhone oder Galaxy S3 ja noch nicht gespielt haben. Sehr unwahrscheinlich, nicht wahr? Bleibt dann also nur noch der Hardcore-Gamer. Aber was will der mit einer OpenSource-Konsole ohne Unterstützung der großen Publisher? Wer ist übrig: Nerds, die gut aussehende Technik und vollmundig versprochene Ideen heiß finden. Ja gut, damit verkauft man vielleicht 30.000 bis 50.000 Konsolen. Nur welcher Entwickler will für so einen Markt entwickeln bzw. seine Spiele portieren? Selbst große Konzerne wie UbiSoft und EA klagen darüber, dass sich PC-Portierungen ihrer AAA-Titel kaum lohnen. Raubkopierer und so seien Schuld. Also denkt sich dann sicherlich jeder Indie-Entwickler: Wie geil, dass es die OUYA mit ihren knapp 50.000 Käufern und der Unterstützung für Hacker gibt. Logisch, nicht? Ähm, auf gar keinen Fall!

Wir fassen zusammen: für Indieentwickler ist die Plattform uninteressant: man muss SDKs kaufen, die Verbreitung ist fragwürdig und der PC als Plattform unschlagbar gut geeignet. Und für uns Spieler gibt es aktuell nichts, was uns den Grund gibt, OUYA wirklich kaufen zu müssen: Keine Exklusiv-Titel, keine großartigen neuen Hardware-Features und kein neues Spielerlebnis. Nur Indie sein wollen und Open-Source anpreisen reicht nicht. Nischendasein oder Totgeburt, dass sind hier viel mehr die zwei Optionen der OUYA.

GameDock: iPhone und iPad als NES-Retro-Konsole

Es gibt Ideen, die sind jetzt nicht so neu, ihre Umsetzung dafür aber umso besser. Das GameDock von Cascadia Games ist so ein Fall. Im Endeffekt ist es nichts weiter als ein iPhone-/iPad/iPod-Touch-Dock (ab iPhone 4, iPod Touch 4 Gen., iPad 2) mit einem HDMI-Ausgang. Doch zwei Sachen unterscheiden das GameDock gehörig von seinen Mitbewerbern: erstens gibt es zwei USB-Controllerports in die u.a. USB-NES-Controller-Fakes (auch von Cascadia entworfen) passen und zweitens sieht das Ding so geil kantig und grau retro aus, dass echtes 8bit-Feeling rüber kommt. Der Preis für ein Dock mit 2 NES-Nachbau-Controllern (das Dock ohne Controller ist leider ausverkauft) liegt aktuell bei 150 USD + 20 USD Versand nach Deutschland / Europa. Das ist zwar happig, wer aber nur die Idee dahinter geil findet, der kann das GameDock auch mit weniger Geld fördern, klassisches Kickstarter-Crowd-Funding halt. Damit ihr jetzt die rosarote Retro-Brille aufgesetzt bekommt hier ein paar Spieledemos live vom GameDock-Prototypen.

Zukünftige Investoren und Gaming-Geeks klicken bitte hier.

Hui & Pfui Vol. 2

Unglaublich Pfui ist, dass es Apple seit zwei Jahren nicht hinbekommt, einen simplen Multitouch-Fehler zu bugfixen. Hui: Scheinproblems Dystopie über den Untergang des Core-Games und die Aufsplittung der Spielerschaft in drei verfeindete Gruppen auf Polyneux, gutes Schmunzelfutter das Teil! Kategorie „grandioser Artikel, unglaublich mieses Spiel“: wunderbar, wie sich Simon über die abgrundtief beschissene Kinect-Steuerung bei Steel Battalion : Heavy Armor aufregt und sich zugleich die Frage stellt, warum man hier überhaupt Kinect braucht, wenn man seinen Panzer eh mit dem Controller steuern muss. Nicht so brilliant hingegen finde ich Andys Versuch, uns Medienhuren auf polygamia zu unterstellen, dass wir immer gleich das als schlecht abstempeln, was die Masse als extrem gut empfindet. Wenn dem wirklich so wäre, würde also jedwede Kritik abseits des Mainstreams nur ein blöder Rant sein? Für junge Spieleentwickler hingegen sehr interessant dürften die Möglichkeiten sein, welche GameFounders ihnen bieten möchte. Neben 5.000 EUR Startkapital für jeden Projektgründer gibt es ein 3 monatiges Training mit zig Branchengrößen. Unterstützt wird das ganze von Microsoft und anderen großen, bösen Firmen. Anmeldeschluss istder 10. Juli 2012, also go, go, go!