mn416/QPULib

Firmware error on RPi 3 Model B

Closed this issue · 5 comments

wimrijnders commented

Hi there,

I must say I'm very intrigued by your RPi GPU project, It appears to be well thought out and I'm really hoping to get it working on my itty-bitty RPi computers.

I would like to report that I can't get it to work on my RPi 3 Model B. I get the following error upon execution of any test, even after updating the firmware:

   Unable to enable QPUs. Check your firmware is latest.

I am aware that this is untested; I encountered the following comment in the docs:

It's been tested on the Pi 1 Model B, the Pi 2, but not yet the Pi 3.

So I can hereby inform you that the Pi 3 does not work.

....yet. I would really like to make this work, please advise me how to go about it. I'm perfectly willing to tinker a bit myself.

This is not the end of the story for me; I've got a couple of older version PI's burrowing around here, will catch one and see if I can get QPULib to work on that.

Edit: I looked up the revision number, it's a Pi 3 Model B, not B+.

wimrijnders commented

I can hereby confirm that QPULib works fine on a Pi 1 Model B, using e.g. make QPU=1 Rot3D.

I can also report that the Pi 1 Model B is then about ten times faster that the Pi 3 Model B running the same test in emulator mode. Encouraging to say the least.

wimrijnders commented

After research, I did the following things:

  • raised the memory split to 128M using raspi-config. This should be plenty.
  • really did a firmware update with rpi-update. The firmware version went from 4.9.35-v7+ to rpi-4.14.y linux tree.

But still no difference. I keep on getting the message Unable to enable QPUs. Suggestions are welcome.

wimrijnders commented

...aaaand I found it: OpenGL was enabled on the PI 3. Apparently it wants the whole GPU for itself or something. After disabling OpenGL, the QPULib test applications worked.

Thank you for rubber-ducking, hope to be able to contribute something useful to this project.

Might as well close now, I think.

mn416 commented

Hi @wimrijnders,

Thanks for reporting this issue and for finding the solution!

I can also report that the Pi 1 Model B is then about ten times faster that the Pi 3 Model B running the same test in emulator mode.

A few comments on performance:

  1. I don't expect the emulator performance to be particularly good. It's mainly there for testing and debugging purposes.

  2. The QPUs seem to offer some attractive speed-ups over the ARM on the Pi 1 and Pi Zero. I'm a little less clear about the gain on the Pi 3, with it's more powerful processor(s). I also wonder if Pi 3's larger caches are accessible to the QPUs. Of course, having all the options at ones fingertips, i.e. QPUs + multicore, can only be a good thing :)

  3. The QPULib compiler doesn't do much in the way of optimisation. So another question is how far QPULib programs are off hand-written QPU assembly, and what we can do to get closer.

wimrijnders commented

With respect to your points:

  1. Totally clear. I don't expect the emulator to be great performance-wise either. However, it's a good platform to test code before submitting it to the hardware.

Case in point: I managed to lock up my RPi2 with my very first QPU program - turned out I was doing one gather() too many, when the input FIFO was already full. It would be good if the emulator could report such things.

  1. It would actually be good to be able to measure performance in various ways, e.g. different iterations of a program, number of QPU's used and compare between RPi version. I'm setting up a TODO-list, this is going on it.

  2. Also understood. For example the branching which is delayed 3 cycles. I not even close to being able to do that stuff right now, but it's going on the list. For somewhere in the future.