Sobre DirectX9

[Emotion]

                                No, el emparejamiento ES lo que te deja ejecutar el codigo de forma limpia y transparente. La primera regla del emparejamiento es que no se puede actualizar un mismo registro en las dos instrucciones, es decir:

mov eax,1
mov eax,2

esto NO empareja. la pipeline se colapsa hasta que se ejecutan las dos instrucciones UNA a UNA.

el segundo caso, que es el que yo he visto en tu codigo, es que si en una instruccion insertas un valor en un registro, no debes utilizar la informacion de ese registro en la siguiente instruccion, ya que la informacion AUN no esta actualizada. es decir,

mov eax,1
mov ebx,eax

esto, evidentemente, NO empareja. Pero ahora vayamos con el ejemplillo practico

[esta es una parte de tu codigo]

mov eax,color32
shr eax,3

AHI esta el fallo. tratas de desplazar los bits de EAX 3 posiciones hacia la derecha cuando AUN estas introduciendo la variable color32 en el registro :sonriendo:

Por cierto, a pesar de que esto se amolda muy bien al software, tambien se puede usar con el hardware, es decir, OpenGL (en mi caso, pero DX tambien) tienen sus buffers en direcciones de memoria fisicas Y accesibles.

Tambien se puede usar para acelerar la generacion de multitexturas (habilitandola en las tarjetas que no puedan por hardware y añadiendo mas a tarjetas que si lo soportan), etc. etc. :sonriendo:

y si ademas, lo haces con multithreading, pues imagina... la imagen de que me hablas pues de 2 segundos a menos de 1 (aunque esto ultimo no te lo puedo asegurar). lo que si te digo es que segun el manual de intel, puedes ejecutar un MOV en 0.5 ciclos de reloj, en lugar de 1 o 2 (depende del caso, de que las instrucciones esten alineadas, emparejadas... etc.). bienvenido al mundo de la optimizacion :sonriendo:

Un saludo.

_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-03-13 12:26 ]                                

[fiero]

                                vaya, veo que estamos en linea...
Muchas gracias por tu explicación, es lo que me imaginaba, lo de emplear el mismo registro en sucesivas instrucciones, tienes toda la razón.
El caso es que acabo de recordar porqué no utilizo MMX en este caso. Una de las razones es que tengo todos los registros mmx ocupados con el mapeo de los triángulos, no en todos los casos, pero por ejemplo, en el mapeo con filtro bilinear los uso todos para las operaciones de interpolación de colores (y a dios pongo por testigo de que no sobra ni uno). O sea que necesitaba un código rápido y que utilizase los mínimos registros posibles, en este caso solo EAX y EDX.
Otra de las razones que hay, en el caso de tener los registros MMX libres, es que el número de operaciones mmx y normales a realizar es más del doble, para solo convertir 2 pixels de 32 bits cada uno. La cosa está en que no hay que desplazar el mismo número de bits todos los bytes RGB, sino que el byte G hay que desplazarlo 2 bits y los R B tres bits, por lo que la ejecución de los 8 bytes de los 2 colores en paralelo se complica una barbaridad.
Por eso, es mejor pixel a pixel, aunque haya que desperdiciar la utilización del pipeline.

Yo cuando empecé con esto de las MMX, me miré en la página de intel lo de la conversión de colores. Ellos utilizan un montón de código MMX, para convertir 4 pixels de golpe, pero tengo comprobado que es igual de rápido de mi manera, y más versatil, ya que pixel a pixel es utilizable en cualquier lado del programa. O sea, que lo que se gana de velocidad de ejecución, se pierde por tener que emplear un güevo de instrucciones más...

Os pongo la dirección de lo de MMX de intel, es interesante... http://cedar.intel.com/cgi-bin/ids.dll/con...e=IDS_EDITORIAL

Gracias por la explicación Emotion
un saludo

[ Este Mensaje fue editado por: fiero el 2002-03-13 12:58 ]

[ Este Mensaje fue editado por: fiero el 2002-03-13 13:08 ]                                

[Emotion]

                                Gracias por el link. Me ha resultado bastante util para un pequeño truco :sonriendo:

Por cierto, el penultimo algoritmo es el que te interesa, ya que te permite procesar 1 pixel cada 3 ciclos, o 8 pixels en 24 ciclos. Bastante interesante.

A pesar de que me comentas que todos los registros MMX los tienes ocupados, utiliza la tecnica del multipass rendering, es decir, primero computa los triangulos y despues realiza la conversion, o al reves. Depende de como tengas implementada la pipeline de tu motor grafico.

En cualquier caso, echale un vistazo al tema del multithreading, te puede salvar el pellejo en mas de una ocasion y ademas tiene la ventaja de que en maquinas con procesador doble no corre, vuela.

saludos.