TUTORIAL para usar tecnologia mmx

[synchrnzr]

                                Para DraKKar: me suena que hay que incluir unas librerías de Intel. Que no sé si se pueden bajar gratuitamente o hay que comprarlas...

Por lo demás, hay que decir que entreveo un pique Berserker <-> ethernet que creo que es mejor que no desarrolleis en los foros (ni en C ni en ASM XDDD)

Algo que veo que ha sido muy obviado: el ensamblador se utiliza ampliamente en la programación de consolas (por la experiencia que tengo, mi SyncAGB es 100% código ensamblador del chip ARM7TDMI, así como el resto de motores de sonido y algunos motores 3D que hay para la misma consola) y en la programación de algunas recreativas serie B que se basan en chips de Intel de la serie 80x86 y necesitan estar bastante optimizadas (en el fondo son como PCs antiguos)

Eso sí: para Windows o para Linux, la programación en ensamblador tiene muchos más inconvenientes que ventajas. Yo hace tiempo que he dejado de programar en ensamblador para estas plataformas. Aunque creo conocer bastante a fondo la arquitectura de los procesadores actuales, el tiempo empleado en el desarrollo de un código en ensamblador más óptimo que el que genera el propio Visual C++ no me compensa el tiempo dedicado a programarlo. Ahora bien, para los más puristas, tened en cuenta que podeis compilar vuestro .C en un .ASM y luego ahí depurad lo que podais (hay un mensaje sobre cómo hacerlo en otro post de estos foros)

Venga, un saludo

Sync                                

[fiero]

                               

El 2002-08-29 12:50, DraKKaR escribió:
Por cierto, sabeis si el Visual Studio 6 hace algun tipo de optimizacion (o se puede activar) para distintas CPUs? Si hace optimizacion MMX, 3DNow!, SSE...?

Creo que no. Si se examina el código generado, se ve que solo emplea instrucciones genéricas del 80486...

En cuanto a lo de usar o no ASM, solo decir que la libreria de microsoft D3DX hasta la versión DX7 sólo eran un conjunto de funciones de ayuda escritas en C. A partir de la versión DX8 ya no hay código C, las funciones las han hecho directamente en ensamblador. Si trazais una de esas funciones (por ejemplo D3DXMatrixMultiply)vereis que dispone de código normal,SSE,MMX,3DNOW, y salta a uno u otro dependiendo del procesador que tengas.

saludos                                

[HaltedMode]

                                  Fiero no estoy muy seguro de estar en lo correcto, pero si con lo de trazar te refieres a debuguear la ejecucion de tu programa, las instrucciones que te apareceran estaran siempre en ensamblador(dado que lo que estas viendo en la pantalla de debug es lo que esta ejecutando el procesador), a menos que tengas el codigo fuente original(pues en ese caso puedes elegir entre ver el codigo ensamblador o el codigo C o ambos mezclados, al menos asi es el debug de Borland), sin embargo dudo que Microsoft te haya entregado el codigo original de las librerias DirectX :sonriendo:.
Lo que me hace pensar esto, es que como tu has dicho, el codigo cambia a un tipo de instrucciones segun el procesador que tengas.

Saludos.

[ Este Mensaje fue editado por: HaltedMode el 2002-08-29 13:42 ]                                

[BeRSeRKeR]

                                :riendo:

¡Saludos!
                               

[fiero]

                               

El 2002-08-29 13:39, HaltedMode escribió:
 Fiero no estoy muy seguro de estar en lo correcto, pero si con lo de trazar te refieres a debuguear la ejecucion de tu programa, las instrucciones que te apareceran estaran siempre en ensamblador(dado que lo que estas viendo en la pantalla de debug es lo que esta ejecutando el procesador), a menos que tengas el codigo fuente original(pues en ese caso puedes elegir entre ver el codigo ensamblador o el codigo C o ambos mezclados, al menos asi es el debug de Borland), sin embargo dudo que Microsoft te haya entregado el codigo original de las librerias DirectX :sonriendo:.
Lo que me hace pensar esto, es que como tu has dicho, el codigo cambia a un tipo de instrucciones segun el procesador que tengas.

Estás en lo cierto, eso pasa por ejemplo al debugear código de las MFC o de otras librerias en las que se cuenta con el código fuente en C. Sin embargo a partir de DX8 ya no viene el código fuente en C. Se nota que está programado directamente en ASM al ver el código, además eso de saltar a un grupo de instrucciones u otro no lo hace ningun compilador :ojo:

saludos                                

[ethernet]

                                para synchrnzr:
al mensaje q me referia era al de WhiteBlaizer q si lo has leido va con animo de ofender. Por lo menos he visto q se sigue con la tematica del thread ( q me parece muy interesante)


Saludos


                               

[WhiteBlaizer]

                                tarjeta de red o como sea :sonriendo:
Si has leido lo que puse... no va con animos de ofender a nadie, asi es como lo ves tu... pork lo mas seguro te sentiras identificado con algo k haya dicho en este post o en otros... si su majestad se ha molestado k se le va a hacer... tu mismo con el dolor :lengua: no te voy a pedir disculpas.

Hay k ver como os pone internet... k pocas neuronas de compresion se os keda... si cogeis todo como si os insultaran... anda ya y el k se ofenda con algo k se meta bajo tierra y k no sepa de los demas.                                

[WhiteBlaizer]

                                Por cierto se me olvidaba reirme:
ajajajajjaajajajajajaa :riendo: es buenismo. La variedad de peña rara k se encuentra uno...                                

[x-alien]

                                joder el post crece.. me ausento y no veas k de peña...

yo ahora estoy aprendiendo ASM.. ensamblador!! no me gusta decirle ASM como los guiris.

uno no se puede o deberia llamarse asi mismo programador si no sabe ensamblador, weno es mi opinion.

el ensamblador es lo mejor para optimizar y aumentar el rendimiento, es mi opinion.. hay kien dice k ya no hace falta pero yo lo estoy aprendiendo por gusto, es mu intertesante el ensamblador.

el programa k uno hace debe estar optimizado al 100% y usar el 100% de lo k hoy dia existe... tecnologia mmx, optimizacion para los pentium 2, 3, 4 y amds(con su 3dnow).  

os recomiendo useis ASM y las funciones del c++ inline.
las funciones inline mejoran mucho el rendimiento del programa y su rapidez pero aumenta el tamaño del exe, no hay k abusar de ellas.

ahora estoy liao con el ensamblador y las cg de nvidia k son muy muy potentes... tan potentes k en el siggraph de este año han puesto el final fantasy(la peli) en tiempo real con una quadro ddc, el programa es de nvidia promocionando su cg... ami me ha engatusao jeje.

saludos
                               

[Emotion]

                                gueno, gueno, vayamos por partes, decia jack el destripador... :sonriendo:

bueno, despues de este caustico chiste malo, vayamos a lo que vamos...

El ASM (o ensamblador para los amantes de los terminos faciles :sonriendo:) es muy bueno precisamente por el hecho de aprovechar la maquina, porque imaginemos que tenemos un motor o mas que un motor, un juego corriendo y que en cada frame el codigo utiliza un 97% de la CPU. Si ese codigo se pudiera optimizar con el ensamblador y, digamoslo como un ejemplo, somos capaces de ganar un 15% de CPU sustituyendo ciertas funciones de alto nivel por otras con partes escritas en ASM o totalmente escritas con ASM, eso simple y llanamente significa que nos sobraria un 18% de CPU para poder implementar mas efectos, con lo cual ganariamos mucho, y en cualquier caso, aun no ganando nada 'visualmente', el codigo siempre se ejecutara mas rapidamente o utilizara la cache de una manera mas eficiente, y eso es decir mucho cuando se habla de procesos criticos, como tareas de render o en este caso, cualquier proceso que complemente al render, que ya es mucho ganar...

en cuanto a lo de la exhibicion de NVIDIA, si, ya habia escuchado algo parecido, incluso antes de eso hicieron un render en tiempo real de la misma pelicula, pero usando una GeForce3 y el invento tiraba a 20FPS, creo, venia en una pagina de internet, solo que no lo recuerdo, sino pondria el enlace... tambien he escuchado que ATI, no queriendo quedarse atras, ha hecho lo mismo, pero renderizando unas secuencias del señor de los anillos utilizando el hardware de la nueva Radeon 9700, estaria bien poder ver esos videos del render (o estar alli, que estaria de lujo...)

en cuanto a lo del CG de NVIDIA... que se lo metan por el culo, yo no lo he probado, pero no estoy conforme con esa metodologia que esta siguiendo NVIDIA, ya que parecen querer imponer el CG con sus tarjetas junto a la tecnologia CineFX (o algo asi se llamaba) y me parece que estan cayendo en el mismo error en el que cayo en su dia 3DFX y que, en mi opinion, les costo su caida como empresa...

Seria mucho mejor esperar a que, en el caso de las dos plataformas, OpenGL (en su version 2.0, que ya hay drivers para ciertas tarjetas, como las de 3DLabs, en beta, eso si) o Direct3D (no conozco mucho ese mundillo, asi que no digo nada...) asentaran de forma generica los shaders y estructuras para animacion, coño... si hasta ATI esta deacuerdo en eso con 3DLabs, pero no... tienen que llegar los señores de NVIDIA y decir 'por favor... queremos mas... y queremos que los demas hagan lo que nosotros queramos...'...

En fin, perdon por la acidez del comentario, pero a mi ese tipo de actitud me revuelve el estomago... en fin, espero que NVIDIA no se equivoque...                                

[BeRSeRKeR]

                                Si, vi lo de FF con una Quadro...¿salió algún video para poder verlo?...a ver que tal era la calidad gráfica y demás :sonriendo:

En cuanto al ensamblador pues bueno quien más quien menos ha dedicado su tiempo a aprender algo pero a mi parecer no merece la pena el tiempo necesario para desarrollar una rutina en ensamblador que compita con la desarrollada en C/C++...además siempre se puede optimizar más el código (para el render o lo que sea), utilizando otros algoritmos más óptimos que los que utilices. Así que yo personalmente prefiero dedicar el tiempo a buscar nuevos métodos para descartar más polígonos y más rapidamente o un sistema de colisiones más rápido que crearme una rutina que concatena matrices (o lo que sea) en ensamblador...

Saludos
                               

[Frodrig]

                                Curioso post.

Atras quedaron los dias en los que utilice el ensamblador (epoca del MSDOS, modo 13h, etc). Actualmente pienso que es preferible saber analizar la complejidad de un algoritmo o las ventajas de utilizar una u otra estructura de datos; ¿porque es rapido un arbol?, ¿que complejidad tiene?, ¿para este problema conviene utilizar una tabla hash o irse a por una lista?, ¿porque no utilizar monticulos en lugar de esperar a tener todos los datos y ordenar despues?. Las librerias STL te ofrecen montones de estruturas de datos y algoritmos, pero hay que saberlos utilizar.

En fin, lo dicho, estoy con Berserker. Yo creo que el ensamblador solo debe de utilizarse cuando sea estrictamente necesario, mientras tanto preocupate de asegurar que tus estructuras de datos y algoritmos den la talla en la tarea asignada (y bajo cualquier caso de uso).

Saludos.


[ Este Mensaje fue editado por: frodrig el 2002-08-29 22:09 ]                                

[ethernet]

                                Un aspecto q no se ha tratado en el post es el tema de la portabilidad. Nadie se ha parado a pensar q todos los procesadores no son de la familia x86?.
Personalmente  la filosofia de id me ha gustado por ese tipo de aspectos ( y por tantos otros) y sino solo teneis q mirar los fuentes del quake2 :sonriendo:) (no mireis la parte de render por soft XDDDD).

Saludos                                

[Emotion]

                                eso ya no es un problema hoy dia, de hecho si te fijas en el principal competidor de Intel y segundo suministrador de procesadores para PCs, el juego de instrucciones es compatible totalmente con el de Intel, bueno... hasta cierto punto.. quiero decir, por decirlo de manera concreta, los Athlon XP soportan hasta las instrucciones SIMD de primer nivel, o SSE, las que no soporta son las SIMD de segundo nivel o SSE2, que son las que lleva el Pentium4, asi que en cuestion de portabilidad... no, que yo sepa no hay ningun problema... que yo sepa, claro...

de todas formas entiendo tu postura, ethernet, lo cierto es que si el alto nivel fuera tan preciso y tan rapido como el ensamblador, no estaria hoy dia jugando con el ASM, pero lo cierto es que el ASM estara ahi siempre, de forma que uno no tiene porque programar con ASM para que un programa sea preciso, tambien hay muchos metodos de optimizacion de alto nivel, solo que si quieres exprimir la maquina A FONDO, entonces no tienes otra alternativa, y sinceramente, no la tendras nunca... las cosas son asi :sonriendo:

un saludo

ahhh... un momento, casi se me olvidaba... alguien sabe si la Radeon 9700 utiliza el mismo concepto de VPU que la P10 de 3DLabs, quiero decir lo de las multiples VPUs virtuales a traves de multi-threading... es que estoy pensando en cambiar de tarjeta y coger una de nueva generacion, y una cosa tengo clara... no sera una NVIDIA, ya he tenido 2, una TNT2 y una GeForce2 (la que tengo ahora), pero ya va siendo hora de cambiar... y aunque es una pasta, estaba pensando inicialmente en la 3DLabs, lo que pasa es que es cara con creces y la Radeon 9700 no se como va de precio pero en la pagina de ATI no ponen mucha informacion... alguien me puede 'iluminar'? gracias de antemano

ahora si... un saludo :sonriendo:                                

[ethernet]

                                Q yo sepa no solo existen intel y amd... de todas maneras, en el ambito de la programacion de juegos, en los ultimos tiempos no tiene mucho sentido la portabilidad puesto q se esta usando DX en la gran mayoria de juegos, q por otra parte es logico viendo el segmento de mercado q compra (o piratea) juegos.

Saludos ;D