You can sign up to get a daily email of our articles, see the Mailing List page.
Latest Comments by Creak
Civilization VI released for Linux, video and port report (updated)
10 February 2017 at 5:24 pm UTC

Quoting: M@GOidCheck out this image I putted in my first post on page 1. There is no way a FX8350 would be on par with a Core i7 4770k if the game is only mono-thread in Windows. And pay attention to the i7 in the top spot, is a 8 core part, like the one Liam uses.
Indeed.
It would need more investigations though, just to be sure that all the cores are effectively used.
Now, if it's true, I'd really be interested in knowing why Asypr couldn't have multi-threading on their port (and I'm talking about the whole game engine multi-threading, not just the renderer). Maybe that was the part of the "evaluation" problem.

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 3:52 pm UTC Likes: 4

I know that I won't change the mind of all the users in this forum, but if I can convince you @liamdawe that GL threaded is good, but not "that good", and that the game engines can be multi-threaded even without the GL threaded feature. Then maybe you would post new articles that won't get the hopes too high for your users.

As a developer in the game industry for 11 years now, I have some knowledge. I completely understand that you don't have to trust me on what I'm saying, but you have access to people that you trust more (Valve, Feral, Aspyr, ...). Ask them your questions like: "is it possible to do some multi-threading in a game engine even though there is no threaded GL?" or "What kind of algorithms can be multi-threaded in an engine apart from the 3D part?"

On my side, I won't say more about this, because I can feel that I'm getting angry at fighting against hopes and beliefs, and that can be very frustrating.

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 3:35 pm UTC

Quoting: liamdaweThat's outdated, it's now enabled by default in the driver and NVIDIA stop if it detects that it's reducing performance...apparently.

See this driver update: https://www.gamingonlinux.com/articles/nvidia-37809-beta-driver-released-adds-opengl-threaded-optimizations-by-default-and-more.8940
Be careful here, they're just talking about the threaded GL optimization. My link is about all the other tweaks that are done in the NVIDIA drivers and are game specific.

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 3:32 pm UTC

Quoting: STiATThey need to get this done, and it's a lot of work. That's why I always say be careful, we'll probably not see the first real DX12/Vulkan games before next year. They're using the technology, but by far not optimized.
I completely agree. I was referring to Vulkan because of the same feeling that "Vulkan will save us all" but for threaded GL.

To be perfectly clear, I never said threaded GL is a bad idea. It's a very good idea in fact. But it won't have the effect on performances that most of the forum users here seem to hope.

A game engine that only use 1 cpu has a lot more problems than Vulkan or threaded GL!

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 3:26 pm UTC

Quoting: MblackwellNvidia's current driver doesn't have a whitelist for multithreading, instead it enables it on everything and performs some heuristics and disables it on the fly if performance is being affected.
I'm not sure it's "on the fly", I think it's more integrated profiles for specific games, as better explained here: https://www.quora.com/How-does-Nvidia-optimize-specific-games-via-driver-updates?share=1

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 2:54 pm UTC

Quoting: CreakAbout the whitelist, today it's "just" threaded GL, but if we open this door, a lot of other features will get in this whitelist as well.
Well.. it was even faster than I expected... :(
http://phoronix.com/scan.php?page=news_item&px=Mesa-RFC-DRIRC-Compat-Change

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 2:44 pm UTC Likes: 1

I think that GL threading is definitively not the silver bullet. I know... I keep posting that everywhere, but GL threading is almost the same as the threading capacities in Vulkan. And in the end, look at the benchmark differences between OpenGL and Vulkan: zero. Some games win a bit, but not that much, and some games loose a bit too.

For instance, look here: http://www.phoronix.com/scan.php?page=article&item=mesa-17-radeon&num=1
The improvements between 13.0 and 17.0 are very impressive on the RADV (kudos to the devs!), but if you compare the 17.0 results in Dota 2 for Vulkan and OpenGL, OpenGL wins all the time! And as for The Talos Principle, Vulkan is now just on par with OpenGL performances.

I'll repeat that again: multi-threading the renderer is, of course, a good thing, but a game engine is not just a 3D engine.

Edit:
About the whitelist, today it's "just" threaded GL, but if we open this door, a lot of other features will get in this whitelist as well.

Getting the 'threaded GL dispatch' code into Mesa is causing some issues, Valve might use a white-list
10 February 2017 at 2:26 pm UTC Likes: 1

Oh "whitelist"... I don't like where this is going...

This is exactly what proprietary NVIDIA and (ex-)AMD drivers do and it has a lot of repercussions on the maintainability and stabilization of the drivers. It is also a pain in the ass to debug since each and every games will have their own special tweaks specified in the drivers, which means more code paths to debug.

Oh this is a BAD idea..

Civilization VI released for Linux, video and port report (updated)
10 February 2017 at 1:01 pm UTC

Quoting: TheRiddickWondering if the GL Threading patch that's being worked on could help this title since its CPU bounded pretty hard?
As I said in my previous comment, multi-threaded OpenGL is not really the problem here. Sure, multi-threaded rendering would help, but not that much. A 3D engine is just a part of the whole engine, multi-threading it is good, but it's not the silver bullet you would expect.

It's the whole engine that has to be multi-threaded and take the most of the CPU cores. And if OpenGL is a problem, you keep it synchronized on one core. Yes, it's going to be a bottleneck, but at least everything else in your frame has been multi-threaded and that is here that you will win the most.

Actually, I would really be interested in CPU consumption on Windows. If it's the same as on Linux, it means that Aspyr simply did their best, but if it has multi-threading, it means that Aspyr could really do better with their ports.

Civilization VI released for Linux, video and port report (updated)
10 February 2017 at 2:12 am UTC Likes: 2

Quoting: liamdawe
Quoting: M@GOid
Quoting: liamdawe
Quoting: M@GOidMultithread is bad in OpenGL? Well, call me skeptical on that.

Anyway, 4A and Feral did it, so technically OpenGL is not blocking a multicore CPU utilization in Civilization VI.
Seriously? Go do some real research you're rather wrong.

Calm down man, I didn't mean to be disrespectful. If I was wrong you could explained why in a more relaxed tone, like M@yeulC did.
I'm perfectly calm :). Just don't see the need to repeat details that are basically common knowledge. I did already say to watch the video of Dave from Red Hat talking. Both Aspyr and Feral have previously explained limitations of OpenGL as have many others. Khronos themselves said about when giving the benefits of Vulkan. It goes on and on.
I think something was miscommunicated at some point.

OpenGL does have a problem with multi-threading, but it doesn't mean that you absolutely can't do anything on the other threads. Multi-threading is a problem with OpenGL when CPU-GPU communications are involved. But CPU-CPU communications are completely allowed. For instance the animations are very often just CPU-only, and for this, it's possible to send jobs on other threads that will compute the animations and get the result before the render pass. And depending on the engine, you can multi-thread quite a bunch of things. In an engine, the 3D part is just a small, important part of the whole, but not everything revolve around this 3D part.

I'll try to find some documentation to prove my point.

Edit:
This codeproject article is a good example that OpenGL and multi-threading are possible:
https://www.codeproject.com/articles/15344/a-multithreaded-opengl-enabled-application

And this too:
http://gamedev.stackexchange.com/questions/90762/taking-advantage-of-multithreading-between-game-loop-and-opengl

Edit 2:
All that to say that I'm pretty disappointed by the CPU usage of the Civ VI port. I would really like to hear from the Asypr devs about why they couldn't multi-thread a little bit more. Normally, when you optimize your engine, you try to max out your CPU cores. In a game engine, a core that does nothing is a wasted resource.