1. Este site usa cookies. Ao continuar a usar este site está a concordar com o nosso uso de cookies. Saber Mais.

OpenCL (Open Computing Language)

Discussão em 'Novidades Hardware PC' iniciada por DJ_PAPA, 11 de Junho de 2008. (Respostas: 14; Visualizações: 3284)

  1. DJ_PAPA

    DJ_PAPA Power Member

    http://www.anandtech.com/weblog/showpost.aspx?i=461


    http://www.apple.com/macosx/snowleopard/?sr=hotnews

    Apple propoe OpenCL. Uma linguagem e API universal para o GPGPU compativel com ATI e Nvidia.
    A ideia é muito interessante. Basicamente é uma especie de Direct_X mas para o GPGPU.
    Em vez de tar cada uma a puxar para seu lado, se puxassem ambas para o mesmo certamente a Intel teria muito mais a temer relativamente a isto.
     
    Última edição: 11 de Junho de 2008
  2. muddymind

    muddymind 1st Folding then Sex

    Isto só peca por vir tarde! (e vamos lá a ver se a AMD e a nvidia não se armam em tótós)

    Parece que não aprendem com erros do passado (glide anyone?) e quem sai sempre prejudicado é o zé povinho que arrisca ficar com o que pagou obsoleto de forma inaceitável...
     
    Última edição: 11 de Junho de 2008
  3. blastarr

    blastarr Power Member

    Mais uma vez, a Apple no seu pior (pegando em projectos dos outros, dando-lhes um novo nome, e anunciando tudo como se fosse a segunda vinda de Cristo à Terra).

    Uma implementação como a que a Apple propõe nunca será tão rápida ou eficiente como o CUDA.
    É um mínimo denominador comum, criado originalmente para todas as principais CPU's general purpose e longe de estar optimizado para aplicações em chips especializados em computação paralela como as GPU's.
     
    Última edição: 12 de Junho de 2008
  4. timber

    timber Zwame Advisor

    A Apple é tão altruísta que até faz linguagens de programação para hardware que praticamente não vende :p

    Enfim pode ser que ande para a frente. O essencial é a parte standard
     
  5. muddymind

    muddymind 1st Folding then Sex

    Eu acho que numa primeira fase o que é importante é haver uniformização neste campo... Achas que faz sentido continuar na situação actual com cuda e brook+ incompatíveis? Isso apenas lhes vai trazer uma morte prematura...

    Seria interessante ver o OpenCL a criar uma layer que oferecesse um nível de programação mais elevado (oferecendo o suporte para POO por exemplo) e assim teríamos algo parecido com o D3D e OGL...

    Sinceramente só espero que a proposta da m$ para uniformizar as coisas com o CPCPU não seja o único standart criado senão o pessoal do *nix e mac fica a chuchar no dedo (como já anda actualmente no que diz respeito a unified shaders com os sucessivos adiamentos do OGL 3.0)...
     
  6. blastarr

    blastarr Power Member

    O Brook e o CUDA não são incompatíveis.
    A prova é o próprio cliente [email protected]
    Duvido muito que o Vijay Pande e a sua equipa não utilizem muitos dos mesmos componentes em ambas as versões, utilizando apenas um compilador diferente para cada arquitectura de GPU's e CPU's suportada pelo programa.
     
  7. muddymind

    muddymind 1st Folding then Sex

    Isso não é verdade... Existem regras de sintaxe e de operações que são ligeiramente diferentes entre os dois! Li há tempos um artigo a explicar isso mesmo... Se o encontrar logo o posto aqui.
     
  8. DJ_PAPA

    DJ_PAPA Power Member

    OpenCL on the Fast Track


    http://www.hpcwire.com/blogs/OpenCL_On_the_Fast_Track_33608199.html
     
  9. bsd

    bsd Power Member

    Alguém sabe de alguma implementação disto que se possa experimentar?
    Não vejo nada no site da AMD, muito menos no da NVIDIA.
     
  10. muddymind

    muddymind 1st Folding then Sex

    Implementação OpenCL? ainda nem a AMD como a nVIDIA têm suporte para tal e provavelmente só deve aparecer daqui a uns 3-4 meses (segundo uma press da AMD eles já tem a coisa +\- avançada e pode ser que saia qualquer coisa antes). No entanto a especificação já está quase concluída e já podes da uma vista de olhos no que deve ser o seu aspecto enfadonho:

    http://en.wikipedia.org/wiki/OpenCL

    http://www.khronos.org/opencl/

    Mas será que todas as API's do khronos group têm de ser enfadonhas? O nível de abstracção é quase nulo...
     
    Última edição: 20 de Novembro de 2008
  11. bsd

    bsd Power Member

    Obrigado pelo link, parece-me que ainda não tinha visto aquele exemplo na Wikipedia.
    O nível de abstracção não é quase nulo, é o mesmo da linguagem C, tens imensas chamadas a funções naquele exemplo, o que é por definição abstracção, tal como tipos float2 que abstrai um vector bidimensional. Fica é feio com aqueles __global e __local.

    Agora, sou capaz de concordar que o C não é, de longe, a linguagem mais adequada para compilar para uma GPU, nem nenhuma outra linguagem imperativa.

    Uma resposta fora de tempo a este comentário: isto é a Apple no seu melhor. A Apple, bem conhecida pelos NDAs, pelas tentativas sucessivas de pôr os outros out of business por via dos tribunais, pela adopção de soluções proprietárias e pelas técnicas de "fidelização" de clientes, aqui está muito bem a empurrar uma solução padrão sem a qual a programação de GPUs nunca iria para a frente. Programar uma GPU hoje requer muito mais tempo e especialização do que a programação normal, é extremamente dispendioso, e ninguém quer ter essa despesa e ainda por cima ficar agarrado a um só vendedor.

    Felizmente o muddymind postou aqui o link para aquele exemplo e podes ver que não é assim. Aquele código só se adecua a uma GPU, por um lado, por outro, também é difícil enfiar ali código de CPU, porque eu não consigo dividir um programa de CPU normal em "kernels".

    Tens ali todos os elementos da programação de uma GPU, um kernel que pode ser executado paralelamente e que tem em si instruções SIMD e nem sequer tem branches. A única parte chata é, como sempre, o bit shuffle envolvido no twiddle_factor. A maior ou menor eficiêncida não depende em nada do facto de ser CUDA ou OpenCL, depende sim do algoritmo usar ou não saltos, de usar ou não os 4 elementos SIMD, do número de registos que usa cada kernel, quantos kerneis podem correr ao mesmo tempo (limitado pelo número de "threads" e número de registos).

    Só se a NVIDIA fosse manhosa e fizesse um compilador de OpenCL pior do que o de CUDA de propósito é que aquilo saía menos eficiente. Ninguém é tão manhoso a esse ponto.
     
  12. muddymind

    muddymind 1st Folding then Sex

    Era precisamente a essa última parte que me estava a referir... A linguagem C deve ser provavelmente a que melhor faz a ponte entre o ser fácil implementar em GPGPU e ser já muito familiar a praticamente todos os programadores. O grande problema volta-se com o género de aplicações para as quais este tipo de tecnologia vai ser destinada e aí penso que o C decididamente não é a melhor escolha...

    Computação paralela com vários domínios já é suficientemente complexa para que tenhamos ainda que adaptar uma linguagem imperativa ao esquema paralelo e depois venham-se queixar que vai ser pouco o software que tira proveito total destas soluções.

    A khronos infelizmente nunca foi muito boa nesse domínio e basta ver a comparação entre o OpenGL e D3D... Se não fossem as bibliotecas GLU e GLX aquilo era um verdadeiro pesadelo por termos de ir tão baixo na API...
     
  13. bsd

    bsd Power Member

    Não sei em relação à comparação entre OpenGL e D3D...
    Prefiro mil vezes o nível de abstracção do OpenGL do que coisas tipo Java3D que pretendem ensinar o programador a estruturar um programa. Para programar em Java3D tenho que estruturar a coisa em volta da framework, não há forma de usar aquilo como API. Não posso mais com frameworks, sinceramente.

    A única crítica que faria ao OpenGL é a cena dos estados, tenho que estar sempre preocupado com o estado em que está o OpenGL, e o estado é complexo, tem muitos factores. Muito mais coisas deviam ser stateless no OpenGL.
     
  14. MeY-ZiNG

    MeY-ZiNG Power Member

    thread interessante... se calhar ficava é melhor na secção de Programação, onde as pessoas do ramo são mais susceptíveis de opinar
     
  15. syMMys

    syMMys Banido

Partilhar esta Página