Todas estas palabras están mucho más relacionadas con el desarrollo móvil de lo que parece a primera vista: los aceleradores hexagonales ya están ayudando a entrenar redes neuronales en dispositivos móviles; álgebra y matan son útiles para conseguir un trabajo en Apple; y la programación de GPU no solo le permite acelerar las aplicaciones, sino que también le enseña a ver la esencia de las cosas.
En cualquier caso, así lo dice el jefe de desarrollo móvil de Prisma,
Andrey Volodin . Y también sobre cómo las ideas fluyen hacia el desarrollo móvil desde GameDev, cómo difieren los paradigmas, por qué Android no tiene desenfoque nativo, y mucho más, se ha lanzado el lanzamiento productivo de AppsCast. Debajo del corte, hablaremos sobre el informe de Andrey sobre
AppsConf sin spoilers.
AppsCast es el podcast de la conferencia de desarrolladores móviles de AppsConf . Cada número es un nuevo invitado. Cada invitado es un orador de la conferencia con quien discutimos su informe y hablamos sobre temas relacionados con él. El podcast está dirigido por los miembros del comité del programa AppsConf Alexei Kudryavtsev y Daniil Popov.Alexey Kudryavtsev: ¡Hola a todos! Andrey, cuéntanos tu experiencia.
Andrey Volodin : Nosotros en Prisma estamos desarrollando productos que están relacionados principalmente con el procesamiento de fotos y videos. Nuestra aplicación estrella es Prisma. Ahora estamos haciendo otra aplicación de Lensa para funcionalidad similar a Facetune.
Dirijo el desarrollo móvil, pero soy un entrenador de juegos. Tengo toda la parte central, escribo tuberías de GPU para todas estas aplicaciones. Desarrollo marcos centrales para que los algoritmos y las neuronas que desarrolló el equipo de I + D funcionen en dispositivos móviles y funcionen en tiempo real. En resumen, matar la informática del servidor y todo eso.
Alexei Kudryavtsev: No parece un desarrollo normal de iOS.
Andrey Volodin: Sí, tengo tales detalles: escribo en Swift todos los días, pero al mismo tiempo está muy lejos de lo que se considera desarrollo de iOS.
Daniil Popov: Usted mencionó las tuberías de GPU, ¿de qué se trata?
Andrey Volodin: Cuando haces editores de fotos, también necesitas configurar la arquitectura y descomponer la lógica, porque la aplicación tiene diferentes herramientas. Por ejemplo, en Lensa hay una herramienta de bokeh que difumina el fondo usando una neurona, hay una herramienta de retoque que hace que una persona sea más bella. Todo esto debe funcionar de manera más eficiente en la GPU. Además, es aconsejable no transferir datos entre el procesador y la tarjeta de video cada vez, sino pre-construir un conjunto de operaciones, realizarlas en una sola ejecución y mostrar al usuario el resultado final.
Las tuberías de GPU son "pequeños bultos" de los cuales se ensamblan las instrucciones para una tarjeta de video. Luego ella hace todo esto de manera rápida y eficiente, y usted toma el resultado a la vez, y no después de cada instrumento. Me aseguro de que nuestras tuberías de GPU sean lo más rápidas posible, eficientes y generalmente existan en principio.
Alexey Kudryavtsev: Dime, ¿cómo llegaste a esto? Un desarrollador habitual de iOS comienza con remaches y moldes, luego va a algún lado con la API y está contento. ¿Cómo sucedió que estás haciendo algo completamente diferente?
Andrey Volodin: En su mayor parte, esto es una coincidencia. Antes de conseguir un trabajo, hice juegos para iOS. Siempre fue interesante para mí, pero entendí que en Rusia especialmente no hay ningún lugar para desarrollarse en esta dirección. Dio la casualidad de que nos encontramos con Prisma. Necesitaban un desarrollador de iOS que pueda escribir en Swift y al mismo tiempo conozca la GPU, en particular, Metal, que acaba de salir, y definitivamente encajo en esa descripción.
Respondí a la vacante, tuvimos una sinergia, y por tercer año he estado profundizando cada vez más en esto. Si algo sale mal ahora, entonces ya tengo todos estos Viper y MVVM, ni siquiera sé cómo se desencripta, tendré que entenderlo desde el principio.
¿Qué hace el ingeniero de GPU?
Daniil Popov: su
perfil de AppsConf dice la GPU Engineer. ¿Qué hace la GPU Engineer la mayor parte del día además de tomar café?
Andrey Volodin: Aquí es necesario mencionar cómo el procesador es fundamentalmente diferente de la GPU. El procesador realiza operaciones como si fuera secuencialmente. Incluso el subprocesamiento múltiple que tenemos a menudo es falso: el procesador se detiene y cambia para hacer pequeñas piezas de diferentes tareas, y las realiza en unos pocos segmentos. La GPU funciona exactamente de la manera opuesta. Hay n procesadores que realmente funcionan en paralelo, y hay paralelismo entre procesos y paralelismo dentro de la GPU.
Mi trabajo principal, además de cosas comunes como optimizar el trabajo con memoria y organizar la reutilización del código, es portar los algoritmos que están escritos para la CPU a las tarjetas de video para que sean paralelos. Esto no siempre es una tarea trivial, porque existen algoritmos muy eficientes que están completamente vinculados a la ejecución secuencial de instrucciones. Mi trabajo es idear, por ejemplo, una aproximación para dicho algoritmo que, tal vez, no sea exactamente lo mismo, pero visualmente el resultado no se puede distinguir. Entonces podemos acelerar 100 veces, sacrificando un poco la calidad.
También estoy portando neuronas. Por cierto, pronto haremos un lanzamiento importante de código abierto. Incluso antes de que apareciera Core ML, teníamos nuestra propia contraparte, y finalmente maduramos para ponerlo en código abierto. Su paradigma es ligeramente diferente de Core ML. Yo, incluido, estoy desarrollando su parte central.
En general, hago todo lo relacionado con algoritmos de computación y computación.
Alexey Kudryavtsev: Un anuncio interesante.
Andrey Volodin: Esto no es un secreto, no lo anunciaremos con algún tipo de fanfarria, solo es posible ver un ejemplo de los marcos utilizados dentro de Prisma.
¿Por qué optimizar para GPU?
Alexei Kudryavtsev: Dime, por favor, ¿por qué optimizamos los algoritmos para GPU en general? Puede parecer que es suficiente agregar núcleos al procesador u optimizar el algoritmo. ¿Por qué exactamente la GPU?
Andrey Volodin: Trabajar en la GPU puede acelerar enormemente los algoritmos. Por ejemplo, tenemos neuronas que se ejecutarán en el procesador central Samsung S10 durante 30 s, y en la GPU habrá 1 fotograma, es decir, 1/60 s. Esta es una experiencia de usuario increíblemente cambiante. No hay una pantalla de carga eterna, puede ver el resultado del algoritmo trabajando en la transmisión de video, o girar el control deslizante y ver los efectos allí mismo.
No es que sea demasiado bueno para escribir en la CPU, por lo que reescribimos todo en la GPU. El uso de una GPU tiene un objetivo transparente: acelerar las cosas.
Alexei Kudryavtsev: La GPU maneja operaciones similares entre sí en paralelo. ¿Tiene solo esas operaciones y, por lo tanto, logra alcanzar tal éxito?
Andrey Volodin: Sí, la principal dificultad no es codificar, sino crear algoritmos que se transfieran bien a la GPU. Esto no siempre es trivial. Sucede que descubriste cómo hacer todo bien, pero para esto necesitas demasiados puntos de sincronización. Por ejemplo, escribe todo en una propiedad, y esta es una señal clara de que será poco paralela. Si escribe mucho en un lugar, entonces todos los hilos necesitarán sincronizarse para esto. Nuestra tarea es aproximar los algoritmos para que sean paralelos bien.
Alexei Kudryavtsev: Para mí, como desarrollador móvil, suena como ciencia espacial.
Andrey Volodin: En realidad, no es tan difícil. Para mí, la ciencia de cohetes es VIPER.
Tercer chip
Daniil Popov: Parece que en la última conferencia de Google I / O anunciaron un pedazo de hierro para TensorFlow y otras cosas. ¿Cuándo aparecerá finalmente el tercer chip en teléfonos móviles, TPU o cómo se llamará, que también hará toda la magia ML en el dispositivo?
Andrey Volodin: Tenemos esto mismo, se conecta a través de USB y puede controlar las neuronas de Google en él. Huawei ya tiene esto, incluso escribimos software para sus aceleradores hexagonales, para que las neuronas de segmentación persigan rápidamente al P20.
Debo decir que en el iPhone ya existen. Por ejemplo, en el último iPhone XS hay un coprocesador llamado NPU (Neural Processing Unit), pero hasta ahora solo Apple tiene acceso a él. Este coprocesador ya está cortando la GPU en el iPhone. Algunos modelos Core ML usan NPU y, por lo tanto, son más rápidos que el Metal desnudo.
Esto es significativo, dado que además de las neuronas de inferencia más bajas, Core ML requiere mucha acción adicional. Primero debe convertir los datos de entrada al formato Core ML, los procesará, luego los devolverá a su formato; debe volver a convertirlos y solo mostrarlos al usuario. Todo esto lleva bastante tiempo. Escribimos canalizaciones gratuitas que funcionan desde el principio hasta el final en la GPU, mientras que los modelos Core ML son más rápidos precisamente debido a este proceso de hardware.
Lo más probable es que en WWDC en junio muestren un marco para trabajar con NPU.
Es decir, como dijiste, ya hay dispositivos, solo que los desarrolladores aún no pueden usarlos por completo. Mi hipótesis es que las propias empresas aún no entienden cómo hacer esto con cuidado en forma de marco. O simplemente no quieren regalar para tener una ventaja en el mercado.
Alexei Kudryavtsev: Con el escáner de huellas digitales, lo mismo sucedió en el iPhone, según recuerdo.
Andrey Volodin: Él no es tan súper asequible incluso ahora. Puede usarlo a nivel superior, pero no puede obtener la impresión en sí. Simplemente puede pedirle a Apple que permita que el usuario lo use. Todavía no es ese acceso completo al escáner en sí.
Aceleradores Hexagonales
Daniil Popov: Usted mencionó el término aceleradores hexagonales. Creo que no todos saben lo que es.
Andrey Volodin: Esta es solo una pieza de arquitectura de hardware que utiliza Huawei. Debo decir que es bastante sofisticada. Pocas personas lo saben, pero en algunos Huawei estos procesadores son, pero no se usan, porque tienen un error de hardware. Huawei los lanzó, y luego encontró un problema, ahora en algunos teléfonos los chips especiales son de peso muerto. En versiones nuevas, todo ya funciona.
En la programación, existe el paradigma SIMD (Instrucción única, Datos múltiples), cuando las mismas instrucciones se ejecutan en paralelo en datos diferentes. El chip está diseñado de tal manera que puede procesar algunas operaciones en paralelo en varios flujos de datos a la vez. En particular, hexagonal significa que en 6 elementos en paralelo.
Alexei Kudryavtsev: Pensé que la GPU funcionaba así: vectoriza una tarea y realiza la misma operación en diferentes datos. Cual es la diferencia
Andrey Volodin : GPU es un propósito más general. A pesar de que la programación para la GPU es bastante baja, con respecto al trabajo con coprocesadores es bastante alta. Para programar en la GPU, se usa un lenguaje tipo C. En iOS, el código todavía se compila con LLVM en las instrucciones de la máquina de todos modos. Y estas cosas para los coprocesadores a menudo se escriben directamente en hardcore: en ensamblador, en instrucciones de la máquina. Por lo tanto, allí el aumento de la productividad es mucho más notable, porque se agudizan para operaciones específicas. No puede contar con ellos para nada, pero solo puede contar para lo que fueron destinados originalmente.
Alexei Kudryavtsev: ¿Y por qué suelen estar diseñados?
Andrey Volodin: Ahora principalmente para las operaciones más comunes en redes neuronales: convolución - convolución o algún tipo de activación intermedia. Tienen una funcionalidad precableada que funciona súper rápido. Por lo tanto, son mucho más rápidos en algunas tareas que la GPU, pero en el resto simplemente no son aplicables.
Alexei Kudryavtsev: Parece que los procesadores DSP, que alguna vez se usaron para audio, y todos los complementos y efectos funcionaron en ellos muy rápidamente. Se vendió hardware costoso especial, pero luego los procesadores crecieron y ahora grabamos y procesamos podcasts directamente en las computadoras portátiles.
Andrey Volodin: Sí, casi lo mismo.
GPU no solo para gráficos
Daniil Popov: ¿Entiendo correctamente que ahora en la GPU puede procesar datos que no están directamente relacionados con los gráficos? Resulta que la GPU está perdiendo su propósito original.
Andrey Volodin: Exactamente. A menudo hablo de esto en las conferencias. Los primeros fueron NVidia, quienes presentaron CUDA. Esta es una tecnología que simplifica la GPGPU (Computación de propósito general en unidades de procesamiento de gráficos). Puede escribir en él un superconjunto de algoritmos de C ++ que están paralelos en la GPU.
Pero la gente ha hecho esto antes. Por ejemplo, los artesanos en OpenGL o en DirectX incluso más antiguos simplemente escribieron datos en la textura: cada píxel se interpretó como datos: los primeros 4 bytes en el primer píxel, los segundos 4 bytes en el segundo. Procesaron las texturas, luego los datos de la textura fueron extraídos e interpretados. Fue muy mutilado y complicado. Ahora las tarjetas de video admiten lógica de propósito general. Puede alimentar cualquier búfer en la GPU, describir sus estructuras, incluso la jerarquía de estructuras en las que se referirán entre sí, calcular algo y devolverlo al procesador.
Daniil Popov: Es decir, podemos decir que la GPU ahora es Data PU.
Andrey Volodin: Sí, los gráficos en la GPU a veces se procesan menos que los cálculos generales.
Alexei Kudryavtsev: La arquitectura de la CPU y la GPU es diferente en esencia, pero puedes considerarla allí y allá.
Andrey Volodin : De hecho, en algunos aspectos la CPU es más rápida, en algunos aspectos la GPU. Esto no quiere decir que la GPU sea siempre más rápida.
Daniil Popov: Hasta donde recuerdo, si la tarea es calcular algo muy diferente, en la CPU puede ser mucho más rápido.
Andrey Volodin: También depende de la cantidad de datos. Siempre existe la sobrecarga de transferir datos desde la CPU a la GPU y viceversa. Si considera, por ejemplo, un millón de elementos, entonces el uso de una GPU generalmente está justificado. Pero contar mil elementos en una CPU puede ser más rápido que simplemente copiarlos en una tarjeta gráfica. Por lo tanto, siempre debe elegir la tarea.
Por cierto, Core ML lo hace. Core ML puede ejecutar, según Apple, para elegir dónde es más rápido calcular: en el procesador o en la tarjeta de video. No sé si esto funciona en realidad, pero dicen que sí.
Hardcore GPU Engineer conocimiento para un desarrollador móvil
Alexey Kudryavtsev: Volvamos al desarrollo móvil. Eres un ingeniero de GPU, tienes toneladas de conocimiento incondicional. ¿Cómo se puede aplicar este conocimiento a un desarrollador móvil? Por ejemplo, ¿qué ves en UIKit que otros no ven?
Andrey Volodin: hablaré sobre esto en detalle en AppsConf. Puedes aplicar mucho donde. Cuando veo, por ejemplo, cómo funciona la API UIKit, puedo entender de inmediato por qué se hace esto y por qué. Al observar la caída del rendimiento al renderizar algunas vistas, puedo entender la razón, porque sé cómo se escribe el renderizado en el interior. Entiendo: para mostrar los efectos que el desenfoque gaussiano realmente hace en la parte superior del búfer de cuadros, primero debe almacenar en caché toda la textura, aplicar una operación de desenfoque intenso, devolver el resultado, terminar de renderizar el resto de las vistas y solo mostrarlo en la pantalla. Todo esto debe caber en 1/60 de segundo, de lo contrario se ralentizará.
Es absolutamente obvio para mí por qué esto es mucho tiempo, pero para mis colegas esto no está claro. Es por eso que quiero compartir los trucos de diseño que usamos a menudo en GameDev, y mis ideas sobre cómo miro los problemas y trato de resolverlos. Será un experimento, pero creo que debería ser interesante.
Por qué Android no tiene desenfoque nativo
Daniil Popov: Usted mencionó el desenfoque, y creo que tengo una pregunta que preocupa a todos los desarrolladores de Android: ¿por qué hay un bluer nativo en iOS y no en Android?
Andrei Volodin: Creo que esto se debe a la arquitectura. Las plataformas de Apple usan la arquitectura de representación Tiled Shading. Con este enfoque, no se procesa todo el marco, sino pequeños mosaicos: cuadrados, partes de la pantalla. Esto le permite optimizar el funcionamiento del algoritmo, ya que la ganancia de rendimiento principal cuando se utiliza la GPU proporciona un uso eficiente de la memoria caché. En iOS, el marco a menudo se representa para que no ocupe nada de memoria. Por ejemplo, en el iPhone 7 Plus, la resolución es 1920 * 1080, que es de aproximadamente 2 millones de píxeles. Multiplicamos por 4 bytes por canal, resulta alrededor de 20 megabytes por cuadro. 20 MB para almacenar simplemente el búfer de trama del sistema.
El enfoque de sombreado en mosaico le permite dividir este búfer en pedazos pequeños y renderizarlo un poco. Esto aumenta en gran medida el número de accesos a la memoria caché, porque para difuminar, debe leer los píxeles ya dibujados y calcular la distribución gaussiana en ellos. Si lee el fotograma completo, la velocidad de caché será muy baja, porque cada secuencia leerá diferentes lugares. Pero si lee piezas pequeñas, la velocidad de caché será muy alta y la productividad también será alta.
Me parece que la falta de desenfoque nativo en Android está relacionada con características arquitectónicas. Aunque, tal vez esta sea una solución de producto.
Daniil Popov: En Android, hay RenderScript para esto, pero allí debes mezclar, dibujar e incrustar con tus manos. Esto es mucho más complicado que configurar una casilla de verificación en iOS.
Andrey Volodin: Lo más probable es que el rendimiento también sea menor.
Daniil Popov: Sí, para satisfacer la lista de deseos del diseñador, tenemos que reducir la escala de la imagen, borrarla y luego volver a escalar para ahorrar de alguna manera.
Andrey Volodin: Por cierto, con esto puedes hacer diferentes trucos. La distribución gaussiana es un círculo borroso. Gauss sigma depende de la cantidad de píxeles que desea que recopilen. A menudo, como optimización, puede reducir la escala de la imagen y reducir un poco la sigma, y cuando devuelva la escala original, no habrá diferencia, porque la sigma depende directamente del tamaño de la imagen. A menudo usamos este truco para acelerar el desenfoque.
Daniil Popov: Sin embargo, RenderScript en Android no le permite hacer un radio superior a 30.
Andrey Volodin: En realidad, un radio de 30 es mucho. Nuevamente, entiendo que recolectar 30 píxeles usando una GPU en cada hilo es muy costoso.
¿Cuáles son las similitudes entre el desarrollo móvil y GameDev
Alexei Kudryavtsev: En las tesis de su informe, dice que el desarrollo móvil y GameDev tienen mucho en común. Dime un poco, ¿qué es exactamente?
Andrey Volodin: La arquitectura de UIKit recuerda mucho a los motores de juegos y a los antiguos. Los modernos han ido en la dirección del Sistema de Componentes de la Entidad, y esto también estará en el informe. Esto también llega a UIKit, hay artículos que escriben cómo puede diseñar vistas en componentes. 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 .