GPU, hexagonale Beschleuniger und lineare Algebra

All diese Wörter hängen viel mehr mit der mobilen Entwicklung zusammen, als es auf den ersten Blick scheint: Sechseckige Beschleuniger helfen bereits dabei, neuronale Netze auf mobilen Geräten zu trainieren. Algebra und Matan sind praktisch, um einen Job bei Apple zu bekommen. Mit der GPU-Programmierung können Sie nicht nur Anwendungen beschleunigen, sondern auch die Essenz der Dinge erkennen.

Auf jeden Fall, sagt der Leiter der mobilen Entwicklung von Prisma, Andrey Volodin . Und auch darüber, wie Ideen von GameDev in die mobile Entwicklung einfließen, wie sich Paradigmen unterscheiden, warum Android keine native Unschärfe aufweist - und vieles mehr, die produktive Version von AppsCast wurde veröffentlicht. Im Rahmen des Schnitts werden wir über Andreys Bericht über AppsConf ohne Spoiler sprechen.



AppsCast ist der PodCon für mobile Entwicklerkonferenzen von AppsConf . Jede Ausgabe ist ein neuer Gast. Jeder Gast ist ein Sprecher der Konferenz, mit dem wir seinen Bericht diskutieren und über damit verbundene Themen sprechen. Der Podcast wird von Mitgliedern des AppsConf-Programmkomitees, Alexei Kudryavtsev und Daniil Popov, moderiert.

Alexey Kudryavtsev: Hallo allerseits! Andrey, bitte erzähl uns von deinen Erfahrungen.

Andrey Volodin : Wir bei Prisma entwickeln Produkte, die sich hauptsächlich auf die Verarbeitung von Fotos und Videos beziehen. Unsere Flaggschiff-App ist Prisma. Jetzt erstellen wir eine weitere Lensa-Anwendung für Facetune-ähnliche Funktionen.

Ich leite die mobile Entwicklung, bin aber ein Gaming-Coach. Ich habe den ganzen Kernteil, ich schreibe GPU-Pipelines für all diese Anwendungen. Ich entwickle Kern-Frameworks, damit die vom Forschungs- und Entwicklungsteam entwickelten Algorithmen und Neuronen auf Mobilgeräten in Echtzeit ausgeführt werden können. Kurz gesagt, um Server-Computing und all das zu töten.

Alexei Kudryavtsev: Es klingt nicht nach normaler iOS-Entwicklung.

Andrey Volodin: Ja, ich habe solche Besonderheiten - ich schreibe jeden Tag über Swift, aber gleichzeitig ist es sehr weit von der iOS-Entwicklung entfernt.

Daniil Popov: Sie haben die GPU-Pipelines erwähnt. Worum geht es?

Andrey Volodin: Wenn Sie Bildbearbeitungsprogramme erstellen, müssen Sie auch die Architektur konfigurieren und die Logik zerlegen, da die Anwendung über verschiedene Tools verfügt. In Lensa gibt es beispielsweise ein Bokeh-Tool, das den Hintergrund mithilfe eines Neurons verwischt. Es gibt ein Retuschier-Tool, das eine Person schöner macht. All dies muss effizienter auf der GPU funktionieren. Darüber hinaus ist es ratsam, nicht jedes Mal Daten zwischen dem Prozessor und der Grafikkarte zu übertragen, sondern eine Reihe von Vorgängen vorab zu erstellen, diese in einem Durchgang auszuführen und dem Benutzer das Endergebnis anzuzeigen.

GPU-Pipelines sind „kleine Klumpen“, aus denen Anweisungen für eine Grafikkarte zusammengesetzt werden. Dann macht sie das alles sehr schnell und effizient, und Sie nehmen das Ergebnis auf einmal und nicht nach jedem Instrument. Ich stelle sicher, dass unsere GPU-Pipelines so schnell wie möglich, effizient und im Allgemeinen im Prinzip vorhanden sind.

Alexey Kudryavtsev: Sag mir, wie bist du dazu gekommen? Ein normaler iOS-Entwickler beginnt mit Nieten und Formen, geht dann irgendwo über die API und ist glücklich. Wie kam es, dass Sie etwas völlig anderes machen?

Andrey Volodin: Zum größten Teil ist dies ein Zufall. Bevor ich einen Job bekam, habe ich Spiele für iOS gemacht. Es war immer interessant für mich, aber ich habe verstanden, dass es in Russland besonders nirgendwo gibt, wo man sich in diese Richtung entwickeln kann. So kam es, dass wir uns mit Prisma fanden. Sie brauchten einen iOS-Entwickler, der auf Swift schreiben kann und gleichzeitig die GPU kennt, insbesondere Metal, die gerade herauskam, und ich passe definitiv zu dieser Beschreibung.

Ich habe auf die Stelle geantwortet, wir hatten Synergien und seit dem dritten Jahr beschäftige ich mich immer tiefer mit dieser Sache. Wenn jetzt etwas schief geht, habe ich bereits alle diese Viper- und MVVMs - ich weiß nicht einmal, wie sie entschlüsselt werden - muss ich von Anfang an verstehen.

Was macht der GPU-Ingenieur?


Daniil Popov: In Ihrem AppsConf- Profil steht die Engineer-GPU. Was macht die Engineer GPU den größten Teil des Tages außer Kaffee zu trinken?

Andrey Volodin: Hier muss erwähnt werden, wie sich der Prozessor grundlegend von der GPU unterscheidet. Der Prozessor führt Operationen wie nacheinander aus. Sogar das Multithreading, das wir haben, ist oft falsch: Der Prozessor stoppt und wechselt, um kleine Teile verschiedener Aufgaben zu erstellen, und führt sie in wenigen Schritten aus. Die GPU funktioniert genau umgekehrt. Es gibt n Prozessoren, die wirklich parallel arbeiten, und es gibt Parallelität zwischen Prozessen und Parallelität innerhalb der GPU.

Meine Hauptaufgabe besteht neben alltäglichen Dingen wie der Optimierung von Speicheroperationen und der Organisation der Wiederverwendung von Code darin, die für die CPU geschriebenen Algorithmen so auf die Grafikkarten zu portieren, dass sie parallel sind. Dies ist nicht immer eine triviale Aufgabe, da es sehr effiziente Algorithmen gibt, die vollständig an die sequentielle Ausführung von Anweisungen gebunden sind. Meine Aufgabe ist es, zum Beispiel eine Annäherung für einen solchen Algorithmus zu finden, der vielleicht nicht genau dasselbe tut, aber visuell kann das Ergebnis nicht unterschieden werden. So können wir 100-mal beschleunigen, was die Qualität ein wenig beeinträchtigt.

Ich portiere auch Neuronen. Übrigens werden wir bald eine große Open Source-Veröffentlichung veröffentlichen. Noch bevor Core ML erschien, hatten wir unser eigenes Gegenstück und sind schließlich gereift, um es in Open Source zu integrieren. Sein Paradigma unterscheidet sich geringfügig von Core ML. Ich, einschließlich, entwickle seinen Kernteil.

Im Allgemeinen mache ich alles rund um Computer Vision-Algorithmen und Computing.

Alexey Kudryavtsev: Eine interessante Ankündigung.

Andrey Volodin: Dies ist kein Geheimnis, wir werden es nicht mit einer Art Fanfare bekannt geben, nur wird es möglich sein, ein Beispiel für die Frameworks zu sehen, die in Prisma verwendet werden.

Warum für GPU optimieren


Alexei Kudryavtsev: Sagen Sie mir bitte, warum wir Algorithmen für die GPU im Allgemeinen optimieren. Es scheint, dass es ausreicht, dem Prozessor Kerne hinzuzufügen oder den Algorithmus zu optimieren. Warum genau die GPU?

Andrey Volodin: Die Arbeit an der GPU kann die Algorithmen enorm beschleunigen. Zum Beispiel haben wir Neuronen, die 30 Sekunden lang auf dem Samsung S10-Zentralprozessor laufen, und auf der GPU gibt es 1 Frame, d. H. 1/60 Sekunden. Dies verändert die Benutzererfahrung unglaublich. Es gibt keinen ewigen Ladebildschirm. Sie können das Ergebnis des Algorithmus sehen, der am Videostream arbeitet, oder den Schieberegler drehen und die Effekte genau dort sehen.

Es ist überhaupt nicht so, dass wir zu cool sind, um auf die CPU zu schreiben, also schreiben wir alles auf der GPU neu. Die Verwendung einer GPU hat ein transparentes Ziel - die Beschleunigung.

Alexei Kudryavtsev: Die GPU verarbeitet ähnliche Vorgänge gut parallel. Haben Sie genau solche Operationen und schaffen es daher, einen solchen Erfolg zu erzielen?

Andrey Volodin: Ja, die Hauptschwierigkeit besteht nicht darin, zu codieren, sondern solche Algorithmen zu erstellen, die gut auf die GPU übertragen werden. Dies ist nicht immer trivial. Es kommt vor, dass Sie herausgefunden haben, wie man alles cool macht, aber dafür benötigen Sie zu viele Synchronisationspunkte. Zum Beispiel schreiben Sie alles in eine Eigenschaft, und dies ist ein klares Zeichen dafür, dass es schlecht parallel ist. Wenn Sie viel an einer Stelle schreiben, müssen alle Threads dafür synchronisiert werden. Unsere Aufgabe ist es, die Algorithmen so zu approximieren, dass sie gut parallel sind.

Alexei Kudryavtsev: Für mich als Entwickler von Mobilgeräten klingt das nach Raketenwissenschaft.

Andrey Volodin: Eigentlich ist es nicht so schwierig. Raketenwissenschaft ist für mich VIPER.

Dritter Chip


Daniil Popov: Es scheint, dass sie auf der letzten Google I / O-Konferenz ein Stück Eisen für TensorFlow und andere Dinge angekündigt haben. Wann wird der dritte Chip endlich in Mobiltelefonen, TPU oder wie heißt er, was wird auch die ganze ML-Magie auf dem Gerät bewirken?

Andrey Volodin: Wir haben genau das, es verbindet sich über USB und Sie können Neuronen von Google darauf steuern. Huawei hat dies bereits, wir haben sogar Software für ihre hexagonalen Beschleuniger geschrieben, damit Segmentierungsneuronen den P20 schnell verfolgen würden.

Ich muss sagen, dass sie im iPhone tatsächlich schon existieren. Im neuesten iPhone XS gibt es beispielsweise einen Coprozessor namens NPU (Neural Processing Unit), auf den bisher nur Apple Zugriff hat. Dieser Coprozessor schneidet bereits die GPU im iPhone. Einige Core ML-Modelle verwenden NPUs und sind daher schneller als Bare Metal.

Dies ist insofern von Bedeutung, als Core ML zusätzlich zu den Neuronen mit der niedrigsten Inferenz viele zusätzliche Maßnahmen erfordert. Zuerst müssen Sie die Eingabedaten in das Core ML-Format konvertieren, sie werden verarbeitet und dann in ihrem Format zurückgegeben. Sie müssen sie zurückkonvertieren und erst dann dem Benutzer anzeigen. Das alles dauert einige Zeit. Wir schreiben Overhead-freie Pipelines, die von Anfang bis Ende auf der GPU funktionieren, während Core ML-Modelle gerade aufgrund dieses Hardwareprozesses schneller sind.

Höchstwahrscheinlich werden sie auf der WWDC im Juni einen Rahmen für die Zusammenarbeit mit der NPU zeigen.

Das heißt, wie Sie sagten, gibt es bereits Geräte, nur Entwickler können sie noch nicht vollständig nutzen. Meine Hypothese ist, dass Unternehmen selbst noch nicht verstehen, wie dies in Form eines Frameworks sorgfältig zu tun ist. Oder sie wollen einfach nicht verschenken, um einen Marktvorteil zu haben.

Alexei Kudryavtsev: Mit dem Fingerabdruckscanner war das gleiche im IPhone, wie ich mich erinnere.

Andrey Volodin: Er ist auch jetzt noch nicht so erschwinglich. Sie können es auf höchster Ebene verwenden, aber Sie können den Ausdruck selbst nicht erhalten. Sie können Apple einfach bitten, den Benutzer die Verwendung zulassen. Es ist immer noch nicht der volle Zugriff auf den Scanner selbst.

Sechskantbeschleuniger


Daniil Popov: Sie haben den Begriff Sechskantbeschleuniger erwähnt. Ich denke nicht jeder weiß was es ist.

Andrey Volodin: Dies ist nur ein Teil der Hardwarearchitektur, die Huawei verwendet. Ich muss sagen, sie ist ziemlich raffiniert. Nur wenige Leute wissen, aber in einigen Huawei sind diese Prozessoren, werden aber nicht verwendet, weil sie einen Hardware-Fehler haben. Huawei hat sie freigegeben und dann ein Problem gefunden, jetzt sind in einigen Handys spezielle Chips Eigengewicht. In frischen Versionen funktioniert schon alles.

Bei der Programmierung gibt es das SIMD-Paradigma (Single Instruction, Multiple Data), bei dem dieselben Befehle parallel für verschiedene Daten ausgeführt werden. Der Chip ist so konzipiert, dass er einige Operationen gleichzeitig in mehreren Datenströmen verarbeiten kann. Sechseckig bedeutet insbesondere, dass auf 6 Elementen parallel.

Alexei Kudryavtsev: Ich dachte, dass die GPU einfach so funktioniert: Sie vektorisiert eine Aufgabe und führt dieselbe Operation für verschiedene Daten aus. Was ist der Unterschied?

Andrey Volodin : GPU ist allgemeiner Zweck. Trotz der Tatsache, dass die Programmierung für die GPU eher niedrig ist, ist sie in Bezug auf die Arbeit mit Coprozessoren ziemlich hoch. Für die Programmierung auf der GPU wird eine C-ähnliche Sprache verwendet. Unter iOS wird der Code trotzdem mit LLVM in Maschinenanweisungen kompiliert. Und diese Dinge für Coprozessoren werden meistens direkt Hardcore geschrieben - im Assembler auf Maschinenanweisungen. Daher ist dort die Produktivitätssteigerung viel deutlicher, da sie für bestimmte Vorgänge geschärft werden. Sie können sich überhaupt nicht auf sie verlassen, aber Sie können nur das zählen, wofür sie ursprünglich bestimmt waren.

Alexei Kudryavtsev: Und warum werden sie normalerweise entworfen?

Andrey Volodin: Jetzt hauptsächlich für die häufigsten Operationen in neuronalen Netzen: Faltung - Faltung oder irgendeine Art von Zwischenaktivierung. Sie verfügen über vorverdrahtete Funktionen, die superschnell funktionieren. Sie sind also bei einigen Aufgaben viel schneller als die GPU, aber im Übrigen sind sie einfach nicht anwendbar.

Alexei Kudryavtsev: Es sieht aus wie DSP-Prozessoren, die früher für Audio verwendet wurden, und alle Plugins und Effekte haben sehr schnell daran gearbeitet. Es wurde spezielle teure Hardware verkauft, aber dann sind die Prozessoren aufgewachsen, und jetzt zeichnen wir Podcasts direkt auf Laptops auf und verarbeiten sie.

Andrey Volodin: Ja, ungefähr gleich.

GPU nicht nur für Grafiken


Daniil Popov: Ich verstehe richtig, dass Sie jetzt auf der GPU Daten verarbeiten können, die nicht direkt mit Grafiken zusammenhängen? Es stellt sich heraus, dass die GPU ihren ursprünglichen Zweck verliert.

Andrey Volodin: Genau. Ich spreche oft auf Konferenzen darüber. Die ersten waren NVidia, die CUDA einführten. Dies ist eine Technologie, die GPGPU (General-Purpose Computing auf Grafikprozessoren) einfacher macht. Sie können eine Obermenge von C ++ - Algorithmen darauf schreiben, die auf der GPU parallelisiert sind.

Aber die Leute haben das schon einmal gemacht. Zum Beispiel haben Handwerker auf OpenGL oder sogar auf älterem DirectX einfach Daten in die Textur geschrieben - jedes Pixel wurde als Daten interpretiert: die ersten 4 Bytes im ersten Pixel, die zweiten 4 Bytes im zweiten. Sie verarbeiteten die Texturen, dann wurden die Daten aus der Textur extrahiert und interpretiert. Es war sehr krückenhaft und kompliziert. Jetzt unterstützen Grafikkarten die Allzwecklogik. Sie können jeden Puffer in die GPU einspeisen, Ihre Strukturen beschreiben, sogar die Hierarchie der Strukturen, in denen sie aufeinander verweisen, etwas berechnen und an den Prozessor zurückgeben.

Daniil Popov: Das heißt, wir können sagen, dass die GPU jetzt Data PU ist.

Andrey Volodin: Ja, Grafiken auf der GPU werden manchmal weniger verarbeitet als allgemeine Berechnungen.

Alexei Kudryavtsev: Die Architektur der CPU und der GPU unterscheidet sich im Wesentlichen, aber Sie können sie sowohl dort als auch dort berücksichtigen.

Andrey Volodin : In gewisser Weise ist die CPU schneller, in gewisser Weise die GPU. Dies bedeutet nicht, dass die GPU immer schneller ist.

Daniil Popov: Soweit ich mich erinnere, kann es auf der CPU viel schneller gehen, wenn die Aufgabe darin besteht, etwas ganz anderes zu berechnen.

Andrey Volodin: Das hängt auch von der Datenmenge ab. Das Übertragen von Daten von der CPU zur GPU und umgekehrt ist immer mit einem Mehraufwand verbunden. Wenn Sie beispielsweise eine Million Elemente berücksichtigen, ist die Verwendung einer GPU normalerweise gerechtfertigt. Das Zählen von tausend Elementen auf einer CPU kann jedoch schneller sein als nur das Kopieren auf eine Grafikkarte. Daher müssen Sie immer die Aufgabe auswählen.

Core ML macht es übrigens. Laut Apple kann Core ML zur Laufzeit auswählen, wo die Berechnung schneller ist: auf dem Prozessor oder auf der Grafikkarte. Ich weiß nicht, ob dies in der Realität funktioniert, aber sie sagen ja.

Hardcore GPU Engineer Wissen für einen mobilen Entwickler


Alexey Kudryavtsev: Kommen wir zurück zur mobilen Entwicklung. Sie sind ein GPU-Ingenieur, Sie haben jede Menge Hardcore-Wissen. Wie kann dieses Wissen auf einen mobilen Entwickler angewendet werden? Was sehen Sie beispielsweise in UIKit, was andere nicht sehen?

Andrey Volodin: Ich werde auf der AppsConf ausführlich darüber sprechen. Sie können viel wo anwenden. Wenn ich zum Beispiel sehe, wie die UIKit-API funktioniert, kann ich sofort verstehen, warum dies getan wird und warum. Wenn ich den Leistungsabfall beim Rendern einiger Ansichten beobachte, kann ich den Grund verstehen, da ich weiß, wie das Rendern darin geschrieben ist. Ich verstehe: Um die Effekte anzuzeigen, die die Gaußsche Unschärfe tatsächlich über dem Bildpuffer ausführt, müssen Sie zuerst die gesamte Textur zwischenspeichern, eine starke Unschärfeoperation darauf anwenden, das Ergebnis zurückgeben, den Rest der Ansichten fertig rendern und sie erst dann auf dem Bildschirm anzeigen. All dies muss in 1/60 Sekunde passen, sonst wird es langsamer.

Mir ist absolut klar, warum dies eine lange Zeit ist, aber für meine Kollegen ist dies nicht klar. Aus diesem Grund möchte ich die Design-Tricks, die wir häufig in GameDev verwenden, und meine Erkenntnisse darüber, wie ich Probleme betrachte und versuche, sie zu lösen, teilen. Es wird ein Experiment sein, aber ich denke, es sollte interessant sein.

Warum Android keine native Unschärfe hat


Daniil Popov: Sie haben die Unschärfe erwähnt, und ich hatte eine Frage, die meiner Meinung nach alle Android-Entwickler beunruhigt: Warum gibt es in iOS und nicht in Android ein natives Blau?

Andrei Volodin: Ich denke, das liegt an der Architektur. Apple-Plattformen verwenden die Rendering-Architektur von Tiled Shading. Bei diesem Ansatz wird nicht der gesamte Rahmen gerendert, sondern kleine Kacheln - Quadrate, Teile des Bildschirms. Auf diese Weise können Sie den Betrieb des Algorithmus optimieren, da der Hauptleistungsgewinn bei Verwendung der GPU eine effiziente Nutzung des Caches ermöglicht. Unter iOS wird der Frame häufig so gerendert, dass er überhaupt keinen Speicherplatz beansprucht. Auf dem iPhone 7 Plus beträgt die Auflösung beispielsweise 1920 * 1080, was ungefähr 2 Millionen Pixel entspricht. Wir multiplizieren mit 4 Bytes pro Kanal, es ergeben sich ungefähr 20 Megabyte pro Frame. 20 MB zum einfachen Speichern des Systemrahmenpuffers.

Mit dem Tiled Shading-Ansatz können Sie diesen Puffer in kleine Teile zerlegen und ein wenig rendern. Dies erhöht die Anzahl der Cache-Zugriffe erheblich, da Sie zum Verwischen die bereits gezeichneten Pixel lesen und die Gaußsche Verteilung darauf berechnen müssen. Wenn Sie den gesamten Frame lesen, ist die Cache-Rate sehr niedrig, da jeder Stream unterschiedliche Stellen liest. Wenn Sie jedoch kleine Stücke lesen, ist die Cache-Rate sehr hoch und die Produktivität ebenfalls hoch.

Es scheint mir, dass das Fehlen nativer Unschärfe in Android mit architektonischen Merkmalen zusammenhängt. Vielleicht ist dies jedoch eine Produktlösung.

Daniil Popov: In Android gibt es dafür RenderScript, aber dort müssen Sie mit Ihren Händen mischen, zeichnen und einbetten. Dies ist viel komplizierter als das Aktivieren eines Kontrollkästchens in iOS.

Andrey Volodin: Höchstwahrscheinlich ist auch die Leistung geringer.

Daniil Popov: Ja, um Designer Wishlist zufrieden zu stellen, müssen wir das Bild verkleinern, bläuen und dann zurückskalieren, um es irgendwie zu speichern.

Andrey Volodin: Übrigens können Sie damit verschiedene Tricks machen. Die Gaußsche Verteilung ist ein unscharfer Kreis. Das Gauß-Sigma hängt von der Anzahl der Pixel ab, die sie sammeln sollen. Als Optimierung können Sie häufig ein Bild verkleinern und das Sigma leicht einschränken. Wenn Sie den ursprünglichen Maßstab zurückgeben, gibt es keinen Unterschied, da Sigma direkt von der Größe des Bildes abhängt. Wir verwenden diesen Trick oft im Inneren, um die Unschärfe zu beschleunigen.

Daniil Popov: Mit RenderScript in Android können Sie jedoch keinen Radius größer als 30 festlegen.

Andrey Volodin: Eigentlich ist ein Radius von 30 viel. Wiederum verstehe ich, dass das Sammeln von 30 Pixeln mit einer GPU in jedem Thread sehr teuer ist.

Was sind ähnliche mobile Entwicklung und GameDev


Alexei Kudryavtsev: In den Thesen zu Ihrem Bericht sagen Sie, dass Mobile Development und GameDev viel gemeinsam haben. Sag mir ein wenig, was genau?

Andrey Volodin: Die Architektur von UIKit erinnert sehr an Spiel-Engines und die alten. Moderne sind in Richtung des Entity Component Systems gegangen, und dies wird auch im Bericht enthalten sein. Dies gilt auch für UIKit. Es gibt Artikel, in denen beschrieben wird, wie Sie Ansichten zu Komponenten entwerfen können. GameDev, Component System Thief 98 .

, , Cocos2d, , , , . , Scene graph — , -, , iOS CGAffineTransform. 4*4, , . .

, UIKit . - — . : GameDev , UIKit setNeedsLayout, layoutIfNeeded.

— , - , , Apple. AppsConf .

: , API Cocos2d iOS ( UI). , ?

: , - . Cocos2d 2008-2009 , UIKit UIKit, . , - , , .

, : core- Cocos2d Apple, Apple Cocos2d, . SpriteKit , Cocos2d. Apple .

: , , UIKit 2009, MacOS, . setNeedsLayout, layoutIfNeeded , .

: , GameDev , MacOS.

: !

: Cocos2d Apple, , GameDev. GameDev , — . , GameDev , , . , , .

: , - , — .

: , , , , — . Protocol-Oriented Programming Swift, , - . GameDev .

: : , . , , , .

GameDev


: : GameDev , GameDev ?

: , , . « , ». , . : , , .

GameDev- . : 30 60 , , , . , . — . -- 1/60 1/30 . , , , GPU , CPU . , .

: ?

: . - , , , . — . , , , — - , - , . , , .

. , GPU float, double, - . , , , . CPU , , , GPU .

, , — .

GameDev,


: , « GameDev, ». , , . , GameDev — . , . GameDev.

: , enterprise- , GameDev . . , , GameDev, .

, . , 4*4. CGAffineTransform — , - , .

, , , , .


: ? , UIKit, , ? , , , . , ?

: — pet project.

, : GPU , . iOS GPU , . iOS , - NVidia AMD- . . API , , .

: API, , Cocos2d Unity, — - . , , , UIKit ?

: Cocos2d — Open Source . , , , , . objective-C, .

pet project, , , API, , , -. , API, VHS-. , GPU. , . , . , : « saturation Instagram, lightroom!» , , 4 — .

, .

— , , . , , - , , , .

: , - . , Cocos2d - — 5 , , , , . , , , ..

: . , . , , , , , , , , , .

: , . , , .

: . , , . , Apple, ARKit. , , . , , , , .

, , : «, IDE, , , , . ».

: — ?

: , , , .

: , , .

: , , , VR . Project Template Xcode, , , - . , .

: .


: - , GameDev GPU.

: . - , , , . , , , , , UI: , , runtime Objective-C — , , . . , : , — , X Y, !

, , - , GameDev GPU- — .

, . AppsConf 22 23 .

Source: https://habr.com/ru/post/de448222/


All Articles