[SpiROSE] OpenGL ES and mainboard

Howdy :]


The first half of this week was dedicated to porting the renderer to OpenGL ES, which I managed to pull off. In the end, the port was really easy, as the desktop version used OpenGL 3.3, which is very close to OpenGL ES.

The renderer PoC running on the wandboard

You may notice there are no 3D visualisation in the middle. This is actually expected, as this view relied on geometry shaders, not available on this GPU. Still, I did not waste time re-implementing it as the only thing that matters are the white things on the bottom left hand of the window.

However, some issues do remain. Those issues only happen on the Wandboard with the Vivante drivers. Any other GL ES environment is working just fine, without those issues (for example, the VMware Mesa driver that now supports OpenGL ES 3.2).

Mainly, I have uniforms that are not found for a shader stage, and steadily returns -1, which is “no uniform found” in GL terminology. strange thing is, only this specific shader is problematic.

Furthermore, the keen-eyed amongst you may have noticed a small glitch on the above picture. The top-right hand slice is missing a pixel column, effectively cutting poor Suzanne’s ear.

What is infuriating is, neither the glitch nor the missing uniforms happen on my Arch Linux VM, where the VMware OpenGL ES driver is consistent and reliable.


This week I also seriously attacked the mainboard and finished up the schematics. As a quick recap, this board is what we called previously the “rotative base”. Its main features are :

  • SBC
  • FPGA
  • Hall Effect sensors
  • Power supplies:
    • 5V (SBC)
    • 4V (LEDs)
    • 3V3 (Drivers, buffers)
    • 3V (FPGA IO)
    • 2V5 (FPGA IO and FPGA PLL)
    • 1V2 (FPGA core)
  • Board-to-board connector to link to the LED panels



I made the PSU with some help on switching ones from Alexis. You may have noticed, we may have gone overboard with the supply rails (man, 7 different voltages on a single board!). However, each have a purpose, and I’ll only bother explaining the two odd ones:

  • 4V: the LEDs are driven to ground by the drivers. Said drivers dissipate the excess voltage themselves. Thus, to avoid overheating, we chose a supply voltage for the LEDs as close to their forward voltage as possible.
  • 3V: The FPGA I/Os can work up to 3V3. However, they are poorly protected, and some overshoot on a 3V3 signal might kill the IO ping. (to be short, the protection diode used by altera is too weak). That’s why the banks which output any signal are using 3V, which is still readable by the buffers and the drivers, while being much more tolerant to overshoot, and other signal integrity problems.

Now, upon its architecture. A picture is worth a thousand words:

As for power, well… With overdrive, at the maximum power of the drivers, we can chew through 22A of current per panel. That’s 44A of blinky goodness. Oooops. Well, fortunately, people already have had this problem, and Ti happens to have a wonderful buck converter module (PTH12040WAD) that can deliver up to 50A. Fantastic!

Place and route

This turned up to be much harder than I expected. It is quite a mess, for one simple reason: the LED panels are identical, but back to back. This means our board-to-board connectors are parallel, but opposite of each other. Most of the signals that go to one go to the other. This means that most of the signals have to cross. Oooopsie!

However, this is getting together. Placement is mostly done, except for a few components that can be tucked anywhere. And most submodules are, internally placed and routed. Think of buck converters, that once grouped and routed, can be moved around, almost like a single component.

The board is quite spacious because of the SoM that takes quite a lot of space. The smallest bounding circle I could do has a diameter of 175mm.

Next week

Simple: moar routing. Right now, this looks more like the giant spaghetti monster than a PCB….

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>




This site uses Akismet to reduce spam. Learn how your comment data is processed.