I only get about half CPU usage, which would suggest that it is only using one thread; supported by Light saying that tron doesn't support multithreaded CPUs.
Will there be any future support on using all threads on a multithreaded CPU? My hopes are that this will improve performance in both clients and servers.
Multithreaded CPUs
Re: Multithreaded CPUs
Yep, almost all of the work is done in a single thread. That's unlikely to change, though I suppose we could technically do game updates in two steps: First all the objects do their raycasts, then they do their updates. Since the raycasts don't change any data, they can all run in parallel without issue.
That's not a change you just do easily, though.
Plus, on the client side, if your multicore CPU is maxing out one core, that means you have a multicore CPU and even a single core will be doing one of two things: Waiting for the VSync (NVidia drivers, for example, don't let the CPU enter idle mode then) or telling the GPU to render far more pixels than your monitor can display.
Or wasting time in inefficient graphics code. We're still using OGL 1.2 mostly, IIRC that can't be divided between threads.
That's not a change you just do easily, though.
Plus, on the client side, if your multicore CPU is maxing out one core, that means you have a multicore CPU and even a single core will be doing one of two things: Waiting for the VSync (NVidia drivers, for example, don't let the CPU enter idle mode then) or telling the GPU to render far more pixels than your monitor can display.
Or wasting time in inefficient graphics code. We're still using OGL 1.2 mostly, IIRC that can't be divided between threads.
- Lucifer
- Project Developer
- Posts: 8683
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: Multithreaded CPUs
There's also a surprising issue that shows up when/if we look seriously at an Android port: Android's threads are far from POSIX-compliant. In that environment, we're going to want to still be able to support running in a single thread, if only to avoid silly bugs that show up because the c library on Android is a crippled mess.Z-Man wrote:Yep, almost all of the work is done in a single thread. That's unlikely to change, though I suppose we could technically do game updates in two steps: First all the objects do their raycasts, then they do their updates. Since the raycasts don't change any data, they can all run in parallel without issue.
That's not a change you just do easily, though.
I found a library that maps OGL 1.2 to OpenGLES (is that the one on Android?). The website advertises it as a drop-in replacement, but I haven't gotten around to actually trying it out to see if that's true. I linked you to it in irc one time. If you have chat logs you can search, you just have to find me talking about OpenGLES.We're still using OGL 1.2 mostly, IIRC that can't be divided between threads.
Re: Multithreaded CPUs
People tried such automatic conversion before, performance was insufficient. Of course, that was years ago and things may have changed.
One low hanging fruit for multicore optimizations could be the various raycasts; they have read only access to the grid datastructures and could run in parallel. You'd just need a shared_mutex to lock the whole thing, with read access using a shared lock and write access a hard lock. And the raycast interface is small enough that turning it into an async interface would not be prohibitive. In the past couple of years, C++ and some support libraries have done a lot to simplify such schemes.
One low hanging fruit for multicore optimizations could be the various raycasts; they have read only access to the grid datastructures and could run in parallel. You'd just need a shared_mutex to lock the whole thing, with read access using a shared lock and write access a hard lock. And the raycast interface is small enough that turning it into an async interface would not be prohibitive. In the past couple of years, C++ and some support libraries have done a lot to simplify such schemes.
- Lucifer
- Project Developer
- Posts: 8683
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: Multithreaded CPUs
It would have to be a several step process. First, see if it builds and runs. Keep it a build-time option. Second, start migrating major bits of code to OpenGLES, you know, the ones that are truly performance-intensive. Third, check performance, rinse and repeat.Z-Man wrote:People tried such automatic conversion before, performance was insufficient. Of course, that was years ago and things may have changed.
There should be a point where we get comparable performance while still having OGL code laying around, because as I understand it, OpenGLES performs much better overall for the same features being used. That would be the point to start playing with an Android port, where it wouldn't surprise me at all if performance started suffering again.
Another thing to look at would be GCC compiling C++ to java byte code. I don't know if they still support that target or not, but it would be worth finding out how well arma runs under it, since supporting a C++ program across different Android devices can be quite difficult, but supporting a Java program isn't too hard.
This is all "what if", of course. I just got fuel injectors for my wife's car, so I know what project I'm doing next.
Re: Multithreaded CPUs
I'm certainly not going to do any of that! Sounds like fiddly work. I'd rather just piece by piece restrict our usage to the GLES subset. It's not going to cost us any performance on the desktop, I'd rather expect it to do the opposite. And I'd definitely leave the issues from third party libraries to someone else.