imgui
imgui copied to clipboard
ocornut
Vsync and run problems with example_sdl_opengl3 on RPi4b Bullseye
(you may also go to Demo>About Window, and click "Config/Build Information" to obtain a bunch of detailed information that you can paste here)
Version/Branch of Dear ImGui: fa2b318
Version: fa2b318 Branch: master
Back-end/Renderer/Compiler/OS Raspberry Pi 4b Bullseye 32bit Linux raspberrypi 5.10.92-v7l+ #1514 SMP Mon Jan 17 17:38:03 GMT 2022 armv7l GNU/Linux
Back-ends: imgui_impl_sdl.cpp + imgui_impl_opengl3.cpp Compiler: gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
My Issue/Question:
I am making an app that runs both on the X11 desktop and without x11 on the tty/cli. I'm using SDL+imgui and kmsdrm rendering on the cli. This is why I chose the SDL backend as it was 'easy' to do.
I started developing on a Buster version of the RPiOS but am now moving over to test on Bullseye which is going to be the 'supported' OS for me. Imgui was doing fine under Buster but now under Bullseye I'm getting strong what looks like vsync glitching. This didn't happen at all under Buster.
I then tried to compile the Imgui example, example_sdl_opengl3, and building goes ok. But when running it I get:
./example_sdl_opengl3
Failed to initialize OpenGL loader!
example_sdl_opengl3: ../../backends/imgui_impl_opengl3.cpp:302: void ImGui_ImplOpenGL3_NewFrame(): Assertion `bd != __null && "Did you call ImGui_ImplOpenGL3_Init()?"' failed.
Aborted
Again this Imgui example worked fine under Buster and I'm now wondering if this and my issue might be related?
Standalone, minimal, complete and verifiable example: Build example_sdl_opengl3 on the above mentioned system and try running.
I'm happy to show my code but I think it might be cleanest start with the imgui example? Actually might as well post it: https://github.com/Fredrum/chiaki/blob/rpi02/rpi/src/main.cpp https://github.com/Fredrum/chiaki/blob/rpi02/rpi/src/gui.cpp
Cheers! Fred
In my experience, example_glfw_opengl3 should build and run unmodified on a Pi 4. Not sure about example_sdl_opengl3 but I'd expect the same for it. (Unfortunately I don't have a spare Pi right now to test for myself.)
Have you tried changing your GL driver with raspi-config? If it works in some and not others it may be a bug on the Pi Foundation's end. I believe ideally you should be using full KMS since it's the new default for Bullseye according to this post. If you upgraded without reimaging you might be using fake KMS or even the legacy driver since they used to be the default.
If you want to check what you're currently using. Look at /boot/config.txt and see if you have an entry for dtoverlay. If I remember correctly; there's no vc4-* values when you're using the legacy driver, vc4-kms-* for full KMS, and vc4-fkms-* for fake KMS.
Hi! I have not tried 'example_glfw_opengl3' just because glfw doesn't allow for easy kmsdrm rendering (no x11, CLI screen) but the SDL backend does. I'll try it after work just to see what happens though.
The PiOS is a newly flashed image using the official rpi-imager + update-upgrade. I just double checked and yes I'm using 'vc4-kms-v3d' not fake kms. I have gpu memory at 256 and CMA at 128. (on a 8gb Pi)
Did I say that 'example_sdl_opengl2' (note 2) is working as expected?
I added 'GL_DEPTH_BUFFER_BIT' to my glClear statement and to my eye the vsync looking glitches calmed down somewhat. But not enough still pretty strong.
Interestingly, after I switch my program to kmsdrm render and then back again to SDL+imgui the refresh glitches completely disappear. It does that every time I try. So I'm wondering if there's some kms mode setting that is incorrect and that my kmsdrm code somehow fixes. I'm not that savvy on that side of things to know what I would need to check.
EDIT: I should add that I'm using a Official Mesa release 21.3.1 built from source.
UPDATE: I just put back the Imgui frame counter from the demo code and I see that in the CLI/kmsdrm I'm rendering at ~109 fps, or quite possibly whatever speed it can. This was the same on Buster but maybe if I can tell SDL/OpenGL to limit to 60fps I would be ok.
Although according to manuals 'SDL_RenderPresent(sdl_renderer);' is meant to wait for monitor vsync refresh before draw flipping so I'm not sure why that's not happening in the first place.
UPDATE2: Nah I don't think that solved it. I tried doing that through SDL and cot a refresh clamp for around 60fps but no difference in vsync glitching.
easy kmsdrm rendering (no x11, CLI screen)
I know full KMS (vc4-kms-v3d) was in beta for several years and it's only just now that they're making it the default. It may be you've stumbled upon a remaining bug in it since this is a somewhat unusual setup.
If I were you, I'd try to repro the glitches with a simple Hello Triangle app (with some added animation of course) to try and narrow down whether this is fundamental or coming from a specific pattern in Dear ImGui.
Failed to initialize OpenGL loader!
Now knowing about the kmsdrm rendering: You might be seeing this because you aren't using X11. Dear ImGui's loader uses glXGetProcAddressARB from libGL which my understanding is an X-specific thing. More details here: https://github.com/ocornut/imgui/issues/4810
You might try manually applying @ShadowNinja's gl3w patch to Dear ImGui's loader or modify it to use SDL_GL_GetProcAddress.
Hi and thanks again for the suggestions! I'll take a look at the gl3w work that's beeing done. But I think my first thing will be to try figure out what my kmsdrm render/render-init does that fixes the issue, as there's so many potential areas to look but that is a pretty good lead. I will make a little video today after work and then I'll take that to the Raspberry forums as I think they have some people who know a bit about the kmsdrm side of things. I'll put the video here too as seeing it in action might prompt some 'aha!'
Here's the video. Sorry its slightly dark. The glitching happens on the whole bottom of the screen not just over the yellow. Note also the change on frame rate / sync as you cat tell by the text at the top edge.
This shows the Imgui+SDL GUI glitching at startup. Then I switch to the more custom kmsdrm video display. The I return and the glitching has disappeared. And the frame rate is locked to 60hz.
https://www.youtube.com/watch?v=9p7AUBnokAk
A strange thing is that I tried taking the SD card from the Pi4b and use it with my Pi Zero2W. Booting from that and running the program exactly the same. And on the Zero2W the sync glitching does not happen. It's like the display hardware interfaces with the software and producing different display modes. Or something.
I figured out what to do! :) I could use some of SDL's display functions for listing and choosing display modes. I believe these are called 'crtc's' in kmsdrm parlour? Not sure if they completely map from SDL to kmsdrm 1:1 but in my case it seemed to work to just set in SDL on app startup. And I have a monitor with the somewhat uncommon 1920x1200 res.
I was surprised to see that the X11 mode was RGB and the tty/CLI screen was ARGB. I still don't understand why the Pi4b and the Zero2W behaved differently?
Cheers!
I almost wonder if it's swapping the buffers but not waiting for vsync so the back buffer is being scanned out while you're still rendering to it. If it was just normal tearing I wouldn't expect things to disappear entirely.
I still don't understand why the Pi4b and the Zero2W behaved differently?
The Zero2W is basically a tiny Pi 3, so it's not quite the same hardware. I wouldn't be surprised if you've found a bug in the driver specific to the VideoCore VI.
Did you end up posting your video on the Raspberry Pi forums?
Yes I did you can see here but no exciting replies yet,
https://forums.raspberrypi.com/viewtopic.php?p=1980245#p1980245
To anyone else seeing this issue, setting MESA_GL_VERSION_OVERRIDE=3.3 before running the app works.
However, editing the Makefile to use OpenGL ES will get it to run without requiring a variable to be set.
