AMD APP SDK 2.8 llega con impresionantes mejoras de rendimiento GPGPU
Han pasado siete meses desde el lanzamiento de AMD Accelerated Parallel Processing (APP) SDK 2.7, el OpenCL ICD (Installable Client Driver) con soporte al API estándar de cómputo acelerado por GPU/CPU (x86/ARM)/FCPGA/CMOS OpenCL de Khronos Group, un largo periodo en que no actualizaban su ICD; pero AMD asegura que la espera valió la pena y hoy nos presentan su nuevo APP 2.8.
El nuevo AMD Accelerated Parallel Processing (APP) SDK 2.8 promete mejoras de rendimiento de hasta un 130% (2.3X) para las aplicaciones aceleradas por GPU (GPGPU), en comparación con el rendimiento ofrecido por el anterior ICD OpenCL SDK 2.7, y consolidando el gran rendimiento ofrecido por los GPUs AMD en aplicaciones OpenCL (aquí otro test GPGPU), tanto en aplicaciones domésticas como para supercomputadores.
APP SDK 2.8 también incluye una nueva librería de plantillas C++ (nombre código Bolt), las que comprenden aplicaciones de muestra OpenCL, Aparapi y C++ AMP.
AMD también pone a disponibilidad su nueva AMD CodeXL, una suite de herramientas para desarrolladores enfocadas a optimizar y depurar aplicaciones OpenCL con el fin de que estas alcancen el mayor desempeño posible en los GPUs y APUs de AMD.
AMD APP SDK 2.8 es compatible con Linux (OpenSUSE 11, Ubuntu 11 y RHEL 6) y Windows Vista y superiores, y requiere que se tengan instalados los controladores AMD Catalyst 12.10 WHQL y superiores; además se requiere de un CPU con soporte al juego de instrucciones SSE2 o superior.
Link: AMD APP SDK 2.8 and CodeXL released (DarkVision Hardware)
También pueden comentar en nuestro foro.
Intel fabricará microprocesadores a medida para...
NVIDIA presenta oficialmente su nuevo GPU GeFor...
Intel Core i7-4770K “Haswell-DT” versión comerc...
Hacer una réplica por supercomputador del cereb...
Smart Dust: La computadora más pequeña que un g...
AMD anuncia su promoción Never Settle Reladed L...
AMD lanza su GPU Radeon HD 8970M “Neptune”
Se filtran imágenes, especificaciones y precio ...
46 Comentarios
AMD APP SDK 2.8 llega con impresionantes mejoras de rendimiento GPGPU
@WINTENDOX. Estas completamente desactualizado, muchos juegos lanzados este año usan técnicas y efectos basados en compute shaders (GPGPU bajo las API DirectCompute de Microsoft, OpenCL y CUDA). Entre ellos podriamos mencionar a Dirt Showdown, Far Cry 3, Assassins Creed 3, Hitman: Absolution, Sleeping Dogs, el futuro Crysis 3 y muchos de los juegos que saldran el próximo año.
Además muchas aplicaciones domésticas usan OpenCL como WinZIP, Photoshop, Premiere, PowerDirector, Vegas, TheaterTek, GIMP, varios encoders de video y sonido, entre otras muchas aplicaciones enfocadas al video, CAD y raytracing; así como también lo tendremos en los navegadores web del próximo año empezando por Firefox.
Saludos.
Yo te voy a preguntar si no sirve para juegos, cuando los motores de físicas empiecen a mover parte del cálculo al GPU, como lo hace physix lástima que use CUDA y no OpenCL (por el temor de nvidia a que corra mejor sobre AMD).
@nicolas(Mua). Al igual que en el uso de la física acelerada por GPU, obviamente al destinar varios shaders al cálculo de efectos en vez de a dibujar polígonos, se dan reducciones al rendimiento, como por ejemplo los vistos al usar PhysX por GPU en algunos de los pocos juegos que los soportan.
Tanto AMD como Nvidia ya han anunciado que casi la totalidad de juegos que patrocinaran usaran este tipo de efectos, así que sea o no beneficioso (según el punto de vista de cada uno), aunque algo tarde, GPGPU llego para quedarse en el mundo de los juegos.
Saludos.
buuu, esta vez te come el monstruo. Tu libretista está wateando wn, dile que se esmere más.
Muy bien nicolás, según vos la vga sólo debería renderizar poligonos planos, como hace pocos años.
Los shaders pesados no sirven para nada, las físicas pesadas tampoco (y con esto me refiero a tener muchísima cantidad de objetos colisionando).
Sabes cuanto le cuesta al CPU agarrar primero y simular cada uno de los objetos de una escena, en que posición estarán en el siguiente cuadro (tarea muy muy paralelizable que puede correr bien en un GPU) y luego que hizo esta simulación mirar uno por uno los objetos a ver si están chocando con otros (escenario muy bueno para correr con muchos hilos, o en un gpu). Y luego encima calcular en base a lo anterior el estado del objeto (vectores de velocidad, aceleración, impulsos, etc).
Ojala vieras como se arrastra una simulación de fluidos en un CPU para que cambies de opinión.
@LM: Entonces no nos podemos quejar de que los juegos cuyas fisicas son acelerados por GPU se vean feos, pues el GPU tiene que encargarse de las fisicas y del Renderizado AL MISMO TIEMPO (simultaneamente), haciendo que pierda ciclos en calcular la fisica (si se ejecuta un juego en un GPU de 1 GHz, la fisica ocuparía un ~30% dependiendo de la escena pues si hay simulaciones grandes como derrumbes o fragmentaciones o rupturas puede ocupar más, y el renderizado ocuparía el resto; terminando con un GPU el cual solo tiene una capacidad efectiva para los gráficos del ~70%, en el ejemplo danterior, son 700MHz)...
A no ser que uses el lenguaje ensamblador de cada GPU para programar la gráfica y la fisica, haciendo al programa compatible solo con los mismos GPU que usas...
Para mi es preferible optimizar los programas con las instrucciones adecuadas (AVX, SSE, etc), y hacer que el programa pueda detectar y usar todos los hilos que puede proveer el CPU, quedando el i3 con 4 hilos, y el FX-8350 y el i7-2700K con 8 hilos, los cual los dejaría más parejos; o bien pongan como requerimientos minimos un CrossFireX/SLI con 2 tarjetas de video de diferente capacidad, asignen la más potente para el renderizado y la otra (la menor) para la fisica; el nombre para esas piezas o configuraciones seria "Acelerador de fisicas" o algo parecido.
@aja. He vuelto a leer mis comentarios, y sinceramente no veo en que parte esté defenciendo a AMD, simplemente le señalé a Wintendox que varios juegos actuales si usan computo acelerado por GPU desde las API OpenCL (Khronos), DirecCompute (Microsoft) y CUDA (Nvidia).
No participo mucho en el Blog por falta de tiempo, y cuando tengo tiempo sólo lo hago en temas como este donde se mantiene ordenado y sin el festival de descalificaciones a los que lamentablemente se llega en otros temas, en los que no da ganas ni de comentar algo... Esperemos que no ocurra ello con este tema.
@Dnuke. El tema del uso del GPU para el cálculo de dichos efectos creo más va por las futuras consolas, las que al parecer se apoyaran en el GPU para dichos cálculos, por lo que sus CPUs al parecer no lucen tan impresionantes como muchos nos imaginabamos.
Claro que en los juegos para PC sería preferible usar la potencia desperdiciada de los actuales CPUs, y no sólo sus avanzados juegos de instrucciones, sió los múltiples núcleos e hilos de procesamiento que poseen, pues actualmente mas del 90% de los juegos no le sacan partido a más de 2 núcleos.
Saludos.
ya te eligieron como el mejor troll del año estas contento de haberle ganado a kyo ahora callate que ya te ganaste tu premio.
Noob total, se entiende jaja.
@dnuke eso es muy relativo. Si vos tenés dos unidades de procesamiento (gpu y cpu), y a uno lo ponés a hacer una cosa, en ese instante no puede hacer otra, eso es obvio.
Ahora, ponete a pensar como funciona un juego, el CPU calcula el estado de la escena y luego lo dibuja (ahí ves 1 frame en la pantalla). Ahora bien, mientras el CPU calcula la física, el GPU no está haciendo nada, porque si no has calculado la posición de un objeto, no lo podés dibujar!
Tomando lo anterior como un hecho, el GPU siempre va a estar 100% disponible para dibujar la pantalla, cuando ya se haya calculado toda la física. Lo único que quita rendimiento es el cambio de contexto que se produce en el GPU: mientras calcula físicas probablemente deba liberar algun recurso que uso en la etapa del renderizado del frame anterior (caches, memoria, registros, etc.), pero no mucho más. Los juegos que usan physx por ejemplo, se enlentecen pero porque la escena se sobrecarga de efectos que quitan tiempo a la etapa de calculo del estado de la escena, no porque el GPU este dibujando las cosas a sólo un 70% de la velocidad, como vos pensas.
Y así fue como wintendox inicio su campaña para defender su título de troll del año de su nuevo rival kyo cuando nisiquiera terminamos este
ResponderNi modo, tiene que lucirse para el proximo año XD
Yo sigo insistiendo, eso (wintendox) no da para troll... un troll normalmente es inteligente y/o tira comentarios que sabe que a la gente no le van a gustar... lo que hace eso y el otro (kyo), dicen lo que piensan... y lo que dicen da para pensar si tienen cerebro o no
AMD NEVER SETTLE!
Responderexcelentes mejoras de opencl, todavia falta mucho para que se masifique, pero es un paso.
ResponderHabría que ver cómo reacciona este E-350 con el PS-CS6. Quizás se recupere y quede a la altura de mi pc de escritorio, ese 130% suena increible para ser una simple actualizaciòn en la versión del APP.-
ResponderNo Pidas milagros. un E-350 solo queda como centro multimedia y ahi queda.
El CS5 corre perfecto acá, me ha salvado varias veces cuando mi tarro ha caido enfermo o está lejos.
No es de fanático... cuando no tenía tarjeta dedicada, andaba mejor que mi tarro de escritorio, además estoy diciendo que tengo que probar cómo anda... No sé que parte no se entiende.
Le instalé al E-350 la APP y los Catalist 12.10 y la mejora es re poca al menos en video a 1080p no es que tenga un 130% de mejora, aunque no apliqué nada de bench, sólo instalé y miré antes y después de instalar el mismo video.
Cuando pueda probaré con los 12.11 a ver si hay algo importante... pero de momento, no aprecio esa tremenda mejora que vocifera AMD.-
@C4ct00s. La mejora es sólo para aplicaciones OpenCL, no para el motor de reproducción de videos acelerado por hardware (UVD) que es el que se usa en la reproducción de contenido, el cual por cierto no ha recibido mejoras de rendimiento o de formatos soportados desde hace mucho.
Saludos.
a dale... probaré con algún editor de video después de los examenes entonces... aunque para esa fecha esta noticia estará como 100 hojas más atrás xDD
nicolas(Mua) y bien a lo chileno Y CON TODO RESPETO!! , PUTA QUE HABLAI WEAS WN OHHHH ... y juras que todas esas ideas que salen del par de neuronas que tienes en tu cerebro son logicas pfff el wintendox ,kyo y tu tienen la mente mas cerrada q la cresta y juran que ustedes son dueños de la verdad , bueno eso , saludos :D
ResponderPrecisamente nicolás es de los pocos que si trollea lo hace con ambas marcas, y nunca lo he visto defendiendo a una únicamente...
en eso estamos de acuerdo pero voy a que trollea con muy poco sentido... como que tiene ideas vagas de lo que opina ... :P pero bueno es mi opinion y me tiene chato po que queri que le haga jajajajaja
Lo que dice ese loco, no es de los que habla weas, o si lo hace, lo hace a proposito... si bien opina en lo que puede y que no siempre nos gusta lo que a el le gusta, pero al menos tiene opinion y puede comentar tranquilamente.
Los otros 2 hablan weas porque no les da para mas :yaoming:
@David Sarmiento
ResponderCuando dicen que rinde 130% más ¿estás seguro que se refieren a 2.3 veces el rendimiento original, es decir, 230% del rendimiento original? ¿no será que se refieren a 1.3X, 130% del rendimiento original?
Me suena muy surrealista un aumento de más del doble del rendimiento, mucho más creíble sería un 30% mas.
Saludos!!
@davidcianorris:
The AMD APP SDK 2.8 includes dozens of new and improved samples for OpenCL™, Aparapi and C++ AMP that deliver significantly faster performance than APP SDK 2.7 – up to 2.3x faster3 on average in 9 key benchmarks Furthermore, virtually all samples are licensed under permissive open source licenses..
http://blogs.amd.com/developer/2012/12/04/more-options-for-accelerating-compute-on-amd-platforms/
Saludos.
@javier. Far Cry 3 no mejorará su rendimiento con el ICD OpenCL 2.8, pues sus efectos GPGPU usan el API DirectCompute, el cual se actualiza junto al controlador gráfico. Los drivers Catalyst 12.11 beta 11 si mejoran el rendimiento en Far Cry 3.
Saludos.
Hasta donde entendí, no verás mucha mejora en juegos, pero si en programas de producción y trabajo.
Gracias a los dos.
Siempre pense que el APP SDK significan las herramientas que se les entregan a los desarolladores para explotar las caracteristicas de dicho hardware, por ende por lo que yo pienso si el Far Cry 3 se copilo en APP SDK 2.7 o 2.6 no sufririan dichas mejoras a menos que saquen un parche del juego. Estoy en lo sierto?
Respondererror de tipeo .. cierto
@mendozakk. APP SDK incluye tanto el driver (ICD) OpenCL como las herramientas para desarrolladores. Siempre AMD publica primero sus nuevos ICD OpenCL junto a las herramientas para desarrollador, para posteriormente incluirlo en sus controladores Catalyst, por lo que no sería de extrañar que los futuros Catalyst 12.12 o 13.1 incluyan de serie el nuevo APP (los actuales vienen con el 2.7).
Far Cry 3 usa DirectCompute y no se beneficia de las mejoras en el ICD de este nuevo APP.
Saludos.
Cuando veremos un test actuaizado con el SDK 2.8?
ResponderNo sé si esta semana me daré tiempo para hacer un test del nuevo APP 2.8, pero en la web de AMD publican algunos mini-bench:
Tests conducted at AMD using performance optimized code samples from AMD APP SDK 2.8 compared to those from 2.7. On a notebook PC with AMD A10-4600M APU with Radeon™ HD 7660D graphics, 2x2GB of DDR-1600 RAM, and Windows® 7 Pro 64-bit, video driver 9.011, the times to execute the code samples are as follows: AESEncryptDecrypt (.024 seconds for SDK 2.7 vs .005 seconds for SDK 2.8); BinarySearch (.028 vs .003); BitonicSort (5.36 vs 0.14); RadixSort (.015 vs .011); ScanLargeArrays (.16 vs .08); Histogram (.20 vs .10); HistogramAtomics (.026 vs .025); QuasiRandomSequence (.037 vs .017); and MonteCarloAsian (1.84 vs .85) for an average time of .114 seconds for SDK 2.7 vs .034 seconds for SDK 2.8 across the 9 samples.
http://blogs.amd.com/developer/2012/12/04/more-options-for-accelerating-compute-on-amd-platforms/
Saludos.
wii u ahora es un 130% más rápida.
Responderahora se entiende el interés de todos por una gpu AMD en las consolas.
Deja tu Comentario