Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Indexed vs Non-Indexed

Iniciado por Lord Trancos, 01 de Enero de 1970, 01:00:00 AM

« anterior - próximo »

Lord Trancos

                                He hecho una pruebecita en mi modesto p233mmx y su voodooo banshee y no he notado diferencias de velocidad entre un objeto formado por algo de mas de 1000 triangulos, en sus dos versiones; una indexada (algo mas de 2000 vertices) y otra sin indexear (algo mas de 3000 vertices) y no he notado ninguna diferencia de velocidad, a pesar de que me esperaba que la transformacion de esos 1000 vertices de mas me repercutiria en el rendimiento...

¿Que opiniais? ¿Es porque son pocos vertices? ¿Es porque hace falta algun HW mas avanzado para sacarle el jugo a las primitivas indexeadas?

SaludoteZ!                                
i>SaludoteZ de Lord Trancos!
http://www.dxlab.tk - http://dxlab.host.sk - programación de DirectX con Delphi.

efreet

                               
Hi Lord Trancos ,

La primitivas indexadas son mucho más rapidas que las no indexadas , solo que hay que utilizarlas correctamente , si no puede ser incluso más lentas que las no indexadas.

La primitivas indexadas son mas rapidas porque unicamente en este modo  utilizan una caché con los ultimos vertices transformados.

Por eso es muy importante en el rendimiento ,
el ORDEN en que se envian a la tarjeta ,los datos de los indices:
( Los indices de los vertices deben ser los mas "adyacentes" posibles )

Por ejemplo:

caso A: (caso no optimo)
Tenemos un VB de 2000 vertices
y tenemos un IV de 1000 triangulos
El orden de los indices es el siguiente:
Triangulo 1: 1 , 1000 ,23
Triangulo 2: 100 , 300 ,503
Triangulo 3: 7 , 100 ,223
Triangulo 4: 110 , 1100 ,723
....

caso B: (caso optimo)
Tenemos un VB de 2000 vertices
y tenemos un IV de 1000 triangulos
El orden de los indices es el siguiente:
Triangulo 1: 1 , 2 ,3
Triangulo 2: 3 , 2 ,4
Triangulo 3: 4 , 5 ,1
Triangulo 4: 8 , 4 ,5
....

Al enviar el IV (index buffer) del caso A ,
no aprovecha las ventajas de la cache.( normalmente las caches no suelen ser muy grandes , mas o menos 10 vertices de cache )
la tarjeta ya que no reutiliza valores ya precalculados. En este caso para los 4 triangulos calcularia 12 vertices.

En el caso B para los 4 triangulos que se muestran solo calcularia 6 vertices.


!Imaginate esto para 10000 triangulos! , la diferencia de rendimiento es abismal.

Un saludo ,
          Efreet.
                               

Drácula

                                1000 vértices no es significativo. Sí lo son 100.000. Pruébalo con 65.000. No lo hagas conm 100.000 porque quizás tengas el límite de los 64K!                                
ltimas mejoras en Merlín: Multitextura.Control y generación automática de LOD.Importa ASE y X. Frustum Clipping por BB.Render añadido de wireframe y del BB.Animaciones por interpolación.Animaciones de textura...
Actualmente:Octree y jerarquías

Emotion

                                64k? hmm... te refieres al limite fisico de la memoria RAM o es que OpenGL/Direct3D tienen la limitacion de 64k por cada bloque de vertices que se mandan?

La verdad es que eso no lo habia escuchado... podrias aclararmelo?

Gracias :ojo:
                               
G3: Get the Power!

Drácula

                                Sí, algunas tarjetas no soportan más de 64K de vértices o índices. Por eso tienes que tener cuidado con ese límite. Supongo que en la documentación de DX aparece algún sitio en el que se puede comprobar esta limitación.
                               
ltimas mejoras en Merlín: Multitextura.Control y generación automática de LOD.Importa ASE y X. Frustum Clipping por BB.Render añadido de wireframe y del BB.Animaciones por interpolación.Animaciones de textura...
Actualmente:Octree y jerarquías

BeRSeRKeR

                                Según nVidia (por lo menos en sus documentos lo he leído), el valor óptimo de bloque de vértices a mandar a la tarjeta es de 64 KB...si la estructura de tu vértice tiene un tamaño de por ejemplo 32 bytes (las coordenadas de vértice, las coordenadas de la normal y las coordenadas de textura) pues te salen 2048 vértices...

Un saludo
                               
¡Si te buscan en nombre de la ley, huye en nombre de la libertad!!

Emotion

                                Ah... o sea que se puede jugar con ese valor para poder encajar en 64k tus vertices (segun la estructura que tengas), no?

Vaya... pues supongo que me resultara... yo uso una tecnica que es peor que te den un hachazo en mitad de la cara, y es a pelo...

Lo que pasa es que mi metodo es estadistico y solo lo utilizo para medir el rendimiento y la velocidad de proceso, no obstante pensare en ese metodo, ya que supongo que me puede ayudar bastante... aunque me queda una dudilla al respecto..

Si estoy usando triangle strips como los encajo para que un grupo completo de triangulos entren en el vertex buffer sin que se me quede un trozo del strip fuera del limite? :sonriendo:

Saludos
                               
G3: Get the Power!

BeRSeRKeR

                                Hmm veamos creo que aquí esta habiendo una confusión...efectivamente, el número máximo de primitivas en un VB es de 65500 para por ejemplo una TNT2 y de 1048575 para una GF3...pero aun así, y siempre según nVidia, el tamaño máximo del bloque de vértices a mandar a la tarjeta es de 64KB...aún así buscaré dicho documento y si lo encuentro pondré aqui la URL...de todas maneras debe estar en la sección http://developer.nvidia.com">Developer Relations de la page de nVidia.

Un saludo
                               
¡Si te buscan en nombre de la ley, huye en nombre de la libertad!!

Drácula

                                ¡Yo no he hablado del límite de 64K de memoria para los vértices! El límite es para el nº de vértices y el nº de índices en algunas tarjetas. Quizás exista también el otro límite que comenta Berserker, pero lo desconozco y me parece un poco "ilógico" que sea tan bajo como él comenta. Pero ya digo que lo desconozco.                                
ltimas mejoras en Merlín: Multitextura.Control y generación automática de LOD.Importa ASE y X. Frustum Clipping por BB.Render añadido de wireframe y del BB.Animaciones por interpolación.Animaciones de textura...
Actualmente:Octree y jerarquías

BeRSeRKeR

                                Bueno ahí va un fragmento de un doc de nVidia sobre los Vertex Buffers...evidentemente no dice nada del tamaño óptimo de 64KB que mencioné pero bueno algo es algo:

"Note that although the maximum number of vertices in a VB is 65535 it's not usually a great idea to approach this kind of size.  Since the VB renaming scheme in DX7 requires the driver to find a contiguous free block of AGP memory which the same size as the original buffer it can be easier for the driver to satisfy these requirements if the request is for a smaller chunk of memory.  Typically that's more likely in cases where the VBs are themselves smaller."

Como dije antes, seguire buscando la cifra mágica :sonriendo: porque después de los comentarios estoy empezando a dudar :riendo:

Un saludo
                               
¡Si te buscan en nombre de la ley, huye en nombre de la libertad!!

BeRSeRKeR

                                Bien, aquí tenéis el http://developer.nvidia.com/docs/IO/1370/ATT/GDC2000_Vertex_Buffers.pdf">documento del que hablaba. Trata sobre la forma óptima de utilizar los vertex buffer y en uno de los puntos dice lo siguiente:

Make them big, but not too big
• because changing VB is expensive
• 64Kb (~2K of vertices) is big enough

Bueno, menos mal que lo he encontrado porque ya empezaba a obsesionarme :riendo:

Un saludo.
                               
¡Si te buscan en nombre de la ley, huye en nombre de la libertad!!

Emotion

                                Entonces y si no lo he entendido mal, puedo usar los VB incluso con mi propia estructura de datos, exceptuando el hecho de que para ganar en velocidad a la hora de procesar los vertices deberia usar un buffer secundario donde apelotonar mis vertices, independientemente de los campos extra, no?

Quiero decir, si mi estructura fuese asi:

typedef struct vertex { float x,y,z; int data; vertex *next; } vertexgroup;

y luego quisiera mandarlos todos de un sopeton tendria que declarar algo asi como:

typedef struct { float x,y,z; } singlevertex;
singlevertex *vertexbuffer[65535];

de esa manera, aunque seria muy bestia, tendria a mi disposicion bloques de vertices para mandarlos a la tarjeta... lo unico malo seria que todos los modelos de la escena tendrian que ser troceados para encajarlos en los bloques y luego mandarlos a la tarjeta...

Creo que me he liado bastante, pero bueno... :riendo:

Aun asi, creo que antes de hacer nada por mi cuenta, intentare coger ese doc de la pagina de nVidia y me lo leere, a ver si consigo hallar una manera de poder acelerar aun mas mis vertices :riendo:

Gracias y Saludos

_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-04-05 12:28 ]                                
G3: Get the Power!

Drácula

                                Sacado de un doc de Nvidia, que supongo debe ser más moderno que el que decía Berserker:

Optimal Vertex Buffer sizes
For the GeForce family of GPUs there is no best size for a VB but the following rules apply:
1.   VB switches are expensive (much more expensive that on the regular HAL) so packing multiple objects into one VB is a good thing – simply because it saves the cost of the transition.
2.   Batches of primitives made up of fewer than about 200 triangles are necessarily sub-optimal. Very small batches (say 10 or fewer) should be regarded as a main target for optimization.
3.   Redundant information in the vertex format can bloat the VB and dramatically reduce the rate at which vertex data can be read across the AGP bus.

Note that (1) and (3) can produce conflicting demands.  Since switching VB is so expensive it can be advantageous to use a common vertex format throughout all or much of your app so that all vertex data can live in a small number of VBs.  This is quite typical of optimization issues and makes the task significantly more complex.

Microsoft have recommended a size of "around 1000 vertices" for most of the lifetime of DX7, but recent evidence suggests that bigger is better and sizes in excess of 2000
vertices are measurably superior.



How DX8 changes things

The two main changes to the handling of VBs under DX8 are the introduction of Index Buffers and lightweight VB changes.

Index Buffers (or 'IB's) are a highly efficient way of passing indexing data to the API.  Index sets which are constant, or which change only infrequently and which are regularly associated with specific VBs offer excellent optimization opportunities.

DX8 also introduces 32 bit indices and allows VBs to be much larger than before.


¿Quién se equivoca? Yo creo que..¡habrá que experimentar a ver que pasa!                                
ltimas mejoras en Merlín: Multitextura.Control y generación automática de LOD.Importa ASE y X. Frustum Clipping por BB.Render añadido de wireframe y del BB.Animaciones por interpolación.Animaciones de textura...
Actualmente:Octree y jerarquías

Lord Trancos

                                Aun no he tenido tiempo para hacer un objeto mas complejo y probarlo, pero he probado a dibujar el objeto 10 veces por frame (lo que son unos 11000 triangulos) y sigue sin haber una diferencia de velocidad entre dibujarlo indexeado y sin indexear.

En cuanto a le eficiencia de los indices supongo que sera la correcta porque despues de cargar el modelo uso el metodo .OptimizeInPlace....                                
i>SaludoteZ de Lord Trancos!
http://www.dxlab.tk - http://dxlab.host.sk - programación de DirectX con Delphi.

_Grey

                                Lo que ocurre al indexar es que se usa el cache de vertices, no creo que en una banshee ganes velocidad(En las aceleradoras antiguas el indexar es inutil), prueba en una Gforce2 colandote en casa de un amigo.Tambien te recomendaria que usases mas vertices por que 11000 son poquitos, y la diferencia no se notara mucho, bajate el "GDC2001_Optimization.pdf" y el "Hardware_TnL.pdf" de developer.nvidia.com igual te sirven.                                






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.