Hola :) El Monday 23 February 2009, Juan Erbes escribió: [...]
Segun el mismo link, parece que intel continua copiando a AMD, despues de copiar el set de instrucciones X86-64, ahora tambien agrega el controlador de memoria, como lo trae la linea de procesadores Opteron y Athlon64 en adelante. Pero intel, va un paso mas adelante, agregando tambien en el mismo encapsulado el controlador de video, lo cual puede llegar a transformarse en un paso en falso, como lo fueron en su momento sus chipsets para el uso de memoria Rambus.
Esto lo está haciendo AMD también. El foco de los fabricantes de chips es que la GPU sea un core más dentro del die de lo que es actualmente una CPU multicore.
Hasta donde se, AMD está integrando el GPU con el chipset del mobo, pero no en el micro como tu dices. Tenés algun link para reafrimar lo que decias?
http://www.reghardware.co.uk/2006/10/26/the_story_of_amds_fusion/
"Start equipping CPUs with their own graphics cores and it certainly sounds like you'll have an SoC part on your hands. Not so, says Hester. Fusion will not just link monolithic components on a single die - the traditional SoC architecture - but will break these components down into more basic parts that can be mixed and matched as needed then linked together using AMD's Direct Connect technology."
Ok, pero una cosa, es que AMD te ponga un chip de video ATI, de rendimiento excelente, en el mismo encapsulado del micro, y otra cosa, es intel, que tiene chips de video de bajo rendimiento, que solamente se pueden comparar en rendimiento con los chips obsoletos de otras marcas. Quizas esa sea una de las razones por las que el Core i7 pierde tanto terreno en video y juegos de alta definición frente al Phenom 2.
Para gráficos posiblemente sí dé más rendimiento (ATI/AMD y/o NVIDIA), pero en cuanto a GPGPU, la verdad es que ATI/AMD se oye poco, al igual que Intel. El que más ruido está haciendo es NVIDIA. Pero eso no es lo único que hay que tener en cuenta. Intel lo que propone es una GPGPU con instrucciónes x86(-64) de forma que no hay que hacer ningún porting (o por lo menos que sea mínimo), no hay que reescribir (tanto) código, ... Tanto en el caso de ATI/AMD como en el de NVIDIA (CUDA+TESLA), hay que reescribir código (porting), lo cual supone unas cuantas horas de análisis y escritura de código. Esto no es una tarea fácil. Actualmente, hay mucha investigación en esto de las GPGPUs, pero deployments reales en producción hay pocos y casi todos en entornos científicos en los que hay un becario sentado programando sin ver el sol. Es una tecnología nueva, hay que ver realmente para qué vale y para qué no vale, cuándo usarlo, sacar aplicaciones con soporte "out of the box", ... todo eso requiere tiempo = dinero. No pienses sólo en si ATI/AMD y/o NVIDIA dan mejor calidad de imagen, FPS, ... En estos casos (GPGPU), eso no es lo más importante. Por ejemplo, he visto benchmarks que demuestran que usar GPGPU para determinados códigos de biología no dan todo el rendimiento esperado, que da mejor rendimiento el usar las instrucciones SSE de tu procesador. En este caso, efectivamente, me da igual que ATI/AMD y/o NVIDIA tengan mejor rendimiento gráfico ya que me da mejor rendimiento una CPU moderna. No se está midiendo el rendimiento DirectX ni OpenGL. Curiosamente. En cuanto a Larrabee vs Fusion vs Tesla, algunos clientes piensan: "Bueno, a lo mejor Larrabee no me da el renidmiento que me puede dar Fusion o Tesla, pero por lo menos no invierto tanto tiempo (lease dinero) en hacer el porting y no me hace falta contratar a una persona exclusivamente con conocimientos de GPGPU que me va a cobrar el doble. De esta manera, no sólo saco un producto más barato (en el que he invertido menos dinero y tiempo), sino que soy el primero en sacar un producto (aka Time to Market)." Recuerda, no basta con tener un producto bueno, de lo contrario AMD/ATI y Linux dominarían el mercado y serían ellos el monopolio ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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