[SpiROSE] Supplying power voxels … Wait watt?

Okay this may not be obvious from the title, but I mainly worked on to parts of the project this week: a new voxelization algorithm and the power supply.


To my great surprise, OpenGL ES GPUs do not support integer operations. This include logic operations. Especially between fragments. Do you see where I am going? If you recall my post regarding the voxelization algorithm, I rely on XOR-ing two fragments to voxelize a column. The OpenGL ES standard does not defines the glLogicOp functions, which is the one I need to XOR my fragments. Bummer.

However, there is a solution. We can emulate a bitwise XOR on n bits by doing n one-bit XORs. But how can we do XOR without XOR? If we look at a truth table, we see that XOR is equivalent to an addition where we keep only the LSB. Indeed, the LSB of 1+1 is 0. Lucky for us, OpenGL has a feature, called the blend mode, that allows to do just that. Now, for every bit of our output voxel texture, we are doing a bitwise add of the fragments.

But there is a huge downside to this method. This method now required a whole byte of data for each layer, where the XOR method required a single bit. Or, to be accurate, this method required a whole color channel per layer. This means we now need several output textures for the whole scene, while a single one was enough for up to 32 layers (32 bpp) previously. Fortunately, even older GL ES did support multitarget rendering (i.e. writing to several textures in a single pass), but with limitations. Our wandboard has the limitation of 16 output textures, which gives 64 total layers (1 layer / channel, 4 layers / texture).

Anyways, we now have this version ready to rock, where the result is basically indistinguishable from the XOR version.

XOR-less version. Notice that there are now 8 voxel textures on the bottom left, each storing 4 voxel layers.

XOR version, for reference


As another acheivement, I got OpenGL ES to work reliably on the SBC, which proved tricky, especially with the broken package for the library I use. I use GLFW as a context-creator (awesome library!), but the version that ships with Ubuntu 16.04 (official linux flavor provided for this board) is utterly broken, with wrong includes, … So much for an LTS distribution!

Furthermore, porting this app to OpenGL ES on the wandboard is in progress, and is looking good so far. Except I have no output. OpenGL magic I guess. Anyhow, OpenGL ES is much more finicky than its desktop counterpart (especially Nvidia’s one), which makes porting very tedious. Oh and working remotely is not the easiest of the tasks to debug graphic apps…

Power supply

We estimated the total worst-case-scenario-if-everything-blows-up current consumption. We are looking at :

  • LEDs: 44A
  • FPGA: 700mA
  • LED drivers: 840mA
  • Clock buffers: 120mA
  • SoM: 2A

Some of those figures are more empiric than anything: FPGA comes from Altera’s excel document calculator thingy, and the SoM comes from an overkill stress test (CPU+GPU+WiFi).

To make the drivers drop the least possible power, LEDs will be powered from a 4V rail, not too far off from their 3.4V forward voltage. Beefy buck DC-DC converters are needed!

Then next big hog is the SoM, which will get his own dedicated buck DC-DC converter, supplying 5V straight away.

All the rest will be fed from a 3V3 buck converter, which will be downstepped to others voltages for the remaining components (3v, 2v5, 1v2).

A single 12V supply will feed all this mess through the various DC-DC converters. We are looking at 190 odd watts.

What’s next?

Next week, I’ll finish the PSU schematics and we’ll be able to route the main rotative PCB, containing PSU, SoM and FPGA (to name a few).

I will also continue to port that damn renderer to GL ES.

Thanks for reading 😀

2 comments to [SpiROSE] Supplying power voxels … Wait watt?

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>