mamedev
[BGFX] Palette problems when an Screen Effect other than NONE is set
MAME version
Git version 02fc472f18a89761c7c4b9add8cd469bb1c609fc
System information
GNU/Linux Debian 13, Mesa latest stable version 25.1.6 CPU: Ryzen 7 8700G, GPU: Radeon 780M, 32GB RAM Labwb Wayland compositor, latest stable version 0.9.0
INI configuration details
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
homepath .
rompath roms
hashpath hash
samplepath samples
artpath artwork
ctrlrpath ctrlr
inipath $HOME/.mame;.;ini
fontpath .
cheatpath cheat
crosshairpath crosshair
pluginspath plugins
languagepath language
swpath software
#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg
nvram_directory nvram
input_directory inp
state_directory sta
snapshot_directory snap
diff_directory diff
comment_directory comments
share_directory share
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
rewind 0
rewind_capacity 100
playback
record
exit_after_playback 0
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview auto
snapbilinear 1
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
sleep 1
speed 1.0
refreshspeed 0
lowlatency 0
#
# CORE RENDER OPTIONS
#
keepaspect 1
unevenstretch 1
unevenstretchx 0
unevenstretchy 0
autostretchxy 0
intoverscan 0
intscalex 0
intscaley 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 0
fallback_artwork
override_artwork
#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.65
effect none
#
# CORE VECTOR OPTIONS
#
beam_width_min 1.0
beam_width_max 1.0
beam_dot_size 1.0
beam_intensity_weight 0
flicker 0
#
# CORE SOUND OPTIONS
#
samplerate 48000
samples 1
volume 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.15
joystick_saturation 0.85
joystick_threshold 0.3
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device keyboard
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
verbose 0
log 0
oslog 0
debug 0
update_in_pause 0
debugscript
debuglog 0
#
# CORE COMM OPTIONS
#
comm_localhost 0.0.0.0
comm_localport 15112
comm_remotehost 127.0.0.1
comm_remoteport 15112
comm_framesync 0
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
drc_log_uml 0
drc_log_native 0
bios
cheat 0
skip_gameinfo 1
uifont "DejaVu Sans|Book"
ui cabinet
ramsize
confirm_quit 0
ui_mouse 0
language
nvram_save 1
#
# SCRIPTING OPTIONS
#
autoboot_command
autoboot_delay 0
autoboot_script
console 0
plugins 1
plugin
noplugin
#
# HTTP SERVER OPTIONS
#
http 0
http_port 8080
http_root web
#
# OSD INPUT MAPPING OPTIONS
#
uimodekey auto
controller_map none
background_input 0
#
# OSD FONT OPTIONS
#
uifontprovider auto
#
# OSD OUTPUT OPTIONS
#
output auto
#
# OSD INPUT OPTIONS
#
keyboardprovider auto
mouseprovider auto
lightgunprovider auto
joystickprovider auto
#
# OSD DEBUGGING OPTIONS
#
debugger auto
debugger_host localhost
debugger_port 23946
debugger_font auto
debugger_font_size 0
watchdog 0
#
# OSD PERFORMANCE OPTIONS
#
numprocessors auto
bench 0
#
# OSD VIDEO OPTIONS
#
video bgfx
numscreens 1
window 0
maximize 1
waitvsync 1
syncrefresh 0
monitorprovider auto
#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution auto
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto
#
# OSD FULL SCREEN OPTIONS
#
switchres 0
#
# OSD ACCELERATED VIDEO OPTIONS
#
filter 1
prescale 1
#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture 0
gl_notexturerect 0
gl_vbo 1
gl_pbo 1
gl_glsl 1
gl_glsl_filter 1
glsl_shader_mame0 none
glsl_shader_mame1 none
glsl_shader_mame2 none
glsl_shader_mame3 none
glsl_shader_mame4 none
glsl_shader_mame5 none
glsl_shader_mame6 none
glsl_shader_mame7 none
glsl_shader_mame8 none
glsl_shader_mame9 none
glsl_shader_screen0 none
glsl_shader_screen1 none
glsl_shader_screen2 none
glsl_shader_screen3 none
glsl_shader_screen4 none
glsl_shader_screen5 none
glsl_shader_screen6 none
glsl_shader_screen7 none
glsl_shader_screen8 none
glsl_shader_screen9 none
#
# OSD SOUND OPTIONS
#
sound auto
audio_latency 2
#
# OSD MIDI OPTIONS
#
midiprovider auto
#
# OSD EMULATED NETWORKING OPTIONS
#
networkprovider auto
#
# BGFX POST-PROCESSING OPTIONS
#
bgfx_path bgfx
bgfx_backend vulkan
bgfx_debug 0
bgfx_screen_chains
bgfx_shadow_mask slot-mask.png
bgfx_lut lut-default.png
bgfx_avi_name auto
#
# SDL PERFORMANCE OPTIONS
#
sdlvideofps 0
#
# SDL VIDEO OPTIONS
#
centerh 1
centerv 1
scalemode none
#
# SDL KEYBOARD MAPPING
#
keymap 0
keymap_file keymap.dat
#
# SDL INPUT OPTIONS
#
enable_touch 0
sixaxis 0
dual_lightgun 0
#
# SDL LOW-LEVEL DRIVER OPTIONS
#
videodriver auto
renderdriver auto
audiodriver auto
gl_lib auto
Emulated system/software
cninja.cpp, but there may be others
Incorrect behaviour
Some colors are wrong when BGFX Video Mode is selected and a Window effect other than NONE is selected. Both BGFX backends (Vulkan and OpenGL) show the same problem.
Look at the eyes of the dinossaur box on 1st stage:
Look at the colors in the outer pixels of the giant carnivore plant on 2nd stage:
Expected behaviour
The colors should be correct. This is what they look with a Video Mode other than BGFX:
Steps to reproduce
- Configure MAME to use the BGFX Video Mode
- Start cninja with
mame cninja - Play and observe the game.
Additional details
I don't quite know if this is a MAME bug or a MESA bug, to be honest, but maybe someone could test MAME on different graphics on current stable MESA and try to reproduce?
I notice a similar issues on the pi5 which also runs debian. The game I had issues with is shinobi you can see the title screen the masks are off in anything other than Screen Effect other than NONE. There was a few games that done this and its not something new I just put it down to an arm issue of some sort, or a side effect of me cross compiling the pi binary on a x64 with clang using the sysroot. I have no issues with x64 using manjaro linux. Both are running on Wayland. I just use opengl driver instead of bgfx on the pi.
I took this to the MESA devs here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13555
Look at the last response by one of the AMD driver devs:
I could reproduce the issue. Few things I noticed:
the a4b71e5b commit enabled a behavior that was turned off by default (running with radeonsi_fp16=true on the previous commit would trigger the issue). replacing all the lowp vec4 tmpvar_ by highp vec4 tmpvar_ in the FS_b1b64d412e68f3584767fd7ac0a454ee1a52d102e41db64f9116ce54effc5005.glsl shader fixes the issue always returning GLSL_PRECISION_HIGH from find_lowerable_rvalues_visitor::visit_leave(ir_call *ir) fixes the issue
I'm not sure if it's really a Mesa bug or an with the shader usage of lowp.
Can you please give some input here from the MAME side of things?
@cuavas Can you please point me to the sources of the bgfx shaders? They are distributed in binary format only, even with the MAME sources, and I'd like to do some tests to find out what's happening here.
In order to avoid further questions :) https://github.com/mamedev/mame/blob/master/.github/workflows/bgfxshaders.yml
In order to avoid further questions :) https://github.com/mamedev/mame/blob/master/.github/workflows/bgfxshaders.yml
Thanks for pointing that out :)
Do you happen to know how to force high precision for the fragment shader?
I'm trying to force it in src/osd/modules/render/bgfx/shaders/chains/crt-geom/crt-geom_common.sc to no avail... it errors out on me with:
Error: (430,11): error: syntax error, unexpected FLOAT_TOK, expecting LOWP or MEDIUMP or HIGHP
It seems that BGFX shaders are written in some "dialect" that don't allow setting precision easily... and this bug may be related to precision. Any ideas, please?
Sorry, my whole knowlage about shaders summirized in the previous comment. Hopefully somebody else will give you a hand.
Sorry, my experience writing shaders pretty much stopped with OpenGL 3 – I’ve never tried to understand the BGFX shader language. Maybe @MooglyGuy knows? This looks like it could be a relatively easy fix if someone knows how to specify this in the BGFX shader language.
Hm, it can't be hard to specify something like precision on the BGFX shader language... Is there a manual for that language, please? I can't see any documentation for it online regarding precision.
Maybe precision is specified at shader build time somehow?
Also, am I the only person using MAME on MESA3D with AMD graphics? Someone else must be seeing these artifacts.
I have the same issues on the raspberry pi 5 so there is plenty of scope for testing quite a few of them floating about. I dont have these issues with amd but its an oder amd card will do a lspci for the gfx card im using that doesnt have this issue. Its worth noting im using manjaro linux that doesnt have the issues with amd.
I have the same issues on the raspberry pi 5 so there is plenty of scope for testing quite a few of them floating about. I dont have these issues with amd but its an oder amd card will do a lspci for the gfx card im using that doesnt have this issue. Its worth noting im using manjaro linux that doesnt have the issues with amd.
On AMD, it started to happen with recent versions of MESA: so it will appear eventually on any distro as they update to recent MESA.
Good to know that VideoCore (Raspberry Pi 5) is also affected by this issue: it could be widespread among video hardware using recent MESA by now.
glxinfo | grep "Mesa"
client glx vendor string: Mesa Project and SGI OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.2.1-arch1.4 OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.1-arch1.4 OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.2.1-arch1.4
after todays update client glx vendor string: Mesa Project and SGI OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.2.3-arch1.2 OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.3-arch1.2 OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.2.3-arch1.2
both of these versions are working fine on Manjaro.
lspci info 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev c7)
@grant2258 What do you mean with working fine? Have you tried BGFX and looked for the mentioned defects in cninja?
@vanfanel Yes cninja and shinobi title screen are fine with manjaro just ran cninja again too double check it happens on the pi but not on the x64 machine for me.
@vanfanel Yes cninja and shinobi title screen are fine with manjaro just ran cninja again too double check it happens on the pi but not on the x64 machine for me.
Can you try with SDL_VIDEODRIVER=wayland mame <game_name>, please? The graphics stack shouldn't be at play here, but who knows.
You use GLX and I use Vulkan on Wayland.
Folks, if you believe this to be a bug in Mesa, kindly take it up with the Mesa developers at this point.
Based on the response from the Mesa developers, I would argue that this is in fact a Mesa issue, as it does not present on other backends, and seems highly architecture-dependent.
I would be happy to implement a work-around on a shader level, but to my knowledge, BGFX's shaderc does not allow precision specifiers within fragment-shader code, or at least I have been unable to find any examples or documentation of this. @bkaradzic himself closed an issue from 2019, in 2022, regarding this exact problem, as "completed" without further comment, so the ball is very much in his court as to whether it's even possible to address this issue by adjusting the BGFX shaders that MAME employs. https://github.com/bkaradzic/bgfx/issues/1770
@MooglyGuy Thanks for your answer, seems pretty logical. I already brought the issue to the MESA devs here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13555
But now that it's clearly a MESA issue, I will reach them again in that issue thread.
@MooglyGuy Thanks for your answer, seems pretty logical. I already brought the issue to the MESA devs here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13555
But now that it's clearly a MESA issue, I will reach them again in that issue thread.
Thanks. I wouldn't necessarily say that it's "clearly" a MESA issue, but when it comes to differences in renderer behavior, I tend towards a common-vote attitude: If their implementation of anything less than high precision differs from the defaults from other vendors and APIs, then they should probably persist the shared behavior of other platforms and APIs.
SDL_VIDEODRIVER=wayland mame cninja SDL_VIDEODRIVER=wayland mame cninja -video bgfx -bgfx_backend vulkan SDL_VIDEODRIVER=wayland mame cninja -video bgfx -bgfx_backend gles SDL_VIDEODRIVER=wayland mame cninja -video bgfx -bgfx_backend opengl
All work fine in the manjaro linux machine hope I covered all options you where looking for.
@grant2258 Yes, thanks!
@MooglyGuy MESA people say it's not so clear that it's a bug either...
From the issue thread in https://gitlab.freedesktop.org/mesa/mesa/-/issues/13555#note_3117765:
Why has it become clear? If anything that issue is evidence that the precision qualifiers are not correctly set.
Again, precision qualifiers should be possible on the BGFX shaders?
EDIT: Answering my own self: it seems that @bkaradzic has again noted the issue on precision qualifiers as "not planned" today in https://github.com/bkaradzic/bgfx/issues/1770 Wow, then this is un-fixable I guess :( I can do my own MESA builds with a workaround, but sooner or later this will affect more people?
@vanfanel With all due respect, I agree that it's a bug on someone's end, but it is absolutely not on the MAME team's end.
At the end of the day, everyone but the Mesa team appears to be in unison when it comes to how precision should be handled when not otherwise specified.
BGFX does not appear to offer any facility for specifying precision for fragment-shader variables.
Thus this comes down to an argument between the Mesa team and @bkaradzic. Branimir can implement - or document - a way of specifying precision for temporaries rather than having shaderc strip them, or the Mesa team can put egos aside and do the same as literally every other vendor and API.
Either way, this is not a MAME issue, and I would encourage both @cuavas and @galibert to close the issue as such. MAME might expose this issue in 3rd-party software, but I have yet to see a cogent argument that this is any fashion our fault.
@MooglyGuy
It would be great if you tell me what bgfx would have to do to fix this. I would expect that GLSL default is highp. Therefore there should not be precision issue.
Anyhow the best way forward is to create issue on bgfx, with simple repro (by modifying existing example).
Allowing precision specificers for temporaries in fragment shaders sounds like functionality that should just plain work, but I'm curious to know how 'lowp' specifiers are creeping into the fragment-shader GLSL during processing by shaderc, as described here - https://github.com/mamedev/mame/issues/14022#issuecomment-3246687320 - as the source .sc does not, itself, contain any precision specifiers.
Just to make sure we're on the same page, this is GLSL issue, not ESSL?
In GLSL they exist just for compatibility with ESSL:
Note: Precision qualifiers in GLSL are supported for compatibility with OpenGL ES. They use the same syntax as ES's qualifiers, but they have no functional effects. Do not use them unless you want your shaders to be ES compatible.
https://wikis.khronos.org/opengl/Type_Qualifier_(GLSL)#Precision_qualifiers
If you're compiling ESSL shaders with shaderc, and using them in OpenGL as GLSL shaders that would be the issue.
Just to make sure we're on the same page, this is GLSL issue, not ESSL?
In GLSL they exist just for compatibility with ESSL:
Note: Precision qualifiers in GLSL are supported for compatibility with OpenGL ES. They use the same syntax as ES's qualifiers, but they have no functional effects. Do not use them unless you want your shaders to be ES compatible.
https://wikis.khronos.org/opengl/Type_Qualifier_(GLSL)#Precision_qualifiers
If you're compiling ESSL shaders with shaderc, and using them in OpenGL as GLSL shaders that would be the issue.
Well, I am seeing these glitches on both Vulkan an OpenGL, if that helps.
@MooglyGuy In defense of us Mesa devs this has nothing to do with egos. There is no magic switch that can make our compiler behave exactly like other compilers and pursuing such a thing is foolish. All compilers have different shader optimisations and different ordering of those shader optimisations. As yet there is nothing to show this is a mesa bug just because it "works" on other drivers doesn't mean it always will, if the shaders do not tell the implementation to keep precision there is nothing stopping future drivers releases from being more aggressive with optimisations just like Mesa.
@bkaradzic There is an apitrace on the Mesa bug report. The trace creates an OpenGL ES context which allows Mesa to make precision dependent optimisations. I don't know the process flow here but yes if these shaders begin as either GLSL or ES shaders and are stripped of precision due to being treated as GLSL shaders, before being used as ES shader then that is the problem.
Since this doesn't seem to be going anywhere, I would like to ask: is the OpenGL (non-BGFX) backend considered "legacy" by now? Will it be removed sometime soon? Or can it be considered the de facto standard MAME renderer?
I am looking for an stable renderer alternative to BGFX for my MAME builds.
We don't have any near-future plans to get rid of the OpenGL 2.1 backend. The caveat is that OpenGL itself is deprecated, although I don't expect it to show serious deterioration any time soon. It's been deprecated for 10 years now on macOS and it works perfectly fine in the latest release on the latest hardware. And I expect Zink and similar translation layers to replace directly implementing it in the drivers so that it can continue to work without being a maintenance burden.
Thanks for taking the time to answer my question! The OpenGL backend seems to be working fine on current GNU/Linux+Wayland desktop, too. So all in all, if it's not going anywhere, this is what I will keep using for now. Too bad that BGFX is needed for Vulkan :(