Implement partial multicore rendering

[ZehMatt]

For testing purpose, perhaps a feature at some point.

[ZehMatt]

What shall happen to this PR? It seems to work well with OpenGL not a lot with the Software renderer but very noticable on debug builds.

[janisozaur]

'shared_mutex' is unavailable: introduced in macOS 10.12

I guess the time has come to drop older versions then

[ZehMatt]

Damn, what did they drop it for?

[janisozaur]

6e44334 should probably change these to 10.12 now

There are some more instances of MACOSX_DEPLOYMENT_TARGET in there now, most likely they all need to get updated.

[AaronVanGeffen]

Builds cleanly, but segfaults on macOS soon after starting:

Process 20801 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001004114f9 openrct2`OpenRCT2::Paint::Painter::CreateSession(rct_drawpixelinfo*, unsigned int) + 825
openrct2`OpenRCT2::Paint::Painter::CreateSession:
->  0x1004114f9 <+825>: movq   %rdx, (%rcx)
    0x1004114fc <+828>: movq   0x8(%rax), %rdx
    0x100411500 <+832>: movq   %rdx, 0x8(%rcx)
    0x100411504 <+836>: movq   0x10(%rax), %rax
Target 0: (openrct2) stopped.

$ clang --version
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[tomlankhorst]

Mutex - the type of the shared mutex to lock. The type must meet the SharedMutex requirements
— cppreference.com thread/shared_lock

... which std::mutex does not.

We could bump the API to 10.12... but that would support a mere 75% of worldwide users.

Alternatively, can't you use unique locks? PR

[ZehMatt]

I'm not sure if the issue is the mutex, have a look at the build logs. Thats the mysterious part here.

[ZehMatt]

I've disabled the whole thing for mac to preserve my sanity. If anyone feels like giving this a shot feel free, I'm done trying.

[tomlankhorst]

I'm not sure if the issue is the mutex, have a look at the build logs. Thats the mysterious part here.

You mean this error?

This is indeed the mutex... can’t shared-lock a non-shared mutex. Can only use unique lock here.
The PR I sent you builds fine.

[janisozaur]

OpenRCT2/src/openrct2/paint/tile_element/Paint.LargeScenery.cpp

Lines 100 to 120 in 71ea5fd

	static const utf8* large_scenery_sign_fit_text(const utf8* str, rct_large_scenery_text* text, bool height)
	{
	static utf8 fitStr[32];
	utf8* fitStrEnd = fitStr;
	safe_strcpy(fitStr, str, sizeof(fitStr));
	int32_t w = 0;
	uint32_t codepoint;
	while (w <= text->max_width && (codepoint = utf8_get_next(fitStrEnd, (const utf8**)&fitStrEnd)) != 0)
	{
	if (height)
	{
	w += large_scenery_sign_get_glyph(text, codepoint)->height;
	}
	else
	{
	w += large_scenery_sign_get_glyph(text, codepoint)->width;
	}
	}
	*fitStrEnd = 0;
	return fitStr;
	}

fitStr needs some locking or refactoring. This should be the last change required.

[ZehMatt]

Done, made it pass a buffer to be filled rather than returning static one.

[AaronVanGeffen]

Could you add a line to the changelog as well?

[ZehMatt]

Good?

[AaronVanGeffen]

Gave it a quick spin. Not noticing much of a difference on my old Linux pc, but all seems to work fine. Quick benchmark:

Off: Rendering 40 times with drawing engine Software (hardware display) took 13.34 seconds.
On: Rendering 40 times with drawing engine Software (hardware display) took 12.20 seconds.

On macOS, the same benchmark:

Off: Rendering 40 times with drawing engine Software (hardware display) took 14.53 seconds.
On: Rendering 40 times with drawing engine Software (hardware display) took 11.36 seconds.

[ZehMatt]

Sadly its not too noticable without the OpenGL renderer but the gfxbenchmark is also not that good since theres nothing rendered really.
Edit: Also I had to introduce a mutex for the global font variables, once thats refactored it should squeeze out a little bit again, same goes for the scrolling text.

[ZehMatt]

Should perhaps mention, this gives debug builds some nice performance under any renderer.

[KKLD]

Thank you so much for working on this project and keeping the childhood dream alive!

I think you did a really great job with this feature. I get about 90% more FPS. It really helps for large parks. On that note, I curiously looked through #10664 and noticed that the maximum values will be increased and I think that will create more lag. Therefore, I was wondering if this multicore rendering only makes use of one additional core or if it can use more?

Looking through the code I noticed this: JobPool(size_t maxThreads = 255)
I also noticed that the picture is split up into 32x32 blocks to be rendered (as far as I can tell), however, I am unsure if it can really use 255 threads and not just 2 threads since I am getting 90% more performance and all of my CPU cores are not used. Therefore, I am wondering if there is an easy fix to use even more cores so we will have a smoother experience when going "limitless" in the new save format.

I hope that this is just a tiny bit useful. Once again thank you so much for working on this project, you have done an amazing job!

(I wonder why the sprite limits are only increased about 6.5 times since I can imagine that this will be the easiest limitation to reach, especially considering the fact that the other limits being raised allows one to easier reach that limit).

[ZehMatt]

It will not use 255 threads unless your CPU has actually 255 cores, the value is clamped. See:

OpenRCT2/src/openrct2/core/JobPool.hpp

Line 51 in 9860f1e

maxThreads = std::min<size_t>(maxThreads, std::thread::hardware_concurrency());

Its just defaulted so you don`t have to manually pass the correct amount from a implementation perspective.

[Gymnasiast]

@KKLD Currently, not many people hit the sprite limit, so a 6.5 times increase should be sufficient. It also means that sprite IDs will continue to fit in 16-bit unsigned integers, which saves a lot of refactoring.

(If you have more questions about the save format, please ask them on Gitter, so we keep this PR clean of off-topic discussions.)