Path to making bgfx default
It would be good to get to a point where we can make BGFX the default render module, at least on Windows where Direct3D 9 is very much on life support, and on macOS where Metal support has been pretty important for quite a while now. With #10858 merged, a lot of corner cases should be fixed, and at least for emulated systems with raster screens, there should be no more need to use legacy Direct3D with HLSL. This issue is for identifying and tracking things that need to be fixed before BGFX can become the default render module.
Please report problems encountered during testing here.
~~Crash on saving slider state after toggling fullscreen~~
~~The render objects are desctroyed and recreated when toggling fullscreen. A proxy object is needed to handle the configuration load/save callbacks to get around this issue.~~
~~Settings lost on toggling fullscreen~~
~~Only the active screen chains are saved on toggling fullscreen, other settings are lost. It should be possible to rope the configuration load/save hooks into service for this, which ties in with the previous point.~~
Some Konami GX games not showing video with Vulkan backend
Some Konami GX games show no video (black screen) with -bgfx_backend vulkan on Windows or Linux, and may crash on Linux. Most backends don’t seem to be affected (opengl, d3d9, d3d11, d3d12 all work). Reproduced with NVIDIA GeForce using consumer GeForce driver on Windows and NVIDIA proprietary driver on Linux. Affected systems include daiskiss and sexyparo. See #10815.
Font textures sized for most recently resized window rather than window showing UI
The easiest way to demonstrate this is with two windows – the system doesn’t matter, pacman is just an example:
- Run
mame -window -numscreens 2 -skip_gameinfo pacman - Rearrange the windows so you can see both of them
- Hit Tab to show the menu on the first window
- Make the second window (the one not showing the menu) as small as possible
- The menu text in the first window will appear as though it’s been downsampled for the second window’s new size
- If you resize the first window, the text will be adjusted for its new size
The issue is that the font textures seem to be sized for the most recently resized window, not the window displaying the UI container.
Maximum prescaled texture size weirdness
The chain manager sets its maximum prescaled screen texture size m_max_prescale_size based on the initial window size and never updates it. However, based on testing it seems that the actual prescaled texture sizes are not what one would expect when the initial window size is small.
I’ll look at the config crash myself. There’s a bit of a fundamental problem at the moment in that render modules aren’t actually OSD modules in the same sense as the other OSD modules. There’s just a static function that knows about all possible renderer classes. It might be time to bite the bullet and change that. It would make several things simpler.
I've already told moogly about these, they're not regressions:
- flickering when resizing by dragging window edge (may be minor, unless you are sensitive to it such as people with epilepsy)
- very slow on d3d12 and vulkan backends with games that have lots of artwork elements (eg. mm2, mbaseb)
The window resizing works fine on linux for me with this update fwiw. I have always had issues with the full screen toggle not working so thats not a regression either.
Thanks for making this thread, Vas.
I'll have a look at the slowness with D3D12 and Vulkan first, I suspect there's a significant amount of overhead due to MAME's whole rendering architecture assuming immediate mode. It's very likely that there might not be much I can do about it in the immediate term, but I can try to identify any low-hanging fruit that exists.
Oh, I should mention it here and add it to the description. There’s still the font texture atlas optimisation weirdness with two windows.
BGFX fullscreen toggle has been broken for a while on the Mac with the Metal backend. I'm unclear if this is our fault or BGFX's. Here's the dump macOS gives, it appears to be a use-after-free.
VM Region Info: 0x7f190f4a8168 is not in any region. Bytes after previous region: 16600165667177 Bytes before following region: 786300239512 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL Stack 700008481000-700008503000 [ 520K] rw-/rwx SM=PRV thread 10 ---> GAP OF 0xfd01a1fd000 BYTES MALLOC_TINY 7fd022700000-7fd022800000 [ 1024K] rw-/rwx SM=PRV
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7ff810f54e1d objc_msgSend + 29 1 mame 0x10bba3aea bgfx::mtl::SwapChainMtl::init(void*) + 714 2 mame 0x10bba9c07 bgfx::mtl::RendererContextMtl::updateResolution(bgfx::Resolution const&) + 199 3 mame 0x10bba577a bgfx::mtl::RendererContextMtl::submit(bgfx::Frame*, bgfx::ClearQuad&, bgfx::TextVideoMemBlitter&) + 394 4 mame 0x10bb6a0b0 bgfx::Context::renderFrame(int) + 160 5 mame 0x10bb69e8e bgfx::Context::swap() + 398 6 mame 0x10bb686e5 bgfx::Context::frame(bool) + 197 7 mame 0x10b6fb351 renderer_bgfx::draw(int) + 1537
I've found issues with the screen curvatures at the corners.
mame -norc -rompath Z:\Mame\roms -window -video bgfx -bgfx_backend auto -bgfx_screen_chains crt-geom sf2ce

I've found issues with the screen curvatures at the corners.
Tested on linux can reproduce on before and after when tinkering with window sizes to make it happen. Fullscreen and maximum window is fine though
Toggle fullscreen to window (and vice-versa) with BGFX on Debian, makes mame crash, it doesn't happen if -video opengl.
mametiny -norc -rompath Z:\Mame\roms -nowindow -video bgfx -bgfx_backend auto -bgfx_screen_chains crt-geom wrally
Error:
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 149 (GLX)
Minor opcode of failed request: 0 ()
Resource id in failed request: 0x1600011
Serial number of failed request: 1191
Current serial number in output stream: 1191
Full AddressSanitizer log with -video bgfx:
video_bgfx.txt
Full AddressSanitizer log with -video opengl (no crash)
video_opengl.txt
In sdl_window_info::toggle_full_screen the window and renderer are destroyed and recreated. That's overkill and probably causing the problem. A simple resize should work.
El mar, 31 ene 2023 a las 12:43, cd4053 @.***>) escribió:
Toggle fullscreen to window (and vice-versa) with BGFX on Debian, makes mame crash, it doesn't happen if -video opengl.
mametiny -norc -rompath Z:\Mame\roms -nowindow -video bgfx -bgfx_backend auto -bgfx_screen_chains crt-geom wrally
Error:
X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 0 () Resource id in failed request: 0x1600011 Serial number of failed request: 1191 Current serial number in output stream: 1191
Full AddressSanitizer log with -video bgfx: video_bgfx.txt https://github.com/mamedev/mame/files/10545907/video_bgfx.txt
Full AddressSanitizer log with -video opengl (no crash) video_opengl.txt https://github.com/mamedev/mame/files/10545930/video_opengl.txt
— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/10859#issuecomment-1410208017, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAMAEIOTZLRSSU2CLV4JDDWVD3HBANCNFSM6AAAAAAUJ2EUQM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The renderer is torn down and recreated on Windows, too, without this issue. The issue on Linux specifically arises from recreating the renderer prior to the window itself having been recreated.
Let's stick to reporting issues, and leave the actual triage and fixes to those of us who are actually equipped to fix them.
2810c9d91bfaee4d833b3c6dc03672799053f702 fixes the configuration persistence issues (both crashing on exit after toggling fullscreen and persisting most settings across a fullscreen toggle).
Not tearing down windows when toggling fullscreen isn’t always an option. There are a few avenues to investigate for addressing the issue of BGFX having its primary window stolen from under it.
AddressSanitizer log from commit https://github.com/mamedev/mame/commit/2810c9d91bfaee4d833b3c6dc03672799053f702.
It doesn't display a BadWindow error anymore.
video_bgfx2.txt
MAME used to crash on Mac for unclean exits (fatalerror()) and the like. With the latest it crashes on clean exits too (pressing Esc).
0 mame 0x11132b0c8 texture_manager::~texture_manager() + 88 1 mame 0x11133a6c9 renderer_bgfx::~renderer_bgfx() + 969 2 mame 0x11133a85e renderer_bgfx::~renderer_bgfx() + 14 3 mame 0x1112e2a64 osd_common_t::osd_exit() + 68 4 mame 0x11137bd59 sdl_osd_interface::osd_exit() + 9
MAME used to crash on Mac for unclean exits (fatalerror()) and the like. With the latest it crashes on clean exits too (pressing Esc).
That shouldn’t be happening. I intentionally destroy the renderers before shutting down the module and destroying the windows in an effort to avoid exactly this (see here). Going to need more information:
- Windowed or fullscreen, and have you toggled fullscreen at any point?
- Do
-video opengland-video accelstill work? - Can you post disassembly of
texture_manager::~texture_manager()in the specific build the stack trace comes from so I can see what it’s actually doing when it crashes?
Linux is having the same behavior segfault on clean exit and a segfault on full screen toggle it used to just freeze up or say bad window depending if you started with -window or not but the clean exit segfault is new. Everything works fine on -video opengl
There’s an object lifecycle issue with texture providers. I’ll try and sort that out tonight.
47aa6fd60d6b1aca920f4c49175752d8124ed689 should fix leaked and double-freed textures. Target manager textures are owned by the target manager, all other textures are owned by the texture manager. You need to explicitly supply a reference or smart pointer when adding a texture to the texture manager depending on whether you will delete it yourself or let the texture manager delete it when it’s removed (or on destruction).
f408dd83e27fb106ed60b66eafebc4015040bf26 fixes crash on toggling fullscreen on Linux (and maybe Mac if we’re lucky).
For some reason slider settings don’t save/restore properly on Linux at the moment. I’ll look into it.
Fix https://github.com/mamedev/mame/commit/f408dd83e27fb106ed60b66eafebc4015040bf26 confirmed, thank you @cuavas.
Fullscreen toggle works on Mac, and exiting no longer crashes. Thanks!
6ff51387fa39a3a1b2a178b16ffcd687445dae83 fixes the config issues I was having.
If you want your chain selections to be saved/restored automatically per-system, don’t put bgfx_screen_chains in your mame.ini or set it to an empty string.
Fullscreen toggle and exit works fine on linux as well with both opengl and vulkan bgfx backends. The issues of shaders crashing when scrolling through is fixed as well. I always have had and was given the impression it was it was mesa issues. This for me is a big update in usability the kind of quality fixes often get left thankless.
Is Linux Wayland support a thing BGFX upstream need to do, or a task for MAME?
At this point, I really don’t care about supporting Wayland in MAME besides via X11 compatibility. It’s more trouble than it’s worth for us.
Thanks for the work with improving the BGFX support in MAME!
I've been building MAME with emscripten (wasm) every now and then for the last years out of curiosity but haven't been able to get BGFX working with emscripten since somewhere around MAME 0.236 using emscripten 2.0.23. However, building later versions of MAME with later emscripten versions has been working well as long as BGFX isn't used.
There is however an issue with building MAME with emscripten from master now, the compile fails with the following errors:
Compiling src/osd/modules/render/drawbgfx.cpp...
../../../../../src/osd/modules/render/drawbgfx.cpp:416:2: error: "Unsupported BX platform"
#error "Unsupported BX platform"
^
In file included from ../../../../../src/osd/modules/render/drawbgfx.cpp:9:
../../../../../src/osd/modules/render/drawbgfx.h:143:11: error: private field 'm_view_width' is not used [-Werror,-Wunused-private-field]
uint16_t m_view_width;
^
../../../../../src/osd/modules/render/drawbgfx.h:144:11: error: private field 'm_view_height' is not used [-Werror,-Wunused-private-field]
uint16_t m_view_height;
^
3 errors generated.
The error occurs using the latest mame src (28fce32e875fa7e1fc3a73218e3759b88915db6e) and emscripten 3.1.24.
The build issue can be reproduced by:
- Checking out the latest source
- In the source dir, execute:
(replacedocker run --rm -ti -v $PWD:/src emscripten/emsdk:3.1.24 emmake make -j 1 SUBTARGET=arcade SOURCES=src/mame/capcom/cps1.cpp WEBASSEMBLY=1 PYTHON_EXECUTABLE=python3 OPTIMIZE=3 ARCHOPTS=-Wno-unused-command-line-argument -Wno-error=unused-command-line-argument -s MAX_WEBGL_VERSION=2 -s LEGACY_GL_EMULATION=1 -s WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION=1 ARCHOPTS_CXX=-Wno-unused-but-set-variable -Wno-unused-command-line-argument -Wno-c++11-narrowing -Wno-deprecated-declarations -s -Wno-unused-variable -Wno-error-j 1with-j $(nproc)for faster compilation)
It would be awesome to be able to again get BGFX working in emscripten builds but that might require some more work in MAME or BGFX but to at least get the emscripten work at all would be good enough :)
Well it needs to supply whatever BGFX wants as the window identifier in the platform data there. Maybe the reason it didn't work is that whichever path it was previously defaulting to (probably X11) didn't actually work with Emscripten, so BGFX was trying to use an invalid "window".
b9c878e6271b73e2b8751fa4efbd8a5d905b42ae checks the window manager type returned by SDL rather than making an assumption at compile time. I expect it still won’t actually work with Emscripten.
For some reason, some Konami GX games don’t show video with -bgfx_backend vulkan and may crash on Linux, see #10815. Affected games include daskiss and sexyparo.
On cubeqst I cannot get the overlay graphics to use the Fighters chain and the LD content to use 'none' at the same time.
mame cubeqst -norc -video bgfx -bgfx_screen_chains none,Fighters -rompath roms;d:\chds
Some LD content is trying to play in the far left columns of the screen (the logo appearance). Happens in cliffhgr too.
0.251 (mame0251-334-g519554c8464) Windows 11 x64 22621.1194 2560x1440 Monitor Res.
- Launch Mame w/ parameters above taking existing mame.ini out of the mix w/ -norc.
- Observe Fighters chain on intro text.
- Observe no LD content playing behind the overlay graphics.
Question: Should the LD games default their LD content to 'none' for the cleanest presentation if a screen0 or screen1 chain is not specifically called out?