Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
Just to give a further idea of the settings I am using and my general setup, I have provided the terminal load status. I am getting great performance at 720P. 1080P is definitely possible but I have not yet tested. 720P is very adequate for visuals and I tend to run most heavier games on the Pi 5 at 720P. It is possible to max out Doom III graphics settings at 720P at full screen with good performance. It gets sketchy at 1080P in busier areas of the Doom III. Your mileage may vary though.
Code: Select all
./gzdoom -file RebirthofCronos_1.pk3 RebirthofCronos_2.pk3 RoCMaps.wad -iwad hexen.wad
GZDoom g4.12pre-489-g0328eca7f - 2024年04月12日 00:05:39 +0200 - SDL version
Compiled on Apr 14 2024
OS: Debian GNU/Linux 12 (bookworm), Linux 6.6.20+rpt-rpi-2712 on aarch64
GZDoom version g4.12pre-489-g0328eca7f
W_Init: Init WADfiles.
adding /home/graphicw/Doom/gzdoom.pk3, 679 lumps
adding /home/graphicw/Doom/game_support.pk3, 3307 lumps
adding ./hexen.wad, 4270 lumps
adding /home/graphicw/Doom/game_widescreen_gfx.pk3, 214 lumps
adding RebirthofCronos_1.pk3, 2493 lumps
adding RebirthofCronos_2.pk3, 690 lumps
adding RoCMaps.wad, 372 lumps
S_Init: Setting up sound.
I_InitSound: Initializing OpenAL
Opened device Built-in Audio Pro
EFX enabled
Using video driver x11
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
Number of detected displays 1 .
Creating window [1536x864] on adapter 0
GL_VENDOR: Broadcom
GL_RENDERER: V3D 7.1
GL_VERSION: 3.1 Mesa 23.2.1-1~bpo12+rpt3
GL_SHADING_LANGUAGE_VERSION: 1.40
GL Version parsed = 3.100000
GL_MAX_TEXTURE_SIZE: 4096
GLES choosing mode: GLES_MODE_OGL2
Resolution: 1280 x 720
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
We still don't have hardware raytracing on on Pi5, but who really needs it. I have accomplished far more than I expected on Pi5 hardware and I can happily say I more than got my money's worth. It brings back the old time fun of trying to push limited hardware to the limit while finding out it is not quite as limited as thought opening the door to push it even more. The Videocore 7 has indeed been a pleasant surprise.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
graphicw, I have GZDoom on a X64 computer, and the X64 computer will run GZDoom at max settings, because of the discrete graphics card.
The Raspberry Pi 5 computer doesn't support OpenGL 3.3, which is required by GZDoom to max out the graphic settings.
The Raspberry Pi 5 should support Vulkan Renderer in GZDoom, because the Raspberry Pi 4 supports the Vulkan Renderer.
GZDoom was recently updated to Version 4.12.0. (g4.12.2).
The Raspberry Pi 5 computer doesn't support OpenGL 3.3, which is required by GZDoom to max out the graphic settings.
The Raspberry Pi 5 should support Vulkan Renderer in GZDoom, because the Raspberry Pi 4 supports the Vulkan Renderer.
GZDoom was recently updated to Version 4.12.0. (g4.12.2).
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
vulkan can not load v3dv driver anymore, Pi4.
Vulkan device: llvmpipe (LLVM 17.0.6, 128 bits)
Vulkan device type: cpu
Vulkan version: 1.3.278 (api) 0.0.1 (driver)
Vulkan device: llvmpipe (LLVM 17.0.6, 128 bits)
Vulkan device type: cpu
Vulkan version: 1.3.278 (api) 0.0.1 (driver)
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
I did not achieve my results using Vulkan, I achieved them using OpenGLES. You can select OpenGLES as your renderer. For some reason, most games resort to using CPU for Vulkan rather than using hardware. You can get even better visuals if Vulkan were able to work correctly.Moonmarch wrote: ↑Tue Apr 30, 2024 9:28 pmgraphicw, I have GZDoom on a X64 computer, and the X64 computer will run GZDoom at max settings, because of the discrete graphics card.
The Raspberry Pi 5 computer doesn't support OpenGL 3.3, which is required by GZDoom to max out the graphic settings.
The Raspberry Pi 5 should support Vulkan Renderer in GZDoom, because the Raspberry Pi 4 supports the Vulkan Renderer.
GZDoom was recently updated to Version 4.12.0. (g4.12.2).
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
I am working on this issue to see if I can get Vulkan to work in GZDoom via hardware. The visuals are of extraordinary high quality using Vulkan, but in software, it is unplayable because it about 1 frame per 10 seconds. Lol I have it working fine in OpenGLES though but if I can solve the Vulkan issue, the visuals will be even better.
I am working on another build project as well. I now have a working ZDL launcher on a Raspberry Pi as well. It makes life so much easier when loading mods and sorting them out between your different version of Doom and Hexen.
- 20240505_01h37m18s_grim.gif
- 20240505_01h37m18s_grim.gif (503.33 KiB) Viewed 6331 times
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
This is what the render quality is in Vulkan mode, just useless though in software mode though. Definitely quite exquisite though but I am sure a lot of the shaders and specular mapping will have to be toned down even on a Pi 5 if I can get Vulkan working in hardware.
- 20240505_02h00m36s_grim.jpeg
- 20240505_02h00m36s_grim.jpeg (443.51 KiB) Viewed 6330 times
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
This is what I can accomplish in OpenGLES. It definitely is not slouch. That is an example of every feature maxxed out other than MSAA which is only X2. Multi-sampling really begins taxing performance on the this GPU. Those ground reflections also create a noticeable drop in performance but the frame rate is still pleasant and higher than what the stock game ran at on my 486 with a shrunken window back in the early 90s. Lol There is even a Lens Flare effect which is noticeable in the last picture but I usually play with that disabled as it is overkill and taxes performance as well unnecessarily. All Sprites are full 3D models via mods I am using. That is an impressive rendering load being handled and frame rate is flawless when floor reflections are turned off and smooth. You can leave everything else on at maximum other than MSAA and speed run the game without skipping a beat. This is the Pi 5 GPU chugging out some decently hardcore graphics workloads even despite the limitations of the OpenGLES API.
- 20240505_02h20m18s_grim.jpeg
- 20240505_02h20m18s_grim.jpeg (324.23 KiB) Viewed 6325 times
- 20240505_02h21m35s_grim.jpeg
- 20240505_02h21m35s_grim.jpeg (378.65 KiB) Viewed 6325 times
- 20240505_02h22m09s_grim.jpeg
- 20240505_02h22m09s_grim.jpeg (307.51 KiB) Viewed 6325 times
Last edited by graphicw on Sun May 05, 2024 7:13 am, edited 1 time in total.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
If you look closely at the above photographs, you will also notice that shadows are being used as well. Such level of graphics used to perform very poorly on Raspberry Pi computers. GZDoom still has quite a bit to offer by using it's OpenGLES hardware renderer option until either or I or someone else can figure out how to get Vulkan API working using the actual GPU hardware.
Vulkan is still experimental in GZDoom though. I will show you the Full Options where you can set the Vulkan Device ID and on the Pi, it should be 0 as GZDoom supposedly defaults to. Software Vulkan would be device ID 1. This is not a problem with the V3DV Driver as I have finally gotten it working in hardware in the FTEQW engine for Quake and it performs as it should. There is still quite a bit of work being done on the Vulkan Driver and there are commits on github that are just a few days old. Some of the work is fairly major and important to implementing the ability of the Raspberry Pi to run more games. The driver is still a work in progress, but in this case, the problem is with the way that GZDoom implements Vulkan support.
Here is an article about one of the major milestones accomplished with work on the V3DV driver and the article is less than a week old.
https://www.phoronix.com/news/V3DV-Exte ... amic-State
Vulkan is still experimental in GZDoom though. I will show you the Full Options where you can set the Vulkan Device ID and on the Pi, it should be 0 as GZDoom supposedly defaults to. Software Vulkan would be device ID 1. This is not a problem with the V3DV Driver as I have finally gotten it working in hardware in the FTEQW engine for Quake and it performs as it should. There is still quite a bit of work being done on the Vulkan Driver and there are commits on github that are just a few days old. Some of the work is fairly major and important to implementing the ability of the Raspberry Pi to run more games. The driver is still a work in progress, but in this case, the problem is with the way that GZDoom implements Vulkan support.
Here is an article about one of the major milestones accomplished with work on the V3DV driver and the article is less than a week old.
https://www.phoronix.com/news/V3DV-Exte ... amic-State
- 20240505_02h50m45s_grim.jpeg
- 20240505_02h50m45s_grim.jpeg (452.15 KiB) Viewed 6311 times
- 20240505_02h50m36s_grim.jpeg
- 20240505_02h50m36s_grim.jpeg (389.35 KiB) Viewed 6311 times
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
By the way, I was testing out the GZDoom with OpenGLES API with all features active in the engine and all the mods that I am using. All features are maxxed out other than MSAA. If you look at the screenshot of the ZDL I managed to build, I definitely was using a lot of mods that covered everything from high resolution textures, lighting, shadows, 3d sprites, weather effects and etc. Yes, it rains, snows, ash falling and etc at times in my Doom. Lol The Pi 5 can definitely do quite a bit of justice in modernizing Doom even without Vulkan not actually working correctly in the engine. I did it with the "Best of Barbra Streisand" still playing on Youtube and everything on the screen still open. Even running all that while running GZDoom, the frame rate was still fine in game.
I did my build a little differently from this guide that allows a smaller size of the final executable and is specifically targeted for the Pi 5 system and build environment. It is actually simple to do this with this particular game as it is designed to be optimized as is using a straight cmake .. rather than cmake -DCMAKE_BUILD_TYPE=Release .. which will have you end up with fluff added to the executable. For this particular source, -DCMAKE_BUILD_TYPE=Release actually hurts optimization when running cmake. It is necessary with certain source, but the CMAKE file in the GZDoom git files already had the ability to automatically detect the build the environment. The CMAKE.txt was set to automatically provide O2 optimization in this build environment which is what we need with this OS environment for best performance. Adding -DCMAKE_BUILD_TYPE=Release may actually result in O3 (I provide an example of CXX flags from a CMAKE.TXT file below showing what RELEASE often results in) which is not considered optimum for this build environment. I didn't check though to see which optimization flag ended up used, but the executable I built is more than 20 megabytes less the executable you get following the instruction in this thread. Straight up cmake .. is all you need to generate a Makefile that is properly optimized if the source code is well programmed and meant to be multi platform.
Here is an example from a Cmake*.txt type file of how it usually works in most builds and why it is best to leave RELEASE out of it as a properly setup CMAKE*.txt will choose the best option based on your build environment in most cases. The CMAKE*.TXT will even show you the build options in many cases even when the source code has not build instructions. You can usually figure it out and end up with an optimum build with experience. This is why I love using a Pi because to get most of the better and more advanced games, you have to build source because they are often not in packages you can simply apt:
I did my build a little differently from this guide that allows a smaller size of the final executable and is specifically targeted for the Pi 5 system and build environment. It is actually simple to do this with this particular game as it is designed to be optimized as is using a straight cmake .. rather than cmake -DCMAKE_BUILD_TYPE=Release .. which will have you end up with fluff added to the executable. For this particular source, -DCMAKE_BUILD_TYPE=Release actually hurts optimization when running cmake. It is necessary with certain source, but the CMAKE file in the GZDoom git files already had the ability to automatically detect the build the environment. The CMAKE.txt was set to automatically provide O2 optimization in this build environment which is what we need with this OS environment for best performance. Adding -DCMAKE_BUILD_TYPE=Release may actually result in O3 (I provide an example of CXX flags from a CMAKE.TXT file below showing what RELEASE often results in) which is not considered optimum for this build environment. I didn't check though to see which optimization flag ended up used, but the executable I built is more than 20 megabytes less the executable you get following the instruction in this thread. Straight up cmake .. is all you need to generate a Makefile that is properly optimized if the source code is well programmed and meant to be multi platform.
Here is an example from a Cmake*.txt type file of how it usually works in most builds and why it is best to leave RELEASE out of it as a properly setup CMAKE*.txt will choose the best option based on your build environment in most cases. The CMAKE*.TXT will even show you the build options in many cases even when the source code has not build instructions. You can usually figure it out and end up with an optimum build with experience. This is why I love using a Pi because to get most of the better and more advanced games, you have to build source because they are often not in packages you can simply apt:
Code: Select all
//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
//Flags used by the CXX compiler during RELEASE builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG- 20240505_01h37m18s_grim.gif
- 20240505_01h37m18s_grim.gif (503.33 KiB) Viewed 6305 times
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
It more or less works the same way in Debian as it does in Arch. I just generally stick to 02 when possible even though 03 may not hurt anything necessarily. I still ended up with a smaller executable in the end and that is always a plus.
https://wiki.archlinux.org/title/CMake_ ... guidelines
https://wiki.archlinux.org/title/CMake_ ... guidelines
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
One plus with O2 is you also get a log if you should have a failure which helps with troubleshooting code. Just what I have always been used to and most packages built in Arch, Debian or Red Hat Linux will normally default to 02 by using a vanilla Cmake command and optimizations are usually correctly picked for hardware and OS environment. You can of course specify very specific hardware features using -march which gets very detailed because you really get into specific and targeted optimizations then.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
@graphicw,
months ago, GZdoom & VKdoom both work in vulkan mod.
so, they might move to vukan-1.3 :?:
months ago, GZdoom & VKdoom both work in vulkan mod.
so, they might move to vukan-1.3 :?:
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
That is a possibility as Vulkan implemented through software on the Pi is 1.3 compliant but definitely too slow to be of any use. There is a possibility that Vulkan through hardware on the Pi may reach 1.3 at some point. There is still quite a bit of activity going on in the git hub for the V3D driver on both the Vulkan and OpenGL APIs as well. It appears as though they may attempt partial conformity with OpenGL 3.2 which will open up many more possibilities.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
As I understand it 1.2 to 1.3 is only software, no extra hardware is required.they might move to vulkan-1.3 :?:
However I think the Pi needed some "hardware" to be "faked" in software for 1.2.
But that was on Pi4, not sure about Pi5, some things we still don't know about on the VC7.
Figuring out how those Mesa drivers work might be a clue.
There has been lots of performance increases with Zink, so OpenGL3.x over Vulkan on Pi?
I used to keep up with what is going on but on my Pi5 even OpenGL is fast enough.
The fly in the soup for me has been Wayland/Wayfire , lots of old apps don't like it, old games etc.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
talking about zink, how to set it up & test?Gavinmc42 wrote: ↑Tue May 07, 2024 7:51 amAs I understand it 1.2 to 1.3 is only software, no extra hardware is required.they might move to vulkan-1.3 :?:
However I think the Pi needed some "hardware" to be "faked" in software for 1.2.
But that was on Pi4, not sure about Pi5, some things we still don't know about on the VC7.
Figuring out how those Mesa drivers work might be a clue.
There has been lots of performance increases with Zink, so OpenGL3.x over Vulkan on Pi?
I used to keep up with what is going on but on my Pi5 even OpenGL is fast enough.
The fly in the soup for me has been Wayland/Wayfire , lots of old apps don't like it, old games etc.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
The software version of Vulkan shows as being 1.3 compliant. It is unplayable in a detailed game like GZDoom as running off of CPU. I am unable to get hardware Vulkan working in GZDoom though I did pull it off in the FTEQW engine and it works correctly in that engine. The hardware driver on Pi is compliant to 1.2.Gavinmc42 wrote: ↑Tue May 07, 2024 7:51 amAs I understand it 1.2 to 1.3 is only software, no extra hardware is required.they might move to vulkan-1.3 :?:
However I think the Pi needed some "hardware" to be "faked" in software for 1.2.
But that was on Pi4, not sure about Pi5, some things we still don't know about on the VC7.
Figuring out how those Mesa drivers work might be a clue.
There has been lots of performance increases with Zink, so OpenGL3.x over Vulkan on Pi?
I used to keep up with what is going on but on my Pi5 even OpenGL is fast enough.
The fly in the soup for me has been Wayland/Wayfire , lots of old apps don't like it, old games etc.
Broadcom does have 1.3 compliance on some of their other SOCs. These chips use VideoCore 7 just like the Pi. My guess is that these are chips intended for set top boxes running closed blob drivers.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
I have been playing Warzone2100 with Vulkan for months with Mesa 23.
Mesa 24+ has big changes that will mean big improvement particularly for Warzone2100.
VKDoom might be better than GZDoom, if it works at all on the Pi?
But a Pi4 is still not going to be as good as the Pi5.
Not sure if Broadcom would bother with blobs now, the open source stuff is getting pretty good.
Does Broadcom still have enough engineers for Videocore blob software?
Lots of their old ones ended up at Raspberry Pi Trading.
But their set top box Linux is kept current
https://github.com/Broadcom/stblinux
Is there another binary blob that is more current?
STB is now a small part of Broadcom, they don't even bother to list the SoC they supply to RPT, but then they never have listed all their products.
Mesa 24+ has big changes that will mean big improvement particularly for Warzone2100.
VKDoom might be better than GZDoom, if it works at all on the Pi?
But a Pi4 is still not going to be as good as the Pi5.
Not sure if Broadcom would bother with blobs now, the open source stuff is getting pretty good.
Does Broadcom still have enough engineers for Videocore blob software?
Lots of their old ones ended up at Raspberry Pi Trading.
But their set top box Linux is kept current
https://github.com/Broadcom/stblinux
Is there another binary blob that is more current?
STB is now a small part of Broadcom, they don't even bother to list the SoC they supply to RPT, but then they never have listed all their products.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
I have not tested VKDoom yet. GZDoom is known to be a full featured but a relatively heavy engine. I may build an older version of GZDoom to see if Vulkan works in an older version. Some people have reported it worked some months ago.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
from this news, have had try kernel-6.9-RC & mesa-24.2-git, but nothing help.
so, don't know what does it mean exactly.
https://www.phoronix.com/news/Raspberry-Pi-V3D-CPU-Jobs
so, don't know what does it mean exactly.
https://www.phoronix.com/news/Raspberry-Pi-V3D-CPU-Jobs
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
I was aware of some CPU jobs having to be implemented. This would not cause llvmpipe to be used in an application where it is nothing but the CPU trying to implement Vulkan with near 0% GPU usage. I have ran into this problem in multiple games where CPU usage is pegged and there is almost zero GPU usage and a closer look revealed they were using llvmpipe and not even trying to use hardware at all.cjan wrote: ↑Sat May 11, 2024 12:52 pmfrom this news, have had try kernel-6.9-RC & mesa-24.2-git, but nothing help.
so, don't know what does it mean exactly.
https://www.phoronix.com/news/Raspberry-Pi-V3D-CPU-Jobs
I have managed to get Vulkan working with FTEQW with Quake One. I have also gotten it to work with Super Tux Kart using hardware as it should. For the most part though, I have had to achieve good results using GLES until it becomes clearer why several game engines are unable to use the hardware of functionality for Vulkan on this particular GPU. My guess is that Vulkan implementation in V3DV is still a work in progress or some game engine projects have moved up to requiring Vulkan 1.3 which is not possible at this moment using hardware V3DV.
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
ok, tested.cjan wrote: ↑Mon Aug 05, 2024 11:43 pmvulkan-1.3 merged 24.3-dev.
https://gitlab.freedesktop.org/mesa/mes ... ests/29476
gzdoom-4.13.3 work, others & git all failed.
Code: Select all
Using video driver wayland
Vulkan device: V3D 4.2.14.0
Vulkan device type: integrated gpu
Vulkan version: 1.3.292 (api) 24.3-git (driver)
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
does Pi4 didn't supported, even vulkan update to 1.3?
*Device does not support the VK_KHR_video_decode_queue extension!
https://www.phoronix.com/news/Vulkan-Vi ... ional-Spec
*Device does not support the VK_KHR_video_decode_queue extension!
https://www.phoronix.com/news/Vulkan-Vi ... ional-Spec
Re: GZDoom DOOM Engine Source Port on the Raspberry Pi 4 Computer
ok, last build, gzdoom-git-4.13pre+179+g6aa7118.
MESA_LOADER_DRIVER_OVERRIDE=zink gzdoom
MESA_LOADER_DRIVER_OVERRIDE=zink gzdoom
Code: Select all
Using video driver wayland
Number of detected displays 1 .
Creating window [1280x720] on adapter 0
Initialization of Vulkan failed: No Vulkan device found supports the minimum requirements of this application
Number of detected displays 1 .
Creating window [1280x720] on adapter 0
Number of detected displays 1 .
Creating window [1280x720] on adapter 0
GL_VENDOR: Mesa
GL_RENDERER: llvmpipe (LLVM 18.1.8, 128 bits)
GL_VERSION: 4.5 (Core Profile) Mesa 24.2.2
GL_SHADING_LANGUAGE_VERSION: 4.50
GL Version parsed = 4.500000
GL_MAX_TEXTURE_SIZE: 16384
GLES choosing mode: GLES_MODE_OGL3
Jump to
- Community
- General discussion
- Announcements
- Other languages
- Deutsch
- Español
- Français
- Italiano
- Nederlands
- 日本語
- Polski
- Português
- Русский
- Türkçe
- User groups and events
- Raspberry Pi Official Magazine
- Using the Raspberry Pi
- Beginners
- Troubleshooting
- Advanced users
- Assistive technology and accessibility
- Education
- Picademy
- Teaching and learning resources
- Staffroom, classroom and projects
- Astro Pi
- Mathematica
- High Altitude Balloon
- Weather station
- Programming
- C/C++
- Java
- Python
- Scratch
- Other programming languages
- Windows 10 for IoT
- Wolfram Language
- Bare metal, Assembly language
- Graphics programming
- OpenGLES
- OpenVG
- OpenMAX
- General programming discussion
- Projects
- Networking and servers
- Automation, sensing and robotics
- Graphics, sound and multimedia
- Other projects
- Media centres
- Gaming
- AIY Projects
- Hardware and peripherals
- Camera board
- Compute Module
- Official Display
- HATs and other add-ons
- Device Tree
- Interfacing (DSI, CSI, I2C, etc.)
- Keyboard computers (400, 500, 500+)
- Raspberry Pi Pico
- General
- SDK
- MicroPython
- Other RP2040 boards
- Zephyr
- Rust
- AI Accelerator
- AI Camera - IMX500
- Hailo
- Software
- Raspberry Pi OS
- Raspberry Pi Connect
- Raspberry Pi Desktop for PC and Mac
- Beta testing
- Other
- Android
- Debian
- FreeBSD
- Gentoo
- Linux Kernel
- NetBSD
- openSUSE
- Plan 9
- Puppy
- Arch
- Pidora / Fedora
- RISCOS
- Ubuntu
- Ye Olde Pi Shoppe
- For sale
- Wanted
- Off topic
- Off topic discussion