You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is this the right place for my bug report?
Calls are done through the userland GL libraries, so I'm starting here. It could be a firmware bug though.
Describe the bug
Rendering to pixel buffer objects (or potentially readback from them?) don't seem to work as it does on other devices. Instead, it yields a blank buffer when it should contain the framebuffer that was rendered. On other Linux devices, this works as intended. It also works when rendering directly to the framebuffer and then calling glReadPixels, but I'd like to avoid stalling the graphics pipeline as recommended here: http://www.songho.ca/opengl/gl_pbo.html.
The example program from the link above exhibits this same issue, but I've attached a simpler example to reproduce the problem below.
To reproduce
Compile the following code twice, once with pixel buffer rendering and once without:
c++ -std=c++17 gltest.cpp -lglut -lGL -o standard c++ -std=c++17 gltest.cpp -lglut -lGL -o pbo -DPBO
Expected behaviour
Both program variants should write 256x256 RGBA-format byte buffers /tmp/frameXX.data containing the framebuffer data of a multicolor square rotating.
Actual behaviour
Only the standard implementation writes the framebuffer correctly. The one that uses pixel buffer objects writes a blank framebuffer. You can md5sum /tmp/frame*.data and they will all have the same hash when running in PBO mode. You can view these files in GIMP by opening them as raw data, RGBA 256x256.
As mentioned, every other system I've run this code on works as expected.
System
Copy and paste the results of the raspinfo command in to this section.
System Information
------------------
Raspberry Pi Zero 2 W Rev 1.0
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
Raspberry Pi reference 2022-01-28
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f01430c9d8f67a4b9719cc00e74a2079d3834d5d, stage4
Linux raspberrypi 5.10.103-v7+ #1530 SMP Tue Mar 8 13:02:44 GMT 2022 armv7l GNU/Linux
Revision : 902120
Serial : 00000000d7638eed
Model : Raspberry Pi Zero 2 W Rev 1.0
Throttled flag : throttled=0x0
Camera : supported=1 detected=0
Videocore information
---------------------
Jan 20 2022 13:59:16
Copyright (c) 2012 Broadcom
version bd88f66f8952d34e4e0613a85c7a6d3da49e13e2 (clean) (release) (start_x)
alloc failures: 0
compactions: 0
legacy block fails: 0
Filesystem information
----------------------
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 29734180 4107792 24363088 15% /
devtmpfs 153364 0 153364 0% /dev
tmpfs 186644 0 186644 0% /dev/shm
tmpfs 74660 692 73968 1% /run
tmpfs 5120 4 5116 1% /run/lock
/dev/mmcblk0p1 258095 49440 208655 20% /boot
tmpfs 37328 20 37308 1% /run/user/1000
Filename Type Size Used Priority
/var/swap file 102396 49408 -2
Package version information
---------------------------
raspberrypi-ui-mods:
Installed: 1.20220301
raspberrypi-sys-mods:
Installed: 20220224
openbox:
Installed: 3.6.1-9+rpt1+deb11u1
lxpanel:
Installed: 0.10.1-2+rpt12
pcmanfm:
Installed: 1.3.2-1+rpt6
rpd-plym-splash:
Installed: 0.30
Output of glGetString(GL_EXTENSIONS) indicates that this should be supported (see GL_ARB_pixel_buffer_object below):
Is this the right place for my bug report?
Calls are done through the userland GL libraries, so I'm starting here. It could be a firmware bug though.
Describe the bug
Rendering to pixel buffer objects (or potentially readback from them?) don't seem to work as it does on other devices. Instead, it yields a blank buffer when it should contain the framebuffer that was rendered. On other Linux devices, this works as intended. It also works when rendering directly to the framebuffer and then calling glReadPixels, but I'd like to avoid stalling the graphics pipeline as recommended here: http://www.songho.ca/opengl/gl_pbo.html.
The example program from the link above exhibits this same issue, but I've attached a simpler example to reproduce the problem below.
To reproduce
Compile the following code twice, once with pixel buffer rendering and once without:
c++ -std=c++17 gltest.cpp -lglut -lGL -o standard
c++ -std=c++17 gltest.cpp -lglut -lGL -o pbo -DPBO
Expected behaviour
Both program variants should write 256x256 RGBA-format byte buffers /tmp/frameXX.data containing the framebuffer data of a multicolor square rotating.
Actual behaviour
Only the standard implementation writes the framebuffer correctly. The one that uses pixel buffer objects writes a blank framebuffer. You can md5sum /tmp/frame*.data and they will all have the same hash when running in PBO mode. You can view these files in GIMP by opening them as raw data, RGBA 256x256.
As mentioned, every other system I've run this code on works as expected.
System
Copy and paste the results of the raspinfo command in to this section.
Output of
glGetString(GL_EXTENSIONS)
indicates that this should be supported (seeGL_ARB_pixel_buffer_object
below):The text was updated successfully, but these errors were encountered: