Multy Threading, Limitations in a LWJGL context

Game Mechanics
#1

I have looked everywhere for a definitive answer to the limit of threads and cant seem to find an answer.

I have heard the max amount of threads you can run (At peek efficiency) is equivalent to the amount of cores your processor has, but then i have heard counter arguments saying that you can have more or less dependent on the complexity of the task and the power required.

What I want to do is run multiple OpenGL Contexts and have; 1 thread as the logic, 1 as the render and 1> to render my randomly generating 3D world. Now should i follow the pretext that one core is equivalent to one thread or what?

#2

As far as the topic goes you can create as many threads as you want. It is likely that most of the threads will not consume 100% of one core (and if it is that is not good for the processor) so you can have multiple going at once.

Now for my opinion, I really don’t recommend more than one thread with an openGL context. The reason is that, for starters, you probably don’t need it. Secondly it sounds like you’re just getting into multi threading which if that’s the case you’ll most likely have a difficult time getting all your threads lining up in the first place not to mention throwing rendering into the mix.

#3

I would refrain from doing so (for now). Multithreading is quite a difficult beast, especially with OpenGL. It might work here, but won’t somewhere else, depending on your own expertise handling threads as well as the OpenGL driver implementation. This might all get better with Vulkan, but it would also be more involved.

If you need to do stuff “in the background”, offload your tasks to a threadpool, but only access the OpenGL context from one single thread. Here is an example how to do this: http://www.java-gaming.org/topics/workerthread-how-to-pass-an-undefined-method-to-be-executed/35568/msg/337145/view.html#msg337145

As for your question: a rule of thumb might be number_of_threads = number_of_cores - 1, but unless you are writing the 7th iteration of an AAA game engine, just throw any number between 3 and 7 in there :wink:

#4

I agree with @thedanisaur and @cylab.
Unless you absolutely and 110%-ly know what you are doing when using multithreading - especially in the context of OpenGL - then using multiple threads will make your performance worse, and even more so
synchronization efforts and the restriction of only being able to use one thread at a time per OpenGL context will introduce an unnecessary complexity into your application that will also give rise to all sorts of hazardous happens-before issues due to potentially incorrect/missing synchronizations.
Multithreading issues can cause alot of trouble and weeks and months of tracing bugs that only happen sometimes. But one has to go through it to understand how horrible it can be. :smiley:
At least if you are not very comfortable with multithreading, I would recommend not doing it. If it is for the purpose of learning it and going through a lot of pain, then of course, do it! :slight_smile:
And using multiple OpenGL contexts when you don’t need multiple windows, possibly just because thinking you can pump more OpenGL calls per time, also with possible resource/context sharing, will make things even worse.
If you don’t run into any performance issues right now that can be solved by parallelism, then I’d just start with only one single thread in total that does input processing, logic update and rendering.
Start small and build things up as you progress and as you need.

#5

This is false. I want to dispel this rumor cause I’ve ran across it a number of times, not cause I’m trying to be a jerk.

If you have 20 threads that run at 1hz you’d be absolutely fine on a modern cpu (hell a quad core 3.4GHz could run how many more?). I’m not saying it’s a good idea (or a bad one) to have that many threads doing small tasks, but you can have literally as many threads as you want the only limit is total processing power of the cpu.

There are obviously other things to consider, such as OS resources and the fact that you don’t need to (and shouldn’t) max your cpu just because you can.

Note: Don’t make threads haphazardly, but if it makes sense to make another thread go for it. (This comes with experience)

#6

I wrote might for a reason and you are equally false if you write that it doesn’t matter. There are costs for context switches involving backing up CPU registers to memory, switching to code accessing non-cached data etc.

So we just need to accept, that every statement is false for sure until the real performance is measured against the real use-cases. :stuck_out_tongue:

#7

[quote]the only limit is total processing power of the cpu
[/quote]
:wink:

but that’s exactly why I had to respond, this conversation should be had.

#8

Thanks guys! So unless your great at OpenGL the its pointless

#9

Not exactly, it’s just that you probably don’t need it. The fact that you asked such a high level question about it (not the details) means that you haven’t started working on implementing it, which usually means that you haven’t ran into a bottleneck where you’d need two render threads at the same time.

Where it would be useful though is a loading screen, since you won’t be rendering on both at the same time, and that’s pretty easy once you’ve got the hang of multi-threading.

#10

In my 3D World, I only multi-threaded the chunk generation. There was no need to create a (bigger) mess by also multi-threading the rendering.

#11

That’s what i was planning to multi thread but I found a solution where i get my tick thread to calculate chunks that need to be generated and it stores it in a array, then my render thread renders ~1 chunk each frame dependent on how long the chunk took to render and whether or not it will affect the current FPS… I suppose I could multi thread this soon, but I cba.