Gráfica S3 Graphics Showcases GPGPU

muddymind

1st Folding then Sex
S3 Graphics Showcases GPGPU with S3FotoPro Imaging Application

S3 Graphics, a leading provider of graphics and HD Multimedia technologies, today announced the availability of S3FotoPro, a GPGPU application using the latest programmable architecture powered by the Chrome 400 Series GPUs. Utilizing an array of S3 stream processors, the GPUs can accelerate parallel data workloads and perform work on thousands of concurrent threads to achieve Gigaflops (GFLOPS) of high-throughput computations.

S3FotoPro is an example of a computationally expensive process for image quality improvements that is best achieved on a GPU instead of a CPU due to the S3 stream processor architecture. The algorithm complexity and high calculation requirements required by S3FotoPro enables the parallel workload speedup to be magnitudes (>100x) of times faster than the latest CPUs in the market today. In addition, the GFLOPS-per-Watt and GFLOPS-per-Dollar favor the GPU computational efficiency over standard CPU calculations.

"S3 Graphics continues to develop and bring to market cutting edge technologies that use the power of the GPU to meet new demands in emerging computation-intensive markets. Application processes that required days can now be completed in seconds using a GPGPU product like ours," said Michael Shiuan, VP of Hardware Engineering at S3 Graphics. "With support for the latest GPGPU applications and languages, S3FotoPro provides a highly useful and versatile tool for end-users and our partners."

"Markets that can benefit from S3 Graphics GPGPU technology include High-Performance Computing (HPC), HD video transcoding/encoding, scientific, engineering, medical, imaging, physics, and many other areas," said Dr. Ken Weng, GM for S3 Graphics. "The potential and opportunities to leverage this novel technology are just starting to open up and the full potential has yet to be realized."

fonte

Parece que o GPGPU veio para ficar :P
 
A aplicação também funciona com o Cpu.
Com jpgs de 2 MB num atom a 1.6 ghz, o processamento foi bastante rápido (questão de menos de 10 segundos por imagem, com outras aplicações a correr)
No fim, tem um viewer para comparar as imagens originais com as processadas e ou foi das imagens que usei ou não notei qualquer diferença a nível de qualidade. Apenas reduziu tamanho dos ficheiros.

Ah....e a aplicação instala na raíz do C: :confused:

Sinceramente, não sei se será a melhor aplicação para mostrar o poder dos Gpu, mesmo com imagens maiores. Tenho algumas duvidas que seja mais rápido que um cpu recente.
Alguém tem uma S3 400 para comparar com o cpu?
 
A aplicação tem como objectivo mostrar a vantagem de GPGPU em processamento de imagens que em muitas áreas é bem mais crítico do que tu pensas... Imagina a seguinte situação:

Está a ser feito um spot a 1080p onde os resultados são guardados em frames individualizados em JPG's (ou PNG para qualidade mas estes sofrem do problema de serem mais pesados em processamento). No final normalmente são aplicados filtros para fazer algumas correcções de tonalidades e nisto este tipo de aplicações podem tornar algo de horas em escassos minutos.

É precisamente esse boost de performance em certas aplicações que a VIA quer transmitir e não a funcionalidade em si daquela aplicação em específico :P

Estou é há espera de ver o SDK deles para isto para ver se consegue chegar ao nível do CUDA (e deus queira que seja bem melhor que o brook+ que para mim tem um paradigma de lógica paralela extremamente limitado e bem mais difícil de tirar partido... quando o GPGPU começar a ser usado em massa tou mesmo a ver a AMD em maus lençóis...)
 
Estou é há espera de ver o SDK deles para isto para ver se consegue chegar ao nível do CUDA (e deus queira que seja bem melhor que o brook+ que para mim tem um paradigma de lógica paralela extremamente limitado e bem mais difícil de tirar partido... quando o GPGPU começar a ser usado em massa tou mesmo a ver a AMD em maus lençóis...)

Nenhuma delas é uma linguagem aberta portanto têm a morte anunciada.
O futuro das aplicações GPGPU onde podem começar a ganhar maior notoriedade no mercado vai começar com o Open CL + DX_11.
http://en.wikipedia.org/wiki/OpenCL

Quer a AMD, quer a Nvidia ou a Sis se não apostarem forte no Open CL e em linguagens abertas muito rapidamente poderão a arrepender-se mais tarde.
O Brook+ so corre em AMD. O Cuda so corre em Nvidia. O Larabee tb nao usará Cuda ou Brook+.

O Larabee da Intel pode vir a não ser grande coisa a reproduzir gráficos, mas vai ser um pequeno monstro em FP colocando-o em pe de igualdade de processamento ao nível dos GPU´s. Isto compatível com X86 e portanto em principio rapidamente o Java, C#, Python, watever poderão aparecer a suportar o Larabee que são linguagens muito alto nível, abertas e a Intel tem muito dinheiro para mexer com tudo isso.

E mesmo assim quer o Brook+, Cuda, Open CL são todas linguagens C o que nos dias de hoje ja não é muito agradável programar. Pelo menos desenvolvam uma linguagem C aberta para ter algum interesse. Se há coisa que se aprende no sector é manteres-te sempre em open-standarts.
 
Última edição:
A aplicação tem como objectivo mostrar a vantagem de GPGPU em processamento de imagens que em muitas áreas é bem mais crítico do que tu pensas... Imagina a seguinte situação:

Está a ser feito um spot a 1080p onde os resultados são guardados em frames individualizados em JPG's (ou PNG para qualidade mas estes sofrem do problema de serem mais pesados em processamento). No final normalmente são aplicados filtros para fazer algumas correcções de tonalidades e nisto este tipo de aplicações podem tornar algo de horas em escassos minutos.

É precisamente esse boost de performance em certas aplicações que a VIA quer transmitir e não a funcionalidade em si daquela aplicação em específico :P

Estou é há espera de ver o SDK deles para isto para ver se consegue chegar ao nível do CUDA (e deus queira que seja bem melhor que o brook+ que para mim tem um paradigma de lógica paralela extremamente limitado e bem mais difícil de tirar partido... quando o GPGPU começar a ser usado em massa tou mesmo a ver a AMD em maus lençóis...)

Eu percebi o que a Via pretende demonstrar. Mas o que eles estão a demonstrar já a nVidia começou a aplicar no CS4.

Eu só duvidei dos números, depois de experimentar a aplicação num processador fraco.
Por isso perguntei se alguém tem uma S3 400.

Fora a demonstração, a S3 só tem hipótese neste mercado se todos os fabricantes começarem a usar a mesma linguagem.
Isto faz lembrar os tempos do Glide, powersgl, redline, metal, etc.
 
Nenhuma delas é uma linguagem aberta portanto têm a morte anunciada.
O futuro das aplicações GPGPU onde podem começar a ganhar maior notoriedade no mercado vai começar com o Open CL + DX_11.
http://en.wikipedia.org/wiki/OpenCL

A questão é que o paradigma de todas as alternativas hoje acabam por ter elos comuns o que permite criar por drivers uma layer que converta OpenCl em CUDA/Brook+/(sem nome da VIA)... Basta ver por exemplo o port do physX para as ATI.

O problema do lado da ATI que referi tem a haver com o seu sistema de shaders que tem um regime de domínios rígido e muito pouco flexível caso querias tirar todo o proveito deles para paralelismo e isso é coisa que não acontece com as nVIDIA. Para ver realmente as consequências dessa situação vejam por exemplo o cliente de folding que o da nVIDIA arrasa completamente o da ATI mesmo sendo que o da ATI já está bem mais maduro...

E mesmo assim quer o Brook+, Cuda, Open CL são todas linguagens C o que nos dias de hoje ja não é muito agradável programar. Pelo menos desenvolvam uma linguagem C aberta para ter algum interesse. Se há coisa que se aprende no sector é manteres-te sempre em open-standarts.

E sinceramente acho que as coisas não melhoraram com o OpenCL... Em termos de formalização acaba por ser superior às alternativas CUDA/Brook+ mas em termos de simplicidade aquilo é horroroso... Mais uma vez tornaram um open-standart enfadonho :rolleyes: (basta ver a diferença do D3D para o OGL para perceberem o que quero dizer...)
 
Back
Topo