20

Captulo 3. Trabajos tutelados

la GPU. Adaptaremos y simplicaremos el algoritmo para el procesado directo 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 evaluacin 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 utilizado la API (

Application Programming Interface ) DirectX 10 [3].

Para ello empezaremos describiendo las caractersticas de las tarjetas grcas 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 apartado 3.2.3 se describe la adaptacin y modicaciones que proponemos sobre
el algoritmo de trabajo persiguiendo el objetivo de la triangulacin y sntesis 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 procesadores. 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

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

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

Pixel Shader aumenta el nmero de instrucciones dinmicas y se

generacin el
respecto al

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

Assembler

Input

(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.

22

Captulo 3. Trabajos tutelados

Input
Assembler
Vertex
Shader
Geometry
Shader
Stream
Output

Memoria

Rasterizer

Pixel
Shader

Output
Merger

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

etry Shader

Geom-

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
de las primitivas entra en el

Pixel Shader

Rasterizer

[17], cada una

(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

High Level Shader Language

shader

se puede usar, entre otros, el

(HLSL)[7]. HLSL es un lenguaje similar a C,

incluyendo todas aquellas acciones que se puedan realizar en lenguaje ensamblador 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. Computacin grca 2: Explotacin de la tarjeta grca para la sntesis

de modelos basados en supercies Bzier

23

3.2.2. Triangulacin y sntesis de NURBS en la GPU

CPU

NURBs
o
T-Splines
Aproximacin
Bzier 1
bicbicas

ETAPA DE PREPROCESO
GPU

Jerarqua
bicbica

Generacin
mallas 2
resoluciones

CPU

Seleccin
de
LOD

ETAPA DE SNTESIS
GPU

Mallas
resolucin

Jerarqua
bicbica

l,

Evaluacin
superficies
Bzier

Rasterizer

Vertex Buffer

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.

En

el 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,0

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, con
de

lo que slo se pueden evaluar supercies Bzier de grado no muy elevado.

Adems como se limita el nmero de registros temporales a
la utilizacin de supercies bicbicas.

12,

esto implica

24

Captulo 3. Trabajos tutelados

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
y

a ser utilizados en el proceso de generacin de los vrtices de la malla

triangular (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

la jerarqua

de supercies Bzier y se seleccionan aquellas supercies que tienen suciente resolucin para garantizar la precisin deseada en la visualizacin. Si
durante el recorrido se alcanza un nodo hoja, se generan supercies bicbicas
k
adicionales. Los puntos de control de cada supercie [B ], 0 k S (siendo

el nmero de supercies Bzier) son enviados a la GPU. Adems, para

cada supercie se selecciona una malla de resolucin adecuada que garantice

la precisin deseada,

(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 realizar 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 supercies Bzier bicbicas, por lo que no fue necesario realizar la conversin
de NURBs a Bzier. Adems, y teniendo en cuenta las capacidades de almacenamiento 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 presentar alternativas a la propuesta previa a travs de varias vas, por una parte,

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

de modelos basados en supercies Bzier

ETAPA DE PREPROCESO
GPU

CPU

Generacin
mallas 2
resoluciones

CPU

Seleccin
de
LOD

25

Mallas
resolucin

l,t,k

Evaluacin
superficies
Bzier

ETAPA DE SNTESIS
GPU

Puntos de
control

Rasterizer

Vertex Buffer

Figura 3.11: Sntesis de supercies Bzier en la GPU

evitando el envo de puntos de control durante el proceso de sntesis mediante 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 proponemos para la triangulacin y sntesis de supercies Bzier en la GPU.
k
Los puntos de control de las supercies Bzier [B ], 1 k S , se envan
una 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.

k
En concreto, en nuestra propuesta [B ] se almacena en tres arrays diferenk
k
k
tes [Bx , By , Bz ], de tipo
uno por cada coordenada y en memoria
de texturas usando un buer de texturas (
) [10]. Se consigue mejor

oat4 4

tbuer

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

26

Captulo 3. Trabajos tutelados

1 VS_OUTPUT DefaultVS(VS_INPUT MRl )

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=MRl .x; v=MRl .y;
8
oat1x4 [u]=(u3 , u2 , u, 1);
9
oat1x4 [v]=(v 3 , v 2 , v, 1);
10 oat4x4 {[Bxk ],[Byk ],[Bzk ]} = leer de texturas (k);
11 oat3 vertice = mul( [u], [N],[B k ], [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 paramtricas 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 preproceso 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
el

Vertex Buer

Index Buer

[20] ya que los valores almacenados en

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

es el nivel l , el ndice de la supercie

y el tamao

de resolucin (ver paso 3 de la gura). As el nmero de envos,

fotograma es:

Ne = 3 S
siendo S el nmero de supercies.

t de la malla
Ne , por cada

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

de modelos basados en supercies Bzier

27

En la GPU, se generan los tringulos necesarios para representar la supercie 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 vectores [U ] y [V ] de la Ecuacin 3.6 (lneas 8 y 9). En la lnea 10 se lee de
la memoria de texturas, los valores correspondientes a los puntos de control
de la supercie

que se est computando en ese momento. Por ltimo, se

multiplican estos valores, siguiendo la Ecuacin 3.6 para generar los vrtices
deseados (lnea 11).
Con esta aproximacin se realiza una llamada sncrona,

draw Primitive

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 . Con

batching
[5]. Esta tcnica persigue minimizar el nmero de llamadas a draw Primitive,
este objetivo hemos introducido en nuestra propuesta la tcnica de

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.

siguiente seccin la utilizacin de la tcnica de

Como se ver en la

batching

est limitada a la

cantidad de memoria disponible en la GPU para el almacenamiento temporal 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 imple32
16
8
4
mentacin (M R + M R + M R + M R ), con nuestra tcnica con
32
32
se necesita reservar S M R
siendo M R
la malla de resolucin de mximo

batching

tamao 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.

28

Captulo 3. Trabajos tutelados

(a)

(b)

(c)

Figura 3.13:
(c) Elefante

Modelos utilizados para l=4 y l=16 (a)

Teapot,

(b)

Teacup

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

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

de modelos basados en supercies Bzier

29

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.
supercies Bzier,

En la Tabla 3.1 se muestran los fotogramas por segundo (FPS) de diferentes escenas para las diferentes propuestas de sntesis de supercies Bzier que
hemos analizado. La primera columna muestra el nmero de modelos utilizados 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 tera

cera columna (GP U ) muestra los FPS en la implementacin del mtodo
descrito en la seccin 3.2.2. Para realizar la implementacin de esta propuesta 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
b
(GP U ) muestra los FPS cuando se realiza la implementacin del algoritmo
c
sin
descrito en la Seccin 3.2.3. La quinta columna (GP U ) muestra

batching

los FPS cuando no se realiza ningn clculo en el

Vertex Shader

pero se geb
nera el mismo nmero de NDP que en el caso de GP U . En la sexta columna
d
(GP U ) se muestran los FPS cuando se aplica la tcnica de
. En las

batching

implementaciones 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

Buer

y del

Index Buer,

Vertex

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
GP U a , con el algo-

presentado en la seccin 3.2.2, reejado en la columna

ritmo adaptado en el que no se utilizan jerarquas de supecies, reejado en

GP U b . La no utilizacin de jerarquas de superes est asociado a la cantidad de memoria disponible en las tarjetas grcas actuales. Esto permite que
modelos en los que anteriormente era necesario utilizar jerarquas de supercies 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.

30

Captulo 3. Trabajos tutelados

Cuadro 3.1: Fotogramas por segundo (fps)

CPU GPUa GPUb GPUc GPUd
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

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

de modelos basados en supercies Bzier

Al comparar las columnas

GP U b

31

GP U c ,

se observa que los resultados

obtenidos 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 factor

que limita el rendimiento. El impacto que el NDP tiene en el rendimiento

b
d
se observa al comparar la columna GP U con la GP U ya que la principal
diferencia 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 pesar de que en este ltimo caso se est enviando un mayor nmero de informacin y los clculos se realicen en la CPU. Pero tenemos que destacar
l
que el rendimiento del
est limitado por el tamao de M R

Vertex Shader

adems de por el

NDP . Con la implementacin de batching

stream

hemos comproba-

Vertex Shader

do que si aumentamos el paralelismo del programa

del
l
(M R S ), conseguimos un mejor rendimiento que con la subdivisin en la
CPU.

La tcnica de

batching

implica el almacenamiento temporal de la infor-

macin en la memoria de la tarjeta grca evitando con ello continuas sincronizaciones 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 comprod
bar en los resultados indicados en la columna GP U cuando el nmero de
objetos 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 posibilidad 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 varios objetivos, liberar la CPU de carga computacin grca, disminuir los

32

Captulo 3. Trabajos tutelados

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 consiste 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 tarjeta 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 sntesis

de modelos basados en superficies Bezier
Raquel Concheiro,1 Margarita Amor,1 Montserrat Boo2 y Ramon Doallo1
Resumen
La forma m
as habitual de sintetizar superficies
B
ezier consiste en su triangulaci
on en la CPU y
el envo posterior de la malla resultante a la GPU
(Graphic Processing Unit). En este trabajo se proponen
y analizan diversas propuestas en las que la GPU es
la encargada de realizar la sntesis directa de los modelos basados en superficies B
ezier. De esta forma se
consigue minimizar el intercambio de informaci
on en
el bus entre CPU y GPU, habitual cuello de botella
en un alto intercambio de informaci
on.
Los m
etodos utilizados tienen en com
un la t
ecnica
de evaluaci
on utilizada en la que el c
omputo de puntos de la superficie se realiza en posiciones equiespaciadas del dominio param
etrico. La posibilidad de
seleccionar la distancia entre muestras en el espacio
param
etrico permite seleccionar de forma directa la
resoluci
on de la malla de tri
angulos a sintetizar.
Palabras clave Superficies B
ezier, GPU, tessellation,
Directx 10, NURBs.

n
I. Introduccio

AS superficies NURBs (Non-Uniform rational

B-splines) [1] son utilizadas en un gran n
umero
de herramientas CAD/CAM y aplicaciones gr
aficas.
El modelado de geometras complejas con NURBs
permite obtener resultados de alta calidad con pocos
requisitos de almacenamiento y con una descripcion
compacta del modelo. Uno de los esquemas usualmente utilizados para la sntesis de modelos basados
en superficies NURBs implica su conversion previa
a superficies Bezier debido a su menor complejidad
para luego proceder a su posterior triangulaci
on [1].
Por ello centraremos el resto del trabajo en la representaci
on y triangulaci
on de superficies Bezier.
La aproximaci
on m
as clasica para sintetizar las
superficies Bezier consiste en su triangulaci
on en
la CPU (Central Processing Unit), y envo de los
polgonos generados a la GPU (Graphic Processing
Unit). Esta aproximaci
on presenta varios problemas,
entre otros, la cantidad de c
alculos realizados en la
CPU mientras la GPU permanece ociosa, y la gran
cantidad de informacion que se enva a traves del bus
que conecta CPU y GPU, lo que lo puede convertir
en un cuello de botella e influir negativamente en el
rendimiento.
Existen diferentes estrategias alternativas a este
metodo clasico como la realizaci
on de la triangulacion en extensiones hardware de la GPU [2], en la
GPU de forma directa en las tarjetas gr
aficas m
as recientes [3], [4], la evaluacion directa de los puntos de
la superficie en la GPU [5] o la sntesis de la imagen
utilizando algoritmos de Ray tracing [6], [7].

1 Dpto.
de Electr
onica y Sistemas. Universidade de A
Coru
na, e-mail: {rconcheiro,margamor,doallo}@udc.es
2 Dpto. de Electr
onica y Computaci
on. Universidade de
Santiago de Compostela, e-mail:mboo@dec.usc.es

En este trabajo se presentan y analizan varias estrategias para la triangulaci

on y sntesis de las superficies Bezier en la GPU. Comenzaremos por analizar
la propuesta presentada en [3] donde se realiza la
sntesis de superficies NURBs en la GPU. Adaptaremos y simplificaremos el algoritmo para el procesado
directo de superficies Bezier eliminando de la propuesta original el requerimiento de utilizacion de jerarquas de superficies. Por otra parte y con el objetivo de la sntesis en tiempo real en mente, analizaremos diferentes tecnicas para la reduccion de los requerimientos de transmisi
on entre CPU y GPU y
para reducir el n
umero de fases de sincronizaci
on.
Finalmente presentamos una comparativa de los resultados obtenidos con las diversas tecnicas propuestas con los asociados a la implementacion tradicional
que eval
ua las superficies directamente en la CPU.
Con este objetivo en nuestra implementacion sobre
la GPU hemos utilizado la API (Application Programming Interface) DirectX 10 [8].
La organizacion del trabajo es la siguiente. En
primer lugar, en la Seccion II se introducen brevemente los conceptos asociados a representaciones
Bezier. La Seccion III se centra en el algoritmo descrito en [3], punto de partida de nuestro trabajo. En
el apartado IV se describe la adaptaci
on y modificaciones que proponemos sobre el algoritmo de trabajo persiguiendo el objetivo de la triangulaci
on y
sntesis de modelos basados en superficies Bezier en
tiempo real. Posteriormente, en la Seccion V, se incluye un an
alisis de los resultados obtenidos para las
diferentes propuestas presentadas. Para finalizar, en
la Seccion VI, se presentan las principales conclusiones.
zier
II. Superficies Be
Por claridad de la presentacion comenzamos describiendo las curvas Bezier.
Una curva Bezier
[1] es un caso especial de una curva NURBs
y viene definida por un polgono de control.
Matematicamente, una curva parametrica Bezier se
define como:
P (t) =

n
X
i=0

Bi Jn,i (t), 0 t 1

(1)

siendo Bi los puntos de control y Jn,i las funciones

blending, que en el caso de las curvas Bezier son polinomios de Bernstein:
n

(ni) i
Jn,i (t) =

(1 t)

(2)

donde n es el grado de las funciones bases de Bernstein y es un valor menos que el n

umero de puntos

35

donde Jn,i (u) y Km,j (v) son las funciones base de

Bernstein en las direcciones parametricas u y v y
Bi,j son los vertices de la red poligonal de control. Los ndices n y m son uno menos que los
vertices en las direcciones u y v, respectivamente.
La Figura 2 muestra un ejemplo de una superficie
Bezier bic
ubica, n = m = 3.
En forma matricial una superficie Bezier se puede
expresar como:

Fig. 1. Ejemplo de curva B

ezier c
ubica, n=3

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

(5)

Para el caso especfico de una superficie Bezier

bic
ubica 44, su expresi
on matricial es:

Q(u, v) = [u

Fig. 2. Ejemplo de superficie B

ezier bic
ubica

de control del polinomio de Bernstein. En las curvas Bezier, el primer y el u

ltimo punto de la curva
Bezier coinciden con los puntos del polgono de control, P (0) = B0 y P (1) = Bn .
La Figura 1 muestra una curva Bezier c
ubica, n =
3. Los polinomios de Bernstein para este caso son:
J3,0 (t)
J3,1 (t)
J3,2 (t)
J3,3 (t)

=
=
=
=

P (t) = (1 t)3 B0 + 3t(1 t)2 B1 + 3t2 (1 t)B2 + t3 B3

La 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]:
n
n
n

n1
n1

nn
0
n
n
0

(1)

.n.
. 1
(1)

n1
0

n
0
n
0

(1)
n1
...
n1
(1)0
0

n
1

(1)

...

...

nn
...

...

...

(1)

Para un polgono de control de cuatro vertices (n =

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

[t3

t2

t1

1]

1
3
3
1

3
6
3
0

3
3
0
0

1
0
0
0

B0
B1
B2
B3

Partiendo de la descripci
on de una curva Bezier se
puede definir de forma an
aloga las superficies Bezier.
As una superficie Bezier se define como:
Q(u, v) =

Pn

i=0

Pm

j=0

0 u, v 1

B0,0

B1,0

B2,0
B3,0

1
3
3
1

3
6
3
0

u 1]

B0,1
B1,1
B2,1
B3,1

3
3
0
0

1
3
3
1

B0,2
B1,2
B2,2
B3,2
1
0
0
0

3
6
3
0

B0,3
B1,3
B2,3
B3,3

v3

3
3
0
0

1
0
0
0

2
v

v
1

n y sntesis de NURBS en
III. Triangulacio
la GPU

(1 t)3
3t(1 t)2
3t2 (1 t)
t3

con lo cual la curva Bezier se define por:

Bi,j Jn,i (u)Km,j (v)

(4)

El algoritmo descrito en [3], [4] presenta, entre

otras propuestas, un metodo para realizar la triangulacion y sntesis de superficies NURBs en la GPU.
En la Figura 3, se muestra el flujo del algoritmo propuesto en [3] para los pasos involucrados en la triangulacion de las superficies. Este algoritmo consiste
en dos etapas. La primera es una etapa de preproceso
donde se realiza una serie de c
alculos en la CPU que
generan la informaci
on necesaria para la siguiente
etapa. Parte de esta informaci
on es almacenada en
la GPU. La segunda etapa es realmente el proceso
de sntesis que se repite por cada fotograma, f . En
el resto de esta secci
on y con el apoyo de esta figura
se resumira brevemente los principales pasos involucrados en esta propuesta.
El metodo aproxima en la CPU cada superficie
NURBs o T-Spline mediante una jerarqua gruesa
de polgonos bic
ubicos Bezier racionales (ver paso 1
de la Figura 3). Uno de los objetivo de [3] es que el
algoritmo funcione sobre cualquier tarjeta gr
afica que
soporte al menos la versi
on 1.0 de Vertex Shader. Al
tener en cuenta aquellas tarjetas que no tienen acceso
a texturas en el Vertex Shader, la cantidad de datos
de entrada para un programa de vertex esta limitado
a 16 atributos por vertice y 8 matrices de programa.
Por ello, s
olo se pueden evaluar superficies Bezier de
grado no muy elevado. Adem
as como se limita el
n
umero de registros temporales a 12, esto implica la
utilizaci
on de superficies bic
ubicas.
El refinado de los polgonos de Bezier en la GPU
para generar una malla de alta calidad se vio frenada hasta la aparicion del Geometry Shader por

36

Apndice A. Artculo




 
    
   A
 

123

567 87 95 8>58>? @5:?

423

   
 

    


 B
 
   

123
   
 

   "
C #

 !

$


 
  
%&
  
  '    D
  
()* +), - .//)*

567 87 95 : ;<65: =:
423

0  

Fig. 3. Esquema del m

etodo de [3] para la sntesis de NURBS en la GPU

la incapacidad de generar nuevos vertices. Esta imposibilidad forz

o en [3] a la utilizaci
on de mallas predefinidas de diferentes resoluciones (ver paso 2 de la
figura), que indican los vertices virtuales y la conectividad entre ellos. De esta forma, con estas mallas
se indican los valores parametricos u y v a ser utilizados en el proceso de generacion de los vertices de la
malla triangular (ver Ecuacion 5). As, los vertices
virtuales que son definidos inicialmente sin coordenadas especficas, son posteriormente procesados en
el Vertex Shader para la generacion de las coordenadas. Adem
as, en [3] en lugar de utilizar una malla
por superficie, que ira en contra de la filosofa del
c
alculo del refinado en la GPU, se crea una malla
predefinida por nivel de resolucion y se almacena en
la 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 se
seleccionan aquellas superficies que tienen suficiente
resolucion para garantizar la precisi
on deseada en
la visualizacion. Si durante el recorrido se alcanza
un nodo hoja, se generan superficies bic
ubicas adicionales. Los puntos de control de cada superficie
[B k ], 0 k S (siendo S el n
umero de superficies
Bezier) son enviados a la GPU. Adem
as, para cada
superficie se selecciona una malla de resolucion adecuada que garantice la precisi
on deseada, l (ver etapa
3 de la figura).
En la GPU (ver paso 4 de la figura) se calcula en
el Vertex Shader la ecuacion 5 para cada superficie
y para cada vertice virtual de la malla resolucion
adecuada para ese caso. Para sintetizar los polgonos
de Bezier en la GPU, en [3] se opto por la evaluacion
directa frente al algoritmo de deCasteljau [9] ya que
la implementacion en la GPU del primero de ellos es
mas eficiente.
zier en la GPU
IV. Sntesis de superficies Be
En esta secci
on describimos el metodo que hemos
implementado para realizar la sntesis de superficies
Bezier mediante su triangulacion en la GPU. Para

ello nos basamos en el metodo descrito en la Seccion

III aunque en nuestra implementacion se han considerado desde un primer momento superficies Bezier
bic
ubicas, por lo que no fue necesario realizar la conversi
on de NURBs a Bezier. Adem
as, y teniendo
en cuenta las capacidades de almacenamiento cada
vez mayores existentes en las tarjetas gr
aficas actuales nuestra propuesta no utilizar
a jerarquas de
superficies. Esto, como se ver
a a continuaci
on, permite reducir los requerimientos de transmision entre
CPU y GPU de la propuesta original. Nuestra implementacion persigue presentar alternativas a la propuesta previa a traves de varias vas, por una parte,
evitando el envo de puntos de control durante el proceso de sntesis mediante su almacenamiento previo
en la memoria de la GPU y, por otra parte, mediante
la explotacion eficiente de los recursos disponibles en
las tarjetas gr
aficas actuales.
En la Figura 4 se presenta la estructura del nuevo
algoritmo que proponemos para la triangulacion y
sntesis de superficies Bezier en la GPU. Los puntos
de control de las superficies Bezier [B k ], 1 k S,
se envan una u
nica vez a la GPU, en la etapa de
preproceso (ver paso 1 de la Figura 4). El almacenamiento de los puntos de control en la GPU permite
evitar el continuo reenvo de la misma informaci
on
cada vez que se procesa una superficie concreta. Esto
es posible, ya que a diferencia del metodo de [3],
nuestra aproximaci
on sigue un metodo mas simplificado donde las superficies Bezier vienen determinadas desde el principio y no dependen del recorrido
por la jerarqua de superficies.
En concreto, en nuestra propuesta [B k ] se almacena en tres arrays diferentes [Bxk , Byk , Bzk ], de tipo
float44 uno por cada coordenada y en memoria de
texturas usando un buffer de texturas (tbuffer ) [10].
Se consigue mejor rendimiento por la utilizaci
on 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 cons-

37

()*


  9
 



   

()*

  

: 
 

,-./. 0, /5,/56 7,16

+)*
8
9

 



   

,-./. 0, 1 23- ,1 41
+)*
<=>? @A BC
D@>? E@F

   ;


  

 

 !" # $%%

&
'



Fig. 4. Sntesis de superficies B

ezier en la GPU

tante. Adem
as la latencia de los c
alculos de acceso a
esta memoria estan mejor ocultos que en otras. Por
otro lado, el tbuffer, permite empaquetar datos que
pueden ser accedidos desde variables separadas en
una misma operaci
on, aumentando as el ancho de
banda.
Las mallas de diferente resolucion que indican las
coordenadas parametricas a ser posteriormente evaluadas para el c
omputo de los nuevos vertices son
generadas en la CPU antes de comenzar el proceso
de sntesis de igual forma que en la secci
on III. Estas
mallas son enviadas a la GPU y almacenadas en ella,
como se puede ver en el paso 2 de la Figura 4. Cada
malla de resolucion, MR, se almacena en la memoria
de la GPU en el paso de preproceso como un Vertex Buffer [11], lo que permite acelerar la sntesis de
la geometra y proporcionar un alto ancho de banda
en el flujo de datos, as que la tarjeta gr
afica puede
leer mas rapidamente las primitivas. No es necesario generar ning
un Index Buffer [11] ya que los
valores almacenados en el Vertex Buffer mantienen
las relaciones de localidad para permitir generar los
polgonos necesarios.
En cada fotograma se sintetizan cada una de las
superficies con el nivel de resolucion adecuado. En
nuestra aproximaci
on, como hemos indicado, no es
necesario enviar los puntos de control de la superficie
Bezier ya que estan almacenados en la GPU. Lo que
se enva por cada superficie y para cada fotograma f
es el nivel l, el ndice de la superficie k y el tama
no
t de la malla de resolucion (ver paso 3 de la figura).
As el n
umero de envos, Ne , por cada fotograma es:
Ne = 3 S
siendo S el n
umero de superficies.
En la GPU, se generan los triangulos necesarios
para representar la superficie Bezier con la resoluci
on seleccionada. En la Figura 5 se muestra el pseudoc
odigo del Vertex Shader para generar la triangulaci
on de las superficies Bezier bic
ubicas en funcion
de 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;
3
8
float1x4 [u]=(u , u2 , u, 1);
9
float1x4 [v]=(v 3 , v 2 , v, 1);
10 float4x4 {[Bxk ],[Byk ],[Bzk ]} = leer de texturas (k);
11 float3 vertice = mul( [u], [N],[B k ], [N], [v]);
12 return vertice;
13 }
Fig. 5. Vertex Shader para la sntesis de superficies B
ezier en
base a las mallas de resoluci
on

Shader ya que el metodo de [3] fue pensado para

ejecutarse en el procesador de vertices. Para cada
superficie, el Vertex Shader recibira como entrada
los valores que forman la malla de resolucion seleccionada para sintetizar la superficie (lnea 1). A partir de estos valores se calculan los vectores [U ] y [V ]
de la Ecuacion 5 (lneas 8 y 9). En la lnea 10 se
lee de la memoria de texturas, los valores correspondientes a los puntos de control de la superficie k que
se esta computando en ese momento. Por u
ltimo,
se multiplican estos valores, siguiendo la Ecuacion 5
para generar los vertices deseados (lnea 11).
Con esta aproximaci
on se realiza una llamada
sncrona, draw Primitive a la GPU por fotograma
y para cada una de las superficies que forman la
escena. Por tanto, el n
umero de sincronizaciones,
NDP , por fotograma es NDP = S. Este aspecto
limita el rendimiento de este metodo como comprobaremos en la secci
on V debido a las m
ultiples llamadas a esta operaci
on sncrona [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 . Con este objetivo hemos introducido en nuestra propuesta la tecnica de batching
[12]. Esta tecnica persigue minimizar el n
umero de
llamadas a draw Primitive, para ello, se juntan los

38

Apndice A. Artculo

TABLA I
Fotogramas por segundo (fps)

(a)

(b)

1 teacup
10 teacups
20 teacups
30 teacups
40 teacups
50 teacups
100 teacups
1 teapot
10 teapots
20 teapots
30 teapots
40 teapots
50 teapots
100 teapots
1 elefante
10 elefantes
20 elefantes

CPU
145,35
29,36
16,03
11,25
8,43
6,85
3,31
129,37
24,82
13,33
9,10
7,13
5,56
2,80
6,91

GP U a
95,51
10,19
4,67
2,57
0,61
0,52
0,26
71,50
8,42
3,29
1,86
0,54
0,43
0,20
1,86
0,078
0,039

GP U b
96,89
11,94
4,34
2,57
0,66
0,52
0,25
74,41
9,58
3,32
1,96
0,53
0,42
0,21
1,96
0,077
0,039

GP U c
97,09
12,27
4,63
2,68
0,66
0,53
0,26
80
9,69
3,44
2,03
0,54
0,43
0,21
2,03
0,078
0,039

GP U d
408,16
85,32
40,21
19,87
13,12
8,49
2,31
363,64
84,60
29,09
14,19
8,54
5,8
1,54
8,37
0,99
0,33

(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 u

nico
envo y se realiza una llamada sncrona por cada fotograma, lo que reduce el n
umero de sincronizaci
on
por fotograma a NDP = 1. Como se ver
a en la siguiente secci
on la utilizaci
on de la tecnica de batching
esta limitada a la cantidad de memoria disponible
en la GPU para el almacenamiento temporal de la
informaci
on hasta que se realice el proceso de sincronizacion. As, si en la implementacion basada en
[3], la memoria reservada era la suma del tama
no
de la malla de las cuatro resoluciones permitidas en
su implementacion (M R32 + M R16 + M R8 + M R4 ),
con nuestra tecnica con batching se necesita reservar S M R32 siendo M R32 la malla de resolucion
de maximo tama
no permitida. De esta forma, la
cantidad de memoria que hay que reservar es nuestra propuesta es mayor y directamente proporcional
al n
umero de superficies que se vayan a sintetizar.
Esto, sin embargo, no es ninguna limitacion en la
propuesta si se realiza el batching hasta que se alcancen las capacidades de almacenamiento disponibles
comenzando, a continuaci
on y tras una fase de sincronizacion, con un nuevo batching.
V. Resultados
En esta secci
on 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 versi
on de DirectX 10 y la versi
on 4.0 de shader.
La animaci
on utilizada consiste en un zoom sobre
los diferentes objetos, de forma que la c
amara se va
alejando lenta y constantemente, cambiando la resoluci
on necesaria para cada objeto. En los an
alisis
presentados en esta secci
on 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 6(a)), que consta de 32 superficies Bezier, Teacup (ver Figura 6(b)) que consta

de 26 superficies Bezier y un Elefante (ver Figura

6(c)) que consta de 811 superficies Bezier.
En la Tabla I se muestran los fotogramas por segundo (FPS) de diferentes escenas para las diferentes propuestas de sntesis de superficies Bezier que
hemos analizado. La primera columna muestra el
n
umero de modelos utilizados por cada escena. La
segunda columna (CPU) muestra los FPS cuando
se realiza la aproximaci
on tradicional, esto es, se
hace la triangulacion de las superficies Bezier en la
CPU usando la tecnica de forward differencing mientras que los triangulos generados se sintetizan en la
GPU [11]. La tercera columna (GP U a ) muestra los
FPS en la implementacion del metodo descrito en la
secci
on III. Para realizar la implementacion de esta
propuesta hemos utilizado nuestro c
odigo de prueba
pero adapt
andolo al caso de la utilizaci
on de jerarquas de superficies, lo que implica el envo de los
puntos de control por fotograma de cada superficie
a representar. La cuarta columna (GP U b ) muestra
los FPS cuando se realiza la implementacion del algoritmo sin batching descrito en la Seccion IV. La
quinta columna (GP U c ) muestra los FPS cuando no
se realiza ning
un c
alculo en el Vertex Shader pero se
genera el mismo n
umero de NDP que en el caso de
GP U b . En la sexta columna (GP U d ) se muestran
los FPS cuando se aplica la tecnica de batching. En
las implementaciones asociada a la GPU y como se
comento previamente se ha optado por la evaluacion
directa de las ecuaciones Bezier, por ser el metodo
mas 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 la
CPU de forma directa para modelos complejos (por
ejemplo en el caso de 10 y 20 elefantes), ya que
el tama
no necesario del Vertex Buffer y del Index
Buffer, es mayor que la memoria de GPU disponible.
En cambio, con las estrategias basadas en la utilizacion de la GPU para el proceso de triangulacion
no se encuentra esta limitacion, ya que la cantidad
de memoria utilizada es mucho menor.
Como primer paso en nuestro an
alisis comparamos
el algoritmo original presentado en la secci
on III, reflejado en la columna GP U a , con el algoritmo adap-

39

tado en el que no se utilizan jerarquas de superficies,

reflejado en GP U b . La no utilizaci
on de jerarquas
de superficies esta asociado a la cantidad de memoria disponible en las tarjetas gr
aficas actuales. Esto
permite que modelos en los que anteriormente era
necesario utilizar jerarquas de superficies con representaciones mas gruesas puedan ser manejados actualmente de forma directa en su mayor grado de resoluci
on. Como consecuencia de ello el modelo puede
ser almacenado en la GPU y reutilizado durante la
animaci
on. Por todo ello se reducen los requerimientos de envo y, con ello, se consigue una mayor velocidad en el proceso de sntesis, como queda reflejado
en los datos numericos de la tabla.
Al comparar las columnas GP U b y GP U c , se observa que los resultados obtenidos son muy similares,
a pesar de que en el segundo de los casos no se realiza ning
un c
alculo. Estos resultados confirman que
el NDP es el factor que limita el rendimiento. El impacto que el NDP tiene en el rendimiento se observa
al comparar la columna GP U b con la GP U d ya que
la principal diferencia entre estas dos opciones es el
NDP por fotograma.
Con la implementacion del metodo de la secci
on
IV sin batching se consigue un rendimiento peor que
con la implementacion en la CPU, a pesar de que en
este u
ltimo caso se este enviando un mayor n
umero
de informaci
on y los c
alculos se realicen en la CPU.
Pero tenemos que destacar que el rendimiento del
Vertex Shader esta limitado por el tama
no de M Rl
adem
as de por el NDP . Con la implementacion de
batching hemos comprobado que si aumentamos el
paralelismo del programa stream del Vertex Shader
(M Rl S), conseguimos un mejor rendimiento que
con la subdivisi
on en la CPU.
La tecnica de batching implica el almacenamiento
temporal de la informaci
on en la memoria de la tarjeta gr
afica evitando con ello continuas sincronizaciones asociadas a cada superficie 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
quedaran muy limitados. Esto se puede comprobar en los resultados indicados en la columna GP U d
cuando el n
umero de objetos del modelo aumenta.
N
otese que por motivos de claridad incluimos en esta
tabla los resultados asociados a la aplicacion de un
u
nico batching, obviando el hecho de que se excedan
los requerimientos de almacenamiento disponibles.
Teniendo en cuenta todos los datos aqu presentados
y la posibilidad de hacer el batching condicionado
al tama
no de la memoria disponible se observa que
la tecnica de batching permite superar a cualquiera
de las otras estrategias incluida la tecnica cl
asica de
procesamiento en la CPU.
VI. Conclusiones
El metodo cl
asico para la sntesis de las superficies
Bezier se basa en la triangulacion de dichas superfices
en la CPU y el envo de la malla de tri
angulos resul-

tante a la GPU para su sntesis. Como se ha podido

comprobar por los resultados obtenidos, al triangulizar los superficies Bezier 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 n
umero de superficies.
Al realizar las triangulaciones directamente en la
GPU se consiguen varios objetivos, liberar la CPU
de carga computaci
on gr
afica, disminuir los requerimientos de comunicacion entre CPU y GPU y,
adem
as, aprovechar las prestaciones asociadas a la
tarjeta gr
afica para este tipo de c
omputos. Por otra
parte y debido a los requerimientos de sincronimo
para realizar la sntesis en la GPU, la tecnica de
batching se ha mostrado como una herramienta efectiva para permitir el procesamiento en la GPU de
forma efectiva y superar con ello las limitaciones asociadas a estrategias previas.
El trabajo futuro para mejorar el rendimiento de
nuestra propuesta consiste en utilizar el Geometry
Shader y aprovechar sus capacidades para la generaci
on de vertices. Creemos que estas nuevas capacidades de la tarjeta gr
afica ser
an clave para el
procesamiento en tiempo real de modelos complejos
basados en superficies Bezier.
Agradecimientos
Este trabajo ha sido financiado por el Ministerio de Educaci
on y Ciencia dentro del proyecto
TIN2007-67537-C03-02 y por la Xunta de Galicia
dentro del Programa de Consolidaci
on de Grupos
de Investigaci
on Competitivos (Ref. 3/2006 DOGA
13/12/2006).
Referencias
[1]

D. F. Rogers, An Introduction to NURBS with Historical

Perspective, Morgan Kaufmann, 2001.
[2] F. J. Espino, M. B
oo, M. Amor and J.D. Bruguera,
Hardware Support for Adaptive Tessellation of B
ezier
Surfaces on Local Tests, Journal of Systems Architecture, pp. 233250, 2007.
[3] M. Guthe, A. Bal
azsand and R. Klein, GPU-based
Trimming and Tessellation of NURBS and T-Spline Surfaces, ACM SIGGRAPH 2005, Volume 24, pp: 1016 1023.
[4] M. Guthe, A. Bal
azsand and R. Klein, GPU-based
Appearance Preserving Trimmed NURBS Rendering,
Journal of WSCG 2006, Vol 14., 2005.
[5] A. Krishnamurthy, R. Khardekar and S. McMains, Direct Evaluation of NURBS Curves and Surfaces on the
GPU, ACM Symposium on Solid and Physical Modeling, pp. 329 334, 2007.
[6] A. Efremov, V. Havran and H.P. Seidel, Robust and Numerically Stable B
ezier Clipping Method for Ray Tracing
NURBS Surfaces, 21st Spring Conference on Computer
Graphics, pp. 127 135, 2005.
[7] 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, pp. 99 106, 2004.
[8] D. Blythe, The Direct3D 10 System, ACM SIGGRAPH 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 DirectX 10.0, Wordware, 2008.
[12] C. Cebenoyan, GPU Gems: Programming Techniques,
Tips and Tricks for Real-Time graphics, chapter Graphics Pipeline Performance, Addison-Wesley, 2004.

40

Apndice A. Artculo

Bibliografa
[1] A. Efremov, V. Havran and H.P. Seidel. Robust and Numerically Stable
Bzier Clipping Method for Ray Tracing NURBS Surfaces.

Conference on Computer Graphics, pages 127  135, 2005.

21st Spring

[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-

3rd International Conference on Computer Graphics,

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

Form Surface.
2004.

GPU Gems: Programming Techniques, Tips and

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

[5] C.

Cebenoyan.

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.

Systems Architecture, pages 233250, 2007.

[7] K. Grya.

Journal of

Microsoft DirectX9 Programmable Graphics Pipeline.

Mi-

crosoft Press, 2003.

[8] M. Guthe, A. Balzsand and R. Klein. GPU-based Trimming and Tessellation of NURBS and T-Spline Surfaces.

Volume 24, pp: 1016 - 1023.

[9] M. Guthe, A. Balzsand and R. Klein.

serving Trimmed NURBS Rendering.
2005.

41

ACM SIGGRAPH 2005,

GPU-based Appearance Pre-

Journal of WSCG 2006, Vol 14.,

42

Bibliografa

[10] Microsoft.

DirectX SDK Documentation, 2007.

Technical Brief. The GeForce 6 Series of GPUs High Performance and Quality for Complex Image Eects, 2004.

[11] Nvidia.

Technical Brief. Microsoft DirectX 10: The Next-Generation

Graphics API, 2006.

[12] Nvidia.

[13] M. Pharr, editor.

GPU Gems II.

[14] L. Piegl and W. Tiller.

Addison-Wesley, 2005.

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.

Jornadas de Paralelismo (Aceptado), 2008.

[16] D. F. Rogers.

XIX

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.
[20] P. Walsh.

Journal of Graphics Tools, 5:27  52, 2000.

Advanced 3D Game Programming with DirectX 10.0.

ware, 2008.

Word-