Apple propõe padronização de gráficos 3D para a web… introduzindo um novo padrão

O Metal, a API gráfica da Apple chegou ao Mac em 2015 com o OS X El Capitan, após fazer sua estreia no iOS um ano antes

Há de se convir que a Apple trabalha para estipular guias e padrões para diversos dispositivos e softwares para o futuro, ainda que não necessariamente apenas os seus (mas desde que a maçã leve certa vantagem). O Swift, a linguagem de programação introduzida em 2014 é um bom exemplo, quando ela se tornou de código aberto e multiplataforma no ano seguinte.

Outra frente em que a Apple está investindo é no desenvolvimento de novos padrões para gráficos 3D na web. A equipe do WebKit, o motor de renderização por trás do Safari (e que por muito tempo foi a base do Chrome até o Google criar um fork próprio chamado Blink, levando a Opera consigo) propôs no W3C (World Wide Web Consortium, a organização responsável por definir normas e padrões para a internet) o desenvolvimento de uma nova API pensada para a web, de modo a explorar melhor os recursos e hardware e integrar plataformas.

A ideia, explicada pelo líder da equipe do WebKit Dean Jackson é propor uma nova suíte de ferramentas que consiga aproveitar todos os recursos das GPUs modernas e sistemas operacionais, não importa sob quais circunstâncias, mais precisamente trabalhando em um nível mais baixo da camada de abstração do que plataformas como o WebGL hoje atuam. De certa forma essa nova API seria mais orientada a objetos do que a última, algo como uma versão de sua API proprietária Metal, presente no iOS e macOS mas voltada para a web.

Além de propiciar um melhor aproveitamento dos recursos de hardware para a geração de gráficos 3D na web, a nova API seria aberta e multiplataforma diferente da maioria das atuais soluções disponíveis, como o DirectX 12 (apenas Windows), Mantle (somente GPUs da AMD) e sua própria Metal.

No entanto a Apple se esqueceu de um outro player presente nesse jogo:

A API Vulkan, a esperada sucessora do OpenGL introduzida no ano passado foi desenvolvida tendo como base a tecnologia Mantle da AMD, sendo assim atua da mesma forma que ela e o Metal da Apple: trabalhando em mais baixo nível ela consegue diminuir a distância entre o desenvolvedor e o processador, que não precisa entender linguagem de máquina para fazer suas bruxarias. Afinal ninguém é um David Wise, com paciência de Jó para compor músicas em Assembly.

O mais interessante no entanto é que a Vulkan já nasceu open source e cross-platform. Ela foi adotada pelo Android 7.0, é compatível com Windows, o Linux vai implementar a API e a nVidia já trabalha com a nova tecnologia. E a Vulkan é pronta para a web também.

A questão no entanto é a fragmentação. A Vulkan depende de apoio dos fabricantes de GPUs, dos desenvolvedores de software e dos grandes players como Microsoft, Google e no caso, da Apple também. Só que como a maçã propõe a criação de uma outra API (obviamente com ela ditando normas, o que não deve acontecer com a criação da Khronos Group), dependendo de como a coisa se desenrolar teremos não um, mas dois padrões distintos.

A Apple inclusive já construiu um protótipo próprio chamado WebGPU, e espera que ele seja usado como base para o desenvolvimento do novo motor gráfico padrão. Claramente Cupertino não possui a menor intenção de colaborar com a Vulkan, ao invés disso deseja que sua ideia seja a norma vigente.

Picuinhas à parte, interessante que as empresas de tecnologia trabalhem pela criação de padrões de modo a facilitar o desenvolvimento de novas tecnologias, mas um cenário com dois motores gráficos para a web disputando espaço não é o ideal.

Fonte: WebKit Blog.

Relacionados: , , , , , , , , , , , , , ,

Autor: Ronaldo Gogoni

Um cara normal até segunda ordem. Além do MeioBit dou meus pitacos eventuais como podcaster do #Scicast, no Portal Deviante.

Compartilhar
  • Apple e padrões universais. HAHAHAHAHAHAHA estou olhando pra você USB e TRS

  • Vinícius Cordeiro

    xkcd relevante: https://xkcd.com/927/

  • Monkey

    Eu voto no Khronos group. Sempre estiveram à frente junto à comunidade
    mas como meu voto não vale nada…

  • Felipe Cotta

    Mais um Padrão, ela tem que apoiar é o Vulkan não adianta gerar outros padrões tem que consolidar um, a comunidade inteira sai ganhando

    • Monkey

      A Apple só visa consolidar seus lucros

      • Raposão do Ártico 🦊

        assim como a microsoft, como o google, como você, como todo mundo aqui

        • Claudio Roberto Cussuol

          É verdade, mas as outras de vez em quando olham um palmo além do próprio umbigo.
          A Apple não faz isso NUNCA.

          • Daniel Tiecher

            Webkit, Darwin, Swift, LLVM, Clang…

        • K9s10

          Eu não!!!

        • Yskar

          Discordo sobre o Google, ele sempre apoia padrões abertos, ao menos tem isso de positivo frente a merda que eles fazem pelo lucro.

          • Raposão do Ártico 🦊

            Apoiam? Conte-nos mais sobre o Google Talk com XMPP que o google abandonou para usar uma solução fechada com o Hangouts e, mais ainda, com o Allo?

            Conte-nos mais sobre os aplicativos para o Android que o Google não liberou o código fonte.

  • Marcogro®
  • “A Vulkan depende de apoio dos fabricantes de GPUs, dos desenvolvedores de software e dos grandes players como Microsoft, Google” , mas não é assim com qualquer padrão? se ninguém adotar/implementar o padrão não pega, isso é um problema para qualquer api.

  • Harlley Sathler
    • Raposão do Ártico 🦊

      ia postar isso

    • K9s10

      kkkkk

    • Yskar

      SEMPRE acontece, SEMPRE.

  • jairo

    Padronizar API não é uma boa , tende a ficar estagnado

    • Eduardo RFS

      wtf? OpenGL, Vulkan, a Web toda em sí é padronizada, ECMAScript e etc…

  • Daniel Tiecher

    Vou adicionar meus 2 cents de desenvolvedor mobile e web aqui…

    A ideia da Apple é boa, quem já trabalhou com WebGL e depois com Metal ou Direct3D sabe que precisamos de uma API melhor para a web. E a Apple analisou a Vulkan antes de propor essa nova API e inclusive conversou com as outras desenvolvedoras de navegadores que concordaram em trabalhar em conjunto num comitê para definir um novo padrão (seja ele o proposto pela Apple ou não).

    Agora, Vulkan não é nem de longe a escolha automática para resolver esse problema da web. Das APIs nativas hoje ela é a que está mais perto do hardware físico e é por esse mesmo motivo a que menos é indicada para trabalhar com Javascript dentro de um navegador, devido à complexidade, diferença de modelo de programação e, principalmente, segurança, pois com certeza ela seria um vetor muito explorado por hackers devido ao poder de acesso que a Vulkan disponibiliza.

    Outro ponto contra a Vulkan é o fato dela não ser suportada oficialmente pela Microsoft, que por questões óbvias tem interesse em controlar seu stack. No Windows ela é suportada hoje pelas fabricantes de GPU através de seus drivers oficiais, porém apenas a AMD e a NVIDIA possuem suporte à Vulkan em suas versões estáveis, a maior fabricante de GPUs, Intel, ainda não possui suporte à Vulkan em seus drivers estáveis e parece não estar interessada em fazer isso tão cedo.

    Essa proposta da Apple no ponto de vista dos navegadores parece ser a mais atraente, pois como cada plataforma tem seu stack 3D definido (Metal, Direct3D, etc.), é muito mais fácil para a Google por exemplo implementar essa nova API em cima do Direct3D no Windows ou Metal no Mac, em vez de escrever em cima da Vulkan, pois nesse caso a Google não precisa se preocupar se o hardware possui suporte ou não à Vulkan, máquinas rodando Windows SEMPRE suportam Direct3D e a mesma coisa serve para Metal no macOS e iOS.

    Só no caso do Linux e Android é que você teria uma garantia maior da Vulkan estar disponível logo de cara, mas isso apenas para versões mais recentes do robozinho ou então em distros Linux que suportam os drivers oficiais da AMD e NVIDIA.

    • Marcio Ferreira

      Enviado do meu iPhone.

      Brincadeira kkk

      • Daniel Tiecher

        Na verdade foi enviado do meu MacBook Pro… 😛

    • Eduardo RFS

      Segurança não seria um problema, OGL também cria brechas, mas o WebGL opera em uma sandbox, como JavaScript e cara JS é excelente para isso, mas uma API low level deve ser WASM

      • Daniel Tiecher

        Segurança é sempre um problema, sandboxes são quebradas constantemente e se você pesquisar boletins de segurança, verá que muitas brechas já foram encontradas usando WebGL para sair da sandbox. Disponibilizar o acesso de uma API bem mais perto do hardware para os navegadores com certeza é mais um vetor para ataques, independente de sandbox ou isolamento de processo.

        • Macgyver Freitas

          Quanto ao suporte, no Linux o vulkan é suportado por intel de 3 geração em diante, e no Windows na 6 em diante, com um certo esforço essa retrocompatibilidade poderia ser levada para o Windows, em VGA dedicada sobra compatibilidade, em Android, o suporte é nativo no 7, mas tbm funciona no 6 e pode ser melhorado, sobre ser baixo nível, onde vc viu q uma escala comparativa de permissões do vulkan, metal e DX? O DX q tá em qlq PC é do 9 ao 11 alto nível, msm limitação do OpenGL. Se a ideia da Apple é uma API q tire melhor proveito de GPUs modernas, está n terá muita retrocompatibilidade de qlq forma. Enfim n vejo motivos para ter uma nova API no lugar do vulkan, tbm n digo q este deve ser o padrão, mas acho menos provável as empresas seguem algo sobre o controle dá Apple. Algo desse tipo n se cria de um mês pro outro, sendo o celular um tipo de hardware de baixa durabilidade e alta rotatividade até isso ficar pronto muitos celulares já suportariam o vulkan.

        • Eduardo RFS

          nah, é o contrario, se for uma API simples e pequena como a vulkan a chance de sair da sandbox é menor e o webgl o que foi achado foi sobre a GPU. Se você tem apenas algumas funções manter essas funções seguras é incrivelmente mais facil

    • Eduardo RFS

      E não, nem toda máquina que roda W10 suporta DX12, sem contar q DX12 é W10 only, uma API low level tem de ser implementada sobre driver ou se for user space over binding vulkan é o mais perto que temos de binding é o suporte é o maior das low level

      • Daniel Tiecher

        Eu não falei DX12, apenas mencionei o Direct3D. Ou seja, implementando da maneira certa levando em consideração a retrocompatibilidade, seria possível suportar essa API proposta usando versões mais antigas do DirectX ou até mesmo OpenGL. A WebGL por exemplo funciona de maneira semelhante no Windows hoje, pois em vez de ter sido implementada via OpenGL nos navegadores, ela na verdade é traduzida para Direct3D usando ANGLE.

        Esse é o grande diferencial, criar uma nova API 3D moderna para a web, que seja mais alto nível e que possa ser implementada em cada plataforma da melhor maneira possível, em vez de criar um subset da Vulkan especifico para a Web.

        • Alberto Prado

          ” propor uma nova suíte de ferramentas que consiga aproveitar todos os recursos das GPUs modernas”
          “trabalhando em um nível mais baixo da camada de abstração do que plataformas como o WebGL”
          Se vc adotar a retrocompatibilidade e ainda coloca isso em uma camada mais alta de abstração, então matou tudo o que poderia ser bom com o desenvolvimento dessa nova API.
          Não adianta muito ser um padrão único mas com performance ruim.
          Acho que seria mais fácil a Apple se juntar ao consórcio Vulkan e persuadir a Intel a se juntar já que ela é sua principal cliente.

          • Daniel Tiecher

            Quando falei de ser um nível mais alto, me referi se comparado à Vulkan, que é a API mais próxima do hardware, seguida da Direct3D e depois da Metal.

            E a retrocompatibilidade serve para suportar plataformas “antigas”, algo muito importante para termos uma boa abrangência à nova API, pois do contrário de que adianta termos uma nova API que devido a falta de compatibilidade com uma fatia considerável do mercado, não pode ser usada?

            Exemplo, a Vulkan é suportada de maneira correta hoje no Android a partir da versão 24 da API (Android 7 ou superior). Market share do Android 7 e 7.1? 1.2% de acordo com a Google…

            Mesmo que uma “WebVulkan” fosse proposta, por questões de compatibilidade com todas as plataformas e navegadores envolvidos, ela teria que ser implementada usando diferentes APIs gráficas no final das contas, além do esforço envolvido em adaptar a Vulkan para a web, algo que devido à sua arquitetura e o seu propósito quando foi criado, não seria tão simples quanto criar uma nova API feita especificamente para trazer uma experiência moderna para acessar recursos da GPU na Web.

          • Alberto Prado

            Plataformas antigas tem que deixa como tá. Ou seja, os navegadores terão que suporta tanto a nova padronização da API, como da forma que é feito hoje. Tem de haver uma transição, pois se adicionar mais uma camada de API, esse HW legado não só não terá uma performance decente como será pior. E a Apple sempre trabalha de maneira disruptiva. Sempre forçando adoção algo teoricamente mais moderno. Isso incentiva o consumo. Ela não teria problemas de deixa algo legado para trás.
            E ainda que fosse implementada essa camada, de toda forma ela tb teria que lidar diretamente com o DX 9, 10, 11, 12, Vulkan, Metal para conseguir chega perto do HW tal como ele disse que queria. Já imaginou ela tendo que lida com cada uma delas e suas diferentes características? As vezes uma faz algo que outra não faz e para não dar diferença de experiência entre as plataformas, a característica diferente teria que ser capada. Sinceramente acho que é melhor que as fabricantes do HW criem a padronização e dentro de cada versão da API elas em conjunto e comum acordo disponibilizam o que poderá ser usado pelos navegadores.
            Quanto a dificuldade de ser implementar isso hoje no Vulkan, eu desconheço pois eu não li nada nesse sentido dos desenvolvedores e tão pouco faço parte do team, logo não posso fala sobre isso.

          • Daniel Tiecher

            Mas não é assim que os padrões web funcionam. Quando uma fabricante implementa um determinado padrão proposto pelo W3C, ela o faz liberando essa funcionalidade em todas as plataformas que ela suporta para aquela versão (salvo raríssimas exceções), do contrário isso causaria uma fragmentação ainda maior do que já temos hoje.

            Exemplo prático: o Chrome 56 saiu agora há pouco e com ele o suporte ao padrão LE do Bluetooth usando a Bluetooth API. Imagina se a Google resolve disponibilizar esse recurso apenas no Android e Chrome OS pois neles o stack Bluetooth é semelhante, e ignora essa funcionalidade no Linux, macOS e Windows pois se tratam de stacks diferentes e ela quer disponibilizar essa funcionalidade apenas no stack dela. Como um desenvolvedor web, o fato da mesma versão de um determinado navegador resolver suportar uma API apenas em uma plataforma e não na outra, me faz pensar bastante se eu uso essa funcionalidade ou não, pois já não bastava eu ter que me preocupar com a fragmentação entre navegadores diferentes, agora eu preciso me preocupar também com a fragmentação do mesmo navegador, NA MESMA VERSÃO, ter suporte fragmentado a determinada funcionalidade.

            E no final das contas, seja a proposta da Apple (que com certeza evoluirá com o tempo e o feedback dos outros vendors que fazem parte do comitê) ou seja uma “Vulkan light”, na prática a implementação será feita usando apenas APIs nativas que vem pré-instaladas em cada plataforma, pois do contrário não há como garantir compatibilidade, que é algo essencial para as desenvolvedoras de navegadores. Novamente cito a maneira que a WebGL foi implementada no Windows pelos navegadores como um exemplo prático do que irá acontecer.

          • Alberto Prado

            Mas isso vai acontecer de qualquer maneira. Seja adotando uma camada adicional de API, seja adotando a API das fabricantes de HW. E o caso do WebGL exemplifica bem isso. Se placa de vídeo/driver não der suporte a ele (WebGL), o browser não exibi o recurso avançado com a aceleração do HW e o faz como antigamente atrás de GDI/GDI (hj DWM). São dois modos possíveis de trabalhar. Se não suporta um, vai com o antigo. Já é fragmentado. Vai acontecer que vai chega uma hora em que todos (ou pelo menos a maioria dos dispositivos) já terão o recursos necessários e nessa hora será descartado o código legado.
            Eu não digo que alguma dev vai deixa de implementa em uma plataforma e na outra sim. Mas que ambas as formas coexistirão por alguma tempo.

          • Eduardo RFS

            Intel é do consorcio vulkan, ela participou ativamente do desenvolvimento do vulkan a apple é a unica q n quis usar

      • Mirai Densetsu

        Se suportar DX11, roda máquinas com Windows 7. Se for pro DX9, até Windows XP roda.

    • Cássio Amaral

      Joinha por mencionar Direct3D e não DirectX, incrível como muita gente acha que DirectX se resume à gráficos, por ser a principal API. E tenho que concordar com você, o que pega é o monopólio do Windows, o que faz suportar o D3D quase que obrigatório.

  • Samuel

    Pavimentam a tecnologia pq querem vender serviços sobre ela. Dado o histórico, acho que essa tb vai pegar

  • Wallacy

    Padrão é algo maravilhoso né? Tão bom, tão bom que cada um tem o seu 😉

    Bora padronizar tudo… Cada um com o seu padrão é claro.

  • Nícolas Wildner

    API = Apple Programming Interface, neste contexto.

  • Cássio Amaral

    Como diria o grande pensador contemporâneo Carlos Cardoso:

    “Padrão é tão bom que toda empresa quer ter o seu.”

  • gcavalcante8808

    Na verdade Vulkan na está disponível em Linux desde o início para o caso da nvidia. Intel e AMD já possuem também a implementação. Víde os benchmarks do phoronix

  • DiMais

    e com a grana que ela tem em caixa ela consegue sucumbir qualquer concorrente, vai fazer o mesmo quando venceu a Nokia (apoiada por outros fabricantes mas não pelas operadoras) na padronização do nano-SIM anos atrás…

  • Yskar

    APENAS ADOTEM O VULKAN, CARALHO!
    Apple fazendo merda como sempre, puta que pariu!

Aproveite nossos cupons de desconto:

Cupom de desconto Locaweb, Cupom de desconto HP, Cupom de desconto Descomplica, Cupom de desconto Nuuvem, Cupom de desconto CVC, Cupom de desconto Asus, Cupom de desconto World Tennis