Emulator

Oops something sent the message before I was done.

Here's the issue at Mesa
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8405

Here's info about my system:

Hardware: Orange Pi 5
OS: Armbian (23.02.2) aarch64
GPU: Mali-G610
Kernel version: Linux orangepi5 5.10.110-rockchip-rk3588 #23.02.2 SMP Fri Feb 17 23:59:20 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
Mesa version:
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Panfrost (0xffffffff)
Device: Mali-G610 (Panfrost) (0xffffffff)
Version: 23.0.0
Accelerated: yes
Video memory: 7689MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Panfrost
OpenGL renderer string: Mali-G610 (Panfrost)
OpenGL version string: 3.0 Mesa 23.0.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 23.0.0-devel
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Note that Panfrost Mesa installed report max cgsl of 310.

I just hacked and got the game to at least start by editing in ProgramShaderCache.cpp

around line 850

  //~ v > GlslEs300 ? "precision highp sampler2DMSArray;" : "",
  v > GlslEs300 ? "precision highp image2DArray;" : "",
  v >= GlslEs310 ? "precision highp image2DArray;" : "");

Not sure how far I'll get as I can't get controller input to work now :P

It still crashes when I toggle full screen but maybe that's just something similar.
I did see something about this in FrameBufferShaderGen too.

The code in FrameBufferShaderGen should only be used if the EFB is multisampled, which would require enabling multisampling in the first place, which shouldn't be possible if the platform doesn't support it (the menu for it shouldn't have any options, I think).

I'm going to submit a pull request to change the check to use v >= GlslEs320 since that seems to be correct based on what I see in the GLSL ES spec (though I don't have any way of testing directly).

I do have menu options for Anti Aliasing, Texture Filtering and different render resolutions.

It looks like there's an additional complication: it's supported when using GL_OES_texture_storage_multisample_2d_array, which is something we do check for, and only allow multisampling on GLES 3.1 if that extension is supported. That extension uses the same sampler2DMSArray keyword in shaders (though it uses a different function outside of shaders; I believe this code enables calling glTexStorage3DMultisampleOES instead of glTexStorage3DMultisample when needed, but I'm not familiar with it.)

Mesa says it supports GL_OES_texture_storage_multisample_2d_array, so that should theoretically work, but it seems like Dolphin isn't actually adding #extension GL_OES_texture_storage_multisample_2d_array : enable. So I think that's the root cause.

For reference:

sampler2DMSArray is a reserved keyword on GLSL ES 3.0 (see spec page 20 (PDF 27)) and 3.1 (see spec page 18 (PDF 25)). It only exists in GLSL ES 3.2 (see spec page 20).

Prior to 76b50855 (#10311) dolphin incorrectly specified sampler2DMS here. That keyword was reserved in GLSL ES 3.0, but became valid in 3.1. Oddly, this is not mentioned in the spec with changes marked (there is no changes version for 3.2). The GLSL ES 1.00 spec (for GLES 2.0 - there does not seem to be a GLSL ES 2.0) does not mention either of these two keywords, but dolphin only supports GLES 3.0+ anyways.

The code that added sampler2DMS was first introduced in 7650117c (#2934), which also added the other logic for stereo + multisampling. The GLES 3.1 path looks like it's written with a fallback path for supporting multisampling without using stereo (so it could use sampler2DMS instead of sampler2DMSArray), as it has separate checks for bSupports3DTextureStorage and bSupports2DTextureStorage then (renamed to bSupports2DTextureStorageMultisample/bSupports3DTextureStorageMultisample in a8876a29 (#4467)), but the actual path for sampler2DMS was removed in f0391491 (#7753)).

Dolphin uses sampler2DMSArray in FramebufferShaderGen (EmitSamplerDeclarations), but only from GenerateFormatConversionShader when samples > 1 and from GenerateResolveColorPixelShader and GenerateResolveDepthPixelShader, which FramebufferManager only calls if IsEFBMultisampled() is true.

Lastly: Vulkan, D3D11, and D3D12 all detect the supported antialiasing modes, but OpenGL hardcodes the list as {1, 2, 4, 8}. That probably should be changed to detect what modes are supported (though I'm not sure if/how that's done).

In summary: the fix is probably to add #extension GL_OES_texture_storage_multisample_2d_array : enable on GLES 3.1 if supported, and only add precision highp sampler2DMSArray if the extension is supported or GLES 3.2 is in use. Also, there is older code that supports falling back to sampler2DMS on GLES 3.1 if sampler2DMSArray is not supported so that either stereo or multisampling can be used, but that code got broken a while ago and needs to be either removed or fixed.

I can confirm Fullscreen is actually working for me now.

Can you check whether https://github.com/dolphin-emu/dolphin/pull/11628 works (and also lets you use multisampling correctly)?

Hmm should I be able to pull those commits before they are merged?
Sorry I'm not that good with git.

I tried
git fetch origin
git cherry-pick 1c4d4abcc249914f2b384e37232e84805f08252a

but get
fatal: bad object 1c4d4abcc249914f2b384e37232e84805f08252a

You want this:

git fetch origin 674690b1aaba82861f6ce7f112c99318fbbfa850
git switch --detach 674690b1aaba82861f6ce7f112c99318fbbfa850

(to return to master afterwards, use git switch master)

Ok cool! Great to learn something new! There's always more to learn about git :)
SO I did those two command lines on the four different commits you linked to.
Re built. Then ran.

It worked!! :D No shader error.
For the AA I get six options listed,
2,4,8 of MSAA & SSAA respectively.
Not sure if that's what we should expect.

Nice one! Thank you so much that's extremely helpful! :)

Oh wait. Once I started a game and went back into the AA menu then all the SSAA options had disappeared.
Only the three MSAA ones remain.

That behavior is somewhat expected; if SSAA isn't supported then it won't be listed, but we're not detecting features on OpenGL until rendering actually starts. It's not good behavior though and should be changed.

Do things look different if 8x MSAA is enabled versus no MSAA?

Its definitely doing the AA on 2 and 4.
But on 8 it turns the screen black.

For the extra options in the AA menu could it be remnants of settings config from runs before I took your commits?

The GPU only presumably only supports up to 4x MSAA, but Dolphin isn't properly checking that and instead is hardcoding the options at None, 2x, 4x, and 8x (this also prevents using higher AA levels on OpenGL if supported, which I've confirmed applies to me on my machine (I should have 16x and 32x)). I've started looking into fixing that but don't have something working yet. SSAA showing up is probably a similar case; it's more likely to be an actual Dolphin bug than something weird caused by previous settings. I'll let you know when I have something else to test for that.

A git clarification: you didn't actually need to run the commands I listed for each commit. git fetch origin 674690b1aaba82861f6ce7f112c99318fbbfa850 downloads 674690b1aaba82861f6ce7f112c99318fbbfa850 and any parent commits that you don't already have, while git switch --detach 674690b1aaba82861f6ce7f112c99318fbbfa850 acts like switching to that commit as a branch (without actually creating a branch). git switch --detach can also be used to go to older commits. You would need to list each commit one at a time for git cherry-pick, though (but that also updates your master branch, which would be more complicated to clean up, and it (generally) doesn't make sense to cherry-pick an older commit).

If you have time, can you check whether https://github.com/dolphin-emu/dolphin/pull/11699 fixes the list of supported antialiasing modes? With that PR on your hardware it should only show None, 2x, and 4x, assuming everything works correctly. (That change doesn't include a copy of the other change, though, so you won't be able to actually run games with it as-is.)

Sorry for taking time to get to this.
I just did,
git fetch origin ccafc6ab51ade22d7dba3029ca13be2e550670f9
git switch --detach ccafc6ab51ade22d7dba3029ca13be2e550670f9

(not sure if thats the right hash to use?)

And I get a limited selection of only one AA option
4xMSAA

But when I select it it doesn't take in the menu.
It just flips straight back to 'None'
No matter how many times I try.

Hmm, that's really odd. I don't think I changed anything with how the menu itself works, and it changing back doesn't seem like normal behavior. The hash you chose is the right one, though.

It only supporting 4x is also strange, but I think allowed; I'm not aware of a rule that says that the valid modes need to be sequential powers of 2 (or even powers of 2 at all).

You said that antialiasing did work with PR 11628 at 2x and 4x. Can you tell if 2x and 4x are giving different results? It's possible that it's just rounding 2x to 4x (which I believe is what the spec says is supposed to happen, though I haven't double-checked).

I was able to reproduce the behavior you mentioned on my machine, and also determined that 2x and 4x behave identically on Mesa (at least with my jank setup). It should be fixed now (4x and None being selectable without 2x).

Cheers I will try it out soon!
One thing to consider is that Mesa is not yet officially supporting this GPU.
Armbian (which I use) is using a Panfrost fork called 'Panfork' which is a version made just for this SOC rk3588.
Hopefully eventually there will be more official Mesa support for this GPU. They have added a driver, 'pancsf' as a first step which is still wip but the actual Mesa Panfrost still does not seem to work.