glshader not working for 'texture' output

[DoubleAgentDave]

The glshader setting that is being used to deprecate the software shaders does not appear to be compatible with any output except opengl. When using the 'texture' output the scale 'Bilinear' is selected ignoring any glshader setting: "DISPLAY: Initialized 1067x800 window-mode using Bilinear scaling on 1080p display-0"

Are you intending to remove the software shaders entirely even from the alternative 'texture' display system? The glshaders don't appear to function at all with this renderer even when using the opengl backend.

If you are can you consider implementing systems such as opengles2 instead of just the fully fledged opengl?

The opengl backend is really difficult to manage on low end old systems such as raspberry pi's. The texture rendering through opengles2 was easier to get working on these systems as you didn't have to swap graphics drivers and restart the system when you wanted to use another program that couldn't manage with the fully fledged opengl system available on the pi.

[johnnovak]

The glshader setting that is being used to deprecate the software shaders does not appear to be compatible with any output except opengl.

That's correct, shaders work with the OpenGL backend only. That's even encoded in the name of the config param glshader.

When using the 'texture' output the scale 'Bilinear' is selected ignoring any glshader setting: "DISPLAY: Initialized 1067x800 window-mode using Bilinear scaling on 1080p display-0"

As above, works as expected, no surprises there.

Are you intending to remove the software shaders entirely even from the alternative 'texture' display system?

We have already removed them (they slowed down the compilation, made the resulting executable larger, etc.). Most of them (but not all) have their GL shader replacements.

If you are can you consider implementing systems such as opengles2 instead of just the fully fledged opengl?

Yes, OpenGL ES is planned to be supported as part of the currently ongoing major graphics rearchitecturing work done by @GranMinigun. OpenGL ES is planned to be supported by the yet-to-be-written OSD functionality too (that is mainly my territorry).

The opengl backend is really difficult to manage on low end old systems such as raspberry pi's. The texture rendering through opengles2 was easier to get working on these systems as you didn't have to swap graphics drivers and restart the system when you wanted to use another program that couldn't manage with the fully fledged opengl system available on the pi.

I appreciate that, but probably you're using some old RPi, v3 or even older, and supporting all sorts of really old hardware is not among our goals. That just slows down development and adds lots of maintenance that takes away from supporting the 90%+ of users who are on more recent hardware. @kcgen and some other folks have done extensive testing on Raspberry Pi 4 with the OpenGL backend, and on that system the shaders are performing rather well, as I remember (not all of them, but certainly the default sharp shader does, and so do some of the less-heavy, RPi optimised CRT shaders). @kcgen can perhaps provide some further details on this.

All in all, I'm pretty sure our current approach is to use the Raspberry Pi 4 as the "bottom-of-the-barrel" hardware we're actively supporting (correct me if I'm wrong, @kcgen). Anything weaker/older than that -- well, if newer versions of DOSBox Staging still work on it, that's good, but expect things to break in the future.

[DoubleAgentDave]

No, I'm using the raspberry pi 400 with the latest retropie installation. It's pretty common, it's just a setting that works currently.

[DoubleAgentDave]

The opengl setting does work fine for this particular version of dosbox, but opengl is not the best option for the rpi400, opengles2 still works better. Once the glshaders work on opengles then this should be sorted. I guess I'll have to ignore this version and update when that's sorted.

Refactoring, while nice your end, screws up a LOT of very recent configuration files. It's great you're actually making this old code easier to read again, even i can understand the majority of it. But configuration file changes affect users more than it does developers.

My point being that if this is meant to be a user facing utility, as it is advertised as somewhat, then some account of users needs to be made when you do major refactoring of configuration files like this. At least a warning as such on the output would be nice rather than just dropping to bilinear without explanation.

If anyone feels like dropping in a command to refactor loaded conf files to change things like the 'scaler' to 'glshader', and place all the mouse stuff in the new place you've made for it, I'd be grateful. Using 'sed' on a large array of '.conf' files from various differing versions is not straight forward with the changes you've made.

As much as I'm annoyed I appreciate this program and the community producing it a lot :) Thanks

[DoubleAgentDave]

It's pretty much "config -wcp 'nameofconf.conf'" isn't it?

Doh!

[kcgen]

@DoubleAgentDave , OpenGL ES 1 and 2 are both supported hardware accelerated backends for the texture* outputs.

To check it out, set your conf's [sdl] texture_renderer setting to either opengles or opengles2.

(However, this shouldn't be needed for the best performance using RetroPie on a pi4).

@nemo93 here has done a ton of testing to determine the optimal settings, and has posted the recommended conf for Retropie + Pi4, here:

https://github.com/dosbox-staging/dosbox-staging/wiki/Config-file-examples#global-config-files-for-various-systems

Note: the mouse settings have mouse moved to their own section.

@nemo93 also hosts a discussion about DOSBox, in general, on the retropie forums: https://retropie.org.uk/forum/topic/25041/dosbox-official-thread/202

[DoubleAgentDave]

That's missing the point I was trying to make earlier, thats the best configuration for running dosbox-staging on the pi4, agreed, it's not the best for running it along side other programs that don't work with the best pi4 driver that actually supports opengl.

Like I said I'll stick with the old version and skip this until the opengles driver is working fully without having to go through 'texture' as the 'texture' backend removes compatibility with the software shaders, like johnnovak said.

[kcgen]

opengl is not the best option for the rpi400

If you can try nemo's conf settings (exactly) above with the resolution values as specified, you should be able to get decent performance, although I believe this involves disabling the glshaders.

The Pi4's video output latency increases dramatically at resolutions beyond 720p, so that factors into the settings (and is the basis for using original resolution).

[kcgen]

it's not the best for running it along side other programs that don't work with the best pi4 driver that actually supports opengl.

@DoubleAgentDave, sorry; I'm struggling to follow the double negatives.

If it's not the best for running along side programs that don't work with the best pi4 driver... then it's the best for running alone side programs that do work with the best pi4 driver?

Maybe there's a configuration settings on the pi4 that can avoid this driver flip/flop problem? @nemo93, do you have some tips? (This is the first I've heard of this dilemma, so hopefully there's a setting that can help!)

[johnnovak]

But configuration file changes affect users more than it does developers.

We put a great deal of thought when it comes to balancing breaking changes to functional improvements. We also deprecate settings first, and still allow the old config setting to be set where this is practical, then only retire it for good after a year or so. But in some cases you just gotta make breaking changes -- removing the old scalers is one of these.

My point being that if this is meant to be a user facing utility, as it is advertised as somewhat, then some account of users needs to be made when you do major refactoring of configuration files like this. At least a warning as such on the output would be nice rather than just dropping to bilinear without explanation.

As per above.

If you're still setting scaler in the [render] section, a warning is issued:

We have documented the removal of scalers in the config descriptions:

See the the relevant commit here, you can read further details about the justification in the commit message: https://github.com/dosbox-staging/dosbox-staging/commit/956a54d9cd2111a256f1fd951099e556b4376aba

What we could have done better is to document the removal of software scalers in the release notes as well. You live and learn! 😂

As for "silently" dropping to bilinear filtering in texture output mode even though when glshader is specified, that's kinda expected, isn't it? You're not using the opengl output mode, so why should a GL shader be applied? In any case, I can see this can be confusing, so we might issue a warning in this case if glshader is set and output is not one of the opengl modes. But you can imagine how many interesting and/or weird config combinations are possible; we can't issue warnings for all these (but are open to constructive criticism; like I said, in this case we might issue a warning).

If anyone feels like dropping in a command to refactor loaded conf files to change things like the 'scaler' to 'glshader', and place all the mouse stuff in the new place you've made for it, I'd be grateful. Using 'sed' on a large array of '.conf' files from various differing versions is not straight forward with the changes you've made.

Not sure if you're aware of the config cascading mechanism we have introduced? Indeed, changing every single game config manually would be a chore... What I personally use and what I recommend is to put the most common settings in your global config, then only override what's necessary in your game-specific configs (as opposed to the old way of configuring everything for every game).

Also, I don't find spending a minute manually fixing up the config "lazily" when I actually play a game to be difficult, but that's me 😄

For reference, this is my global config and some of my game specific configs that reside in the local game directories:

Global config

[dosbox]
captures = D:\Emulators\DOS\Captures\

[sdl]
fullscreen = on
windowresolution = 1440x960
vsync = true
priority = auto auto

[cpu]
cycles = fixed 9600
cycleup = 400
cycledown = 400

[mixer]
rate = 48000
blocksize = 1024
prebuffer = 25
compressor = off

[sblaster]
sbtype = sbpro1

[midi]
mididevice = mt32
midiconfig = 1

[fluidsynth]
soundfont = D:\Emulators\DOS\SoundFonts\GeneralUser GS 1.471\GeneralUser GS v1.471.sf2

[mt32]
model = cm32l
romdir = D:\Emulators\DOS\ROMs\Roland\

[gus]
ultradir = U:\ULTRASND

[autoexec]
@mount U D:\Emulators\DOS\Utils
@path Z:\;U:\CMD
@mode con delay=1 rate=30
@mixer opl x40 /noshow

Some game specific configs

I'm using automounts (e.g. drives/C in the game directories).

Eye of the Beholder

[mixer]
reverb = small

[autoexec]
autotype -w 0.01 -p 0.01 4 1 y
C:
START
EOB
exit

Prince of Persia

[mixer]
reverb = large

[autoexec]
c:
PRINCE
exit

Eric the Unready

[mouse]
mouse_sensitivity = 60,120

[autoexec]
imgmount D "CD\Eric the Unready (1997)(Legend).iso" -t iso
c:
call LEGEND
exit

[DoubleAgentDave]

It's more to do with all the other emulators and programs that are available for the Pi4, the development on that system is coming along fast, but there are a few programs that won't ever support the best pi4 GPU driver. When you use them you have to swap driver. It's not an issue for you lot that's why I closed the thread. If you're only targeting the best possible Pi4 configuration (there aren't actually that many sane ones), then this is not an interesting issue for you.

If it's not the best for running along side programs that don't work with the best pi4 driver... then it's the best for running alone side programs that do work with the best pi4 driver?

Yes, basically, but changing all the negatives to positives in a sentence miss the point sometimes, language isn't the same as math. If you are running a Pi4 with the settings that are compatible with older programs, then you can't use 'best case' settings. It's the problem with benchmarking in general, you might get amazing results for your setup, but if I have to keep flip flopping between compatibility modes to get it to work I won't use those settings, I'll use the ones that work in the majority of cases. (I.E. the GPU driver with full opengl support and the one with only partial support, i'll use the partial support case where I can get opengles working but not opengl). In any case there are very few dos games that run crap on the Pi400 even with poor setups.

It's just the software shader removal killed an option I liked and could get working in the compromised situation I'm using. Like I said, I'll skip this version and wait for the one with full opengles support without going through the 'texture' renderer.

What we could have done better is to document the removal of software scalers in the release notes as well. You live and learn! joy

Maybe, but I appreciate the comments here too :)

I appreciate the changes and the effort you and the community here have gone to, it's really good to see people putting in so much time and effort into something like this. I really appreciate it, thank you :D

[kcgen]

Thanks for expanding on the GL vs ES issue, @DoubleAgentDave.

I recall this was a big problem a couple years ago, with their fake-KMS drivers and other terrible-performing "full" GL wrapper drivers around the native/hardware-supporting ES API.

But is this still a problem? (I could have sworn it was solved).

For example, I can run Staging in output = opengl with a GLshader, like glshader = interpolation/sharp and get excellent performance:

2023-01-03 17:31:40.789 | SDL: version 2.0.10 initialized (KMSDRM video and alsa audio)
2023-01-03 17:31:40.797 | RENDER: Using GLSL shader 'interpolation/sharp'
2023-01-03 17:31:40.798 | DISPLAY: Initialized 1280x720 window-mode using Bilinear scaling on 720p display-0
2023-01-03 17:31:40.843 | OPENGL: Vendor: Broadcom
2023-01-03 17:31:40.843 | OPENGL: Version: 2.1 Mesa 19.3.2
2023-01-03 17:31:40.844 | OPENGL: GLSL version: 1.20
2023-01-03 17:31:40.844 | OPENGL: Pixel buffer object: available
2023-01-03 17:31:40.844 | OPENGL: NPOT textures: supported

And then, back-to-back, run output = texturenb with texture_renderer = opengles2, and also get excellent performance. SDL reports using the GLES2 API:

3-01-03 17:33:05.972 | SDL: version 2.0.10 initialized (KMSDRM video and alsa audio)
2023-01-03 17:33:05.979 | DISPLAY: Initialized 1280x720 window-mode using Nearest-neighbour scaling on 720p display-0
2023-01-03 17:33:06.241 | SDL: Using standard SDI (auto) display refresh rate of 60 Hz
2023-01-03 17:33:06.247 | SDL: Using driver "opengles2" for texture renderer

I'm not making any system-level changes (like running raspi-config, kernel config.txt tweaks, or rebooting between those runs).

Atleast on my pi4, Both GLES2 and OpenGL are fully available, without compromises.

[GranMinigun]

One of the big problems is low memory bandwidth which leads to poor performance even on desktop systems with integrated graphics. DOSBox currently isn't very efficient when it comes to rendering. I have a couple of things on my mind to improve that and possibly win several milliseconds per frame, although Raspberry Pi will hit its CPU limits pretty fast after that, I feel, - which might be a good thing depending on one's point of view.

texture outputs will never support shaders. I do have a pre-scale setting in mind to replicate the behaviour of sharp bilinear shader, but that might come at a cost. GL ES 2/3 backend is a relatively short-term goal (well... relative to the whole rendering rewrite project), Vulkan is longer-term, all of them will support shaders, including chaining.

For the time being, you can comment out lines 3341-3343 (3384-3386 at HEAD) in src/gui/sdlmain.cpp to get a bit of performance with opengl output. This will disable pixel buffer object use, which hampers unified memory devices heavily. Maybe that'll provide enough of a headroom?

[DoubleAgentDave]

The problem was exactly the KMS vs fake KMS drivers. There is an issue when using one or two emulators I use regularly enough to justify using the crappy fake kms driver which meant I had a lot of problems with the opengl backend.

From the sound of it I think my case is pretty marginal. The GL ES 2/3 backend will solve a lot of problems for me, and probably a load of other people using embedded systems. Vulkan would be lovely for my laptop, it's still not stable enough on the pi for me to want to use it anytime soon on that, so a long timeline on that sounds appropriate. I imagine playing with vkbasalt/ReShade shaders would be fun though.

For the time being, you can comment out lines 3341-3343 (3384-3386 at HEAD) in src/gui/sdlmain.cpp to get a bit of performance with opengl output. This will disable pixel buffer object use, which hampers unified memory devices heavily. Maybe that'll provide enough of a headroom?

It wasn't really a performance issue that made me go to the texture output, it was just that the texture output worked with the fake-kms driver without compatibility problems. Dosbox had a solution to another programs lack of compatibility with the proper GPU drivers, so this isn't really your problem. The issue was more the lack of a feature that was useful in an edge case. There are a whole bunch of emulators I was using (https://retropie.org.uk/stats/pkgflags/) that got flagged as not working so I didn't switch. While most have alternatives, there is stuff like the colecovision and sharp x68000 that are sticking points.

[kcgen]

There is an issue when using one or two emulators I use regularly enough to justify using the crappy fake kms driver

I hear you; those bad old days of the fake kms drivers were a rough patch for the Pi, and it hurts knowing that some people are trapped in with software dependencies.

I can only hope that the colecovision and sharp x68000 emu's eventually upgrade and free you from these shackles!

[nemo93]

@kcgen thanks for pinging me. I've updated the wiki to reflect the new conf for 0.80. If anyone could update the conf for MacOS/Windows on that page that would be appreciated (or to remove it completely).

@DoubleAgentDave the thread is a bit long for me to read in thoroughly. If you're on RPi4 and Retropie my only advice would be to stick to the defaults provided. As kcgen kindly explained Staging has been extensively tested for months (years?) on RPi. Objective still being to get as close as console-like experience as possible. Should you install Staging from 'Retropie Setup' you'll get the best defaults out-of-the-box. Those defaults guarantee best performance. Next install a few games and see how it goes. I can point you to the Get Started to be sure you rely on the layered config approach (definitely recommended) where you have one global 'all rounder' config plus one (tiny) conf per game.

This is the opportunity for me to thank again all the devs/maintainers/contributors of Staging who still support those very low-spec devices as well as distros with somewhat outdated packages 😉