Update bgfx, bx and bimg to current upstream versions

[belegdol]

Update to the libraries to current upstreams:

• bgfx to c18122226e9bce55b19cae5bc630e4f25e360e1e
• bx to 198cd120e4941d8aeb677db945ef4291a1ced291
• bimg to ec02df824a763b2e2ae31e19c674ba0bc88c0695

This is needed by #11451.

[belegdol]

It unfortunately appears that the PR does not fix the build failure we are hitting (XCode 14 building for macOS). So waiting is the only option at the moment.

[belegdol]

Since there was no progress on the upstream PR and further upstream commits have worsened the pre-macOS 13 situation further, I have decided to revert the offending commits myself. I also added a README file explaining the deviations so that these reverts can be undone once we no longer care for pre-Ventura.
Please note that I have no way of testing macOS myself.

[cuavas]

@rb6502 should I merge this? Will you be able to test macOS with the OpenGL and Metal backends?

[cuavas]

On Windows, most things work as well as they did previously. The main things that are wonky are:

• None of the xBR Multipass chains seem to work with any backend. They all produce a black screen.
• None of the xBR chains work properly with the opengl backend. Most of them produce a black screen or a monochrome image.
• Attempting to use the xBR-mlv4 Multipass + Dilation chain with the d3d12 or vulkan backend freezes my PC so had I need to hold down the power button to turn it off – no response to any other input. I think this is worse than previous versions of bgfx, IIRC I could run through all the chains in the past and the worst thing that happened was bad video.

[belegdol]

On Windows, most things work as well as they did previously. The main things that are wonky are:

* None of the xBR Multipass chains seem to work with any backend.  They all produce a black screen.

* None of the xBR chains work properly with the `opengl` backend.  Most of them produce a black screen or a monochrome image.

* Attempting to use the xBR-mlv4 Multipass + Dilation chain with the `d3d12` or `vulkan` backend freezes my PC so had I need to hold down the power button to turn it off – no response to any other input.  I think this is worse than previous versions of bgfx, IIRC I could run through all the chains in the past and the worst thing that happened was bad video.

Thank you for testing. This is unfortunate. I am travelling this week so I will not be able to check this. Truth be told, shader code is black magic to me so if this is an unacceptable regression we might need to revert.

[cuavas]

@angelosa is reporting crashes on Ubuntu Linux with default configuration:

   from /lib/x86_64-linux-gnu/libnvidia-glcore.so.470.199.02
(gdb) bt
#0  0x00007ffff13008b7 in ?? ()
   from /lib/x86_64-linux-gnu/libnvidia-glcore.so.470.199.02
#1  0x000055556630af5b in bgfx::vk::RendererContextVK::submit(bgfx::Frame*, bgfx::ClearQuad&, bgfx::TextVideoMemBlitter&) ()
#2  0x000055556628e2d5 in bgfx::Context::renderFrame(int) ()
#3  0x00005555662984ca in bgfx::Context::renderThread(bx::Thread*, void*) ()
#4  0x00005555663a5493 in bx::ThreadInternal::threadFunc(void*) ()
#5  0x00007ffff7e38609 in start_thread (arg=<optimized out>)
    at pthread_create.c:477
#6  0x00007ffff64c2133 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

It appears to be using Vulkan by default with NVIDIA binary drivers. He also said that using -bgfx_backend opengl results in a segmentation fault on exit.

I can remove the xBR Multipass shaders if that’s the only major problem, but crashes on Linux are somewhat concerning.

[belegdol]

Crashes I can look into next week. Which videodriver and x11 or Wayland session?

[cuavas]

Since the major motivation for this is to support Wayland on Linux if it’s crashy on Linux it defeats the whole purpose.

[belegdol]

Since the major motivation for this is to support Wayland on Linux if it’s crashy on Linux it defeats the whole purpose.

I wholeheartedly agree. I did test it on both Nvidia binary driver and on open source Radeon and didn't see crashes. But if there are issues with different configurations then we should delay these changes at least.

ETA: I did test with 535.xx driver though whereas the crash appears to be with 470.xx. One of the changes which made Wayland possible was ditching GLX and using EGL for both X11 and Wayland. I still have and old laptop running Fedora 37 and 470.xx driver so I can check how it fares once I am back.
It might be tight for the September release though so please feel free to revert and we can revisit in October. Apologies for the trouble.

[angelosa]

He also said that using -bgfx_backend opengl results in a segmentation fault on exit.

With MAME symbols build (?), on application exit (including on MAME info/nag screens) and -verbose:

No more renderers - shutting down BGFX library

Thread 2 "decosym" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeca9a700 (LWP 197320)]
0x00007fffec28aa60 in ?? ()
(gdb) bt
#0  0x00007fffec28aa60 in ?? ()
#1  0x00007ffff7e375a1 in __nptl_deallocate_tsd () at pthread_create.c:301
#2  0x00007ffff7e3862a in __nptl_deallocate_tsd () at pthread_create.c:256
#3  start_thread (arg=<optimized out>) at pthread_create.c:488
#4  0x00007ffff64c2133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

#
# CORE SCREEN OPTIONS
#
brightness                0.95
contrast                  1.0
gamma                     0.95
pause_brightness          0.65
effect                    none
video                     bgfx
numscreens                1
window                    1
maximize                  1
waitvsync                 0
syncrefresh               0
monitorprovider           auto

# BGFX POST-PROCESSING OPTIONS
#
bgfx_path                 bgfx
bgfx_backend              opengl
bgfx_debug                0
bgfx_screen_chains        unfiltered
bgfx_shadow_mask          slot-mask.png
bgfx_lut                  
bgfx_avi_name             auto

#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture       0
gl_notexturerect          0
gl_vbo                    1
gl_pbo                    1
gl_glsl                   0
gl_glsl_filter            1

Using standard Ubuntu 20.04 nVidia driver metapackage from nvidia-driver-470 for a GK208B GeForce GT 710

[MistyDreams]

Im not getting a segfault with manjaro linux ./mamed rygar -video bgfx -bgfx_backend opengl. Is there a specific game that I should be testing?

Also make sure to use the latest bgfx folders contents. Ill test on another machine with radeon drivers as im using the built in intel on this machine. I did do an asan build as well and there is a shed load of memory leaks I wont paste that here unless its wanted.

SUMMARY: AddressSanitizer: 16254 byte(s) leaked in 586 allocation(s).

[rb6502]

This looks good on my Mac running the latest Sonoma beta, with both OpenGL and Metal backends. It's probably going to break my unofficial patch that re-enabled back compatibility to 10.13 though, which as I noted earlier I promised we wouldn't do before January.

[cuavas]

If this can't be patched to work on macOS 10.13, or it's too crashy on Ubuntu-like Linux distros, I'll just revert it. Otherwise I'll remove the xBR Multipass chains.

[belegdol]

Given the plethora of issues with this update: would it be worth cherry-picking the minimum number of patches needed to get Wayland working? We would still end up with bgfx divergent from upstream but it seems less problematic than syncing with upstream and then reverting a bunch of commits.

[cuavas]

Given the plethora of issues with this update: would it be worth cherry-picking the minimum number of patches needed to get Wayland working?

I don’t know how practical that would be, given how much code churn there seems to be on upstream bgfx.

[belegdol]

Given the plethora of issues with this update: would it be worth cherry-picking the minimum number of patches needed to get Wayland working?

I don’t know how practical that would be, given how much code churn there seems to be on upstream bgfx.

Let me see next week, maybe it will work. For now please feel free to revert.