Colin Riley: entrevista exclusiva para AT

Nueva entrevista exclusiva con Colin Riley. Si aún no lo conoces, él es un ingeniero que se licenció en la Universidad de Glasgow, y tras trabajar varios años en la creación de controladores para GPU, depuracion y compiladores, actualmente trabaja en AMD (Radeon) con más de cuatro años en esta empresa ocupando el puesto de ingeniero. Gracias a su trabajo, tus juegos van un poco más rápido.

Colin también es un apasionado de la electrónica, FPGAs y RISC-V, en lo que trabaja en sus ratos libres. Si quieres conocer algo más sobre él y sus aficiones, te invito a seguir leyendo la entrevista completa…

¡Por favor, ES IMPORTANTE! Colin está recaudando fondos para el hospital infantil de Edinburgo. Puedes donar dinero a él u otras organizaciones contra el cáncer. Para más información, visita el blog personal de Colin. ¡Tu ayuda puede salvar vidas!

Architecnología: Siempre suelo preguntar: ¿Quién es Colin Riley?

Colin Riley: Soy Colin, un ingeniero de software que actualmente se dedica a los gráficos a bajo nivel. Vivo en Escocia, y desde muy joven siempre quise trabajar en tecnología informática. A lo largo de mi carrera he trabajado con hardware divertido e inusual, como el acelerador original PhysX PPU y la CPU IBM Cell BE. Durante más de 10 años, tras dejar la universidad donde estudié Ingeniería de Software, trabajé en una empresa de Edimburgo, Escocia, escribiendo compiladores, runtime y depuradores, con algunos desarrollos de tecnología de videojuegos, sobre todo en PlayStation 3.

Desde 2016 he trabajado desde casa en controladores de juegos para la GPU y, más recientemente, en tecnología de juegos, haciendo que los juegos se ejecuten y se vean bien en el PC. Aunque el trabajo a distancia se ha convertido en una necesidad para este año, ya era mi realidad antes y es algo que valoro mucho. Tengo tres hijos y el hecho de estar con el más pequeño mientras trabajo desde casa me ha hecho darme cuenta de lo mucho que echaba de menos a los otros dos mientras crecían. No creo que pueda volver a trabajar predominantemente desde un entorno de oficina; definitivamente soy una de las personas cuya productividad aumentó después de pasar a trabajar a distancia.

Como hobby, me gusta incursionar en la electrónica, los juegos (particularmente los competitivos shooters en primera persona), y tengo un blog donde documento mis proyectos. Mis proyectos han ido desde controlar una CPU Z80 real con un microcontrolador Teensy, a conseguir ranuras PCIe de tamaño completo en un Raspberry Pi, hasta mi último proyecto, que es crear una CPU RISC-V compatible y educativa para FPGAs.

AT: ¿Cuándo y cómo te comenzó a interesar la tecnología?

CR: De niño siempre estaba desmontando las cosas. Walkmans, VCRs, incluso televisores. Me interesaba cómo estos pequeños componentes utilizaban la electricidad para cobrar vida con el sonido y el vídeo. A pesar de esto, no sabía cómo funcionaba la electrónica, hasta que conseguí un kit electrónico 200-in-1. A pesar de haber abierto los ZX Spectrum y los Commodore64, no me metí en la programación hasta mi primer PC familiar, que era un 486 que funcionaba con Win95. Empecé escribiendo pequeños scripts de archivos por lotes (batch) y luego pasé a Visual Basic después de que mi profesor de informática de la escuela se dio cuenta de que estaba muy interesado y me permitió tomar prestados los diversos CDs de instalación para el PC de mi casa. He estado enganchado al hardware y al software desde entonces, pero a medida que envejezco me siento más atraído hacia el hardware.

AT: ¿Tienes algún referente? ¿Alguien que te haya inspirado?

CR: Una vez que me di cuenta de que el desarrollo de juegos era lo que quería perseguir, me involucré en el modding de Quake 3. La comunidad era muy activa en ese momento y había mucha gente en la que inspirarse. Siempre había alguna nueva idea de juego que se estaba probando y gente con mucho talento que la estaba creando. Hice diseño de niveles, diseño de interfaz de usuario y, finalmente, codificación del juego en C.

Los amigos que hice a partir de entonces se dedicaron a la tecnología, y algunos fundaron empresas, como Splash Damage en el Reino Unido. Todavía soy amigo de ellos hoy en día. Cuando estaba empezando y aprendiendo, los grandes programadores en los que me inspiré fueron, obviamente, John Carmack y Tim Sweeney, pero creo que para mí fueron los canales de la comunidad de modding en el IRC de Quakenet y varios foros los que me hicieron seguir adelante y querer más. Había un sentimiento de tutoría dentro de ese grupo que era increíblemente valioso.

AT: ¿Por qué llamó tu atención RISC-V?

CR: Yo estaba trabajando en una empresa que trabajaba con el proyecto de compilación de LLVM en ese momento. Estuve en todas las listas de correo de desarrollo, y noté más mensajes para la implementación de RISC-V. Había oído hablar del proyecto RISC-V antes, pero estaba recibiendo muchos elogios, así que empecé a investigar más, y fue entonces cuando me di cuenta de que probablemente iba a ganar tracción, ya que las cadenas de herramientas del compilador y el ecosistema son un factor enorme para una adopción más amplia. Como estaba buscando un ISA para adoptar en mi proyecto de FPGA como hobby, uno con una buena cadena de herramientas, todo encajó y leí las especificaciones.

AT: ¿Ves una buena oportunidad de crecimiento en RISC-V ahora que NVIDIA ha comprado Arm? ¿Crees que se volverá popular esta ISA (en PC/HPC/IoT,..)?

CR: Incluso antes de los últimos acontecimientos pensé que estaba en una buena trayectoria. Ha habido grandes proyectos basados en la ISA en cuanto a microcontrolador/IoT durante un tiempo y justo la semana pasada vi a SiFive impulsando la adopción del estilo PC. Me encantaría ver una placa RISC-V de estilo Raspberry Pi asequible, pero creo que el aspecto asequible todavía está un poco lejos. Espero equivocarme en eso y que pronto aparezca algo, ya que abriría el RISC-V a más desarrolladores.

AT: He visto que has diseñado una CPU usando VHDL. ¿Qué ha sido lo más complicado del proceso?

CR: Mis artículos «Design a CPU in VHDL» han definido mi interés en una convergencia de hardware y software durante los últimos 5 años más o menos. Para mí, como ingeniero de software, la parte más difícil fue tratar de conceptualizar el flujo de datos del CPU en VHDL. Incluso como ingeniero de bajo nivel, desarrollándose cerca del metal, puedes fallar en comprender cuán complejo y crítico es todo lo que hay debajo. Para colmo, nunca había hecho ningún desarrollo de FPGA anteriormente.

Elegí VHDL en lugar de Verilog como lectura antes de empezar a comparar Verilog con C y VHDL con Pascal/Ada – y habiendo desarrollado en C durante más de 10 años, todavía no me consideraría un experto. Así que fue VHDL.

La CPU que diseñé se llamaba TPU – la Test Processing Unit, o Terrible Processing Unit. Estoy seguro de que los diseñadores profesionales de CPU elegirían este último nombre. Esto fue mucho antes de que Google nombrara a su procesador de IA TPU, por cierto.

Era un CPU increíblemente simple, en serie, que sólo tiene una de las etapas tradicionales de Fetch, Execute, Writeback pipeline activas en un momento dado. Para obtener rendimiento, normalmente se ejecutan en paralelo, múltiples corrientes de datos canalizados para maximizar el rendimiento.

El TPU fue concebido como un proyecto puramente académico; estos son los pasos necesarios para construir un CPU – el rendimiento vendrá después. Incluso con una CPU tan simple, el flujo de datos entre las diversas unidades del diseño sigue siendo crítico. Por lo general, define el tiempo que a su vez afecta a la velocidad de reloj en la que se puede ejecutar el diseño. La sincronización del diseño es algo con lo que todavía tengo que luchar, a pesar de que el TPU se está transformando en el proyecto RPU RISC-V, más utilizable. Siento que es algo oscuro dentro de la comunidad de FPGA, no hay muchas guías fáciles de seguir sobre cómo arreglar los problemas de tiempo en los diseños.

AT: ¿Cuál es tu FPGA favorita? ¿Por qué?

CR: Mirando hacia atrás, esto es fácil. Mi favorita era el miniSpartan6+ de Scarab Hardware. No está disponible ahora, pero fue una de las primeras tarjetas de desarrollo FPGA kickstarter de la época que tenía HDMI, memoria y tarjeta SD integrada en la tarjeta.

Estando involucrado en gráficos por computadora profesionalmente, siempre fue un plan para eventualmente tener alguna salida gráfica en mis proyectos. Había tarjetas con VGA pero podían ser caras y parecía extraño seguir la ruta de la VGA analógica sabiendo que HDMI (o, más correctamente, DVI-D) podía ser emitido por estas nuevas tarjetas FPGA.

Es la placa que me hizo pasar de «Quiero entrar en las FPGAs algún día» a «Me divierto usando las FPGAs como hobby». He seguido usando las FPGAs de Xilinx Spartan en mis proyectos, ya que son muy potentes pero tienen disponibles placas de desarrollo asequibles.

Recientemente he tenido interés en las FPGAs Lattice – especialmente debido al soporte del kit de herramientas de código abierto – y tengo algunas placas incluyendo la TinyFPGA de Luke Valenty.

Ahora hay una gran variedad de placas asequibles disponibles, desde la digilent ArtyS7 para los fans de Xilinx Spartan hasta la OrangeCrab de Greg Davills para Lattice ECP5 con amplio soporte de cadena de herramientas. He tendido a quedarme con Xilinx principalmente por una razón – mi decisión de usar VHDL ha tenido consecuencias no deseadas cuando se trata del soporte de la cadena de herramientas, y las iniciativas de código abierto y las nuevas HDL tienden a no tener grandes opciones de VHDL. Tengo la esperanza de que en los próximos meses y años esto cambie.

AT: ¿Cuál es tu herramienta de desarrollo favorita? ¿Por qué?

CR: ¡Depuradores! Siento que los depuradores a veces no tienen suficiente crédito. He pasado mucho tiempo implementando depuradores para GPUs y DSPs, y fui uno de los primeros en contribuir al proyecto LLVM LLDB, así que sé lo difícil que puede ser implementar uno realmente bueno con características útiles.

Un gran depurador no se interpone en el camino del desarrollador, y un mal depurador, bueno, ¡no pensemos en eso! La mayoría de la gente ve a los depuradores como herramientas para encontrar y arreglar errores en el código, pero yo me encuentro usándolos sobre todo para aprender y asociarme con nuevas bases de código complejas. Cuando se me presenta un nuevo proyecto – uno con una gran cantidad de código existente que no he escrito – me meto en el depurador y empiezo a recorrer el camino de la ejecución. Es un conocimiento rápido del proyecto. Tiendo a encontrar algún detalle oculto que a veces contradice los comentarios del código, por lo que ahorra mucho tiempo en el futuro.

Cuando estudié en la universidad no se dedicaba mucho tiempo a cómo usar eficazmente los depuradores. Realmente espero que eso haya cambiado en la educación de software hoy en día. No es una herramienta necesaria para el desarrollo, pero aumenta mi productividad de forma exponencial.

AT: Como ingeniero de videojuegos… ¿Cuál es el mayor reto al que te has enfrentado a lo largo de tu carrera?

CR: Los videojuegos siempre están empujando al hardware hacia adelante, es un fenómeno que ha tenido enormes y, a veces, invisibles implicaciones para la tecnología. No mucha gente puede mirar un juego y comprender realmente la cantidad de trabajo e innovación técnica que conlleva. Desde hacer frente a las comunicaciones de red retrasadas y limitadas, hasta la construcción de activos en granjas de servidores, hasta la retroalimentación del sensor de latencia ultra baja en la Realidad Virtual – la tecnología de la industria de los juegos se ha filtrado en el comercio del mercado de alta frecuencia, la nube y los campos médicos.

El hardware de los juegos, tradicionalmente la GPU, ahora alimentan a los teléfonos, para que puedan conducir los coches y, más recientemente, la potencia de procesamiento se ha usado en la investigación del COVID-19 utilizando folding@home.

Al ser una industria que termina por alimentar a tantas otras industrias «tradicionales» y adaptarse a los nuevos avances de la tecnología, ya sea basada en hardware o en software, puede ser difícil. Siempre me hizo sentir que siempre había algo más – y nuevo – que tenía que aprender. Es un gran desafío tenerlo profesionalmente, especialmente si puedes estar directamente involucrado en esos avances, pero siempre te mantiene al límite y con los pies en el suelo.

AT: Por último… ¿Cuál piensas que será la próxima tecnología disruptiva en el mundo de los gráficos/gaming?

CR: Creo que la escala tiene que serlo. La escala de los mundos virtuales, la cantidad de jugadores, la interactividad y el cruce entre los medios de juego. Para mí, el juego siempre ha sido un esfuerzo social y gente como los de Fortnite han demostrado que la escala puede cambiar las cosas: grandes eventos globales que ocurren en tiempo real en un entorno de juego con amigos. Mientras que Fortnite ciertamente dio con una fórmula ganadora, hay muchos más que explotarán la tecnología para este efecto.

Hay una enorme cantidad de datos ahí fuera y muchos de ellos pueden ser utilizados en los juegos. Espero que siga un aspecto creativo, como el de Media Molecules’ Dreams en PS4, un uso impresionante de la tecnología que permite a cualquiera crear mundos y experiencias virtuales.

Para esto necesitaremos cada vez más poder de procesamiento – tanto local para el jugador como remotamente en servidores en nube, y por supuesto, mayor ancho de banda y conexiones de baja latencia para aquellos que quieran participar. Tengo la suerte de vivir en una zona donde el acceso a Internet no es un problema, pero conexiones más baratos y más amplios para todos – posiblemente a través de sistemas de satélites de baja órbita como el SpaceX Starlink – permitirá este aumento de escala. ¡Será una década muy interesante y emocionante en esta área!

AT: Thank you Colin!