WIP: Metal

[SamoZ256]

This is a work in progress Metal backend. The performance is very bad due to the fact that it starts a new render pass on every draw call. There is a lot of code reused from the OpenGL backend. For instance, the texture implementation is almost the same (except for the little Metal-specific code) and I was even able to use the surface cache from the OpenGL backend simply by removing one assert, which suggest that some things could maybe be abstracted away so that all the backends can reuse the code. Anyway, the backend still ignores a lot of stuff, like viewport/scissor and it doesn't use depth buffers yet. The result:

The image is too bright, probably because of incorrect color space.

[wheremyfoodat]

Hi!

I am not sure how feasible it is to upstream and maintain a Metal renderer on upstream at the moment, so I redirected the PR to a dedicated Metal branch instead of the upstream master branch for the time being.

Some notes:

• Please move metal-cpp into a submodule instead of including it in the repo, since that makes it a lot easier to update if needed and to search through the repo without getting hits on metal-cpp stuff
• Switch and replace of Handle -> HandleType has caused quite the mess in the core code. This is generally not a wanted change, both because random bits of text got changed and because Handle and similar names are used in all 3DS documentation/libraries/RE.
• If possible, please undo random older files being formatted/changed unnecessarily (eg all the service/kernel/memory files), those will be formatted eventually but doing it en masse and in unrelated PRs leads to the PR being impossible to review

[wheremyfoodat]

Nice work on the renderer of course, nice to see that particular scene running nicely on it.

Changing the PR to be a draft so it's not accidentally merged while it's not ready, feel free to change it back when you feel like it.

[SamoZ256]

Thanks for your feedback. To reply to your notes:

1. Metal-cpp is provided on the Apple website, so I don't know if it could be moved into a submodule.
2. I kind of knew it was a bad change, but it was colliding with Handle defined in metal-cpp. What would be the best way to handle this? The same issue was with NO, but that was a bit easier to fix, since it was just a macro in metal-cpp (I solved this by changing the order of including files, probably not the best solution)
3. Okay, I will try to undo that, it was just my IDE auto-formatting stuff

[wheremyfoodat]

Thanks for your feedback. To reply to your notes:

1. Metal-cpp is provided on the Apple website, so I don't know if it could be moved into a submodule.
2. I kind of knew it was a bad change, but it was colliding with Handle defined in metal-cpp. What would be the best way to handle this? The same issue was with NO, but that was a bit easier to fix, since it was just a macro in metal-cpp (I solved this by changing the order of including files, probably not the best solution)
3. Okay, I will try to undo that, it was just my IDE auto-formatting stuff

Ah I see. In that case, do not worry about 1 & 2, I will likely put up a slightly modified Metal-cpp repo on the Panda3DS-emu org that we can use as a submodule and update or modify as necessary.

[SamoZ256]

Unfortunately, I can only undo the formatting manually (which is quite painful), so I will probably have to wait until it's done separately and merge it into this branch.

[SamoZ256]

Super Mario 3D Land menu has progressed, there is just some missing ground and the background is corrupted (also the bottom screen is incorrect as well). The intro cutscene has corrupted background as well.

Going to work on the performance and memory leaks, since its pretty hard to debug in cinematic 2 fps.

[wheremyfoodat]

SM3DL will have funny breakage on title screen without logic ops implemented

[wheremyfoodat]

(On an unrelated note, are you testing on an M-series or Intel device? On M-series ARM chips, the shader recompiler is currently disabled by default in config.toml and enabling it should also give you a performance boost)

[SamoZ256]

(On an unrelated note, are you testing on an M-series or Intel device? On M-series ARM chips, the shader recompiler is currently disabled by default in config.toml and enabling it should also give you a performance boost)

I am using an M-series Mac, is it the "EnableShaderJIT" option?

[wheremyfoodat]

Yeah

[SamoZ256]

Okay, the shader JIT solved the performance problems completely, thanks. NSMB2 has a problem in the levels:

But the same problem is on OpenGL as well. Maybe I could message you on the Discord server if I will need to ask anything?

[wheremyfoodat]

NSMB2 is notoriously hard to hw render. It stores all textures in a gigantic texture atlas and uploads new textures by doing partial invalidations, which currently doesn't work.

Yeah sure hop on #dev-discussions