El día 30 de diciembre de 2009 13:33, Rafa Grimán
Hola :)
On Wednesday 30 December 2009 16:44:18 Juan Erbes wrote:
El d�a 30 de diciembre de 2009 12:34, Juan Erbes
escribi�: El d�a 30 de diciembre de 2009 11:25, Carlos E. R.
escribi�: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-12-30 a las 09:30 +0100, Rafa Grim�n escribi�:
Hola :)
On Tuesday 29 December 2009 22:43:10 Carlos E. R. wrote:
On 2009-12-29 17:01, Carlos E. R. wrote: > El 2009-12-29 a las 12:04 -0300, Juan Erbes escribi�:
[...]
Conclusi�n: el modo "threaded" empeora considerablemente la velocidad de �conversi�n xvid.
�Has probado a desactivar el SMT o HyperThreading o como lo llame Intel? Se hace desde la BIOS.
Lo pregunto porque he visto en demos de la propia Intel que hay veces que el tenerlo activado no es del todo bueno. Tambi�n lo he visto en pruebas realizadas por nosotros en determinadas aplicaciones HPC.
Interesante. A ver si me acuerdo de mirarlo.
Pero ten en cuenta que s� veo mejora con esa aplicaci�n generando mpeg4. Seg�n el c�dec que elijas, se usa una librer�a u otra, que creo desarrolladas por diferentes equipos. Y en los foros se comenta precisamente que libxvid va lenta incluso en modo threaded. Que s�lo separan un hilo para el video, otro para el sonido, y otro para la multiplexaci�n. Si fuera una aplicaci�n realmente paralelizada, el v�deo se dividir�a en varios hilos.
Lastima que en Linux no tengamos ningun software de codigo abierto para hacer esa conversi�n mediante ATI Stream o Nvidia Cuda:
http://foros.3dgames.com.ar/hardware.31/493181.respuesta-ati-cuda-ati-str eam-computing.html
Bueno, al menos del lado de ATI, publicaron el sdk 2.0 con OpenCL 1.0 para Opensuse y ubuntu hace menos de 10 dias: http://developer.amd.com/GPU/ATISTREAMSDK/Pages/default.aspx#five
Cierto, es una pena que las GPGPUs no se estén tomando más ne serio ... es cuestión de tiempo ;)
Tanto STREAM de ATI como CUDA/Tesla de NVIDIA son buenas tecnologías siempre y cuando las aplicaciones que vayas a portar tengan instrucciones SIMD. Además de eso, hace falta tener las herramientas de desarrollo: librerías, compiladores, ...
Hoy por hoy, esta tecnología está en su infancia y aún queda. Cada vez hay más aplicaciones que están adoptando esta tecnología:
http://www.nvidia.com/object/cuda_home.html
http://www.amd.com/us/products/technologies/stream- technology/commercial/Pages/partners.aspx
http://developer.amd.com/samples/streamshowcase/Pages/default.aspx
Pero no es "main stream".
Hacen falta los programadores, que desarrollen las aplicaciones de conversi�n, usando esa tecnolog�a.
Efectivamente, pero he visto que en algunas Universidades se imparten cursos de programación de GPGPUs. A ver con qué nos sorprenden las nuevas generaciones ;)
En todo caso, tanto Intel como AMD dijeron que su meta era que la GPGPU fuera parte del socket. Es decir, que fuera un "core más". Según los roadmaps publicados de Intel, es lo que va a empezar a hacer con Westmere y continuar desde allí.
Ya, ya sé que Westmere lo que incluye es un core gráfico, no realmente una GPGPU, pero desde allí avanzar ese core gráfico para convertirlo en una GPGPU, es decir, el famoso proyecto Larrabee. Ya veremos lo que saldrá.
Esto deja a NVIDIA cojo porque tanto AMD como Intel tienen su CPU y GPU.
Algo mas sobre OpenCL: http://www.youtube.com/watch?v=IEWGTpsFtt8&feature=related http://www.youtube.com/watch?v=7PAiCinmP9Y&feature=related Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org