Todas essas palavras estão muito mais relacionadas ao desenvolvimento móvel do que parece à primeira vista: aceleradores hexagonais já estão ajudando a treinar redes neurais em dispositivos móveis; álgebra e matan são úteis para conseguir um emprego na Apple; A programação da GPU não apenas permite acelerar os aplicativos, mas também ensina a ver a essência das coisas.
Em qualquer caso, diz o chefe do desenvolvimento móvel da Prisma,
Andrey Volodin . E também sobre como as idéias fluem para o desenvolvimento móvel do GameDev, como os paradigmas diferem, por que o Android não possui desfoque nativo - e muito mais, uma versão produtiva do AppsCast foi lançada. Sob o corte, falaremos sobre o relatório de Andrey no
AppsConf sem spoilers.
O AppsCast é o podcast da conferência para desenvolvedores de aplicativos da AppsConf . Cada edição é um novo convidado. Cada convidado é um orador da conferência com quem discutimos seu relatório e falamos sobre tópicos relacionados a ele. O podcast é organizado por membros do comitê do programa AppsConf, Alexei Kudryavtsev e Daniil Popov.Alexey Kudryavtsev: Olá pessoal! Andrey, por favor, conte-nos sobre a sua experiência.
Andrey Volodin : Nós da Prisma estamos desenvolvendo produtos relacionados principalmente ao processamento de fotos e vídeos. Nosso aplicativo principal é o Prisma. Agora, estamos criando outro aplicativo Lensa para funcionalidade do tipo Facetune.
Lidero o desenvolvimento móvel, mas sou treinador de jogos. Eu tenho toda a parte principal, escrevo pipelines de GPU para todos esses aplicativos. Desenvolvo estruturas básicas para que os algoritmos e neurônios desenvolvidos pela equipe de P&D funcionem em dispositivos móveis, funcionem em tempo real. Em suma, matar a computação do servidor e tudo mais.
Alexei Kudryavtsev: Não parece um desenvolvimento regular do iOS.
Andrey Volodin: Sim, tenho essas especificidades - escrevo no Swift todos os dias, mas ao mesmo tempo está muito longe do que é considerado desenvolvimento iOS.
Daniil Popov: Você mencionou os pipelines da GPU, do que se trata?
Andrey Volodin: Ao criar editores de fotos, você também precisa configurar a arquitetura e decompor a lógica, porque o aplicativo possui ferramentas diferentes. Por exemplo, em Lensa, existe uma ferramenta de bokeh que desfoca o fundo usando um neurônio, há uma ferramenta de retoque que deixa uma pessoa mais bonita. Tudo isso precisa funcionar com mais eficiência na GPU. Além disso, é aconselhável não transferir dados entre o processador e a placa de vídeo todas as vezes, mas criar previamente um conjunto de operações, executá-las em uma execução e mostrar ao usuário o resultado final.
Os pipelines da GPU são "pequenos pedaços" dos quais são montadas as instruções para uma placa de vídeo. Então ela faz tudo isso de maneira rápida e eficiente, e você obtém o resultado de cada vez, e não após cada instrumento. Garanto que nossos pipelines de GPU sejam o mais rápido possível, eficientes e geralmente existam em princípio.
Alexey Kudryavtsev: Diga-me, como você chegou a isso? Um desenvolvedor iOS regular começa com rebites e moldes, depois passa pela API e fica feliz. Como aconteceu que você está fazendo algo completamente diferente?
Andrey Volodin: Na maior parte, isso é uma coincidência. Antes de conseguir um emprego, fiz jogos para iOS. Sempre foi interessante para mim, mas entendi que, na Rússia, não há lugar especialmente para se desenvolver nessa direção. Aconteceu que nos encontramos com o Prisma. Eles precisavam de um desenvolvedor iOS que pudesse escrever no Swift e, ao mesmo tempo, conhecer a GPU, em particular o Metal, que acabou de ser lançada na época, e eu definitivamente me encaixo nessa descrição.
Respondi à vaga, tivemos uma sinergia e, pelo terceiro ano, estou aprofundando cada vez mais isso. Se algo der errado agora, então eu já tenho todos esses Viper e MVVMs - nem sei como descriptografar - vou ter que entender desde o início.
O que o engenheiro da GPU faz
Daniil Popov: Seu
perfil do AppsConf diz a GPU do Engenheiro. O que a GPU do Engineer faz a maior parte do dia além de tomar café?
Andrey Volodin: Aqui é necessário mencionar como o processador é fundamentalmente diferente da GPU. O processador executa operações como se sequencialmente. Até o multithreading que possuímos é frequentemente falso: o processador para e alterna para realizar pequenos pedaços de tarefas diferentes e as executa em algumas partes. A GPU funciona exatamente da maneira oposta. Existem n processadores que realmente funcionam em paralelo e existe paralelismo entre processos e paralelismo na GPU.
Meu trabalho principal, além de coisas comuns, como otimizar o trabalho com memória e organizar a reutilização de código, é que eu porto os algoritmos escritos para a CPU nas placas de vídeo para que elas fiquem paralelas. Isso nem sempre é uma tarefa trivial, porque existem algoritmos muito eficientes que estão completamente ligados à execução seqüencial de instruções. Meu trabalho é apresentar, por exemplo, uma aproximação para um algoritmo que talvez não seja exatamente a mesma coisa, mas visualmente o resultado não possa ser distinguido. Para que possamos obter aceleração 100 vezes, um pouco de qualidade sacrificante.
Eu também estou portando neurônios. A propósito, em breve faremos um grande lançamento de código aberto. Mesmo antes do Core ML aparecer, tínhamos nosso próprio colega e finalmente amadurecemos para colocá-lo em código aberto. Seu paradigma é um pouco diferente do Core ML. Eu, inclusive, estou desenvolvendo sua parte principal.
Em geral, faço tudo em torno dos algoritmos e da computação do Computer Vision.
Alexey Kudryavtsev: Um anúncio interessante.
Andrey Volodin: Isso não é um segredo, não o anunciaremos com algum tipo de alarde, apenas será possível ver um exemplo dos frameworks usados no Prisma.
Por que otimizar para GPU
Alexei Kudryavtsev: Diga-me, por favor, por que otimizamos algoritmos para GPU em geral? Pode parecer que basta adicionar núcleos ao processador ou otimizar o algoritmo. Por que exatamente a GPU?
Andrey Volodin: O trabalho na GPU pode acelerar tremendamente os algoritmos. Por exemplo, temos neurônios que serão executados no processador central Samsung S10 por 30 s e na GPU haverá 1 quadro, ou seja, 1/60 s. Isso está mudando incrivelmente a experiência do usuário. Não existe uma tela de carregamento eterno, você pode ver o resultado do algoritmo trabalhando no fluxo de vídeo ou girar o controle deslizante e ver os efeitos ali.
Não é de todo interessante o fato de escrevermos na CPU, então reescrevemos tudo na GPU. O uso de uma GPU tem um objetivo transparente - acelerar as coisas.
Alexei Kudryavtsev: a GPU lida com operações semelhantes entre si bem em paralelo. Você tem exatamente essas operações e, portanto, consegue alcançar esse sucesso?
Andrey Volodin: Sim, a principal dificuldade não é codificar, mas criar esses algoritmos que são bem transferidos para a GPU. Isso nem sempre é trivial. Acontece que você descobriu como fazer tudo de bom, mas para isso você precisa de muitos pontos de sincronização. Por exemplo, você escreve tudo em uma propriedade, e este é um sinal claro de que será mal paralelo. Se você escrever muito em um só lugar, todos os threads precisarão ser sincronizados para isso. Nossa tarefa é aproximar os algoritmos para que eles sejam paralelos.
Alexei Kudryavtsev: Para mim, como desenvolvedor móvel, soa como ciência de foguetes.
Andrey Volodin: Na verdade, não é tão difícil. Para mim, a ciência do foguete é VIPER.
Terceiro chip
Daniil Popov: Parece que na última conferência de E / S do Google eles anunciaram um pedaço de ferro para o TensorFlow e outras coisas. Quando o terceiro chip finalmente aparecerá em telefones celulares, TPU ou como será chamado, o que também fará toda a mágica do ML no dispositivo?
Andrey Volodin: Temos
exatamente isso, ele se conecta via USB e você pode direcionar neurônios do Google. A Huawei já tem isso, até escrevemos software para seus aceleradores hexagonais, para que os neurônios de segmentação perseguissem rapidamente o P20.
Devo dizer que no iPhone eles já existem. Por exemplo, no iPhone XS mais recente, existe um coprocessador chamado NPU (Unidade de processamento neural), mas até agora apenas a Apple tem acesso a ele. Este coprocessador já está cortando a GPU no iPhone. Alguns modelos Core ML usam NPUs e, portanto, são mais rápidos que o bare metal.
Isso é significativo, já que, além dos neurônios de menor inferência, o Núcleo ML requer muita ação adicional. Primeiro, você precisa converter os dados de entrada no formato Core ML, processá-los e depois devolvê-los em seu formato - você precisa convertê-los novamente e só depois mostrá-los ao usuário. Isso tudo leva algum tempo. Escrevemos pipelines livres de sobrecarga que funcionam do começo ao fim na GPU, enquanto os modelos Core ML são mais rápidos precisamente devido a esse processo de hardware.
Provavelmente, na WWDC em junho, eles mostrarão uma estrutura para trabalhar com NPU.
Ou seja, como você disse, já existem dispositivos, apenas os desenvolvedores ainda não podem usá-los ao máximo. Minha hipótese é que as próprias empresas ainda não entendem como fazer isso com cuidado na forma de uma estrutura. Ou eles simplesmente não querem ceder para ter uma vantagem no mercado.
Alexei Kudryavtsev: Com o scanner de impressões digitais, a mesma coisa estava no iPhone, pelo que me lembro.
Andrey Volodin: Ele não é tão super acessível agora. Você pode usá-lo em nível superior, mas não consegue obter a impressão em si. Você pode simplesmente pedir à Apple para permitir que o usuário a use. Ainda não é esse acesso total ao próprio scanner.
Aceleradores hexagonais
Daniil Popov: Você mencionou o termo aceleradores hexagonais. Eu acho que nem todo mundo sabe o que é.
Andrey Volodin: Essa é apenas uma parte da arquitetura de hardware que a Huawei usa. Devo dizer que ela é bastante sofisticada. Poucas pessoas sabem, mas em alguns Huawei esses processadores são, mas não são usados, porque possuem um bug de hardware. Huawei lançou-os e, em seguida, encontrou um problema, agora em alguns telefones chips especiais são peso morto. Em versões novas, tudo já funciona.
Na programação, existe o paradigma SIMD (Instrução Única, Vários Dados), quando as mesmas instruções são executadas em paralelo em dados diferentes. O chip foi projetado de forma a poder processar alguma operação em paralelo em vários fluxos de dados ao mesmo tempo. Em particular, hexagonal significa que em 6 elementos em paralelo.
Alexei Kudryavtsev: Eu pensei que a GPU simplesmente funciona assim: vetoriza uma tarefa e executa a mesma operação em dados diferentes. Qual a diferença?
Andrey Volodin : GPU é de propósito mais geral. Apesar de a programação da GPU ser de nível bastante baixo, no que diz respeito ao trabalho com coprocessadores, é de nível bastante alto. Para a programação na GPU, é usada uma linguagem C. No iOS, o código ainda é compilado com o LLVM nas instruções da máquina. E essas coisas para coprocessadores costumam ser escritas diretamente diretamente - no montador, nas instruções da máquina. Portanto, o aumento da produtividade é muito mais perceptível, porque eles são aprimorados para operações específicas. Você não pode contar com nada, mas pode contar apenas para o que eles foram originalmente destinados.
Alexei Kudryavtsev: E por que eles geralmente são projetados?
Andrey Volodin: Agora principalmente para as operações mais comuns em redes neurais: convolução - convolução ou algum tipo de ativação intermediária. Eles têm uma funcionalidade pré-cabeada que funciona super-rapidamente. Portanto, eles são muito mais rápidos em algumas tarefas que a GPU, mas em todo o resto eles simplesmente não são aplicáveis.
Alexei Kudryavtsev: Parece que os processadores DSP, que costumavam ser usados para áudio, e todos os plugins e efeitos trabalharam neles muito rapidamente. Foi vendido um hardware caro especial, mas os processadores cresceram e agora gravamos e processamos podcasts diretamente em laptops.
Andrey Volodin: Sim, sobre o mesmo.
GPU não apenas para gráficos
Daniil Popov: Entendo corretamente que agora na GPU você pode processar dados que não estão diretamente relacionados aos gráficos? Acontece que a GPU está perdendo seu objetivo original.
Andrey Volodin: Exatamente. Costumo falar sobre isso em conferências. Os primeiros foram a NVidia, que apresentou o CUDA. Essa é uma tecnologia que simplifica a GPGPU (computação de uso geral em unidades de processamento gráfico). Você pode escrever nele um superconjunto de algoritmos C ++ que são paralelos na GPU.
Mas as pessoas já fizeram isso antes. Por exemplo, artesãos no OpenGL ou no DirectX ainda mais antigo simplesmente gravaram dados na textura - cada pixel foi interpretado como dados: os primeiros 4 bytes no primeiro pixel, os segundos 4 bytes no segundo. Eles processaram as texturas e depois os dados da textura foram extraídos e interpretados. Era muito apertado e complicado. Agora, as placas de vídeo suportam lógica de uso geral. Você pode alimentar qualquer buffer na GPU, descrever suas estruturas, até a hierarquia de estruturas nas quais elas se referirão umas às outras, calcular algo e devolvê-lo ao processador.
Daniil Popov: Ou seja, podemos dizer que a GPU agora é Data PU.
Andrey Volodin: Sim, às vezes os gráficos na GPU são processados menos que os cálculos gerais.
Alexei Kudryavtsev: A arquitetura da CPU e da GPU é diferente em essência, mas você pode considerar isso lá e ali.
Andrey Volodin : De fato, em alguns aspectos, a CPU é mais rápida, em alguns aspectos, a GPU. Isso não quer dizer que a GPU seja sempre mais rápida.
Daniil Popov: Tanto quanto me lembro, se a tarefa é calcular algo muito diferente, então na CPU pode ser muito mais rápido.
Andrey Volodin: Também depende da quantidade de dados. Sempre há a sobrecarga de transferência de dados da CPU para a GPU e vice-versa. Se você considerar, por exemplo, um milhão de elementos, o uso de uma GPU geralmente é justificado. Mas contar mil elementos em uma CPU pode ser mais rápido do que copiá-los para uma placa gráfica. Portanto, você deve sempre escolher a tarefa.
A propósito, o Core ML faz isso. O Core ML pode executar, de acordo com a Apple, a escolha de onde é mais rápido calcular: no processador ou na placa de vídeo. Não sei se isso funciona na realidade, mas eles dizem que sim.
Hardcore GPU Engineer conhecimento para um desenvolvedor móvel
Alexey Kudryavtsev: Vamos voltar ao desenvolvimento móvel. Você é um engenheiro de GPU, possui toneladas de conhecimento intenso. Como esse conhecimento pode ser aplicado a um desenvolvedor de dispositivos móveis? Por exemplo, o que você vê no UIKit que outras pessoas não veem?
Andrey Volodin: Vou
falar sobre isso em detalhes no AppsConf. Você pode aplicar muito onde. Quando vejo, por exemplo, como a API do UIKit funciona, posso entender imediatamente por que isso é feito e por quê. Observando a queda de desempenho ao renderizar algumas visualizações, posso entender o motivo, porque sei como a renderização é escrita dentro. Entendo: para exibir os efeitos que o desfoque gaussiano realmente faz sobre o buffer de quadros, você primeiro precisa armazenar em cache toda a textura, aplicar uma operação de desfoque pesado a ela, retornar o resultado, terminar de renderizar o restante das visualizações e mostrá-lo na tela. Tudo isso deve caber em 1/60 de segundo, caso contrário, diminuirá a velocidade.
É absolutamente óbvio para mim por que isso faz muito tempo, mas para meus colegas isso não está claro. É por isso que quero compartilhar os truques de design que costumamos usar no GameDev, e minhas idéias sobre como encaro os problemas e tento resolvê-los. Será um experimento, mas acho que deve ser interessante.
Por que o Android não tem desfoque nativo
Daniil Popov: Você mencionou o desfoque, e eu acho que tenho uma pergunta que preocupa todos os desenvolvedores do Android: por que existe um bluer nativo no iOS e não no Android.
Andrei Volodin: Eu acho que isso é por causa da arquitetura. As plataformas da Apple usam a arquitetura de renderização Tiled Shading. Com essa abordagem, nem todo o quadro é renderizado, mas pequenos blocos - quadrados, partes da tela. Isso permite otimizar a operação do algoritmo, porque o principal ganho de desempenho ao usar a GPU fornece um uso eficiente do cache. No iOS, o quadro geralmente é renderizado para que não ocupe memória. Por exemplo, no iPhone 7 Plus, a resolução é 1920 * 1080, que é de cerca de 2 milhões de pixels. Nós multiplicamos por 4 bytes por canal, resultando em cerca de 20 megabytes por quadro. 20 MB para simplesmente armazenar o buffer do quadro do sistema.
A abordagem Tiled Shading permite dividir esse buffer em pedaços pequenos e renderizá-lo um pouco. Isso aumenta muito o número de acessos ao cache, porque, para desfocar, você precisa ler os pixels já desenhados e calcular a distribuição Gaussiana neles. Se você ler o quadro inteiro, a taxa de cache será muito baixa, porque cada fluxo lerá lugares diferentes. Mas se você ler pequenos pedaços, a taxa de cache será muito alta e a produtividade também será alta.
Parece-me que a falta de desfoque nativo no Android está conectada aos recursos arquitetônicos. Embora, talvez essa seja uma solução de produto.
Daniil Popov: No Android, existe o RenderScript para isso, mas é preciso misturar, desenhar, incorporar com as mãos. Isso é muito mais complicado do que definir uma caixa de seleção no iOS.
Andrey Volodin: Provavelmente, o desempenho também é menor.
Daniil Popov: Sim, a fim de satisfazer a lista de desejos do designer, temos que reduzir a escala da imagem, deixá-la em azul e, em seguida, aumentar a escala para salvar de alguma forma.
Andrey Volodin: A propósito, com isso você pode fazer truques diferentes. A distribuição gaussiana é um círculo desfocado. O Gauss sigma depende do número de pixels que você deseja que eles coligam. Freqüentemente, como otimização, você pode reduzir a escala da imagem e reduzir um pouco o sigma e, quando retornar a escala original, não haverá diferença, pois o sigma depende diretamente do tamanho da imagem. Costumamos usar esse truque para acelerar o desfoque.
Daniil Popov: No entanto, o RenderScript no Android não permite que você faça um raio maior que 30.
Andrey Volodin: Na verdade, um raio de 30 é muito. Mais uma vez, entendo que coletar 30 pixels usando uma GPU em cada thread é muito caro.
O que são desenvolvimento móvel semelhante e GameDev
Alexei Kudryavtsev: Nas teses do seu relatório, você diz que o desenvolvimento móvel e o GameDev têm muito em comum. Me conte um pouco, o que exatamente?
Andrey Volodin: A arquitetura do UIKit lembra muito os mecanismos de jogo e os antigos. Os modernos foram na direção do Sistema de Componentes de Entidades, e isso também estará no relatório. Isso também se aplica ao UIKit, existem artigos que escrevem sobre como você pode projetar visualizações em 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 .