En algunos artículos previos ya he hablado de las características de Python y también he introducido algunas ideas sobre OpenCL al tratar el paralelismo en GPU. Uno de los problemas que suele plantearse durante el aprendizaje de una nueva API/lenguaje, en este caso concreto OpenCL, es que suele implicar también adecuarse al uso de unas herramientas concretas (bibliotecas, objetos/funciones, compiladores, etc.) y un procedimiento de prueba-error bastante tedioso.
La sencilla operación de enumerar las plataformas y dispositivos disponibles desde OpenCL, siguiendo las indicaciones de la documentación, implican el uso de C/C++, la codificación de un programa completo que es necesario compilar antes de ejecutarlo y ver el resultado, pero hasta llegar a éste normalmente habrá obstáculos: errores durante la compilación, compilación correcta pero con errores de ejecución, sin errores de ejecución pero resultado nulo o incompleto y así sucesivamente.
Personalmente, cuando quiero probar algo nuevo o escribir un prototipo rápido para alguna tarea, prefiero recurrir a un intérprete porque me permite centrarme en el objetivo al no tener que pasar por el habitual proceso de edición-compilación-ejecución. En su lugar escribo las sentencias en la shell del intérprete y obtengo un error inmediato o el resultado que buscaba. Una vez que tengo bien claro cómo hacer aquello que pretendo no hay más que transcribirlo al lenguaje en el que vaya a efectuarse la implementación definitiva y, teóricamente, debería funcionar.
Al comenzar a probar OpenCL mi enfoque no fue distinto y por ello busqué la manera de trabajar con él desde Python, en lugar de hacerlo desde C/C++ que es lo más corriente. Para ello no hay más que configurar e instalar la extensión PyOpenCL, algo que debería ser simple pero que, en la realidad, no lo es tanto, más por las dependencias existentes entre las diferentes partes que otra cosa. Por ello, y por si a alguien le interesa usar OpenCL desde Python, he preparado este pequeño artículo indicando los pasos que he seguido, y que habría que reproducir, para comenzar a funcionar en pocos minutos.
Si buscamos en cualquier tabla periódica de elementos químicos comprobaremos que el indio es un metal, entre el cadmio y el estaño, con símbolo In y unas características peculiares que le hacen muy raro, estimándose que solamente se encuentra en un 0.000001 por ciento de la corteza terrestre.
¿Qué tiene de interesante este metal, te preguntarás? Bueno, es el responsable del funcionamiento de la pantalla táctil de tu móvil y/o PDA, ya sea resistiva o capacitiva, utilizándose también en las modernas televisiones y pantallas de ordenador, así como en la fabricación de células fotovoltáicas. El problema es que su escasez, si no se encuentra una tecnología alternativa, podría hacer que en pocos años las pantallas táctiles sean algo del pasado según apunta un artículo publicado en New Scientist.
El indio es un metal y, como tal, es conductor, aunque no tan buen conductor como el cobre o el oro. A diferencia de éstos, sin embargo, es posible crear láminas de óxido de indio totalmente transparentes. En las pantallas táctiles resistivas (en las que hay que utilizar un puntero) se usan dos de estas láminas a muy pequeña distancia, de forma que la presión las hace tocarse entre sí y conducir de una a otra. Las de tipo conductivo aprovechan el hecho de nuestro propio cuerpo, las yemas de nuestros dedos, es conductivo y usa una sola lámina para conseguir el mismo resultado y prescindir del puntero.
En los televisores y pantallas se utiliza el indio para conseguir, mediante electrodos transparentes, la activación/desactivación de cada uno de los píxeles. Además de transparentes y conductoras, este material consigue que las capas sean antiestáticas y actúen como barrera frente a la radiación tanto infraroja como ultravioleta.
El problema al que deberá hacerse frente de manera casi inmediata puede resumirse en una corta lista de hechos:
No es necesario hacer muchos cálculos para darse cuenta de que las reservas existentes se agotarán, al ritmo que están consumiéndose, en una década o incluso menos. Esto provocará asimismo que en los próximos años el precio del óxido de indio, ya en niveles altos, se dispare según la lógica de la oferta y la demanda.
La industria tendrá que buscar, en consecuencia, un sustituto a este raro material, lo cual no resulta sencillo. La transparencia conjugada con el grado de conductividad adecuado no son características que se unan con frecuencia. El óximo de cadmio, por ejemplo, es transparente pero cuatro veces más conductivo que el de indio, lo cual le hace presa fácil de la corrosión. La solución es envolverlo en una lámina de indio, mucho más delgada de la que se utilizan en las pantallas actuales, lo cual es una vía para reducir el consumo de este raro metal.
En el artículo de New Scientist, cuya lectura recomiendo, apuntan otras alternativas actualmente en investigación, como los nanotubos de carbono (el grafeno del que tanto se ha escrito en los últimos días a raíz de la concesión del Nobel de física) o los nanohilos de plata. En cualquier caso es necesario encontrar una tecnología sutitutiva del óximo de indio en un plazo relativamente corto y, definitivamente, cuidar mejor nuestros dispositivos con pantalla táctil, quizá se conviertan en una pieza de museo.
Visual Basic 2010 conserva el espíritu de las versiones de Visual Basic utilizadas por millones de programadores a lo largo de los últimos años. Cuenta con un entorno sencillo y un compilador extremadamente rápido, pero se ha convertido en un lenguaje con las más avanzadas características: continuación implícita de línea, sentencias lambda, inicialización simplificada de colecciones de datos, nuevas facilidades para la implementación paralela de tareas, colecciones de datos que contemplan la enumeración en paralelo, etc.
Éstas son solamente algunas de las novedades que incorpora Visual Basic 2010 y que son tratadas en este libro de manera detallada junto con muchas otras:
My para implementar en pocas líneas de código tareas complejas y cómo extender dicho namespace.
Se muestra cómo aprovechar cada una de ellas mediante ejercicios sencillos y concisos que te permitirán obtener el máximo rendimiento del nuevo Visual Basic en el menor tiempo. Los ejemplos de código utilizados en el libro, para facilitar su aprendizaje, pueden descargarse desde la web de Anaya Multimedia.
Como es habitual, en la sección Libros puedes encontrar todos los detalles sobre éste y los demás libros que he publicado hasta el momento, incluyendo imágenes de sus portadas y el índice completo de contenidos.
El diseño de shaders usando programas como Shader Maker resulta bastante sencillo, pero el objetivo último es usar esos shaders en nuestras propias aplicaciones. Para ello habría que seguir el procedimiento descrito en la entrada sobre OGLSL de la sección de lenguajes de shading. Traducido a código, dicho procedimiento se implementaría así:
// Variables para almacenar los identificadores de shaders
GLuint vs, gs, ps, shaders;
// y para contener el código
char *codVS, *codGS, *codPS;
// Asignar a codVS, codGS y codPS el código de los shaders
codVS = "uniform vec3 dirLuz; \
varying float intensidad;\
\
void main() { \
intensidad = dot(dirLuz, gl_Normal);\
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\
}";
codPS = "varying float intensidad;\
\
void main() { \
if (intensidad > 0.95) // se asigna un color blanco\
gl_FragColor = vec4(1.0,1.0,1.0,1.0);\
else if (intensidad > 0.75) // rojo\
gl_FragColor = vec4(1.0,0.0,0.0,1.0);\
else if (intensidad > 0.5) // verde\
gl_FragColor= vec4(0.0,1.0,0.0,1.0);\
else if (intensidad > 0.25) // azul\
gl_FragColor = vec4(0.0,0.0,1.0,1.0);\
else // o amarillo\
gl_FragColor = vec4(1.0,1.0,0.0,1.0);\
}";
// Se crea y compila el VS
vs = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vs, 1, &codVS, NULL);
glCompileShader(vs);
// Se crea y compila el GS
gs = glCreateShader(GL_GEOMETRY_SHADER_EXT);
glShaderSource(gs, 1, &codGS, NULL);
glCompileShader(gs);
// Se crea y compila el PS
ps = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(ps, 1, &codPS, NULL);
glCompileShader(ps);
// Se crea un programa y se asocian los shaders
shaders = glCreateProgram();
glAttachShader(shaders, vs);
glAttachShader(shaders, gs);
glAttachShader(shaders, ps);
// Y finalmente se linka y asocia al cauce
glLinkProgram(shaders);
glUseProgram(shaders);
// A partir de aquí dibujar la escena con OpenGL
Las funciones glCreateShader(), glShaderSource(), glCompileShader(), etc., forman parte de OpenGL 2.1 o posterior. Lo más cómodo es descargar GLEW e incluir al inicio de nuestro módulo de código el archivo de cabecera glew.h. Éste contiene una serie de marcos que se encargarán de convertir las llamadas a las anteriores funciones en la invocación adecuada a la extensión que corresponda.
Con esta breve entrada pongo punto y final a esta extensa serie introductoria sobre la programación de shaders, en la que he abordado desde los fundamentos básicos de cada tipo de shader hasta su desarrollo en la práctica con ejemplos sencillos, pasando por el análisis de los lenguajes disponibles y algunas herramientas. En el margen derecho tienes la sección Curso sobre shaders que te permite acceder a todas las entradas de esta series.
A pesar de que mi primer ordenador fue un Sinclair ZX81 tal y como indiqué en la entrada Microordenadores Sinclair (I), el ordenador con el que realmente me adentré de lleno en la informática fue un MSX de la primera generación, concretamente un Sony HB-55P. En este ordenador escribí mis primeros programas serios, para cálculos de costes en la empresa en que trabajaba entonces, así como los primeros programas que publiqué en revistas especializadas. Incluso mi primer libro está en gran parte escrito para este tipo de ordenador.
Tras este MSX, cuyo uso simultaneé con un ZX Spectrum, llegó mi primer MSX-2: un Philips NMS 8245, al que siguió poco tiempo después un NMS 8255 de la misma marca que se convirtió en mi único ordenador durante muchos años, hasta bien entrada la década de los 90. Si a principios de los 80 usaba únicamente BASIC y ensamblador Z80, con este ordenador aprendí a programar en Pascal (gracias a Turbo Pascal 1.0) y en C (gracias al compilador de HiSoft). En él programé un gestor de bases de datos similar a dBase (programa que usaba en un PC de la empresa en que trabajaba), una aplicación de dibujo parecida a PaintBrush y un diseñador de pantallas de entrada de datos que generaba automáticamente código en C.
Mi vinculación con la gama MSX ha sido tan dilatada y fructífera que me ha llevado a tener siempre una especial debilidad por los microordenadores que seguían esta norma, como es fácil comprobar en las fotografías siguientes. En ellas puede apreciarse que hay una gran cantidad de máquinas (33 en total), si bien no todas las que tengo. Además de ordenadores propios, que he tenido siempre conmigo desde principios de los 80, hay muchas donaciones de amigos y conocidos que tenían MSX así como algunas adquisiciones, por ejemplo el impresiontante Turbo-R GT.
Torre de Babel - Francisco Charte Ojeda - Desde 1997 en la Web
