Threaded OpenGL API calls #2014

fzurita · 2019-02-23T16:01:09Z

This is a redo of the implementation of #1452. This version has almost no impact on the main code and it just replaces the gl calls with the threaded version since the API is now the same.

This was specifically tailored to work with GLideN64, but it could theoretically work with other projects with minor modification.

Downsides are that not all OpenGL calls are implemented, only the ones the GLideN64 uses. If new OpenGL calls are needed, they will have to be added, but that is no different than before. Adding calls does become a little more difficult though. Also, if threading is disabled, it will behave identically as before.

Most everything is in the src/Graphics/OpenGLContext/ThreadedOpenGl folder, so it's kept out of the way.

And one last thing, I only checked compilation in Windows. I haven't tested this version in Windows, but it should work the same as the older pull request.

fzurita · 2019-02-23T16:04:03Z

src/Graphics/OpenGLContext/opengl_ColorBufferReaderWithBufferStorage.cpp

@@ -30,7 +30,6 @@ void ColorBufferReaderWithBufferStorage::_initBuffers()
 	// Initialize Pixel Buffer Objects
 	for (u32 index = 0; index < m_numPBO; ++index) {
 		m_bindBuffer->bind(Parameter(GL_PIXEL_PACK_BUFFER), ObjectHandle(m_PBO[index]));
-		m_fence[index] = 0;


No longer using fences since they can hurt performance and this is not really trying to be that accurate in async mode.

fzurita · 2019-02-23T16:05:04Z

src/Graphics/OpenGLContext/opengl_CachedFunctions.cpp

@@ -152,9 +173,7 @@ void CachedTextureUnpackAlignment::setTextureUnpackAlignment(s32 _param)
 /*---------------CachedFunctions-------------*/

 CachedFunctions::CachedFunctions(const GLInfo & _glinfo)
-: m_bindFramebuffer(GET_GL_FUNCTION(glBindFramebuffer))


We don't want to get any function pointers directly.

fzurita · 2019-02-23T16:14:30Z

Performance improvements vary by settings, but with my phone and synced color buffer copies to RDRAM enabled, performance is 30% to 40% faster in the best case scenario. With async, I'm seeing about a 10-15% performance improvement.

fzurita · 2019-02-23T16:27:46Z

Performance could also be further improved. I'm still newing things up a lot. I also found a thread safe memory pool implementation which helped significantly, but if I used it too much, it actually slowed things down due to synchronization.

I think eventually I will replace that thread safe memory pool with a lock free ring buffer which should further improve performance since allocating in the heap is so expensive.

gonetz · 2019-02-24T05:24:46Z

I haven't tested this version in Windows

I just tested it. 32bit mupen64plus build crashes on start of any rom.
Compilation of 64bit version gives me tons of warnings like:
src\graphics\openglcontext\threadedopengl\opengl_WrappedFunctions.h(991): warning C4244: 'initializing': conversion from '__int64' to 'unsigned long', possible loss of data (compiling source file ..\..\src\Graphics\OpenGLContext\ThreadedOpenGl\opengl_WrappedFunctions.cpp)
The build crashes too.

fzurita · 2019-02-24T09:46:42Z

Ok, thanks, I'll investigate. Android works correctly though. I have the feeling that it is probably something wrong with the initialization of GL function pointers.

fzurita · 2019-03-05T13:48:22Z

I started debugging this in Windows. It doesn't crash for me, but it does hang at startup. I'll try to figure out what that's about.

fzurita · 2019-03-07T06:44:48Z

Ok, it now correctly runs in Windows and there are no warnings in the 64 bit build.

I am encountering a strange issue that I didn't see in the previous version of this. Disabling the speed limiter in Project 64 actually makes it run slower.... Trying to debug.

fzurita · 2019-03-07T13:04:24Z

Ok, it was running slow because I was doing a debug build instead of release build. In Windows though, threaded mode seems to run slower then not threaded. I have the feeling it's the synchronized memory pool I'm using. I'm going to have to to move a lock free ring buffer memory pool. I couldn't find one around anywhere, so I will have to make my own unfortunately. (Although I do realize that synchronization is required even with a "lock-free" implementation, but a ring buffer big enough should almost never actually pause to lock).

fzurita · 2019-03-14T04:02:40Z

Even after introducing a lock free ring buffer pool, performance still seems to be about 10-20% worse in Windows when threaded mode is enabled.... I don't quite understand why. It seems to be the opposite in Android.

@gonetz Can you check if it helps N64 depth compare? My GPU doesn't seem to support that very well.

gonetz · 2019-03-14T07:52:19Z

Sure, I'll check it.

gonetz · 2019-03-14T08:29:03Z

@fzurita How do you test performance?

fzurita · 2019-03-14T11:45:43Z

Turn threaded mode on and off. It can be done using the GUI or the GLideN64.ini. I usually just compare FPS.

gonetz · 2019-03-14T15:40:39Z

I usually just compare FPS.

It is not reliable. FPS counter constantly jumps.

fzurita · 2019-03-14T15:50:59Z

I guess a more reliable way would be total frames rendered over a longer period of time, like total frames over a minute since the start of the game. There is no easy way to get that though.

Also, I know the source of the slow down on windows though. The opengl command queue consumer is slow to respond to the producer. It's fast in Linux. It seems like mutexes and condition variables are not as efficient in Windows (in my use case). I'm going see if I can figure out a workaround.

fzurita · 2019-03-14T15:57:27Z

Also, for N64 depth compare, which seem really slow according to you in Banjo Tooie, you should be able to perceive a difference if the change in performance is large enough. I think it could help this scenario since it's a GPU limited case.

fzurita · 2019-03-16T13:11:37Z

Performance seems to be ok in threaded mode in Windows now, only around 5% performance loss by just looking at the FPS counter with no limiter.

It should help though in cases where GPU drivers have to wait, which doesn't seem to happen in Windows at all it seems.

loganmc10 · 2019-03-16T13:13:24Z

I believe some OpenGL drivers are already threaded, so this kind of thing would probably be mostly duplicated in the driver, which is why in some instances you probably won't see much difference or even slightly worse results

fzurita · 2019-03-16T13:15:11Z

Yeah, I'm aware of that. Which is probably why I don't see much of a performance improvement in Windows. I was hoping it would help in cases where the GPU driver is stalling, like N64 depth compare.

I'm surprised there is no slow down at all in Windows with an NVidia Geforce 980 GTX with sync color buffer to RDRAM.

fzurita · 2019-03-16T13:25:15Z

Ok, it would help if I had frame buffer emulation enabled.

I'm seeing a significant performance improvement in windows with sync color buffer to RDRAM enabled. About a 25% improvement.

fzurita · 2019-03-16T13:50:42Z

With frame buffer emulation enabled, enabling threading is definitely faster in all cases I have seen so far in Windows.

fzurita · 2019-03-16T14:17:54Z

After finding the bottleneck in Windows and fixing it there, it has vastly improved android performance. It went from a 10-15% performance improvement to about a 40% performance improvement in Android.

fzurita · 2019-03-24T12:06:00Z

Ok. I have experienced similar things in Android. That's the reason I automatically kill the emulation process when a game is exited.

I can do this because mupen64plus-ae consists of two processes, one for the gallery and another for the emulation.

fzurita · 2019-03-26T02:59:00Z

Rebasing with master

fzurita · 2019-03-26T03:43:07Z

I did some testing in the Nexus Player. I'm seeing a 78% performance increase with threaded mode.

Edit: In my devices, it seems to be running faster or close to Glide64mk2 now, it's pretty impressive.

dankcushions · 2019-03-26T11:10:04Z

I haven't forgotten this :) I'll try and test it on the rpi3 B+ tonight. I still don't have a great way of benchmarking differences in performance (I know many games with slowdowns on the pi3, but it's not always clear what bottleneck is at play)

fzurita · 2019-03-26T12:25:04Z

@dankcushions you can disable the frame limiter and enable the fps display in GLideN64.

fzurita · 2019-03-30T03:04:07Z

Some additional fixes, added GL_LUMINANCE as a valid color format, aligned the Ring Buffer to 4 bytes, it turns out that some devices don't like OpenGL commands with data that is not 4 byte aligned.

fzurita · 2019-04-01T02:13:29Z

Added fix for #2029.

The fix is to increase the buffered drawer buffer size from 4MB to 8MB.

fzurita · 2019-04-01T04:44:43Z

There seems to be some kind of issue with GlDrawElementsUnbufferedCommand that seems to manifest only sometimes. I'm trying to debug.

fzurita · 2019-04-06T01:46:09Z

Figured out the problem... In cases where the OpenGL command queue gets rather big due to the GPU driver falling behind, the device is literally running out of memory. GlDrawElementsUnbufferedCommand just happens to be the command that is called the most. I'm going to have to figure out a way to limit it.

fzurita · 2019-04-07T02:15:50Z

Ok, all known issues should be fixed.

gonetz · 2019-04-07T09:46:07Z

src/Graphics/OpenGLContext/ThreadedOpenGl/atomicops.h

@@ -0,0 +1,675 @@
+// ©2013-2016 Cameron Desrochers.
+// Distributed under the simplified BSD license (see the license file that
+// should have come with this header).


Should we have a copy of BSD license file in our repo?

fzurita · 2019-04-07T11:38:14Z

Ok, I can pull it in.

fzurita · 2019-04-07T11:58:40Z

The license file has been added for that library.

gonetz · 2019-04-08T03:51:14Z

Thanks! I think it is ready for merge now.
Great work, Francisco!

fzurita · 2019-04-08T03:57:30Z

Great, thanks! :-)

dankcushions · 2019-06-28T13:12:02Z

I'm trying to get some real benchmarking data on the raspberry pi 3 for this one so I can justify turning it on by default for everyone in RetroPie, however i can't seem to get --nospeedlimit working via mupen64plus. we don't use a GUI so it's sent as a command line argument. i am using the dummy audio plugin, VerticalSync is False in my mupen64plus.cfg, but still the games will never exceed 60VI/sec, even in title screens (eg Mario Kart 64), or staring at a wall in goldeneye.

If I switch to gles2n64 video plugin, the speed of MK64 is around double.

Weirdly, if I try the latest beta (ie, on their respective github releases pages) versions of mupen64plus and gliden64 for windows, it runs without a speed limit.

Either this is broken in the latest master, or there's something strange going on with RPI ?

fzurita · 2019-06-28T13:17:47Z

It could be vertical sync being enabled somehow at the OS level.

dankcushions · 2019-06-28T15:40:48Z

I built with the verbose flag, hoping that might shed some light:

2019/06/28,15:06:39.564,mupen64plus_DisplayWindow.cpp:53,VERBOSE, "[gles2GlideN64]: _setAttributes"
2019/06/28,15:06:39.614,mupen64plus_DisplayWindow.cpp:97,VERBOSE, "[gles2GlideN64]: Create setting videomode 320x240"
2019/06/28,15:06:39.615,opengl_GLInfo.cpp:27,VERBOSE, "OpenGL ES major version: 2"
2019/06/28,15:06:40.510,opengl_GLInfo.cpp:28,VERBOSE, "OpenGL ES minor version: 0"
2019/06/28,15:06:40.510,opengl_GLInfo.cpp:31,VERBOSE, "OpenGL vendor: Broadcom"
2019/06/28,15:06:40.511,opengl_GLInfo.cpp:50,VERBOSE, "OpenGL renderer: VideoCore IV HW"
2019/06/28,15:06:40.512,opengl_GLInfo.cpp:130,WARNING, "Async color buffer copies are not supported on GLES2"
2019/06/28,15:06:40.512,opengl_GLInfo.cpp:136,WARNING, "LOD emulation not possible on this device"
2019/06/28,15:06:40.523,TextDrawer.cpp:191,VERBOSE, "Generated a 747 x 14 (10 kb) texture atlas"
2019/06/28,15:06:47.936,GBI.cpp:372,VERBOSE, "Load microcode type: 0 crc: 0x6932365f romname: SUPER MARIO 64"

not very useful, although i can confirm at least that

a) the --nospeedlimit is being respected at the mupen64plus, as all of the 'waiting' messages have dissappeared from the mupen64plus consoleoutput

and b) that on my pi vsync is always on - i switched the display mode to 1080 24Hz, and mariokart runs at 24fps. I think the reason i saw speed ups on gles2n64 plugin, even with vsync locked on, is because it had enough headroom to go from 30fps to 60fps, but gliden64 does not.

I'll get my pi fully updated and see if I can do some sort of standalone gl test to see if vsync is functional.

dankcushions · 2019-07-12T14:57:26Z

so i finally figured out my issue! the problem was that VSync was always on because of this issue: #2070

with that fix, I'm able to exceed vsync with --nospeed limit, so here's some figures for an rpi3B+:

Threaded True:
mario64 title screen: 95-105 VI/S

False:
mario64 title screen: 72-85 VI/S

fzurita · 2019-07-12T15:02:03Z

Great! Sounds like a good improvement.

fzurita commented Feb 23, 2019

View reviewed changes

fzurita force-pushed the threaded_GLideN64_v2 branch 2 times, most recently from 4a1405e to 50d57ff Compare March 7, 2019 06:43

gonetz force-pushed the master branch from 1748887 to d12f9fe Compare March 10, 2019 14:36

fzurita force-pushed the threaded_GLideN64_v2 branch from 50d57ff to 7079108 Compare March 14, 2019 03:36

fzurita force-pushed the threaded_GLideN64_v2 branch 4 times, most recently from 7dfa17c to a12732e Compare March 16, 2019 13:08

fzurita force-pushed the threaded_GLideN64_v2 branch from 52f9f4d to 3bfbef9 Compare March 26, 2019 02:58

fzurita force-pushed the threaded_GLideN64_v2 branch from 34d8347 to bc03282 Compare March 30, 2019 03:03

fzurita force-pushed the threaded_GLideN64_v2 branch 3 times, most recently from 5640caf to 994ccc4 Compare April 1, 2019 02:12

fzurita force-pushed the threaded_GLideN64_v2 branch from 994ccc4 to 3e2a074 Compare April 7, 2019 02:15

gonetz reviewed Apr 7, 2019

View reviewed changes

Threaded GLideN64 calls

cc242ec

fzurita force-pushed the threaded_GLideN64_v2 branch from 3e2a074 to cc242ec Compare April 7, 2019 11:57

gonetz merged commit 5df3f9d into gonetz:master Apr 8, 2019

dankcushions mentioned this pull request Jul 13, 2019

ThreadedVideo = True for GLiden64 RetroPie/RetroPie-Setup#2778

Merged

Threaded OpenGL API calls #2014

Threaded OpenGL API calls #2014

Conversation

fzurita commented Feb 23, 2019 • edited Loading

fzurita Feb 23, 2019 • edited Loading

Choose a reason for hiding this comment

fzurita Feb 23, 2019

Choose a reason for hiding this comment

fzurita commented Feb 23, 2019 • edited Loading

fzurita commented Feb 23, 2019

gonetz commented Feb 24, 2019

fzurita commented Feb 24, 2019 • edited Loading

fzurita commented Mar 5, 2019

fzurita commented Mar 7, 2019 • edited Loading

fzurita commented Mar 7, 2019 • edited Loading

fzurita commented Mar 14, 2019 • edited Loading

gonetz commented Mar 14, 2019

gonetz commented Mar 14, 2019

fzurita commented Mar 14, 2019 via email • edited Loading

gonetz commented Mar 14, 2019 • edited Loading

fzurita commented Mar 14, 2019 • edited Loading

fzurita commented Mar 14, 2019

fzurita commented Mar 16, 2019

loganmc10 commented Mar 16, 2019

fzurita commented Mar 16, 2019 • edited Loading

fzurita commented Mar 16, 2019

fzurita commented Mar 16, 2019

fzurita commented Mar 16, 2019 • edited Loading

fzurita commented Mar 24, 2019 • edited Loading

fzurita commented Mar 26, 2019

fzurita commented Mar 26, 2019 • edited Loading

dankcushions commented Mar 26, 2019

fzurita commented Mar 26, 2019

fzurita commented Mar 30, 2019

fzurita commented Apr 1, 2019

fzurita commented Apr 1, 2019

fzurita commented Apr 6, 2019

fzurita commented Apr 7, 2019

gonetz Apr 7, 2019

Choose a reason for hiding this comment

fzurita commented Apr 7, 2019

fzurita commented Apr 7, 2019

gonetz commented Apr 8, 2019

fzurita commented Apr 8, 2019

dankcushions commented Jun 28, 2019

fzurita commented Jun 28, 2019 • edited Loading

dankcushions commented Jun 28, 2019

dankcushions commented Jul 12, 2019

fzurita commented Jul 12, 2019

fzurita commented Feb 23, 2019 •

edited

Loading

fzurita Feb 23, 2019 •

edited

Loading

fzurita commented Feb 23, 2019 •

edited

Loading

fzurita commented Feb 24, 2019 •

edited

Loading

fzurita commented Mar 7, 2019 •

edited

Loading

fzurita commented Mar 7, 2019 •

edited

Loading

fzurita commented Mar 14, 2019 •

edited

Loading

fzurita commented Mar 14, 2019 via email •

edited

Loading

gonetz commented Mar 14, 2019 •

edited

Loading

fzurita commented Mar 14, 2019 •

edited

Loading

fzurita commented Mar 16, 2019 •

edited

Loading

fzurita commented Mar 16, 2019 •

edited

Loading

fzurita commented Mar 24, 2019 •

edited

Loading

fzurita commented Mar 26, 2019 •

edited

Loading

fzurita commented Jun 28, 2019 •

edited

Loading