Threading about openrhythm

[mdsitton]

I would rather not use OpenMP. It seems like it could be nice if you want to speed up stuff that is more sequential in nature. So I'm not sure it would be all that useful for us.

I think the traditional thread route would be better as long as we can reasonably figure a decent way to spread the workload around.

One idea is to look into implementing some form of thread pools. Basically we would setup a fixed number of threads based upon the number of cpu cores. The threads would always be running. Then we would queue up work to the threads. Certain things probably wont be able to be multithreaded, for example most windowing apis require you to only use the window from the thread you created it from for example. So we would probably need a few fixed threads, along with some threadpools to handle the other work.

[mdsitton]

However despite needing to do window/event stuff from the main thread. OpenGL should work from a thread that is separate from the main thread though i would need to experiment with that somewhat... I'm curious if that would allow us reduce input latency any :P

[mdsitton]

Though if we were going to go that route I would want to implement my own native Win32 and X11 windowing support. Because i think for X11 threading OpenGL is a bit more Finicky, I know its allowed on windows though.

[Salamandar]

I think you didnt understand one thing : I didnt mean it was one implementation or the other ;)
For instance I think that audio on-the-fly decoding could be speed up a (very little ?) bit with openMP. And SoundTouch uses (optionnal) OpenMP anyways ;)
I see what you mean about windowing, i've done enough GTK+ to know it ^^
Using thread pools could be a good idea, although we usually will have "fixed" tasks for the whole app lifetime. And I don't want some tasks to eventually block the app because we only have 2cores :p

[mdsitton]

Just as an update to this I did do that experiment with running opengl on a separate thread from the window event thread. It helps immensely with getting more accurate time stamps for input events, which i think will be very very useful when doing note hit detection.
So i really would like to transition everything to use this if possible, and move away for sdl2(it gives event timestamps but i just don't see them being as accurate as I want). The other option if a platform gives very accurate time stamps without needing to do a separate events thread then we wont need another thread for it(and if SDL2 uses the data the platform its running on for its internal timestamps then we can even use sdl2 for that platform as well).

[Salamandar]

That's a good thing then :D Even on Windows ?

[mdsitton]

Well the current thing is I know i can do it on windows, i'm not sure about linux or mac yet.

[Salamandar]

Well as I said in #17, we don't need to create a thread for the audio tasks, LibSoundio handles everything. Right now I don't think the code in soundio.cpp is multithread safe but I'll come around that. It's basically a non-issue right now.

[mdsitton]

The problem last I looked soundio is blocking unless you've changed its usage so it doesn't

[Salamandar]

It's not blocking "anymore". The only blocking function in libsoundio is wait_events and can be replaced by a regular call to flush_events. Its only purpose is to send the SoundIo::on_devices_change and SoundIo::on_backend_disconnect callbacks if needed.

[mdsitton]

Oh alright, good to know. I looked at it briefly a while back to see if there was something other than wait_events but didn't immediately find it.

[Salamandar]

Yeah. And my soundio wrapper exposes soundio_flush_events as a direct call to flush_events(&soundio)

[mdsitton]

Something i was thinking about, with the new rendering architecture the main game thread can probably be ran on a totally separate thread from the rendering thread.

[mdsitton]

My current short term plan for this is to just haphazardly add extra threads where they make sense. Longer term i'd like to have some sort of task system where tasks can be launched as a thread.