What about 2D/3D hardware acceleration and audio support on Raspberry PI?

C

cabriofahrer

Why does FreeBSD do not have that yet? The other day I installed FreeBSD on a Raspberry PI 3 and it works like a charm, but these 2 important features are missing. Why? All Linuxes seem to have it, even NetBSD has it. Why is FreeBSD lacking behind in this? Such a pity...
 
I believe this is due to Raspberry using binary blobs for this and these are only available for Linux.

I use a Raspberry Pi 400 and i miss 3D acceleration, HDMI audio and WiFi.

Made me go back to Linux for my daily driver. :eek:
 
eternal_noob said:
and these are only available for Linux.
Click to expand...
Is that so? As I said, NetBSD has it, so would it not be possible to port it from there? But on the other hand, apparently NetBSD is not even capable of shutting down the Raspberry properly, a shutdown -p now makes the thing hang without turning off, which makes NetBSD a total no-go in spite of hardware acceleration and audio support...
 
Counter intuitively and unknown to many, the very latest release of Raspberry Pi OS (bullseye) does not provide 3D acceleration (OpenGL) support for the Raspberry Pi 3 or older. Neither in the 32-bit or 64-bit release. This is powered (slowly) by LLVMpipe, same as FreeBSD. You can verify this via glxinfo on both OSes.

The reason being is that VC4 (Broadcom's driver blob) was deprecated and the replacement (V3D, similar name) only robustly supports the GPU in the Raspberry Pi 4. If you enable glamor on the Pi3, it can report VC4 but it is an unsupported config resulting in crashes and graphical issues such as: https://github.com/RPi-Distro/chromium-browser/issues/35

So you will need to use the old Raspbian (Buster) and 32-bit only to have 3D accel in Linux. Personally, I would rather keep with the newer OS and use LLVMpipe which offers a higher OpenGL support (4.x) compared to VC4 (OpenGL 2.1).

Some more info I just found is here.
 
I don't understand why a product like Raspberry works with binary blobs. Are there really no chipsets with open-source code ?
 
The VideoCore chip in the Raspberry Pi does *now* have an open-source driver (V3D). However the focus is on Raspberry Pi 4 because that is "where the money is". Even though ironically it is still probably easier to buy a v3.
 
Alain De Vos said:
I don't understand why a product like Raspberry works with binary blobs. Are there really no chipsets with open-source code ?
Click to expand...
Short answer: No.

Long answer: Everything in life is a tradeoff. The Raspberry group made a tradeoff between the SOC being inexpensive SOC, having features, and supporting an easy-to-use development and use environment (Linux). Being 100% open source was not a goal that was important enough to justify jeopardizing the other goals. You have to remember that the Pi is intended and designed mostly as an educational tool, to help with computer education. It is not built to please open source fanatics, nor industrial users, nor be a cheap competitor to traditional motherboards or laptops.
 
Thank you very much for your answers. I didn't know that this was because of binary blobs. So after all that was said here and reading the other linked information, can I come to the conclusion that there will not be a FreeBSD driver for the QuadCore / Raspberry 3?
And is the driver for sound a blob as well?
And although going a bit OT, can anyone say anything about the above described problem with NetBSD not shutting down properly?
 
cabriofahrer said:
can I come to the conclusion that there will not be a FreeBSD driver for the QuadCore / Raspberry 3?
Click to expand...
I believe once Linux gets a stable V3D driver for the VideoCore found in the Raspberry Pi 3 (currently it does not), then FreeBSD might follow via its LinuxKPI compatibility layer, however this might be after quite a while. The Raspberry Pi is pretty neat but unfortunately there are probably more important things that the FreeBSD developers prefer to work on.
cabriofahrer said:
And is the driver for sound a blob as well?
Click to expand...
I'm not sure about sound but another thing that is missing is the wifi. OpenBSD does have a working open-source driver, I am actually not entirely sure the reason why FreeBSD does not. The firmware has a couple of security flaws, but this affects all platforms and they seem to keep the driver around.
 
kpedersen said:
The Raspberry Pi is pretty neat but unfortunately there are probably more important things that the FreeBSD developers prefer to work on.
Click to expand...
Another very useful thing to work on would be to make FreeBSD (amd64) installable on devices that only have a 32-bit EFI. This would benefit quite some owners of Laptops with an Intel Atom Baytrail processor, for example. Obviously a 64-bit processor with a 32-bit EFI is a very unfortunate hardware implementation. The best viable option for me that I have found on a Laptop like that so far is Fedora, but I really would prefer FreeBSD...
 
kpedersen said:
Counter intuitively and unknown to many, the very latest release of Raspberry Pi OS (bullseye) does not provide 3D acceleration (OpenGL) support for the Raspberry Pi 3 or older. Neither in the 32-bit or 64-bit release. This is powered (slowly) by LLVMpipe, same as FreeBSD. You can verify this via glxinfo on both OSes.

The reason being is that VC4 (Broadcom's driver blob) was deprecated and the replacement (V3D, similar name) only robustly supports the GPU in the Raspberry Pi 4. If you enable glamor on the Pi3, it can report VC4 but it is an unsupported config resulting in crashes and graphical issues such as: https://github.com/RPi-Distro/chromium-browser/issues/35

So you will need to use the old Raspbian (Buster) and 32-bit only to have 3D accel in Linux. Personally, I would rather keep with the newer OS and use LLVMpipe which offers a higher OpenGL support (4.x) compared to VC4 (OpenGL 2.1).

Some more info I just found is here.
Click to expand...
I have Raspios 11 (bullseye) running on my RPi3 with all packages updated through apt update and apt upgrade. In raspi-config there are two options inside the advanced menu for the graphics acceleration:

- G1 Legacy Original non-GL desktop driver
- G2 GL (Full KMS) OpenGL desktop driver with full KMS

So is the G1 Legacy driver "the old one", prior to bullseye, that DOES provide 3D acceleration? I am attaching the full kodi log, but here is the part that mentions the graphics:

Code: 
2024-02-27 08:48:37.626 T:945      INFO <general>: CApplication::CreateGUI - using the gbm windowing system
2024-02-27 08:48:37.626 T:945      INFO <general>: Checking resolution 16
2024-02-27 08:48:37.665 T:945      INFO <general>: GL_VENDOR = Broadcom
2024-02-27 08:48:37.666 T:945      INFO <general>: GL_RENDERER = VC4 V3D 2.1
2024-02-27 08:48:37.666 T:945      INFO <general>: GL_VERSION = OpenGL ES 2.0 Mesa 20.3.5
2024-02-27 08:48:37.666 T:945      INFO <general>: GL_SHADING_LANGUAGE_VERSION = OpenGL ES GLSL ES 1.0.16
2024-02-27 08:48:37.666 T:945      INFO <general>: GL_EXTENSIONS = GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_depth_texture GL_AMD_performance_monitor GL_OES_packed_depth_stencil GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_pack_reverse_row_order GL_EXT_occlusion_query_boolean GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_separate_shader_objects GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_draw_elements_base_vertex GL_EXT_texture_border_clamp GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_border_clamp GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_KHR_parallel_shader_compile GL_MESA_tile_raster_order
2024-02-27 08:48:39.135 T:945      INFO <general>: GLES: Maximum texture width: 2048

So do I have proper acceleration or not? All I can say is that watching stuff through Kodi apps (e.g. the German ZDF Mediathek) to me looks fine.
In the raspi-config menu I also saw the possibility of allocating up to 256 MB of memory to the GPU. I set it to 128 MB.
So which of the 2 above settings (G1 or G1) would be better?

kpedersen said:
I believe once Linux gets a stable V3D driver for the VideoCore found in the Raspberry Pi 3 (currently it does not), then FreeBSD might follow via its LinuxKPI compatibility layer, however this might be after quite a while.
Click to expand...
Any news on this since last time?
 

Attachments

  • raspios11_kodi.log.txt
    326.6 KB · Views: 36
cabriofahrer said:
So do I have proper acceleration or not?

Any news on this since last time?
Click to expand...

It looks like you have OpenGL ES working at least. And with the V3D driver (rather than the older binary blob).

GL_RENDERER = VC4 V3D 2.1
GL_VERSION = OpenGL ES 2.0 Mesa 20.3.5
Click to expand...

This is not the full fat desktop OpenGL or OpenGL Core so only programs that support the (originally mobile) OpenGL ES context may work.

However, that is not to say that your setup doesn't support OpenGL, just that Kodi might only be creating the ES profile.
What do you get with i.e glxinfo?

May be related but NetBSD can only use it for 32-bit kernels due to the upstream source(?) not bing 64-bit clean. The manpage mentions it in the bugs section. It also discusses that it isn't the "full fat" OpenGL and that programs need to be specially built (probably for the ES profile). That said, perhaps I am confusing things. It has been a while since I have fiddled with my collection of Raspberry Pis.
 
I am attaching the complete glxinfo. However, it looks like you originally described in #5: Although it says "direct rendering: Yes", further below it says:

Code: 
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa/X.org (0xffffffff)
    Device: llvmpipe (LLVM 11.0.1, 128 bits) (0xffffffff)
    Version: 20.3.5
    Accelerated: no

So what do you think? Even in Raspios 11 I don't have the latest kodi version (it's only 19), I don't think that going back to something with Debian 10 would be of any advantage, I would even have an older kodi version. Also I do not find any Raspios versions prior to 11 (bullseye).
 

Attachments

  • glxinfo.txt
    114.8 KB · Views: 25
Hmm, indeed that looks to be using the software renderer rather than V3D.

In the mentioned raspi-config did you select the "G2 GL (Full KMS) OpenGL desktop driver with full KMS"? What this should do is add a line in the config.txt:

Code: 
dtoverlay=vc4-kms-v3d

After a reboot, then try glxinfo again.

Some info on that here.
 
After choosing now "G2 GL (Full KMS) OpenGL desktop driver with full KMS", assigning 256 MB of video memory and rebooting, the line "dtoverlay=vc4-kms-v3d" is present in config.txt (see screenshot). But nothing has changed, the output of glxinfo is the same, only the value for video memory varies a little bit.
 

Attachments

  • config.txt.png
    config.txt.png
    55.6 KB · Views: 29
  • glxinfo2.txt
    114.8 KB · Views: 28
A little update here: I flashed another SD card with the new Raspios12 version and glxinfo is looking good now! It seems that there is hardware acceleration for v3d through mesa now. Is this correct? What could this mean for FreeBSD / what would have to be done? I am also attaching apt list --installed.
 

Attachments

  • apt-list.txt
    96.2 KB · Views: 32
  • glxinfo_raspios12.txt
    51.3 KB · Views: 25
You must log in or register to reply here.
Back
Top