Pi3D AssertionError on all demos

[dlleigh]

I decided to try out Pi3D but can't even get the demos running. No matter what demo I try, it fails in DisplayOpenGL with AssertionError "assert s >= 0".

I checked the FAQ and found this very problem right at the top, with the explanation:

When starting any demo I get an AssertionError in DisplayOpenGL assert s >= 0
This is generally caused by the graphics memory allocation on the Raspberry Pi being too low (less than 32)

But that doesn't seem to be the cause of my problem. I've got the graphics memory set to 128MB right now and it fails. I've tried it at 64MB and it fails.

The machine is a Raspberry Pi 3 running the latest version of Raspbian (Raspbian Jessie with Pixel, Version: March 2017, Release date: 2017-03-02, Kernel version:4.4). I installed Pi3D vusing pip3 two days ago, and downloaded the demos directly from the github master two days ago.

Any ideas on what might be going wrong?

[dlleigh]

The problem might be bad hardware.

I just tried exactly the same thing on a Raspberry Pi 2 that I have -- same OS version, same everything -- and the Pi3D demos work fine.

Unless there's a known problem running Pi3D on the 3, I'd say there's something else very weird going on.

[dlleigh]

Yes, something weird is going on, but it's probably not the hardware.

I tried the same SD card in a different RPi 3 and it came up with the same errors. I then reflashed the SD card with Raspbian (same version as before) and did a clean re-install and everything works fine now in the original RPi 3. I'm not sure what the problem was before, but now it's gone.

I can play with Pi3D now. I hope the problem doesn't return.

[paddyg]

Hi, it's frustrating that it 'just' started working without a satisfactory explanation for what caused the error. When you had the assertion error was there anything else installed and possibly running on the RPi that could have conflicted? I don't really know what might cause that error generally but it is issued by the code here so is due to either of the functions called from the libbcm_host.so: init() or graphics_get_display_size() not working as expected. I don't know if something might have set the width or height to confuse things (unlikely) or if it's something to do with recent patches to the shared object code on 1st, 2nd then 12th March though I don't know how those changes end up in the SD image, presumably they arrive via update, upgrade after the download has been released. Maybe @popcornmix would know.

If you (or anyone else) comes across the error again please let me know.

Paddy

[dlleigh]

Yes, very frustrating.

Another data point of interest is that the demos in /opt/vc/src/hello_pi were also failing, but are now working. If I recall correctly, the particular program hello_dispmanx was reporting a weird display size, something like 2 by something large and bizarre. I don't remember the specific numbers, but it matches with your conjecture of graphics_get_display_size() possibly not working correctly.

[Cigano1434]

@dlleigh @paddyg
Any luck on finding the answer to this problem. I am having the issue currently on a brand new RaspberryPi 3. I installed the Full Raspian using NOOBS, then followed the instructions found here:
https://pi3d.github.io/html/ReadMe.html ... spberry-pi
After completing the installation and attempting to run any of the examples, I get the same AssertionError. I tried reinstallation from scratch, again using NOOBS (My next step is to install from a Raspian Image, rather than using NOOBS.) Same problem.

I checked the same /opt/vc/src/hello_pi/hello_dispmanx example that dlleigh mentioned and the results I got were:

Open display[0]...
Display is 4 x 1036708308
Sleeping for 10 seconds...

Strange. I did try changing the Overscan settings, but that didn't change anything. I also thought setting a hard-coded resolution might help, but the raspi-config only has the option for "Default Monitor preferred resolution", though I will be looking into how to set that manually.

Jason

[paddyg]

Jason, I've not found anything else out. On my RPi 3 I did
$ ls /opt/vc/lib -l
and saw that date of the libbcm_host.so file was some time in 2016. The /opt/vc/src/hello_pi demos and pi3d worked ok. Then I updated the system:
$ sudo apt-get update
$ sudo apt-get dist-upgrade
and the file date had changed to Mar 31 2017 and the demos and pi3d still worked. You could try doing the same (assuming you haven't already downloaded and burnt a new sd card).

Though I don't know any details it seems very unlikely that the video card drivers would be released without running through a test suite so I'm quite doubtful that this is the cause of the problem. The fact that the error happens in the hello_pi demos makes me think it's a problem remote from pi3d.

Let me know if you find any other info.

[Cigano1434]

Paddy,

Thanks for your response. I've been able to run most of the demos now. The short answer is the GL driver change.

I imaged a different SD card with Raspian (Not using NOOBS) and configured it and received the same error. I began to suspect that it was the driver. I had been changing the GL driver in raspi-config to "G1 FL (Full KMS) Open GL Desktop Driver with full KMS", so I tried the other two options.

The only one that worked as the "G3 Legacy Original non-GL desktop driver". Switching it to this driver allowed me to run the demos (most of them). Consequently, it also gave me more options for manually setting the screen resolution.

I also re-ran the /opt/vc/src/hello_pi/hello_dispmanx and the output was three colored squares and the following text:

Open display[0]...
Display is 1920 x 1080
Sleeping for 10 seconds...

completely as expected.

So, is there a reason that the GL drivers don't work...I don't know, but I'm off and running with my project now. Thanks.

[paddyg]

Ah, that would explain it. OpenGL ES was brought out after OpenGL aimed at embedded graphics systems such as phones. It has reduced functionality compared with OpenGL but is more ubiquitous and ES2.0 is the native system used on the Raspberry Pi; Pi3d uses this. To run pi3d on laptops and desktop computers you need to install libraries that will emulate OpenGL ES behaviour on the OpenGL graphics card. To get software designed to run on big computers to work on the Raspberry Pi there needs to be a reverse process of emulating the OpenGL functionality. I suspect this is harder to do because, presumably, the missing functionality has to be patched over by the cpu.

So I think the GL drivers are good if you want to run desktop software on the Raspberry Pi without having to modify the graphics code. As I understand it the GL driver is still experimental but once it's fully working I might look at the pros and cons of making pi3d use it. I would expect some performance loss, but it might be small, however the change would make running pi3d on android devices harder.

Paddy

[Cigano1434]

Paddy,

That makes total sense. Thanks for the help and enlightenment. And thanks for a great library. You have already made my life a ton easier.

Jason

[Cigano1434]

Paddy,

OK. I'm breaking protocol by asking a different question in the thread, but it is related, and I've found the forum search to be lacking.

The question is why can I load all sorts of images into a slideshow, but as soon as the image is 1920x1080, it just shows a blank screen.

Here is what I mean:

My code:

Code: Select all

import pi3d

display = pi3d.Display.create()
camera = pi3d.Camera(is_3d=False)
shader = pi3d.Shader('uv_flat')
slide = pi3d.ImageSprite('/home/pi/radar/media3/bg1.jpg', shader=shader, w=display.width, h=display.height, z=1.0)
slide.set_alpha(1)

keyboard = pi3d.Keyboard()

while display.loop_running():
  slide.draw()
  if keyboard.read() == 27:
    break

This works fine for displaying an image that is smaller than 1920x1080. I even took one of my 1920x1080 images and shrunk it by 1 pixel in each direction (1919x1079) and it worked fine. But, as soon as I increase the size to 1920x1080 (which is the same as the display size), it displays a blank screen.

I tested these images with the pi3d demos as well with the same result (blank screens when these images were supposed to be displayed)

What am I doing wrong here?

[paddyg]

Hmm, that seems odd. I've just run your code on a RPi3 with an image resized to 1920x1080 and it seems fine. There is a GPU limit of 2048x2048 which I have discussed here but that's well beyond this size. I think insufficient GPU memory allocation always causes an explicit error rather than a blank screen so unlikely to be that. What resolution is your screen?

[Cigano1434]

Paddy,

The screen resolution is 1920 x 1080 (the max for this TV I'm testing with). I added logging code as below:

Code: Select all

import pi3d

import logging
log = logging.getLogger('radar')
log_handler = logging.FileHandler('test.log')
log_handler.setFormatter(logging.Formatter('%(asctime)s %(levelname)s %(message)s'))
log.addHandler(log_handler)
log.setLevel(logging.DEBUG)

display = pi3d.Display.create()
camera = pi3d.Camera(is_3d=False)
shader = pi3d.Shader('uv_flat')
slide = pi3d.ImageSprite('/home/pi/radar/media2/bg1.jpg', shader=shader, w=display.width, h=display.height, z=1.0)
log.info('display size: ' + str(display.width) + ' x ' + str(display.height))

keys = pi3d.Keyboard()

while display.loop_running():
  slide.set_alpha(1)
  slide.draw()
  if keys.read() == 27:
    break

The line outputted to the log file is:

Code: Select all

2017-04-21 18:02:10,081 INFO display size: 1920 x 1080

Perhaps there is an issue with the file itself. I can't attach the files since they are too big for the forum to accept. I will test with the 1080 file converted from jpg to png and see if that makes a difference.

[Cigano1434]

I noticed that the larger 1920x1080 image was 96 dpi, so I converted it to 72 dpi (no change.)

I've uploaded the three files I'm using for testing to the following links:

1920 x 1080 JPG (doesn't work)
https://drive.google.com/open?id=0B20sG ... TFKakJnQU0

1920 x 1080 PNG (doesn't work)
https://drive.google.com/open?id=0B20sG ... C1tM0h5NG8

1919 x 1079 JPG (works)
https://drive.google.com/open?id=0B20sG ... TQ0bXlqUkk

[Paeryn]

I noticed that the larger 1920x1080 image was 96 dpi, so I converted it to 72 dpi (no change.)

I've uploaded the three files I'm using for testing to the following links:

1920 x 1080 JPG (doesn't work)
https://drive.google.com/open?id=0B20sG ... TFKakJnQU0

1920 x 1080 PNG (doesn't work)
https://drive.google.com/open?id=0B20sG ... C1tM0h5NG8

1919 x 1079 JPG (works)
https://drive.google.com/open?id=0B20sG ... TQ0bXlqUkk

I just tested your code with the first (non-working) image you posted.
1) When gpu_mem is set < 64, you get an assertion error.
2) When gpu_mem is set = 64 you get a black screen,
3) When gpu_mem is set > 64 you get the image as expected.
So it looks like you are hitting a memory limit somewhere and pi3d isn't reporting back an error in creating the texture. Possibly not a big enough contiguous block of memory to hold the texture so you end up with a non-texture.

[Cigano1434]

Paeryn,

You are right. For some reason, the split memory had switched back to the default 64 MB. I'll have to look into why that is. I have switched it to 128, which is where I have had it for all my other testing. I switched it and it works fine.

I didn't think to look there for two reasons:

1) I had already switched it to 128
2) The 1920x1080 image file is actually smaller than the 1919x1079 image in bytes. So, I assume the images must go through a conversion to an array prior to being used as a texture...?? As a byte for byte conversion, it would take more memory, no matter the file size, which makes sense.

Thanks for the help!

Jason

[paddyg]

@Paeryn, thanks for sorting this out. I did test different memory allocations first (actually it was the only thing I tested!) but my 1920x1080 png displayed fine with 64kB (or 63kB). I'm using a RPi3 without a monitor over realvnc so I've set the screen res to w1024,h768 (to allow > 5fps) When I set the resolution with Display.create to 1920x1080 I get a black screen!

The critical factor is the amount of memory used in total for all textures, buffer arrays etc. So this is obviously enough to tip over the memory threshold. glGetError() after glTexImage2D() line 306 Texture.update_ndarray() gives GL_OUT_OF_MEMORY so I will add some error catching in here.

Paddy

PS Jason, when the example program closes it leaves curses in an annoying state as there is no Keyboard.close() after the break. See here for suggestions.

Also pi3d has a wrapper for the python logger so you can simply do

Code: Select all

LOGGER = pi3d.Log(level='INFO', file='test.log')
LOGGER.info('display size: {} x {}'.format(display.width, display.height))

Unfortunately logging in pi3d module files, such at Texture, doesn't seem to get logged so this is something to fix as a priority!
EDIT - don't provide the name argument to Log to make it default to root which then catches all the pi3d module logging.

[paddyg]

As a quick post script - I have added LOGGER.critical('Out of GPU memory') to Texture and altered pi3d.Log so that it uses the root logger (reverted as it did this already if no name argument given). Now if you create a pi3d.Log object before the Texture is created then the error will be logged. Maybe this should go in Buffer Added to Buffer too. (In develop branch)

[Cigano1434]

Paddy,

Thanks for the update and the fixes. I had noticed the console issue, but I was tackling one issue at a time. Thanks for the information on the Context. I will be using that from now on, even though I am only using the keyboard for debug purposes as this app will have no keyboard input.

Jason