Uso de Processing

20 Captulo 3. Trabajos tutelados

la GPU. Adaptaremos y simplicaremos el algoritmo para el procesado direc-

to de supercies Bzier eliminando de la propuesta original el requerimiento

de utilizacin de jerarquas de supercies. Por otra parte y con el objetivo

de la sntesis en tiempo real en mente, analizaremos diferentes tcnicas para

la reduccin de los requerimientos de transmisin entre CPU y GPU y para

reducir el nmero de fases de sincronizacin. Finalmente presentamos una

comparativa de los resultados obtenidos con las diversas tcnicas propuestas

con los asociados a la implementacin tradicional que evala las supercies

directamente en la CPU.

Existen diferentes estrategias alternativas a este mtodo clsico como la

realizacin de la triangulacin en extensiones hardware de la GPU [6], en la

GPU de forma directa en las tarjetas grcas ms recientes [8, 9], la evalua-

cin directa de los puntos de la supercie en la GPU [2] o la sntesis de la

imagen utilizando algoritmos de Ray tracing [18, 1, 4, 19].

Con este objetivo en nuestra implementacin sobre la GPU hemos uti-

lizado la API (Application Programming Interface) DirectX 10 [3].

Para ello empezaremos describiendo las caractersticas de las tarjetas gr-

cas y su evolucin en los ltimos aos. La Seccin 3.2.2 se centra en el

algoritmo descrito en [8], punto de partida de nuestro trabajo. En el aparta-

do 3.2.3 se describe la adaptacin y modicaciones que proponemos sobre

el algoritmo de trabajo persiguiendo el objetivo de la triangulacin y snte-

sis de modelos basados en supercies Bzier en tiempo real. Posteriormente,

en la Seccin 3.2.4, se incluye un anlisis de los resultados obtenidos para

las diferentes propuestas presentadas. Para nalizar, en la Seccin 3.2.5, se

presentan las principales conclusiones.

3.2.1. GPU (Graphic Processing Unit)

En los ltimos aos se ha realizado una intensa investigacin para trasladar

las computaciones asociadas a algoritmos de computacin grca desde la

CPU a la GPU [13]. Esto es posible, gracias a las crecientes prestaciones del

hardware grco y su cada vez mayor programabilidad.

Las GPUs han evolucionado desde un cauce jo hacia una malla de proce-

sadores. La evolucin que han sufrido las GPUs desde su aparicin se puede

dividir en seis generaciones diferentes.

La primera generacin de GPUs surgen en 1998, con por ejemplo: TNT2,

ATIs Rage y 3dfx's Voodoo3. Era posible rasterizar tringulos pretransfor-

mados y aplicar una o dos texturas. Pero no se podan transformar vrtices

de objetos 3D, por lo que las transformaciones de vrtices se realizaban en

la CPU, y adems el conjunto de operaciones disponibles era muy limitado.

La segunda generacin abarca los aos 1999 y 2000, con por ejemplo:

3.2. Computacin grca 2: Explotacin de la tarjeta grca para la sntesis

de modelos basados en supercies Bzier 21

Nvidia Geforce 256, Geforce2, ATI Radeon 7600 o S3's Savage3D. Se libera

a la CPU de la transformacin de vrtices y la iluminacin local. Se sigue

teniendo un conjunto de operaciones muy limitadas a pesar de que aumentan

aquellas destinadas a combinar texturas y pxeles. Por ello, se dice que esta

generacin es congurable, pero todava no programable.

La tercera generacin de GPUs surge en 2001, con por ejemplo: Nvidia

Geforce 3 y 4 Ti, Microsoft Xbox, ATI Radeon 8500. En esta generacin

surge el Vertex Shader, lo que proporciona vrtices programables, y permite

especicar una secuencia de instrucciones para procesar vrtices. Pero a nivel

de pixel todava no son programables aunque hay una mayor congurabilidad.

Debido a esto, esta generacin est considerada de transicin.

La cuarta generacin abarca los aos 2002 y 2003, por ejemplo la familia

Nvidia Geforce GX y la ATI Radeon 9700. Proporcionan Vertex y Pixel

Shader, y ofrecen la posibilidad de realizar transformaciones complejas en la

GPU en lugar de en la CPU. A nivel de vrtice se producen varias mejoras,

ya que se aumenta el nmero de instrucciones, se aade un mayor control del

ujo del programa, y se introducen llamadas y retornos de funciones.

En los aos 2004 y 2005 [13], [11] se desarrolla la quinta generacin de

tarjetas grcas, por ejemplo: Nvidia 6800, Nvidia 7800 y ATI x1800. En esta

generacin el Vertex Shader puede acceder a texturas por primera vez, y con

respecto al Pixel Shader aumenta el nmero de instrucciones dinmicas y se

admiten programas ms exibles con saltos.

En el ltimo paso de la evolucin de la GPU, por ejemplo familias Nvidia

Geforce 8, Nvidia Geforce 9 y la ATI Radeon HD2900, se han introducido

los shaders unicados, en lugar de procesadores especcos. Se caracteriza

por una arquitectura unicada donde los stream processors (SPs) unicados

pueden procesar vrtices, pxeles o geometras, puesto que son procesadores

en punto otante de propsito general. Esto permite que la GPU pueda

asignar dinmicamente vrtices, pxeles o geometras a los SPs disponibles

sin preocuparse por el nmero de shaders disponibles de cada tipo, y stos

van adaptando su dedicacin en funcin de la carga de trabajo de cada tipo

de shader.

En la Figura 3.9 se muestra el cauce funcional de las actuales GPUs de

acuerdo a las directivas del DirectX 10 [3]. A continuacin describiremos

brevemente las principales etapas de este cauce.

La primera de las tres etapas programables es el Vertex Shader (VS). En

esta etapa se procesan uno a uno todos los vrtices que llegan desde el Input

Assembler (etapa que realiza el preprocesado de los datos que llegan a la

GPU para adaptarlos a los diferentes shaders) modicando sus caractersticas

como color, posicin e iluminacin. Nunca se crean o eliminan vrtices sino

que para cada vrtice de entrada se obtiene un nico vrtice de salida.


MemoriaStreamOutput

GeometryShader

PixelShader

VertexShader

InputAssembler

OutputMerger

Rasterizer

Figura 3.9: Etapas del cauce grco

El Geometry Shader (GS) es una de las incorporaciones de la nueva gene-

racin de GPUs. Recibe como entrada una primitiva simple (punto, lnea o

tringulo) y tiene la capacidad de generar vrtices. Un programa del Geom-

etry Shader puede generar como salida ms de una primitiva en una nica

invocacin o puede incluso eliminar la primitiva de entrada no produciendo

ninguna salida.

Por ltimo, despus de pasar por la etapa de Rasterizer [17], cada una

de las primitivas entra en el Pixel Shader (PS), ltima de las etapas progra-

mables del cauce y en la cual se calcula el valor para cada pixel, aplicando

tcnicas como bump mapping o sombreado [17].

Actualmente, para programar los shader se puede usar, entre otros, el

High Level Shader Language (HLSL)[7]. HLSL es un lenguaje similar a C,

incluyendo todas aquellas acciones que se puedan realizar en lenguaje en-

samblador de shaders. HLSL tambin admite instrucciones shader similares

a expresiones matemticas, y como otros lenguajes grcos, aprovecha todas

las ventajas de la utilizacin de vectores y matrices matemticas.



3.2.2. Triangulacin y sntesis de NURBS en la GPU

NURBso

T-Splines

AproximacinBzier

bicbicasJerarquabicbica

Generacinmallas

resoluciones

Jerarquabicbica

Seleccinde

LOD

l,

Mallasresolucin

Evaluacinsuperficies

BzierVertex Buffer

Rasterizer

CPU

CPU GPU

GPUETAPA DE SNTESIS

ETAPA DE PREPROCESO

1

2

3 4

Figura 3.10: Esquema del mtodo de [8] para la sntesis de NURBS en la

GPU

El algoritmo descrito en [8, 9] presenta, entre otras propuestas, un mtodo

para realizar la triangulacin y sntesis de supercies NURBs en la GPU. En

la Figura 3.10, se muestra el ujo del algoritmo propuesto en [8] para los pasos

involucrados en la triangulacin de las supercies. Este algoritmo consiste en

dos etapas. La primera es una etapa de preproceso donde se realiza una serie

de clculos en la CPU que generan la informacin necesaria para la siguiente

etapa. Parte de esta informacin es almacenada en la GPU. La segunda etapa

es realmente el proceso de sntesis que se repite por cada fotograma, f . Enel resto de esta seccin y con el apoyo de esta gura se resumir brevemente

los principales pasos involucrados en esta propuesta.

El mtodo aproxima en la CPU cada supercie NURBs o T-Spline me-

diante una jerarqua gruesa de polgonos bicbicos Bzier racionales (ver paso

1 de la Figura 3.10). Puesto que uno de los objetivo de [8] es que el algoritmo

funcione sobre cualquier tarjeta grca que soporte al menos la versin 1,0de Vertex Shader, y en aquellas tarjetas que no tienen acceso a texturas

en el Vertex Shader, la cantidad de datos de entrada para un programa de

vertex est limitado a 16 atributos por vrtice y 8 matrices de programa, conlo que slo se pueden evaluar supercies Bzier de grado no muy elevado.

Adems como se limita el nmero de registros temporales a 12, esto implicala utilizacin de supercies bicbicas.


El renado de los polgonos de Bzier en la GPU para generar una malla

de alta calidad se vio frenada hasta la aparicin del Geometry Shader por

la incapacidad de generar nuevos vrtices. Esta imposibilidad forz en [8]

a la utilizacin de mallas predenidas de diferentes resoluciones (ver paso

2 de la gura), que indican los vrtices virtuales y la conectividad entre

ellos. De esta forma, con estas mallas se indican los valores paramtricos uy v a ser utilizados en el proceso de generacin de los vrtices de la mallatriangular (ver Ecuacin 3.6). As, los vrtices virtuales que son denidos

inicialmente sin coordenadas especcas, son posteriormente procesados en

el Vertex Shader para la generacin de las coordenadas. Adems, en [8] en

lugar de utilizar una malla por supercie, que ira en contra de la losofa

del clculo del renado en la GPU, se crea una malla predenida por nivel

de resolucin y se almacena en la GPU en este paso del preproceso.

En el paso 3 de la gura, se atraviesa para cada fotograma f la jerarquade supercies Bzier y se seleccionan aquellas supercies que tienen su-

ciente resolucin para garantizar la precisin deseada en la visualizacin. Si

durante el recorrido se alcanza un nodo hoja, se generan supercies bicbicas

adicionales. Los puntos de control de cada supercie [Bk], 0 k S (siendoS el nmero de supercies Bzier) son enviados a la GPU. Adems, paracada supercie se selecciona una malla de resolucin adecuada que garantice

la precisin deseada, l (ver etapa 3 de la gura).En la GPU (ver paso 4 de la gura) se calcula en el Vertex Shader la

ecuacin 3.6 para cada supercie y para cada vrtice virtual de la malla

resolucin adecuada para ese caso. Para sintetizar los polgonos de Bzier

en la GPU, en [8] se opt por la evaluacin directa frente al algoritmo de

deCasteljau [17] ya que la implementacin en la GPU del primero de ellos es

ms eciente.

3.2.3. Sntesis de supercies Bzier en la GPU

En esta seccin describimos el mtodo que hemos implementado para rea-

lizar la sntesis de supercies Bzier mediante su triangulacin en la GPU.

Para ello nos basamos en el mtodo descrito en la Seccin 3.2.2 aunque en

nuestra implementacin se han considerado desde un primer momento su-

percies Bzier bicbicas, por lo que no fue necesario realizar la conversin

de NURBs a Bzier. Adems, y teniendo en cuenta las capacidades de al-

macenamiento cada vez mayores existentes en las tarjetas grcas actuales

nuestra propuesta no utilizar jerarquas de supercies. Esto, como se ver a

continuacin, permite reducir los requerimientos de transmisin entre CPU

y GPU de la propuesta original. Nuestra implementacin persigue presen-

tar alternativas a la propuesta previa a travs de varias vas, por una parte,



Generacinmallas

resoluciones

Seleccinde

LODl,t,k

Mallasresolucin

Evaluacinsuperficies

BzierVertex Buffer

Rasterizer

CPU

CPU GPU

GPUETAPA DE SNTESIS

ETAPA DE PREPROCESO

1

2

3 4

2

Puntos decontrol

Figura 3.11: Sntesis de supercies Bzier en la GPU

evitando el envo de puntos de control durante el proceso de sntesis median-

te su almacenamiento previo en la memoria de la GPU y, por otra parte,

mediante la explotacin eciente de los recursos disponibles en las tarjetas

grcas actuales.

En la Figura 3.11 se presenta la estructura del nuevo algoritmo que pro-

ponemos para la triangulacin y sntesis de supercies Bzier en la GPU.

Los puntos de control de las supercies Bzier [Bk], 1 k S, se envanuna nica vez a la GPU, en la etapa de preproceso (ver paso 1 de la Figura

3.11). El almacenamiento de los puntos de control en la GPU permite evitar

el continuo reenvo de la misma informacin cada vez que se procesa una

supercie concreta. Esto es posible, ya que a diferencia del mtodo de [8],

nuestra aproximacin sigue un mtodo ms simplicado donde las supercies

Bzier vienen determinadas desde el principio y no dependen del recorrido

por la jerarqua de supercies.

En concreto, en nuestra propuesta [Bk] se almacena en tres arrays diferen-tes [Bkx, B

ky , B

kz ], de tipo oat44 uno por cada coordenada y en memoriade texturas usando un buer de texturas (tbuer) [10]. Se consigue mejor

rendimiento por la utilizacin de la memoria de texturas que con las otras

memorias de la GPU, puesto que su acceso no esta sujeto a las restricciones

de los patrones de acceso a memoria que tienen que cumplir la memoria

global y la constante. Adems la latencia de los clculos de acceso a esta

memoria estn mejor ocultos que en otras. Por otro lado, el tbuer, permite

empaquetar datos que pueden ser accedidos desde variables separadas en una


1 VS_OUTPUT DefaultVS(VS_INPUT MR

l)

2 {

3 oat4x4 [N]= { -1, 3, -3, 1,

4 3,-6, 3, 0,

5 -3, 3, 0, 0,

6 3, 0, 0, 0, }

7 u=MR

l.x; v=MR

l.y;

8 oat1x4 [u]=(u3, u2, u, 1);9 oat1x4 [v]=(v3, v2, v, 1);10 oat4x4 {[Bkx ],[B

ky ],[B

kz ]} = leer de texturas (k);11 oat3 vertice = mul( [u], [N],[Bk], [N], [v]);12 return vertice;

13 }

Figura 3.12: Vertex Shader para la sntesis de supercies Bzier en base a

las mallas de resolucin

misma operacin, aumentando as el ancho de banda.

Las mallas de diferente resolucin que indican las coordenadas paramtri-

cas a ser posteriormente evaluadas para el cmputo de los nuevos vrtices son

generadas en la CPU antes de comenzar el proceso de sntesis de igual forma

que en la seccin 3.2.2. Estas mallas son enviadas a la GPU y almacenadas

en ella, como se puede ver en el paso 2 de la Figura 3.11. Cada malla de

resolucin, MR, se almacena en la memoria de la GPU en el paso de pre-

proceso como un Vertex Buer [20], lo que permite acelerar la sntesis de

la geometra y proporcionar un alto ancho de banda en el ujo de datos,

as que la tarjeta grca puede leer ms rpidamente las primitivas. No es

necesario generar ningn Index Buer [20] ya que los valores almacenados en

el Vertex Buer mantienen las relaciones de localidad para permitir generar

los polgonos necesarios.

En cada fotograma se sintetizan cada una de las supercies con el nivel

de resolucin adecuado. En nuestra aproximacin, como hemos indicado, no

es necesario enviar los puntos de control de la supercie Bzier ya que estn

almacenados en la GPU. Lo que se enva por cada supercie y para cada

fotograma f es el nivel l, el ndice de la supercie k y el tamao t de la mallade resolucin (ver paso 3 de la gura). As el nmero de envos, Ne, por cadafotograma es:

Ne = 3 S

siendo S el nmero de supercies.



En la GPU, se generan los tringulos necesarios para representar la su-

percie Bzier con la resolucin seleccionada. En la Figura 3.12 se muestra

el pseudocdigo del Vertex Shader para generar la triangulacin de las su-

percies Bzier bicbicas en funcin de las mallas de resolucin. Utilizamos

el Vertex Shader ya que el mtodo de [8] fue pensado para ejecutarse en el

procesador de vrtices. Para cada supercie, el Vertex Shader recibir co-

mo entrada los valores que forman la malla de resolucin seleccionada para

sintetizar la supercie (lnea 1). A partir de estos valores se calculan los vec-

tores [U ] y [V ] de la Ecuacin 3.6 (lneas 8 y 9). En la lnea 10 se lee dela memoria de texturas, los valores correspondientes a los puntos de control

de la supercie k que se est computando en ese momento. Por ltimo, semultiplican estos valores, siguiendo la Ecuacin 3.6 para generar los vrtices

deseados (lnea 11).

Con esta aproximacin se realiza una llamada sncrona, draw Primitive a

la GPU por fotograma y para cada una de las supercies que forman la escena.

Por tanto, el nmero de sincronizaciones, NDP , por fotograma es NDP = S.Este aspecto limita el rendimiento de este mtodo como comprobaremos en

la seccin 3.2.4 debido a las mltiples llamadas a esta operacin sncrona

[5, 12]. Hay que tener en cuenta que cuando se genera la malla de polgonos

en la CPU NDP = 1 por fotograma.

Para lograr una mejora del rendimiento es necesario minimizar NDP . Coneste objetivo hemos introducido en nuestra propuesta la tcnica de batching

[5]. Esta tcnica persigue minimizar el nmero de llamadas a draw Primitive,

para ello, se juntan los datos de todas las supercies a sintetizar en un nico

envo y se realiza una llamada sncrona por cada fotograma, lo que reduce

el nmero de sincronizacin por fotograma a NDP = 1. Como se ver en lasiguiente seccin la utilizacin de la tcnica de batching est limitada a la

cantidad de memoria disponible en la GPU para el almacenamiento tempo-

ral de la informacin hasta que se realice el proceso de sincronizacin. As,

si en la implementacin basada en [8], la memoria reservada era la suma

del tamao de la malla de las cuatro resoluciones permitidas en su imple-

mentacin (MR32 +MR16 +MR8 +MR4), con nuestra tcnica con batchingse necesita reservar SMR32 siendoMR32 la malla de resolucin de mximotamao permitida. De esta forma, la cantidad de memoria que hay que reser-

var es nuestra propuesta es mayor y directamente proporcional al nmero

de supercies que se vayan a sintetizar. Esto, sin embargo, no es ninguna

limitacin en la propuesta si se realiza el batching hasta que se alcancen las

capacidades de almacenamiento disponibles comenzando, a continuacin y

tras una fase de sincronizacin, con un nuevo batching.


(a)

(b)

(c)

Figura 3.13: Modelos utilizados para l=4 y l=16 (a) Teapot, (b) Teacup y

(c) Elefante

3.2.4. Resultados

En esta seccin se presentan los resultados obtenidos. Todas las medidas,

se han obtenido en un sistema Intel core duo E6600 con 2GB de RAM, una

Geforce 8800GTX y utilizando Microsoft Vista, con la versin de DirectX 10

y la versin 4.0 de shader.

La animacin utilizada consiste en un zoom sobre los diferentes objetos,

de forma que la cmara se va alejando lenta y constantemente, cambiando

la resolucin necesaria para cada objeto. En los anlisis presentados en esta

seccin se ha considerado la existencia de cuatro resoluciones posibles l=4,

8, 16, 32.

Las escenas utilizadas como pruebas consisten en diferentes replicaciones

de los siguientes modelos: una Teapot (ver Figura 3.13(a)), que consta de 32



supercies Bzier, Teacup (ver Figura 3.13(b)) que consta de 26 supercies

Bzier y un Elefante (ver Figura 3.13(c)) que consta de 811 supercies Bzier.

En la Tabla 3.1 se muestran los fotogramas por segundo (FPS) de diferen-

tes escenas para las diferentes propuestas de sntesis de supercies Bzier que

hemos analizado. La primera columna muestra el nmero de modelos utiliza-

dos por cada escena. La segunda columna (CPU) muestra los FPS cuando

se realiza la aproximacin tradicional, esto es, se hace la triangulacin de

las supercies Bzier en la CPU usando la tcnica de forward dierencing

mientras que los tringulos generados se sintetizan en la GPU [20]. La ter-

cera columna (GPUa) muestra los FPS en la implementacin del mtododescrito en la seccin 3.2.2. Para realizar la implementacin de esta propues-

ta hemos utilizado nuestro cdigo de prueba pero adaptndolo al caso de la

utilizacin de jerarquas de supercies, lo que implica el envo de los puntos

de control por fotograma de cada supercie a representar. La cuarta columna

(GPU b) muestra los FPS cuando se realiza la implementacin del algoritmosin batching descrito en la Seccin 3.2.3. La quinta columna (GPU c) muestralos FPS cuando no se realiza ningn clculo en el Vertex Shader pero se ge-

nera el mismo nmero de NDP que en el caso de GPUb. En la sexta columna

(GPUd) se muestran los FPS cuando se aplica la tcnica de batching. En lasimplementaciones asociada a la GPU y como se coment previamente se ha

optado por la evaluacin directa de las ecuaciones Bzier, por ser el mtodo

ms adecuado para dicha plataforma hardware [8].

Una de las desventajas de la triangulacin en la GPU es que no es posible

utilizar el mtodo de la CPU de forma directa para modelos complejos (por

ejemplo en el caso de 10 y 20 elefantes), ya que el tamao necesario del Vertex

Buer y del Index Buer, es mayor que la memoria de GPU disponible.

En cambio, con las estrategias basadas en la utilizacin de la GPU para el

proceso de triangulacin no se encuentra esta limitacin, ya que la cantidad

de memoria utilizada es mucho menor.

Como primer paso en nuestro anlisis comparamos el algoritmo original

presentado en la seccin 3.2.2, reejado en la columna GPUa, con el algo-ritmo adaptado en el que no se utilizan jerarquas de supecies, reejado en

GPU b. La no utilizacin de jerarquas de superes est asociado a la canti-dad de memoria disponible en las tarjetas grcas actuales. Esto permite que

modelos en los que anteriormente era necesario utilizar jerarquas de super-

cies con representaciones ms gruesas puedan ser manejados actualmente de

forma directa en su mayor grado de resolucin. Como consecuencia de ello el

modelo puede ser almacenado en la GPU y reutilizado durante la animacin.

Por todo ello se reducen los requerimientos de envo y, con ello, se consigue

una mayor velocidad en el proceso de sntesis, como queda reejado en los

datos numricos de la tabla.


Cuadro 3.1: Fotogramas por segundo (fps)

CPU GPU

aGPU

bGPU

cGPU

d

1 teacup 145,35 95,51 96,89 97,09 408,16

10 teacups 29,36 10,19 11,94 12,27 85,32

20 teacups 16,03 4,67 4,34 4,63 40,21

30 teacups 11,25 2,57 2,57 2,68 19,87

40 teacups 8,43 0,61 0,66 0,66 13,12

50 teacups 6,85 0,52 0,52 0,53 8,49

100 teacups 3,31 0,26 0,25 0,26 2,31

1 teapot 129,37 71,50 74,41 80 363,64

10 teapots 24,82 8,42 9,58 9,69 84,60

20 teapots 13,33 3,29 3,32 3,44 29,09

30 teapots 9,10 1,86 1,96 2,03 14,19

40 teapots 7,13 0,54 0,53 0,54 8,54

50 teapots 5,56 0,43 0,42 0,43 5,8

100 teapots 2,80 0,20 0,21 0,21 1,54

1 elefante 6,91 1,86 1,96 2,03 8,37

10 elefantes 0,078 0,077 0,078 0,99

20 elefantes 0,039 0,039 0,039 0,33



Al comparar las columnas GPU b y GPU c, se observa que los resultadosobtenidos son muy similares, a pesar de que en el segundo de los casos no

se realiza ningn clculo. Estos resultados conrman que el NDP es el factorque limita el rendimiento. El impacto que el NDP tiene en el rendimientose observa al comparar la columna GPU b con la GPUd ya que la principaldiferencia entre estas dos opciones es el NDP por fotograma.Con la implementacin del mtodo de la seccin 3.2.3 sin batching se

consigue un rendimiento peor que con la implementacin en la CPU, a pe-

sar de que en este ltimo caso se est enviando un mayor nmero de in-

formacin y los clculos se realicen en la CPU. Pero tenemos que destacar

que el rendimiento del Vertex Shader est limitado por el tamao de MRl

adems de por el NDP . Con la implementacin de batching hemos comproba-do que si aumentamos el paralelismo del programa stream del Vertex Shader

(MRl S), conseguimos un mejor rendimiento que con la subdivisin en laCPU.

La tcnica de batching implica el almacenamiento temporal de la infor-

macin en la memoria de la tarjeta grca evitando con ello continuas sin-

cronizaciones asociadas a cada supercie individual a representar. Se observa

claramente que para que el batching sea efectivo se debe realizar de forma

reiterada cada vez que se llene la memoria del sistema pues, de otra forma,

las prestaciones del sistema quedarn muy limitados. Esto se puede compro-

bar en los resultados indicados en la columna GPUd cuando el nmero deobjetos del modelo aumenta. Ntese que por motivos de claridad incluimos

en esta tabla los resultados asociados a la aplicacin de un nico batching,

obviando el hecho de que se excedan los requerimientos de almacenamiento

disponibles. Teniendo en cuenta todos los datos aqu presentados y la posibi-

lidad de hacer el batching condicionado al tamao de la memoria disponible

se observa que la tcnica de batching permite superar a cualquiera de las

otras estrategias incluida la tcnica clsica de procesamiento en la CPU.

3.2.5. Conclusiones

El mtodo clsico para la sntesis de las supercies Bzier se basa en

la triangulacin de dichas superces en la CPU y el envo de la malla de

tringulos resultante a la GPU para su sntesis. Como se ha podido comprobar

por los resultados obtenidos, al triangulizar los supercies Bzier en la GPU

se obtiene un mejor rendimiento debido al paralelismo inherente a la GPU,

aunque esta mejora en el rendimiento disminuye conforme aumenta el nmero

de supercies.

Al realizar las triangulaciones directamente en la GPU se consiguen va-

rios objetivos, liberar la CPU de carga computacin grca, disminuir los


requerimientos de comunicacin entre CPU y GPU y, adems, aprovechar

las prestaciones asociadas a la tarjeta grca para este tipo de cmputos.

Por otra parte y debido a los requerimientos de sincronimo para realizar la

sntesis en la GPU, la tcnica de batching se ha mostrado como una herra-

mienta efectiva para permitir el procesamiento en la GPU de forma efectiva

y superar con ello las limitaciones asociadas a estretegias previas.

El trabajo futuro para mejorar el rendimiento de nuestra propuesta con-

siste en utilizar el Geometry Shader y aprovechar sus capacidades para la

generacin de vrtices. Creemos que estas nuevas capacidades de la tarjeta

grca sern clave para el procesamiento en tiempo real de modelos complejos

basados en supercies Bzier.

Apndice A

Artculo

En este apndice se incluye el artculo titulado Explotacin de la tar-

jeta grca para la sntesis de modelos basados en supercies Bzier. Este

artculo, recoge los puntos principales del trabajo comentado en este dossier.

Ha sido aceptado en las XIX Jornadas de paralelismo, que se celebrarn en

Castelln en septiembre de 2008.

33

34 Apndice A. Artculo

Explotacion de la tarjeta grafica para la sntesisde modelos basados en superficies Bezier

Raquel Concheiro,1 Margarita Amor,1 Montserrat Boo2 y Ramon Doallo1

ResumenLa forma mas habitual de sintetizar superficies

Bezier consiste en su triangulacion en la CPU yel envo posterior de la malla resultante a la GPU(Graphic Processing Unit). En este trabajo se proponeny analizan diversas propuestas en las que la GPU esla encargada de realizar la sntesis directa de los mo-delos basados en superficies Bezier. De esta forma seconsigue minimizar el intercambio de informacion enel bus entre CPU y GPU, habitual cuello de botellaen un alto intercambio de informacion.Los metodos utilizados tienen en comun la tecnica

de evaluacion utilizada en la que el computo de pun-tos de la superficie se realiza en posiciones equies-paciadas del dominio parametrico. La posibilidad deseleccionar la distancia entre muestras en el espacioparametrico permite seleccionar de forma directa laresolucion de la malla de triangulos a sintetizar.

Palabras claveSuperficies Bezier, GPU, tessellation,Directx 10, NURBs.

I. Introduccion

LAS superficies NURBs (Non-Uniform rationalB-splines) [1] son utilizadas en un gran numerode herramientas CAD/CAM y aplicaciones graficas.El modelado de geometras complejas con NURBspermite obtener resultados de alta calidad con pocosrequisitos de almacenamiento y con una descripcioncompacta del modelo. Uno de los esquemas usual-mente utilizados para la sntesis de modelos basadosen superficies NURBs implica su conversion previaa superficies Bezier debido a su menor complejidadpara luego proceder a su posterior triangulacion [1].Por ello centraremos el resto del trabajo en la repre-sentacion y triangulacion de superficies Bezier.La aproximacion mas clasica para sintetizar las

superficies Bezier consiste en su triangulacion enla CPU (Central Processing Unit), y envo de lospolgonos generados a la GPU (Graphic ProcessingUnit). Esta aproximacion presenta varios problemas,entre otros, la cantidad de calculos realizados en laCPU mientras la GPU permanece ociosa, y la grancantidad de informacion que se enva a traves del busque conecta CPU y GPU, lo que lo puede convertiren un cuello de botella e influir negativamente en elrendimiento.Existen diferentes estrategias alternativas a este

metodo clasico como la realizacion de la triangu-lacion en extensiones hardware de la GPU [2], en laGPU de forma directa en las tarjetas graficas mas re-cientes [3], [4], la evaluacion directa de los puntos dela superficie en la GPU [5] o la sntesis de la imagenutilizando algoritmos de Ray tracing [6], [7].

1Dpto. de Electronica y Sistemas. Universidade de ACoruna, e-mail: {rconcheiro,margamor,doallo}@udc.es2Dpto. de Electronica y Computacion. Universidade de

Santiago de Compostela, e-mail:[email protected]

En este trabajo se presentan y analizan varias es-trategias para la triangulacion y sntesis de las super-ficies Bezier en la GPU. Comenzaremos por analizarla propuesta presentada en [3] donde se realiza lasntesis de superficies NURBs en la GPU. Adaptare-mos y simplificaremos el algoritmo para el procesadodirecto de superficies Bezier eliminando de la pro-puesta original el requerimiento de utilizacion de je-rarquas de superficies. Por otra parte y con el obje-tivo de la sntesis en tiempo real en mente, analizare-mos diferentes tecnicas para la reduccion de los re-querimientos de transmision entre CPU y GPU ypara reducir el numero de fases de sincronizacion.Finalmente presentamos una comparativa de los re-sultados obtenidos con las diversas tecnicas propues-tas con los asociados a la implementacion tradicionalque evalua las superficies directamente en la CPU.Con este objetivo en nuestra implementacion sobrela GPU hemos utilizado la API (Application Pro-gramming Interface) DirectX 10 [8].La organizacion del trabajo es la siguiente. En

primer lugar, en la Seccion II se introducen breve-mente los conceptos asociados a representacionesBezier. La Seccion III se centra en el algoritmo des-crito en [3], punto de partida de nuestro trabajo. Enel apartado IV se describe la adaptacion y modifi-caciones que proponemos sobre el algoritmo de tra-bajo persiguiendo el objetivo de la triangulacion ysntesis de modelos basados en superficies Bezier entiempo real. Posteriormente, en la Seccion V, se in-cluye un analisis de los resultados obtenidos para lasdiferentes propuestas presentadas. Para finalizar, enla Seccion VI, se presentan las principales conclu-siones.

II. Superficies Bezier

Por claridad de la presentacion comenzamos des-cribiendo las curvas Bezier. Una curva Bezier[1] es un caso especial de una curva NURBsy viene definida por un polgono de control.Matematicamente, una curva parametrica Bezier sedefine como:

P (t) =

ni=0

BiJn,i(t), 0 t 1 (1)

siendo Bi los puntos de control y Jn,i las funcionesblending, que en el caso de las curvas Bezier son poli-nomios de Bernstein:

Jn,i(t) =(ni

)(1 t)(ni)ti (2)

donde n es el grado de las funciones bases de Berns-tein y es un valor menos que el numero de puntos

35

Fig. 1. Ejemplo de curva Bezier cubica, n=3

Fig. 2. Ejemplo de superficie Bezier bicubica

de control del polinomio de Bernstein. En las cur-vas Bezier, el primer y el ultimo punto de la curvaBezier coinciden con los puntos del polgono de con-trol, P (0) = B0 y P (1) = Bn.La Figura 1 muestra una curva Bezier cubica, n =

3. Los polinomios de Bernstein para este caso son:

J3,0(t) = (1 t)3J3,1(t) = 3t(1 t)2J3,2(t) = 3t2(1 t)J3,3(t) = t3

con lo cual la curva Bezier se define por:

P (t) = (1t)3B0+3t(1t)2B1+3t2(1t)B2+t3B3La ecuacion para expresar una curva Bezier de

forma matricial es:

P (t) = [T ][N ][G] (3)

donde [T ] = [tn tn1 . . . t1 t0], la matriz [G]T =[B0 B1 . . . Bn] contiene las geometras de la curva,y [N]:(n0

)(nn

)(1)n

(n1

)(n1n1)(1)n1 . . .

(nn

)(nnnn

)(1)0

. . . . . . . . . . . .(n0

)(n1

)(1)1

(n1

)(n10

)(1)0 . . . 0(

n0

)(n0

)(1)0 0 . . . 0

Para un polgono de control de cuatro vertices (n =3)

P(t)=[T][N][G]=

[t3 t2 t1 1]

1 3 3 13 6 3 03 3 0 01 0 0 0

B0B1B2B3

Partiendo de la descripcion de una curva Bezier sepuede definir de forma analoga las superficies Bezier.As una superficie Bezier se define como:

Q(u, v) =n

i=0

mj=0Bi,jJn,i(u)Km,j(v)

0 u, v 1 (4)

donde Jn,i(u) y Km,j(v) son las funciones base deBernstein en las direcciones parametricas u y v yBi,j son los vertices de la red poligonal de con-trol. Los ndices n y m son uno menos que losvertices en las direcciones u y v, respectivamente.La Figura 2 muestra un ejemplo de una superficieBezier bicubica, n = m = 3.En forma matricial una superficie Bezier se puede

expresar como:

Q(u, v) = [U ][N ][B][M ]T [V ] (5)

Para el caso especfico de una superficie Bezierbicubica 44, su expresion matricial es:

Q(u, v) = [u3 u2 u 1]

1 3 3 13 6 3 03 3 0 01 0 0 0

B0,0 B0,1 B0,2 B0,3B1,0 B1,1 B1,2 B1,3

B2,0 B2,1 B2,2 B2,3B3,0 B3,1 B3,2 B3,3

1 3 3 13 6 3 03 3 0 0

1 0 0 0

v3v2v1

III. Triangulacion y sntesis de NURBS enla GPU

El algoritmo descrito en [3], [4] presenta, entreotras propuestas, un metodo para realizar la trian-gulacion y sntesis de superficies NURBs en la GPU.En la Figura 3, se muestra el flujo del algoritmo pro-puesto en [3] para los pasos involucrados en la trian-gulacion de las superficies. Este algoritmo consisteen dos etapas. La primera es una etapa de preprocesodonde se realiza una serie de calculos en la CPU quegeneran la informacion necesaria para la siguienteetapa. Parte de esta informacion es almacenada enla GPU. La segunda etapa es realmente el procesode sntesis que se repite por cada fotograma, f . Enel resto de esta seccion y con el apoyo de esta figurase resumira brevemente los principales pasos involu-crados en esta propuesta.El metodo aproxima en la CPU cada superficie

NURBs o T-Spline mediante una jerarqua gruesade polgonos bicubicos Bezier racionales (ver paso 1de la Figura 3). Uno de los objetivo de [3] es que elalgoritmo funcione sobre cualquier tarjeta grafica quesoporte al menos la version 1.0 de Vertex Shader. Altener en cuenta aquellas tarjetas que no tienen accesoa texturas en el Vertex Shader, la cantidad de datosde entrada para un programa de vertex esta limitadoa 16 atributos por vertice y 8 matrices de programa.Por ello, solo se pueden evaluar superficies Bezier degrado no muy elevado. Ademas como se limita elnumero de registros temporales a 12, esto implica lautilizacion de superficies bicubicas.El refinado de los polgonos de Bezier en la GPU

para generar una malla de alta calidad se vio fre-nada hasta la aparicion del Geometry Shader por


!

"

#

$

%

&

'

(

)* +), -.//)*

0

123

123 4

23

4

23

56787 95:;58>?@5:?

A

B

C D

Fig. 3. Esquema del metodo de [3] para la sntesis de NURBS en la GPU

la incapacidad de generar nuevos vertices. Esta im-posibilidad forzo en [3] a la utilizacion de mallas pre-definidas de diferentes resoluciones (ver paso 2 de lafigura), que indican los vertices virtuales y la conec-tividad entre ellos. De esta forma, con estas mallasse indican los valores parametricos u y v a ser utiliza-dos en el proceso de generacion de los vertices de lamalla triangular (ver Ecuacion 5). As, los verticesvirtuales que son definidos inicialmente sin coorde-nadas especficas, son posteriormente procesados enel Vertex Shader para la generacion de las coordena-das. Ademas, en [3] en lugar de utilizar una mallapor superficie, que ira en contra de la filosofa delcalculo del refinado en la GPU, se crea una mallapredefinida por nivel de resolucion y se almacena enla GPU en este paso del preproceso.En el paso 3 de la figura, se atraviesa para cada

fotograma f la jerarqua de superficies Bezier y seseleccionan aquellas superficies que tienen suficienteresolucion para garantizar la precision deseada enla visualizacion. Si durante el recorrido se alcanzaun nodo hoja, se generan superficies bicubicas adi-cionales. Los puntos de control de cada superficie[Bk], 0 k S (siendo S el numero de superficiesBezier) son enviados a la GPU. Ademas, para cadasuperficie se selecciona una malla de resolucion ade-cuada que garantice la precision deseada, l (ver etapa3 de la figura).En la GPU (ver paso 4 de la figura) se calcula en

el Vertex Shader la ecuacion 5 para cada superficiey para cada vertice virtual de la malla resolucionadecuada para ese caso. Para sintetizar los polgonosde Bezier en la GPU, en [3] se opto por la evaluaciondirecta frente al algoritmo de deCasteljau [9] ya quela implementacion en la GPU del primero de ellos esmas eficiente.

IV. Sntesis de superficies Bezier en la GPU

En esta seccion describimos el metodo que hemosimplementado para realizar la sntesis de superficiesBezier mediante su triangulacion en la GPU. Para

ello nos basamos en el metodo descrito en la SeccionIII aunque en nuestra implementacion se han consi-derado desde un primer momento superficies Bezierbicubicas, por lo que no fue necesario realizar la con-version de NURBs a Bezier. Ademas, y teniendoen cuenta las capacidades de almacenamiento cadavez mayores existentes en las tarjetas graficas ac-tuales nuestra propuesta no utilizara jerarquas desuperficies. Esto, como se vera a continuacion, per-mite reducir los requerimientos de transmision entreCPU y GPU de la propuesta original. Nuestra imple-mentacion persigue presentar alternativas a la pro-puesta previa a traves de varias vas, por una parte,evitando el envo de puntos de control durante el pro-ceso de sntesis mediante su almacenamiento previoen la memoria de la GPU y, por otra parte, mediantela explotacion eficiente de los recursos disponibles enlas tarjetas graficas actuales.En la Figura 4 se presenta la estructura del nuevo

algoritmo que proponemos para la triangulacion ysntesis de superficies Bezier en la GPU. Los puntosde control de las superficies Bezier [Bk], 1 k S,se envan una unica vez a la GPU, en la etapa depreproceso (ver paso 1 de la Figura 4). El almace-namiento de los puntos de control en la GPU permiteevitar el continuo reenvo de la misma informacioncada vez que se procesa una superficie concreta. Estoes posible, ya que a diferencia del metodo de [3],nuestra aproximacion sigue un metodo mas simpli-ficado donde las superficies Bezier vienen determi-nadas desde el principio y no dependen del recorridopor la jerarqua de superficies.En concreto, en nuestra propuesta [Bk] se alma-

cena en tres arrays diferentes [Bkx , Bky , B

kz ], de tipo

float44 uno por cada coordenada y en memoria detexturas usando un buffer de texturas (tbuffer) [10].Se consigue mejor rendimiento por la utilizacion dela memoria de texturas que con las otras memoriasde la GPU, puesto que su acceso no esta sujeto alas restricciones de los patrones de acceso a memoriaque tienen que cumplir la memoria global y la cons-

37

!" #$%%

&

'

()*

()* +

)*

+

)*

,-./. 0, 123-,141

,-./. 0, /5,/567,16

8

9

: ;

9

?@

A BC

D

@

>

? E@F

Fig. 4. Sntesis de superficies Bezier en la GPU

tante. Ademas la latencia de los calculos de acceso aesta memoria estan mejor ocultos que en otras. Porotro lado, el tbuffer, permite empaquetar datos quepueden ser accedidos desde variables separadas enuna misma operacion, aumentando as el ancho debanda.Las mallas de diferente resolucion que indican las

coordenadas parametricas a ser posteriormente eva-luadas para el computo de los nuevos vertices songeneradas en la CPU antes de comenzar el procesode sntesis de igual forma que en la seccion III. Estasmallas son enviadas a la GPU y almacenadas en ella,como se puede ver en el paso 2 de la Figura 4. Cadamalla de resolucion, MR, se almacena en la memoriade la GPU en el paso de preproceso como un Ver-tex Buffer [11], lo que permite acelerar la sntesis dela geometra y proporcionar un alto ancho de bandaen el flujo de datos, as que la tarjeta grafica puedeleer mas rapidamente las primitivas. No es nece-sario generar ningun Index Buffer [11] ya que losvalores almacenados en el Vertex Buffer mantienenlas relaciones de localidad para permitir generar lospolgonos necesarios.En cada fotograma se sintetizan cada una de las

superficies con el nivel de resolucion adecuado. Ennuestra aproximacion, como hemos indicado, no esnecesario enviar los puntos de control de la superficieBezier ya que estan almacenados en la GPU. Lo quese enva por cada superficie y para cada fotograma fes el nivel l, el ndice de la superficie k y el tamanot de la malla de resolucion (ver paso 3 de la figura).As el numero de envos, Ne, por cada fotograma es:

Ne = 3 Ssiendo S el numero de superficies.En la GPU, se generan los triangulos necesarios

para representar la superficie Bezier con la resolu-cion seleccionada. En la Figura 5 se muestra el pseu-docodigo del Vertex Shader para generar la triangu-lacion de las superficies Bezier bicubicas en funcionde las mallas de resolucion. Utilizamos el Vertex

1 VS OUTPUT DefaultVS(VS INPUT MRl)2 {3 float4x4 [N]= { -1, 3, -3, 1,4 3, -6, 3, 0,5 -3, 3, 0, 0,6 3, 0, 0, 0, }7 u=MRl.x; v=MRl.y;8 float1x4 [u]=(u3, u2, u, 1);9 float1x4 [v]=(v3, v2, v, 1);10 float4x4 {[Bkx ],[Bky ],[Bkz ]} = leer de texturas (k);11 float3 vertice = mul( [u], [N],[Bk], [N], [v]);12 return vertice;13 }

Fig. 5. Vertex Shader para la sntesis de superficies Bezier enbase a las mallas de resolucion

Shader ya que el metodo de [3] fue pensado paraejecutarse en el procesador de vertices. Para cadasuperficie, el Vertex Shader recibira como entradalos valores que forman la malla de resolucion selec-cionada para sintetizar la superficie (lnea 1). A par-tir de estos valores se calculan los vectores [U ] y [V ]de la Ecuacion 5 (lneas 8 y 9). En la lnea 10 selee de la memoria de texturas, los valores correspon-dientes a los puntos de control de la superficie k quese esta computando en ese momento. Por ultimo,se multiplican estos valores, siguiendo la Ecuacion 5para generar los vertices deseados (lnea 11).Con esta aproximacion se realiza una llamada

sncrona, draw Primitive a la GPU por fotogramay para cada una de las superficies que forman laescena. Por tanto, el numero de sincronizaciones,NDP , por fotograma es NDP = S. Este aspectolimita el rendimiento de este metodo como compro-baremos en la seccion V debido a las multiples lla-madas a esta operacion sncrona [12]. Hay que teneren cuenta que cuando se genera la malla de polgonosen la CPU NDP = 1 por fotograma.Para lograr una mejora del rendimiento es nece-

sario minimizar NDP . Con este objetivo hemos in-troducido en nuestra propuesta la tecnica de batching[12]. Esta tecnica persigue minimizar el numero dellamadas a draw Primitive, para ello, se juntan los


(a)

(b)

(c)

Fig. 6. Modelos utilizados para l=4 y l=16 (a) Teapot, (b)Teacup y (c) elefante

datos de todas las superficies a sintetizar en un unicoenvo y se realiza una llamada sncrona por cada fo-tograma, lo que reduce el numero de sincronizacionpor fotograma a NDP = 1. Como se vera en la si-guiente seccion la utilizacion de la tecnica de batchingesta limitada a la cantidad de memoria disponibleen la GPU para el almacenamiento temporal de lainformacion hasta que se realice el proceso de sin-cronizacion. As, si en la implementacion basada en[3], la memoria reservada era la suma del tamanode la malla de las cuatro resoluciones permitidas ensu implementacion (MR32+MR16+MR8+MR4),con nuestra tecnica con batching se necesita reser-var S MR32 siendo MR32 la malla de resolucionde maximo tamano permitida. De esta forma, lacantidad de memoria que hay que reservar es nues-tra propuesta es mayor y directamente proporcionalal numero de superficies que se vayan a sintetizar.Esto, sin embargo, no es ninguna limitacion en lapropuesta si se realiza el batching hasta que se alcan-cen las capacidades de almacenamiento disponiblescomenzando, a continuacion y tras una fase de sin-cronizacion, con un nuevo batching.

V. Resultados

En esta seccion se presentan los resultadosobtenidos. Todas las medidas, se han obtenido en unsistema Intel core duo E6600 con 2GB de RAM, unaGeforce 8800GTX y utilizando Microsoft Vista, conla version de DirectX 10 y la version 4.0 de shader.La animacion utilizada consiste en un zoom sobre

los diferentes objetos, de forma que la camara se vaalejando lenta y constantemente, cambiando la re-solucion necesaria para cada objeto. En los analisispresentados en esta seccion se ha considerado la exis-tencia de cuatro resoluciones posibles l=4, 8, 16, 32.Las escenas utilizadas como pruebas consisten en

diferentes replicaciones de los siguientes modelos:una Teapot (ver Figura 6(a)), que consta de 32 su-perficies Bezier, Teacup (ver Figura 6(b)) que consta

TABLA I

Fotogramas por segundo (fps)

CPU GPUa GPUb GPUc GPUd

1 teacup 145,35 95,51 96,89 97,09 408,1610 teacups 29,36 10,19 11,94 12,27 85,3220 teacups 16,03 4,67 4,34 4,63 40,2130 teacups 11,25 2,57 2,57 2,68 19,8740 teacups 8,43 0,61 0,66 0,66 13,1250 teacups 6,85 0,52 0,52 0,53 8,49100 teacups 3,31 0,26 0,25 0,26 2,311 teapot 129,37 71,50 74,41 80 363,6410 teapots 24,82 8,42 9,58 9,69 84,6020 teapots 13,33 3,29 3,32 3,44 29,0930 teapots 9,10 1,86 1,96 2,03 14,1940 teapots 7,13 0,54 0,53 0,54 8,5450 teapots 5,56 0,43 0,42 0,43 5,8100 teapots 2,80 0,20 0,21 0,21 1,541 elefante 6,91 1,86 1,96 2,03 8,3710 elefantes 0,078 0,077 0,078 0,9920 elefantes 0,039 0,039 0,039 0,33

de 26 superficies Bezier y un Elefante (ver Figura6(c)) que consta de 811 superficies Bezier.En la Tabla I se muestran los fotogramas por se-

gundo (FPS) de diferentes escenas para las diferen-tes propuestas de sntesis de superficies Bezier quehemos analizado. La primera columna muestra elnumero de modelos utilizados por cada escena. Lasegunda columna (CPU) muestra los FPS cuandose realiza la aproximacion tradicional, esto es, sehace la triangulacion de las superficies Bezier en laCPU usando la tecnica de forward differencing mien-tras que los triangulos generados se sintetizan en laGPU [11]. La tercera columna (GPUa) muestra losFPS en la implementacion del metodo descrito en laseccion III. Para realizar la implementacion de estapropuesta hemos utilizado nuestro codigo de pruebapero adaptandolo al caso de la utilizacion de jerar-quas de superficies, lo que implica el envo de lospuntos de control por fotograma de cada superficiea representar. La cuarta columna (GPU b) muestralos FPS cuando se realiza la implementacion del al-goritmo sin batching descrito en la Seccion IV. Laquinta columna (GPU c) muestra los FPS cuando nose realiza ningun calculo en el Vertex Shader pero segenera el mismo numero de NDP que en el caso deGPU b. En la sexta columna (GPUd) se muestranlos FPS cuando se aplica la tecnica de batching. Enlas implementaciones asociada a la GPU y como secomento previamente se ha optado por la evaluaciondirecta de las ecuaciones Bezier, por ser el metodomas adecuado para dicha plataforma hardware [3].Una de las desventajas de la triangulacion en la

GPU es que no es posible utilizar el metodo de laCPU de forma directa para modelos complejos (porejemplo en el caso de 10 y 20 elefantes), ya queel tamano necesario del Vertex Buffer y del IndexBuffer, es mayor que la memoria de GPU disponible.En cambio, con las estrategias basadas en la uti-lizacion de la GPU para el proceso de triangulacionno se encuentra esta limitacion, ya que la cantidadde memoria utilizada es mucho menor.Como primer paso en nuestro analisis comparamos

el algoritmo original presentado en la seccion III, re-flejado en la columna GPUa, con el algoritmo adap-

39

tado en el que no se utilizan jerarquas de superficies,reflejado en GPU b. La no utilizacion de jerarquasde superficies esta asociado a la cantidad de memo-ria disponible en las tarjetas graficas actuales. Estopermite que modelos en los que anteriormente eranecesario utilizar jerarquas de superficies con repre-sentaciones mas gruesas puedan ser manejados ac-tualmente de forma directa en su mayor grado de re-solucion. Como consecuencia de ello el modelo puedeser almacenado en la GPU y reutilizado durante laanimacion. Por todo ello se reducen los requerimien-tos de envo y, con ello, se consigue una mayor veloci-dad en el proceso de sntesis, como queda reflejadoen los datos numericos de la tabla.Al comparar las columnas GPU b y GPU c, se ob-

serva que los resultados obtenidos son muy similares,a pesar de que en el segundo de los casos no se rea-liza ningun calculo. Estos resultados confirman queel NDP es el factor que limita el rendimiento. El im-pacto que el NDP tiene en el rendimiento se observaal comparar la columna GPU b con la GPUd ya quela principal diferencia entre estas dos opciones es elNDP por fotograma.Con la implementacion del metodo de la seccion

IV sin batching se consigue un rendimiento peor quecon la implementacion en la CPU, a pesar de que eneste ultimo caso se este enviando un mayor numerode informacion y los calculos se realicen en la CPU.Pero tenemos que destacar que el rendimiento delVertex Shader esta limitado por el tamano de MRl

ademas de por el NDP . Con la implementacion debatching hemos comprobado que si aumentamos elparalelismo del programa stream del Vertex Shader(MRl S), conseguimos un mejor rendimiento quecon la subdivision en la CPU.La tecnica de batching implica el almacenamiento

temporal de la informacion en la memoria de la tar-jeta grafica evitando con ello continuas sincroniza-ciones asociadas a cada superficie individual a re-presentar. Se observa claramente que para que elbatching sea efectivo se debe realizar de forma reite-rada cada vez que se llene la memoria del sistemapues, de otra forma, las prestaciones del sistemaquedaran muy limitados. Esto se puede compro-bar en los resultados indicados en la columna GPUd

cuando el numero de objetos del modelo aumenta.Notese que por motivos de claridad incluimos en estatabla los resultados asociados a la aplicacion de ununico batching, obviando el hecho de que se excedanlos requerimientos de almacenamiento disponibles.Teniendo en cuenta todos los datos aqu presentadosy la posibilidad de hacer el batching condicionadoal tamano de la memoria disponible se observa quela tecnica de batching permite superar a cualquierade las otras estrategias incluida la tecnica clasica deprocesamiento en la CPU.

VI. Conclusiones

El metodo clasico para la sntesis de las superficiesBezier se basa en la triangulacion de dichas superficesen la CPU y el envo de la malla de triangulos resul-

tante a la GPU para su sntesis. Como se ha podidocomprobar por los resultados obtenidos, al triangu-lizar los superficies Bezier en la GPU se obtiene unmejor rendimiento debido al paralelismo inherente ala GPU, aunque esta mejora en el rendimiento dis-minuye conforme aumenta el numero de superficies.Al realizar las triangulaciones directamente en la

GPU se consiguen varios objetivos, liberar la CPUde carga computacion grafica, disminuir los reque-rimientos de comunicacion entre CPU y GPU y,ademas, aprovechar las prestaciones asociadas a latarjeta grafica para este tipo de computos. Por otraparte y debido a los requerimientos de sincronimopara realizar la sntesis en la GPU, la tecnica debatching se ha mostrado como una herramienta efec-tiva para permitir el procesamiento en la GPU deforma efectiva y superar con ello las limitaciones aso-ciadas a estrategias previas.El trabajo futuro para mejorar el rendimiento de

nuestra propuesta consiste en utilizar el GeometryShader y aprovechar sus capacidades para la gene-racion de vertices. Creemos que estas nuevas ca-pacidades de la tarjeta grafica seran clave para elprocesamiento en tiempo real de modelos complejosbasados en superficies Bezier.

Agradecimientos

Este trabajo ha sido financiado por el Minis-terio de Educacion y Ciencia dentro del proyectoTIN2007-67537-C03-02 y por la Xunta de Galiciadentro del Programa de Consolidacion de Gruposde Investigacion Competitivos (Ref. 3/2006 DOGA13/12/2006).

Referencias

[1] D. F. Rogers, An Introduction to NURBS with HistoricalPerspective, Morgan Kaufmann, 2001.

[2] F. J. Espino, M. Boo, M. Amor and J.D. Bruguera,Hardware Support for Adaptive Tessellation of BezierSurfaces on Local Tests, Journal of Systems Architec-ture, pp. 233250, 2007.

[3] M. Guthe, A. Balazsand and R. Klein, GPU-basedTrimming and Tessellation of NURBS and T-Spline Sur-faces, ACM SIGGRAPH 2005, Volume 24, pp: 1016 -1023.

[4] M. Guthe, A. Balazsand and R. Klein, GPU-basedAppearance Preserving Trimmed NURBS Rendering,Journal of WSCG 2006, Vol 14., 2005.

[5] A. Krishnamurthy, R. Khardekar and S. McMains, Di-rect Evaluation of NURBS Curves and Surfaces on theGPU, ACM Symposium on Solid and Physical Model-ing, pp. 329 334, 2007.

[6] A. Efremov, V. Havran and H.P. Seidel, Robust and Nu-merically Stable Bezier Clipping Method for Ray TracingNURBS Surfaces, 21st Spring Conference on ComputerGraphics, pp. 127 135, 2005.

[7] C. Benthin, I. Wald and P. Slusallek, Interactive RayTracing of Free-Form Surface, 3rd International Con-ference on Computer Graphics, Virtual Reality, Visual-isation and Interaction in Africa, pp. 99 106, 2004.

[8] D. Blythe, The Direct3D 10 System, ACM SIG-GRAPH 2006, vol. 25, pp. 724734, 2006.

[9] P. Shirley, Fundamentals of Computer Graphics,Addison-Wesley, 2003.

[10] Microsoft, DirectX SDK Documentation, 2007.[11] P. Walsh, Advanced 3D Game Programming with Di-

rectX 10.0, Wordware, 2008.[12] C. Cebenoyan, GPU Gems: Programming Techniques,

Tips and Tricks for Real-Time graphics, chapter Graph-ics Pipeline Performance, Addison-Wesley, 2004.

Bibliografa

[1] A. Efremov, V. Havran and H.P. Seidel. Robust and Numerically Stable

Bzier Clipping Method for Ray Tracing NURBS Surfaces. 21st Spring

Conference on Computer Graphics, pages 127 135, 2005.

[2] A. Krishnamurthy, R. Khardekar and S. McMains. Direct Evaluation of

NURBS Curves and Surfaces on the GPU. ACM Symposium on Solid

and Physical Modeling, pages 329 334, 2007.

[3] D. Blythe. The Direct3D 10 System. ACM SIGGRAPH 2006, 25:724

734, 2006.

[4] C. Benthin, I. Wald and P. Slusallek. Interactive Ray Tracing of Free-

Form Surface. 3rd International Conference on Computer Graphics,

Virtual Reality, Visualisation and Interaction in Africa, pages 99 106,

2004.

[5] C. Cebenoyan. GPU Gems: Programming Techniques, Tips and

Tricks for Real-Time graphics, chapter Graphics Pipeline Performance.

Addison-Wesley, 2004.

[6] F. J. Espino, M. Bo, M. Amor and J.D. Bruguera. Hardware Support

for Adaptive Tessellation of Bzier Surfaces on Local Tests. Journal of

Systems Architecture, pages 233250, 2007.

[7] K. Grya. Microsoft DirectX9 Programmable Graphics Pipeline. Mi-

crosoft Press, 2003.

[8] M. Guthe, A. Balzsand and R. Klein. GPU-based Trimming and Tes-

sellation of NURBS and T-Spline Surfaces. ACM SIGGRAPH 2005,

Volume 24, pp: 1016 - 1023.

[9] M. Guthe, A. Balzsand and R. Klein. GPU-based Appearance Pre-

serving Trimmed NURBS Rendering. Journal of WSCG 2006, Vol 14.,

2005.

41

42 Bibliografa

[10] Microsoft. DirectX SDK Documentation, 2007.

[11] Nvidia. Technical Brief. The GeForce 6 Series of GPUs High Perfor-

mance and Quality for Complex Image Eects, 2004.

[12] Nvidia. Technical Brief. Microsoft DirectX 10: The Next-Generation

Graphics API, 2006.

[13] M. Pharr, editor. GPU Gems II. Addison-Wesley, 2005.

[14] L. Piegl and W. Tiller. The NURBS book. Springer, 1997.

[15] R. Concheiro, M. Amor, M. Bo, R. Doallo. Explotacin de la tarjeta

grca para la sntesis de modelos basados en supercies Bzier. XIX

Jornadas de Paralelismo (Aceptado), 2008.

[16] D. F. Rogers. An Introduction to NURBS with Historical Perspective.

Morgan Kaufmann, 2001.

[17] P. Shirley. Fundamentals of Computer Graphics. Addison-Wesley, 2003.

[18] T. Nishita, T. W. Sederberg and M. Kakimoto. Ray Tracing Trimmed

Rational Surface Patches. ACM SIGGRAPH 1990, 24:337 345, 1990.

[19] W. Martin, E. Cohen, R. Fish and P. Shirley. Practical Ray Tracing of

Trimmed NURBS Surfaces. Journal of Graphics Tools, 5:27 52, 2000.

[20] P. Walsh. Advanced 3D Game Programming with DirectX 10.0. Word-

ware, 2008.

Uso de Processing

Documents

Transcript of Uso de Processing