いずれにせよ、Prismaモバイル開発部長のAndrei Volodinはそう述べています。 また、GameDevからモバイル開発へのアイデアの流れ、パラダイムの違い、Androidにネイティブブラーがない理由など、AppsCastの生産的なリリースがリリースされました。 カットの下で、ネタバレなしのAppsConfに関するAndreyのレポートについてお話します。
AppsCastは、AppsConfモバイル開発者会議専用のポッドキャストです。 各号は新しいゲストです。 各ゲストは会議のスピーカーであり、私たちは彼のレポートについて議論し、それに関連するトピックについて話します。 AppsConfプログラム委員会のメンバーであるAlexei KudryavtsevとDaniil Popovがポッドキャストをリードしています。
Alexey Kudryavtsev：みなさん、こんにちは！ アンドレイ、あなたの経験を教えてください。
Andrey Volodin ：Prismaでは、主に写真とビデオの処理に関連する製品を開発しています。 私たちの主力アプリはPrismaです。 現在、Facetuneのような機能のための別のLensaアプリケーションを作成しています。
私はモバイル開発をリードしていますが、私はゲームのコーチです。 私はコア部分全体を持っており、これらすべてのアプリケーション用のGPUパイプラインを作成しています。 R＆Dチームが開発したアルゴリズムとニューロンがモバイルデバイスで実行され、リアルタイムで動作するように、コアフレームワークを開発しています。 要するに、サーバーコンピューティングなどをすべて殺すことです。
Alexei Kudryavtsev：通常のiOS開発のようには聞こえません。
Andrey Volodin：はい、私はそのような特異性を持っています-私は毎日Swiftで書いていますが、同時にiOS開発と見なされるものからはほど遠いです。
Daniil Popov： GPUパイプラインについて言及しましたが、それは何ですか？
Andrey Volodin：写真エディターを作成するとき、アプリケーションにはさまざまなツールがあるため、アーキテクチャを構成し、ロジックを分解する必要もあります。 たとえば、Lensaには、ニューロンを使用して背景をぼかすボケツールがあり、人をより美しくするレタッチツールがあります。 これはすべて、GPU上でより効率的に動作する必要があります。 さらに、毎回プロセッサとビデオカード間でデータを転送するのではなく、一連の操作を事前に構築し、1回の実行で実行し、ユーザーに最終結果を表示することをお勧めします。
GPUパイプラインは「小さな塊」であり、そこからビデオカードの命令が集められます。 その後、彼女はこれらすべてを非常に迅速かつ効率的に実行し、各楽器の後ではなく、一度に結果を取得します。 GPUパイプラインが可能な限り高速で効率的で、一般的に存在することを確認します。
アレクセイ・クドリャフツェフ：どうしてこれに来たのですか？ 通常のiOS開発者は、リベットと金型から始め、APIを使用してどこかに行き、満足しています。 まったく違うことをしているのはどうしてですか？
Andrey Volodin：ほとんどの場合、これは偶然です。 仕事に就く前に、iOS用のゲームを作りました。 それは私にとって常に興味深いことでしたが、ロシアではこの方向に発展する場所は特にないことを理解しました。 偶然にも、Prismaと出会いました。 彼らは、Swiftで記述できると同時に、GPU、特に当時出てきたばかりのMetalを知っているiOS開発者を必要としていました。
私は欠員に対応し、相乗効果がありました。3年目は、このことにさらに深く関わっています。 何か問題が発生した場合、これらのViperおよびMVVMのすべてに既に含まれています-どのように解読されるかさえわかりません-最初から理解する必要があります。
GPUエンジニアは何をしますか
Daniil Popov： AppsConf プロファイルはエンジニアGPUを言っています。 エンジニアGPUはコーヒーを飲む以外にほとんど何をしますか？
Andrey Volodin：ここで、プロセッサとGPUの根本的な違いについて言及する必要があります。 プロセッサは、シーケンシャルに操作を実行します。 私たちが持っているマルチスレッドでさえ、しばしば偽物です：プロセッサは停止し、異なるタスクの小さな断片を作成するために切り替わり、いくつかのスライスでそれらを実行します。 GPUはまったく逆の方法で動作します。 実際に並列に動作するn個のプロセッサがあり、プロセス間の並列性とGPU内の並列性があります。
私の主な仕事は、メモリの最適化やコードの再利用の整理などのありふれたものに加えて、CPU向けに記述されたアルゴリズムをビデオカードに移植して、並列化することです。 命令のシーケンシャル実行に完全に関連付けられている非常に効率的なアルゴリズムがあるため、これは必ずしも些細な作業ではありません。 私の仕事は、たとえば、おそらくまったく同じではないが、視覚的に結果を区別できないようなアルゴリズムの近似を考え出すことです。 そのため、100倍の加速を得ることができますが、品質は少し犠牲になります。
また、ニューロンを移植しています。 ところで、私たちはまもなくメジャーなオープンソースリリースを行います。 Core MLが登場する前から、独自のカウンターMLがあり、最終的に成熟してオープンソースになりました。 そのパラダイムはCore MLとは少し異なります。 私も含めて、中核部分を開発しています。
一般的に、私はコンピュータービジョンアルゴリズムとコンピューティングを中心にあらゆることを行います。
Alexey Kudryavtsev：興味深い発表です。
Andrey Volodin：これは秘密ではありません。私たちは何らかのファンファーレでそれを発表しません。Prisma内で使用されるフレームワークの例を見ることができるだけです。
GPU向けに最適化する理由
Alexei Kudryavtsev：教えてください、なぜ一般的なGPUのアルゴリズムを最適化するのですか？ プロセッサにコアを追加するか、アルゴリズムを最適化するだけで十分のように思われるかもしれません。 まさにGPUなのはなぜですか？
Andrey Volodin： GPUでの作業は、アルゴリズムを非常に高速化できます。 たとえば、Samsung S10中央処理装置では30秒間、GPUでは1フレーム、つまり1/60秒間実行されるニューロンがあります。 これは信じられないほど変化するユーザーエクスペリエンスです。 永遠の読み込み画面はありません。ビデオストリームで動作しているアルゴリズムの結果を確認したり、スライダーをひねって効果を確認したりできます。
CPUで書くにはあまりにもクールだというわけではないので、GPUですべてを書き換えます。 GPUを使用することには、物事を高速化するという透明な目標があります。
Alexei Kudryavtsev： GPUは互いに類似した操作を並行してうまく処理します。 あなたはそのようなオペレーションを持っているので、そのような成功を達成することができますか？
Andrey Volodin：はい、主な難しさはコーディングすることではなく、GPUにうまく転送されるようなアルゴリズムを作成することです。 これは必ずしも些細なことではありません。 クールなことをすべて行う方法を考え出したことがありますが、このために必要な同期ポイントが多すぎます。 たとえば、すべてを1つのプロパティに記述します。これは、並列性が不十分であることを明確に示しています。 1か所で大量に記述する場合、すべてのスレッドはこのために同期する必要があります。 私たちの仕事は、アルゴリズムを近似して、それらがうまく並列するようにすることです。
Alexei Kudryavtsev：私にとって、モバイル開発者としては、ロケット科学のように聞こえます。
Andrey Volodin：実際、それほど難しくはありません。 私にとって、ロケット科学は重要です。
サードチップ
Daniil Popov：前回のGoogle I / Oカンファレンスで、TensorFlowなどの鉄を発表したようです。 3番目のチップが最終的に携帯電話、TPUに登場するのはいつですか、それはデバイスのMLマジックをすべて実行しますか？
Andrey Volodin：私たちはまさにこれを持っています。USB経由で接続し、Googleからニューロンを駆動できます。 Huaweiにはすでにこれがあります。セグメンテーションニューロンがP20をすばやく追跡できるように、六角形のアクセラレータ用のソフトウェアも作成しました。
iPhoneには実際にすでに存在していると言わなければなりません。 たとえば、最新のiPhone XSにはNPU（Neural Processing Unit）と呼ばれるコプロセッサーがありますが、これまでのところAppleだけがそれにアクセスできます。 このコプロセッサはすでにiPhoneのGPUを削減しています。 一部のCore MLモデルはNPUを使用するため、ベアメタルよりも高速です。
最下位の推論ニューロンに加えて、Core MLには多くの追加アクションが必要であるため、これは重要です。 最初に入力データをCore ML形式に変換する必要があります。それを処理してから、その形式で返します。変換し直してから、ユーザーに表示する必要があります。 これにはすべてかなり時間がかかります。 GPUで最初から最後まで機能するオーバーヘッドのないパイプラインを記述しますが、Core MLモデルはこのハードウェアプロセスにより正確に高速になります。
最も可能性が高いのは、6月のWWDCで、NPUと連携するためのフレームワークを示すことです。
つまり、あなたが言ったように、既にデバイスがあり、開発者だけがまだそれらを完全に使用することはできません。 私の仮説は、企業自身がフレームワークの形でこれを慎重に行う方法をまだ理解していないということです。 または、彼らは市場の優位性を得るためにただ配りたくありません。
Alexei Kudryavtsev：指紋スキャナーでは、私が覚えている限り、同じことがiPhoneにもありました。
アンドレイ・ヴォロディン：彼は今でもそれほど手頃な価格ではありません。 トップレベルで使用できますが、印刷自体を取得することはできません。 ユーザーに使用を許可するようAppleに依頼するだけです。 スキャナー自体への完全なアクセスではありません。
六角形の加速器
ダニエル・ポポフ：六角形の加速器という用語について言及しました。 誰もがそれが何であるかを知っているとは思いません。
Andrey Volodin：これは、Huaweiが使用しているハードウェアアーキテクチャのほんの一部です。 彼女はかなり洗練されています。 知っている人はほとんどいませんが、一部のHuaweiではこれらのプロセッサーは使用されていませんが、ハードウェアのバグがあるため使用されていません。 Huaweiはそれらをリリースし、問題を発見しました。現在、一部の携帯電話では特殊なチップが重くなっています。 新しいバージョンでは、すべてがすでに機能しています。
プログラミングでは、同じ命令が異なるデータで並列に実行される場合、SIMD（単一命令、複数データ）パラダイムがあります。 このチップは、複数のデータストリームで同時にいくつかの操作を処理できるように設計されています。 特に、六角形とは、6個の要素が平行であることを意味します。
Alexei Kudryavtsev： GPUはまさにそのように動作すると考えました。タスクをベクトル化し、異なるデータに対して同じ操作を実行します。 違いは何ですか？
Andrey Volodin ：GPUはより一般的な目的です。 GPUのプログラミングはかなり低レベルであるという事実にもかかわらず、コプロセッサーでの作業に関してはかなり高レベルです。 GPUでのプログラミングには、Cライクな言語が使用されます。 iOSでは、コードはLLVMでマシン命令にコンパイルされます。 また、コプロセッサー向けのこれらのことは、ほとんどの場合、ハードコアで直接記述されます-アセンブラー、マシン命令で。 したがって、特定の操作に対して生産性が向上するため、生産性の向上はより顕著になります。 それらをまったく当てにすることはできませんが、最初に意図したものだけを数えることができます。
アレクセイ・クドリャフツェフ：そして、なぜ彼らは通常設計されているのですか？
Andrey Volodin：現在、主にニューラルネットワークで最も一般的な操作のために：畳み込み-畳み込みまたは何らかの中間活性化。 彼らは超高速で動作する事前に配線された機能を持っています。 したがって、一部のタスクではGPUよりもはるかに高速ですが、それ以外のすべてでは単に適用できません。
Alexei Kudryavtsev： DSPプロセッサのように見えますが、以前はオーディオに使用されていましたが、すべてのプラグインとエフェクトが非常に迅速に機能していました。 特別な高価なハードウェアが販売されましたが、その後プロセッサが成長し、現在ではラップトップで直接ポッドキャストを記録および処理しています。
アンドレイ・ヴォロディン：はい、ほぼ同じです。
グラフィックスだけでなくGPU
Daniil Popov： GPUで、グラフィックスに直接関係のないデータを処理できるようになったことを正しく理解していますか？ GPUの本来の目的が失われていることがわかります。
アンドレイ・ヴォロディン：そのとおり 。 私はよく会議でこれについて話します。 最初はCUDAを導入したNVidiaでした。 これは、GPGPU（グラフィック処理装置での汎用コンピューティング）をよりシンプルにするテクノロジーです。 GPUで並列化されたC ++アルゴリズムのスーパーセットを作成できます。
しかし、人々はこれを以前にやったことがあります。 たとえば、OpenGLまたはさらに古いDirectXの職人は、単にデータをテクスチャに書き込みました。各ピクセルはデータとして解釈されました。最初のピクセルの最初の4バイト、2番目の2番目の4バイト。 彼らはテクスチャを処理し、テクスチャからデータを抽出して解釈しました。 それは非常に松葉杖で複雑でした。 現在、ビデオカードは汎用ロジックをサポートしています。 GPUの任意のバッファにフィードし、構造を記述し、構造が相互に参照する構造の階層を含めて、何かを計算し、それをプロセッサに返すことができます。
Daniil Popov：つまり、GPUは現在Data PUであると言えます。
Andrey Volodin：はい、GPU上のグラフィックスは一般的な計算よりも処理が少ない場合があります。
Alexei Kudryavtsev： CPUとGPU のアーキテクチャは本質的に異なりますが、 あちらこちらで検討できます。
Andrey Volodin ：確かに、いくつかの点でCPUは高速で、いくつかの点ではGPUが高速です。 これは、GPUが常に高速であると言うことではありません。
Daniil Popov：私が覚えている限りでは、タスクが非常に異なるものを計算することである場合、CPU上でははるかに高速になります。
Andrey Volodin：データ量にも依存します。 CPUからGPUへ、またはその逆にデータを転送するオーバーヘッドが常にあります。 たとえば、100万個の要素を考慮する場合、GPUを使用することは通常正当化されます。 しかし、CPU上の1000個の要素を数えることは、それらをグラフィックカードにコピーするよりも高速です。 したがって、常にタスクを選択する必要があります。
ちなみに、Core MLはそれを行います。 Appleによると、Core MLは、プロセッサまたはビデオカードのどちらでより高速に計算するかを選択するために実行できます。 これが実際に機能するかどうかはわかりませんが、彼らは「はい」と言います。
モバイル開発者向けのハードコアGPUエンジニアの知識
アレクセイ・クドリャフツェフ：モバイル開発に戻りましょう。 あなたはGPUエンジニアであり、筋金入りの知識が豊富にあります。 この知識をモバイル開発者にどのように適用できますか？ たとえば、他の人には見られないUIKitでは何が見えますか？
Andrey Volodin：これについては、AppsConfで詳しく説明します。 どこでもたくさん適用できます。 たとえば、UIKit APIがどのように機能するかを見ると、なぜこれが行われたのか、そしてなぜなのかをすぐに理解できます。 いくつかのビューをレンダリングするときにパフォーマンスが低下するのを見ると、レンダリングが内部にどのように記述されているかを知っているため、その理由を理解できます。 私は理解しています：ガウスぼかしが実際にフレームバッファの上に行う効果を表示するには、最初にテクスチャ全体をキャッシュし、それに重いぼかし操作を適用し、結果を返し、残りのビューのレンダリングを終了してから、画面に表示する必要があります。 これはすべて1/60秒に収まる必要があります。そうしないと、速度が低下します。
なぜこれが長いのかは私には明らかですが、同僚にとってはこれは明らかではありません。 だから、GameDevでよく使用するデザイントリックと、問題をどのように見て解決するかについての洞察を共有したいと思います。 それは実験になりますが、面白いと思います。
Androidにネイティブブラーがない理由
Daniil Popov：あなたはぼかしについて言及しました、そして、私はすべてのAndroid開発者を心配していると思う質問がありました：なぜAndroidではなくiOSにネイティブブルーがありますか。
Andrey Volodin：これは建築のせいだと思います。 Appleプラットフォームは、タイルシェーディングレンダリングアーキテクチャを使用します。 このアプローチでは、フレーム全体ではなく、小さなタイル（正方形、画面の一部）がレンダリングされます。 これにより、GPUを使用する際の主なパフォーマンスの向上によりキャッシュが効率的に使用されるため、アルゴリズムの動作を最適化できます。 iOSでは、多くの場合、フレームはメモリをまったく占有しない方法でレンダリングされます。 たとえば、iPhone 7 Plusでは、解像度は1920 * 1080で、約200万ピクセルです。 チャネルごとに4バイトを掛けると、フレームごとに約20メガバイトになります。 システムのフレームバッファを単純に保存するための20 MB。
タイルシェーディングアプローチでは、このバッファーを小さな断片に分割し、少しレンダリングすることができます。 これにより、キャッシュアクセスの回数が大幅に増加します。なぜなら、ぼかしを行うには、すでに描画されているピクセルを読み取り、それらのガウス分布を計算する必要があるからです。 フレーム全体を読み取る場合、各ストリームは異なる場所を読み取るため、キャッシュレートは非常に低くなります。 しかし、小さな断片を読むと、キャッシュレートが非常に高くなり、パフォーマンスも高くなります。
Androidのネイティブブラーの欠如は、アーキテクチャの機能に関係しているように思えます。 ただし、これは製品ソリューションかもしれません。
Daniil Popov： AndroidにはこのためのRenderScriptがありますが、手でミックス、描画、パッドする必要があります。 これは、iOSで1つのチェックボックスを設定するよりもはるかに複雑です。
Andrey Volodin：ほとんどの場合、パフォーマンスも低下しています。
Daniil Popov：はい、デザイナーのウィッシュリストを満足させるために、写真を縮小し、それを退屈させ、それからお金を節約するために元に戻す必要があります。
Andrey Volodin：ところで、これを使えば、さまざまなトリックを行うことができます。 ガウス分布はぼやけた円です。 ガウスシグマは、収集するピクセルの数に依存します。 多くの場合、最適化として、画像を縮小してシグマをわずかに狭めることができます。元のスケールに戻すと、シグマは画像のサイズに直接依存するため、違いはありません。 内部でこのトリックを使用して、ぼかしを高速化します。
Daniil Popov：ただし、AndroidのRenderScriptでは、半径を30より大きくすることはできません。
アンドレイ・ヴォロディン：実際、半径30はたくさんあります。 繰り返しますが、各スレッドでGPUを使用して30ピクセルを収集するのは非常に費用がかかることを理解しています。
モバイル開発とGameDevの類似点は何ですか
Alexei Kudryavtsev：レポートの論文では、モバイル開発とGameDevには多くの共通点があると言います。 少し教えてください
Andrey Volodin： UIKit のアーキテクチャは、ゲームエンジンと古いエンジンを非常に連想させます。 最新のものはエンティティコンポーネントシステムに向かっており、これもレポートに含まれます。 これはUIKitにも当てはまります。コンポーネントのビューを設計する方法を書いている記事があります。 しかし、それはGameDevで発明されました。98年にコンポーネントシステムがゲームThiefで初めて使用されたときです。
基本的に、たとえば、私が長い間取り組んでいたCocos2dと、最初の実装で使用されたアイデアは非常に似ています。 シーングラフが使用されます。シーンツリーは、各ノードにサブノードがある場合、アフィン変換を累積することによってレンダリングされます。アフィン変換は、iOSで特にCGAffineTransformと呼ばれます。 これらは、座標系を変更するために乗算される4 * 4のマトリックスです。 どこでもアニメーションはほぼ同じように行われます。
ゲームエンジンとUIKitの両方で、すべてが時間補間に基づいて構築されています。 色やフレーム間の位置など、いくつかの値を補間するだけです。 最適化は同じです。GameDevでは、多くの作業を行わないのが一般的であるため、UIKitはsetNeedsLayout、layoutIfNeededを使用します。
私はこれらの類似点を常に自分自身のために描いています-私がかつてやったことと、Appleフレームワークで見たものとの間。 これについてはAppsConfで説明します。
Daniil Popov：実際、Cocos2d APIはiOS（UI用）に似ています。 開発者はお互いの仕事に触発されたと思いますか、それとも単に建築的にうまくいったと思いますか？
Andrey Volodin：彼らは何かに触発されたと思う。 Cocos2dは2008-2009年に登場しましたが、UIKitは現在知られているUIKitではありませんでした。 そこでは、いくつかのテクニックが特別に繰り返され、人々がより快適に作業できるようになりました。
最初はCocos2dコアチームがAppleのアイデアを少し借りてから、AppleがCocos2dをすべてのアーキテクチャソリューションに完全にコピーしました。 SpriteKitは、本質的にCocos2dに登場したすべてのアイデアの完全なコピーです。 この意味で、Appleは支持を取り戻しました。
Alexei Kudryavtsev： 2009年のUIKitと同じトリックは、古代から存在していたMacOSにまだあったようです。 同じsetNeedsLayout、layoutIfNeededがあり、アフィン変換があります。
Andrey Volodin：もちろん、GameDevはMacOSよりも長く存在します。
Alexey Kudryavtsev：議論することはできません！
Andrey Volodin：したがって、Cocos2dとAppleフレームワークを比較するのではなく、原則としてGameDevに由来するパラダイムを検討します。 GameDevで、人々は最初に継承が悪いことに気付きました。 全世界がOOPに熱狂したとき、GameDevはすでに継承が問題を引き起こしていると考え始め、コンポーネントを思い付きました。 業界としてのモバイル開発は、たった今これに来ました。
アレクセイ・クドリャフツェフ：アラン・ケイはずっと前に相続が悪いことに気付いたようです。
Andrey Volodin ：はい、しかし、全体として、数年前にみんながPLOはクールだと言っていたことを認めなければなりません。 そして今、Swiftにはプロトコル指向プログラミング、機能主義があり、誰もが新しい何かを思いつきます。 GameDevでは、これらの気分は長い間現れてきました。
アレクセイ・クドリャフツェフ：発言します：アラン・ケイはOOPを思いついた人です。 彼は、相続財産を発明したのではなく、メッセージを送るだけであり、一般的に誤解されていたと言いました。
モバイル開発とGameDevの違い
Alexei Kudryavtsev：違いについて教えてください：GameDevとモバイル開発は根本的にどのように異なり、GameDevのどれを使用できないのですか？
Andrey Volodin：基本的な違いは、製品開発が可能な限り怠zyであることです。 「尋ねられるまで、起きない」という原則に基づいてコードを記述しようとしています。 コールバックが機能するまで、何もしません。 製品開発のレンダリングでさえ怠zyです。フレーム全体が再描画されるのではなく、変更された部分のみが再描画されます。
この意味でのGameDev開発は容赦ありません。 すべてがフレームごとに行われます：シーン全体が1秒間に30または60回スクラッチから再描画され、各フレーム、各オブジェクトが更新され、各フレームが物理学によってシミュレートされます。 多くのことが起こり、これはパラダイムを大きく変えます。 あなたは1つのフレーム内で生活を始めます-私はこれにレポートの全体を捧げました。 1/60秒または1/30秒にすべてを合わせる必要があります。 そのため、GPUがフレームをレンダリングしている間に、CPUで次のものを準備しながら、考案し、予備計算の最大数、並列化を開始します。 そのため、ゲームのバッテリーは通常のアプリケーションよりもはるかに速く消耗します。
アレクセイ・クドリャフツェフ：そして、なぜゲームですべてをあまりにも怠doにできないのですか？
アンドレイ・ヴォロディン：ゲームの概念はあまり許しません。 たとえば、ダイナミクスがほとんどなく、一部のパーツのみが変更されるテトリスなど、一部のゲームは間違いなくこの恩恵を受けることができます。 しかし、全体的に、ゲームは非常に複雑なものです。 たとえば、キャラクターが立っているときでも、彼は揺れます-いくつかのアニメーションが発生し、いくつかのロジックがあり、物理学が誤って計算されています。 各フレームは非常に大きく変化するため、フラグメントを再利用することはほとんど不可能になるため、保存するとより多くの損害が生じる可能性があります。
さらに、固定された制限があります。 たとえば、GPUはdouble型よりもfloat型の方がうまく機能します。これは、精度がはるかに低いためです。 したがって、たとえば、画面の一部のみを再描画すると、顕著なアーチファクトが発生する場合があります。 CPUでは、すべてが倍精度でレンダリングされるため、精度は高く、美しいフォントときれいな曲線を使用できますが、GPUにはまだある程度の近似値があります。
これらの要因の組み合わせは、各フレームがすべてのオブジェクトを更新するために、重い計算を必要とするという事実につながります。
古典的な開発は、あなたが考えるよりもGameDevにずっと近いです。
Daniil Popov：あなたの将来のレポートから、「古典的な開発はあなたが思っているよりもGameDevにずっと近い」という挑発的な声明を議論したいと思います。 私はすぐに、ゲームの松葉杖に関する一連の記事を思い出しました。これらの記事は、時間がないときに開発をスピードアップするように設計されています。 これらの記事は、GameDevが最適化のために松葉杖の松葉杖であるという印象を与えます。 通常の開発では、今では誰もがアーキテクチャ、美しいコードに夢中になっています。 これをGameDevと関連付けることはできません。
Andrei Volodin：もちろん、企業はこれを行いませんが、インディーズGameDevではそれについてです。 しかし、特にこの論文は何か他のものについてです。 開発者はGameDevが使用する概念の多くを使用していることに気づきますが、それを理解することすらありません。
たとえば、アフィン変換。 これが4 * 4行列の単なる乗算であると明確に言うことはできません。 多くの場合、CGAffineTransformは不透明なデータ構造であり、その中に何かが格納されており、どのようにビューがスケーリングされるのかが明確ではありません。
レポートでは、私たちが毎日使用しているものの反対側を示すようにしますが、同時に、おそらく完全に理解していないかもしれません。
数学の利点について
Alexei Kudryavtsev：モバイル開発者はどうやってこの理解に到達できますか？ UIKitのレンダリングのフードの下にあるものを理解する方法、アフィン変換が内部にどのように配置され、再び怖がらないようにするか？ 私はこれが行列であることを理解していますが、どの具体的な数字が何に責任があるのか、私には言えません。 恐れたり理解したりしないように、どこで情報を入手できますか？
Andrey Volodin：最も明白なアドバイスは、ペットプロジェクトの作成を開始することです。
この点で言及する価値がある主なもの：モバイルGPU開発のすべての概念は、デスクトップ上の概念とまったく同じです。 iOS GPUプログラミングは、デスクトップ環境にあるものと根本的に違いはありません。 したがって、iOSのトピックに関する資料が不足している場合は、いつでもNVidiaまたはAMDソリューションの資料を読んで、それらに触発されます。 イデオロギー的に、それらはまったく同じです。 APIは少し異なりますが、通常、既存のプラクティスをデスクトッププログラミングからモバイルに移行する方法は明確です。
Alexei Kudryavtsev：たとえば、Cocos2dやUnityゲームエンジンなどのAPIを使用する場合、何も早く理解できません。いくつかのメソッドを取得するだけです。 UIKitに転送できるように、どのように理解し始め、どこを読むのが良いのかを見るのが良いでしょうか？
Andrey Volodin： Cocos2dはオープンソースプロジェクトであり、よく書かれています。 私はこれに手を携えていたので、あまり客観的ではありませんが、読んでインスピレーションを得ることができるかなり良いコードがあるように思えます。 あまり現代的ではない目的Cで書かれていますが、多くの困難な場所に関する詳細なコメントがあります。
しかし、ペットプロジェクトについて話すときは、ゲームを作るような高レベルのプロジェクトについて話すのではなく、たとえばグリッチエフェクトを作るAPIを書くことについて話します。 ご存知のように、VHSエフェクトを作成する一般的なAPIがあります。 そして、プロセッサ上ではなく、GPU上です。 これは、週末に実行できる比較的単純なタスクです。 しかし、一度も試したことがない場合はそれほど簡単ではありません。 初めてこれをやったとき、「これがInstagramやlightroomのプリセットでコントラストと彩度がどのように機能するかということです！」ということを学びました。
タワーのシンプルさをそのまま引き剥がします。
あなたは毎日それを使用し、当然のことと考えています-それは機能しますが、あなたは方法を理解していません。 それからあなたは自分でそれを始めます、そしてあなたはおそらくあなたがおそらく複雑なことをしているという事実から楽しいになりますが、実際にはそれがとても面白いほど面白いのは面白いです。
Daniil Popov：とにかく、何らかの数学的な基礎が必要なように思えます。 たとえば、Cocos2dでは、一部のシェーダーは文字通り5行のコードであり、座ってゲートの雄羊のように見ると、そこに何が書かれているのか理解できません。 おそらく、数学、基本概念などを知らなくても、シェーダーの言語に飛び込まないのはとても簡単です。
アンドレイ・ヴォロディン：数学に同意します。 線形代数の基本的な知識がなければ、難しいでしょう。最初にそれを理解する必要があります。 しかし同時に、大学で線形代数のコースを受講し、少なくとも大まかにスカラー積とその幾何学的意味、ベクトル積とその幾何学的意味、固有ベクトルとは何かを想像すると、通常、行列、行列乗算のしくみ、それを理解するのは非常に簡単です。
Daniil Popov：多くの場合、コンピューター専攻の学生は、物理学と数学は必要ないことを嘆きます。 おそらく、今では多くの人が行列乗算の仕組みをほとんど覚えていないでしょう。
アンドレイ・ヴォロディン：私にとってこれは痛い問題です。 私は同じで、慢に苦しみました。なぜ機能分析などが必要なのですか。 しかし、ARKitチームでAppleにインタビューしたとき、私には貴重な人生経験があります。 インタビューには膨大な数の数学があり、後でペアになったことに感謝しました。 大学で受けたバックグラウンドがなければ、これらの質問に答えることは決してなかったでしょうし、それがどのように機能するかも理解できなかったでしょう。
今、私自身が大学で教えているとき、または公開日に到着しているとき、私はいつも次のように言います。「友達、あなたはIDEに座る十分な時間があるでしょう。 機械学習の時代には、これは間違いなく重宝します。」
ダニエル・ポポフ：最も重要なことは、インタビューが終わったということですか？
アンドレイ・ヴォロディン：はい、もちろん、そしてそれは私が数学的な背景を持っていたからです。
アレクセイ・クドリャフツェフ：なぜマタンを学ぶべきか、そしてその後どこで手に入れることができるかがわかった。
Andrei Volodin：たとえば、アフィン変換を理解し、正常なものを知ることなくして、VRの世界に行くことはできません。 Xcodeでプロジェクトテンプレートを作成する場合でも、すべてがそこで乗算され、ベクター作品があり、何かが転置されます。 , .
: .
: - , GameDev GPU.
: . - , , , . , , , , , UI: , , runtime Objective-C — , , . . , : , — , X Y, !
, , - , GameDev GPU- — .
幼少期にコンピューターゲームを作ることも夢見ていたら、始めましょう。4月 22日と23日にモスクワのInfospaceで開催されるモバイルデベロッパーAppsConfの会議で、Andrei Volodinの話を聞いてください。