San Jose, CA -No ultimo dia do GTC assisti uma das melhores palestras apresentadas por terceiros de todo o evento. Quatro designers gráficos de quatro grandes estúdios (LucasFilm, Disney, Sony, DigitalDomain, responsáveis pelos filmes mais fantásticos dos últimos tempos) contaram suas experiências e responderam perguntas da platéia. E o impacto pra mim foi incrível, pois […]
San Jose, CA -No ultimo dia do GTC assisti uma das melhores palestras apresentadas por terceiros de todo o evento. Quatro designers gráficos de quatro grandes estúdios (LucasFilm, Disney, Sony, DigitalDomain, responsáveis pelos filmes mais fantásticos dos últimos tempos) contaram suas experiências e responderam perguntas da platéia. E o impacto pra mim foi incrível, pois me fez ver um outro lado da programação via GPU que eu não fazia idéia. Foi uma verdadeira ducha fria pra mim.
Pra explicar, eu preciso voltar ao passado quando entrevistei no Brasil designers gráficos do mercado de publicidade, na época a programação via GPU era um sonho distante e tudo era feito via CPU através dos Render Farms. Uma das coisas que mais me impressionou naquela época foi a questão preço/tempo/qualidade. Ou seja, se o cliente quiser qualidade máxima, vai custar caro e vai levar tempo (por causa pro processamento mais lento), por isso se faz concessões para adequar o projeto ao prazo que o cliente tem (geralmente muito curto) e ao orçamento disponível. A indústria toda, sejam os profissionais, os clientes, os softwares de desenvolvimento, se adaptou a essa realidade e funciona muito bem assim.
Pois vamos voltar para o universo do cinema e a esses fantásticos designers. Filmes como Transformer 2, o próximo Harry Potter, algumas animações da Disney e até filmes mais antigos de enorme sucesso compartilham decisões (e prêmios, alguns desses caras são ganhadores de Oscars ou Emmy…) que afetam o orçamento, prazo e a qualidade do produto final. Só que a gente como expectador não percebe (claro, é por isso que eles ganham tantos prêmios) porque ao longo do tempo eles desenvolveram truques que permitem otimizar tempo, qualidade, custo sem grande esforço. Um dos palestrantes apresentou seu modelo de simulação de fogo 3D baseado em layers (camadas) finas em 2D sobrepostas, utilizando mecânica de fluídos que é bem resolvida pelas CPUs atuais. Juro pra vocês que o fogo é perfeito, pode simular a queima de materiais diversos (que afeta sua cor, fumaça, partículas) e que a platéia não vai perceber o truque.
E esse é o tendão de Aquiles na programação via GPU no setor de cinema. É um produto especializado em algumas tarefas, requer uma programação completamente nova, requer pesquisa, estudo, desenvolvimento de ferramentas, e nesses estúdios não há muito tempo pra isso. E pior, eles já deram um jeito de resolver esses problemas no passado com os recursos que tinham… pra quê mudar agora?
Esses designers trabalham com três categorias de tempo: o “overnight” (de um dia para o outro), o “take a coffee” (tempo de tomar um cafezinho) e o “real time” interativo. Segundo eles próprios, por mais que a GPU ofereça inúmeras vantagens em performance, a geração de uma cena com efeitos especiais envolve tantos processos que se meia dúzia deles for acelerada em 20 vezes, o tempo total não mudará de categoria. Por isso a maioria desenvolve processos em GPU apenas para coisas pequenas, rápidas, descartáveis, embora todos concordem que a visualização (preview) em real time é uma vantagem significativa para o designer.
Outra questão é que, pelo menos por enquanto, os códigos utilizados por esses profissionais fazem parte do acervo da empresa e não são compartilhados com o publico ou com outros estúdios. Os quatro afirmaram que possuem quatro versões diferentes de simulação de fogo ou de água, com pouca ou nenhuma utilização de GPU, mas que funcionam perfeitamente. Portanto, não faz sentido desenvolver outra rotina pra fazer algo “mais rápido” se no final das contas não fará tanta diferença assim. E mesmo que usassem CUDA ou OpenCL, esse código não seria aberto por questões comerciais…
Todos afirmaram mais uma coisa surpreendente: ainda não se sentem completamente a vontade com a programação via GPU porque não há um “standard” a seguir. Tanto o CUDA quanto o OpenCL ainda são muito novos e estão mudando a cada geração de placas (aliás, os designers afirmaram que a maioria dos efeitos ainda é feita em OpenGL). Transformers 2 por exemplo usa intensivamente GPU porque foi uma decisão corporativa, não uma decisão dos designers. Todos alegaram ter receio da continuidade da plataforma, não querem perder tempo (e dinheiro) para desenvolver algo para GPU agora, sem saber se dentro de quatro anos o código ainda irá funcionar perfeitamente como já acontece com os códigos baseados em CPU.
Enfim, embora sejam inegáveis os benefícios da programação via GPU, noto que a adoção e os resultados mais fascinantes são justamente naqueles setores onde o desenvolvimento partindo do zero faz sentido, e a economia de custos e tempo de processamento é decisiva. Quanto mais próxima da “pesquisa pura”, mais viável é o uso da GPU. Porém percebi cara a cara com os profissionais de cinema que o buraco é mais embaixo quando já existe algo pronto e funcional, maduro o suficiente para atender as necessidades mais diversas. O que eles desenvolveram ao longo do tempo (desde os anos 70) funciona e permitem criar coisas fantásticas nas telonas, reescrever esses códigos aparentemente não faz muito sentido pra eles…
