openmsx-devel

[openMSX-devel] SDLGL-FB16/32 renderers

[Maarten t. H. <ma...@tr...>]

Hi all,

We currently have two renderers that are only built when the source tree 
is not in "release mode": a flag we briefly set when tagging a release.

The renderers are called SDLGL-FB16 and SDLGL-FB32. If I recall 
correctly, these:
- render in MSX resolution in software (all our renderers do; doing this 
on the GPU turned out to be very inefficient)
- scale in software (unlike SDLGL-PP)
- upload to video memory via OpenGL calls

I'm wondering how to translate this to the Meson build. Currently it 
works exactly like the non-Meson build, by looking at the release flag. 
But conceptually it feels like this should be a component instead: these 
renderers are an optional feature that can included or excluded from the 
build.

In the non-Meson build, components are implicit: a component is enabled, 
unless:
- a required dependency is not found
- the component is disabled by the platform (via the LINK_MODE variable)

So there is no way for the user to explicitly enable or disable 
components. That's something we inherited from the autoconf way of 
working, but over the years I've realized it's not a good approach: the 
user should be able to control whether a component is enabled or not and 
if the user explicitly enables it, it should be an error if the 
component cannot be built. This is different from autoconf's approach, 
which drops an optional component if a dependency is not available, even 
if the user explicitly asked for that component.

Fortunately, Meson has a different way of dealing with this. You can 
define features and for each feature there is a flag that the user can 
set to "enabled", "disabled" or "auto". The "auto" value is the autoconf 
behavior: build the feature if possible, otherwise drop it. But if a 
user selects "enabled", it is an error if the feature has missing 
dependencies, such as a library that cannot be found.

Since we have a better system for controlling features with Meson, 
converting these renderers to a component controlled by a feature makes 
sense. I think the feature should be specific to these renderers and no 
longer tied to release mode, which also controls things like showing the 
Git revision in the version number.

What I would like to know:
- are these renderers still useful for testing?
- if so, do we want them enabled for developers only or also in daily 
builds?

Related to this is the question of what we want to do with software 
scaling in general, but I'll compose a separate mail for that.

Bye,
		Maarten

Re: [openMSX-devel] SDLGL-FB16/32 renderers

[Wouter V. <ver...@gm...>]

These renderers should not be included in daily builds. These are not
useful for users (and can only confuse them).

I don't remember the last time i used these renderers for development, but
then I also haven't worked on rendering stuff for many year. If it's easy
to make these into optional (disabled by default) components then that's
fine. But I also wouldn't mind dropping them. Maybe that's even better? We
can always get them back from git.

A few of our scaling algorithm exist in the software renderer (SDL) but not
in openGL scalers (SDLGL-PP). The SDLGL-FBxx renderers could be a
workaround for that. But OTOH nobody complained about the lack of these
renderers.

An example of a software-only scaler is MLAA. But also in software that
scaler is incomplete. Should we drop it? (Or is someone motivated to finish
it)?

Wouter

On Sun, Feb 24, 2019 at 8:52 AM Maarten ter Huurne <ma...@tr...>
wrote:

> Hi all,
>
> We currently have two renderers that are only built when the source tree
> is not in "release mode": a flag we briefly set when tagging a release.
>
> The renderers are called SDLGL-FB16 and SDLGL-FB32. If I recall
> correctly, these:
> - render in MSX resolution in software (all our renderers do; doing this
> on the GPU turned out to be very inefficient)
> - scale in software (unlike SDLGL-PP)
> - upload to video memory via OpenGL calls
>
> I'm wondering how to translate this to the Meson build. Currently it
> works exactly like the non-Meson build, by looking at the release flag.
> But conceptually it feels like this should be a component instead: these
> renderers are an optional feature that can included or excluded from the
> build.
>
> In the non-Meson build, components are implicit: a component is enabled,
> unless:
> - a required dependency is not found
> - the component is disabled by the platform (via the LINK_MODE variable)
>
> So there is no way for the user to explicitly enable or disable
> components. That's something we inherited from the autoconf way of
> working, but over the years I've realized it's not a good approach: the
> user should be able to control whether a component is enabled or not and
> if the user explicitly enables it, it should be an error if the
> component cannot be built. This is different from autoconf's approach,
> which drops an optional component if a dependency is not available, even
> if the user explicitly asked for that component.
>
> Fortunately, Meson has a different way of dealing with this. You can
> define features and for each feature there is a flag that the user can
> set to "enabled", "disabled" or "auto". The "auto" value is the autoconf
> behavior: build the feature if possible, otherwise drop it. But if a
> user selects "enabled", it is an error if the feature has missing
> dependencies, such as a library that cannot be found.
>
> Since we have a better system for controlling features with Meson,
> converting these renderers to a component controlled by a feature makes
> sense. I think the feature should be specific to these renderers and no
> longer tied to release mode, which also controls things like showing the
> Git revision in the version number.
>
> What I would like to know:
> - are these renderers still useful for testing?
> - if so, do we want them enabled for developers only or also in daily
> builds?
>
> Related to this is the question of what we want to do with software
> scaling in general, but I'll compose a separate mail for that.
>
> Bye,
>                 Maarten
>
>
>
>
>
> _______________________________________________
> openMSX-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmsx-devel
>

Re: [openMSX-devel] SDLGL-FB16/32 renderers

[Maarten t. H. <ma...@tr...>]

On zondag 24 februari 2019 09:52:48 CET Wouter Vermaelen wrote:

> These renderers should not be included in daily builds. These are not
> useful for users (and can only confuse them).

OK, then setting the default for that feature to "disabled" would make 
sense.

> I don't remember the last time i used these renderers for development,
> but then I also haven't worked on rendering stuff for many year. If
> it's easy to make these into optional (disabled by default)
> components then that's fine. But I also wouldn't mind dropping them.
> Maybe that's even better? We can always get them back from git.

Getting things back from Git is not a good long-term strategy, since the 
longer the code hasn't been in the source tree, the more work it is 
going to be to get it working again if you need it. So I'd only be in 
favor of dropping them if we think we're never going to use them again.

> A few of our scaling algorithm exist in the software renderer (SDL)
> but not in openGL scalers (SDLGL-PP). The SDLGL-FBxx renderers could
> be a workaround for that. But OTOH nobody complained about the lack
> of these renderers.

I think the whole scaling system is not very easy to understand for 
users and having these renderers as an official workaround would only 
solidify that complexity. If we really need the workaround, it should be 
done automatically inside the SDLGL-PP renderer, in my opinion.

Which renderers have no GL counterpart, besides MLAA?

> An example of a software-only scaler is MLAA. But also in software
> that scaler is incomplete. Should we drop it? (Or is someone
> motivated to finish it)?

I am motivated, but also short on time.

Note that when finished, MLAA would be like the HQ scaler: we would 
compute slopes in MSX-resolution on the CPU, then upload that data into 
a texture and have it rendered at output resolution on the GPU. So it 
wouldn't remain a software-only scaler.

Bye,
		Maarten