El motor ogre3d es uno de los más completos y populares de los motores 3D opensource. Tiene a muchos desarrolladores trabajando para mejorarlo y usando las distintas herramientas que exsiten actualmente.

Los chicos de intel, siempre tan dispuestos a ayudarnos para que usemos multicores, han escrito un completo pdf sobre multithreading y el ogre3D. Lo chulo es que destripan de forma sencilla cómo está desarrollado el ogre3D, y las distintas capas que lo componen. Así, tenemos un completo diagrama de las distintas etapas de render (que son bastantes).

 El pdf comenta varias cosas que a veces hablamos en esta web. Hace una discusión de cómo modificar los datos de la escena usando multithreading. Podremos usar una cola de comandos. Esto es, un thread postea en una cola "mover objeto" y los comando se van ejecutando de forma secuencial cuando sea preciso. El problema es que a veces hay que mandar comandos con datos muy grandes, que tendríamos que copiar (modificar los vértices, por ejemplo)

 Otra forma es duplicar datos, tener una especie de "double buffer" para lo que se modifica constantemente. El tema es que puede que pintemos más rápido de lo que modificamos las copias. Hace unos días hablamos aquí de unas estructuras de datos en java que hacian algo parecido, pero mas al estilo transacciones, que podría mejorar esto severamente.

Otra forma de meter threads es que el mismo sistema de render sea multithreading. Este es el más complejo, sobre todo porque hay que tener en cuenta un montón de dependencias entre los distintos sistemas, y puede que tengamos que esperar por ciertas partes para completarse. Aqui tambien podríamos usar una cola para renderizar sin bloqueos. 

Y ya a más bajo nivel, podrñiamos hacer multithreading la parte más de bajo nivel (opengl o directx). 

 Los resultados son un poco decepcionantes, ya que las mejoras son, en el mejor de los casos, de un 30%. Eso sí, las demos de ogre son muy gpu, así que no aprovechan los multicores a tope.

De todos modos, mi conclusión es que lo mejor es un thread para el ogre, y dejar a la cpu a realizar el resto de tareas. Esi sí, tendremos que esperar a que el multithreading de gpu sea una realidad (DX10 tene algo ya), para aprovechar mejor ciertas partes de render.

Comentarios

Agregarnuevo Buscar

- Rubén Penalva - Double buffer y lista de cambi     | 195.219.143.xxx | 2008-06-06 10:58:38 Hi, por lo que he estado leyendo de charlas y articulos, al final todo el mundo llegamos a la misma conclusion: un double buffer de algun tipo entre los datos que comparten el render y la "simulacion" (fisica, ia, logica, etc...) y una lista de cambios. Partimos de que tenemos un hilo para render, otro para simulacion, unos datos que comparten ambos, por ejemplo, grafo de escena y que ademas el tiempo de simulacion supera al de render. Cuando la simulacion modifique los datos tiene que bloquearlos hasta que los modifique para que el render no haga una lectura en "sucio" de los datos. Si ademas le añadimos que la carga la tenemos en la parte de simulacion, lo que estamos haciendo es secuencializar el proceso. La grafica estara mucho tiempo parada sin hacer nada. Como somos muy listos, pensamos que si el problema esta en el bloqueo que se produce entre el productor(simulador) y el consumidor(render) podemos duplicar los datos y librarnos de practicamente todos los bloqueos. En un mundo ideal, con esto conseguiriamos que el unico punto de boqueo fuese la sincronizacion. Y como estamos en un mundo ideal esta sincronizacion consistiria en un simple swap de punteros! yuhu! (...danza de la victoria...) Ahora viene la leche que te pegas... En el mundo real no puedes hacer simplemente un swap de punteros de los datos, si no que hay que hacer una sincronizacion de los datos. El problema fundamental es que los datos que tiene el render son antiguos con respecto a los modificados por la simulacion. Por lo que si se hace un swap la simulacion tendria los datos antiguos y no los que ha calculado. Solucion, la mas facil y la menos eficiente es volcar todos los cambios de la simulacion a los datos del render. Cuando tu simulacion haya acabado de actualizar sus datos (frame), se copian estos datos a los datos del render. Asi ambos tienen lo mismo. Otra solucion mas compleja y mas eficiente es tener una lista de cambios y solo actualizar lo que se haya cambiado. Un saludo, Rubén Penalva Citar 0   0

derethor   | Super Administrator | 2008-06-08 14:14:11 Creo que esta claro que, segun tengamos mas y mas procesadores, el ir bloqueando procesos es contraproducente. Para mi, una parte muy grande se soluciona ocn una lista en runtime, que vaya metiendo los datos ya procesados. Cada dia me gusta mas la idea de una lista con "transacciones" tipo sql, que seria interesante de desarrollar (algun dia tendre todo el tiempo que me gustaria?) y para mi, el problema que se plantea es la cantidad de cosas que se crean en runtime... Citar 0   0

Escribir comentario
Nombre:
Email:	No notificar:Notificar:
Website:
Título:
Código UBB:	-color-aguanegroazulfucsiagrisverdelimamarrónmarinoolivapúrpurarojoplataturquesablancoamarillo -tamaño-minúsculopequeñomedianograndeenorme
	Por favor introduce el codigo anti-spam que puedes leer en la imagen.

Powered by !JoomlaComment 3.12

Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved.