Quoting: GuestFrom a programmers perspective if you can manage your own thread priorities, the user can raise the overall process priority appropriately... or some other process manager could.. for example Windows auto boosts the front process's priority.

Moreover, cgroups is Linux specific, and PTHREAD_SCOPE_PROCESS is not. You have more chance of getting it well supported if it works like every other OS does.

Of course, but as I wrote it's not fun if/when there are other processes running on the same machine competing for CPU time with your threads since all the process scope threads in your application is seen as a single item for the global scheduler. Now I have no experience with programming games since I mainly do server stuff, but the problems that you describe sounds more being due to starting more threads than there are cores on the system which makes them compete with each other in the first place.

The Windows auto boost of the interactive thread is perhaps nice for a game but creates havoc for system daemon writers like me (and thankfully it can be user disabled [but only on the system as a whole]) with latencies going completely haywire every time a end user would move a window around and so on.

Quoting: GuestYou are thinking of forked processes, which are copy-on-write. Web servers typically use forked processes for resilience - if a worker sub-process dies, it can be re-spawned and doesn't crash the whole web server. It also provides for process isolation which increases security.

Threads implicitly share their processes memory. Again the confusion here is because threads were originally poorly implemented on Linux as a "hack" on fork().

Yes this particular scenario of a web server such as Apache works this way by forking but it's not mandatory nor is it always desirable. You can avoid heavy overhead IPC:s (and do note that such IPC have a much heavier overhead than the Infinity channel have on a Ryzen type of cpu architecture) and so on by using threads instead of forked processes even when most of the work load is not shared so still, there is no way for the kernel/system to know what to do with threads and a cpu architecture such as Ryzen more than give the developers tools for managing this on their own because it's only them that know if thread A will often share data with thread B but not with thread C and thus pin them so that threads A and B are always running on the same CCX while thread C can roam free wherever there are idle process time.

The problem here is not that the threads have access to a shared memory pool, the problem is that some of these threads actively do work on the same memory locations which if they run on different CCX:es will cause massive amounts of copying over the Infinity channel.

IF this was "solved" by the kernel then the consequences would be that all threads created by a application would be pinned to schedule on the same CCX leaving quite a few cores running completely idle and all this just to handle a particular work load where the threads do heavy work with the same memory.

View this comment - View article - View full comments

Quoting: GuestI'll try to explain PTHREAD_SCOPE better...

As you know, processes on Linux all have a "priority" value, which is how the kernel scheduler picks the next process to be run. Every process has at least one thread, and games often use multiple threads to do things. Each thread in a process also has a priority value, and this influences which thread in a process the scheduler picks to run.

On Windows, OS X and BSD, thread priorities are *relative* to the processes priority. That means when the kernel picks the process to be run, the scheduler can also see which of that processes threads most urgently need attention. The process itself is completely free to set it's threads priorities as appropriate.

However on Linux, there is a bit more of a potted history with threading. Originally the kernel didn't have threads at all, only processes. Threads were later added by creating processes which shared another process's address space. So it's a bit of a bodge really. This is why if you use the right parameters to "ps", you can see threads, and why threads have a pid_t value.

So on Linux, a threads priority isn't relative to it's owning process - its relative to all the other process priorities too. The problem with this is that changing process priority is, quite rightly, a privileged operation... otherwise it'd be easy to starve out more essential system processes by a rogue process setting a high priority. This also means that a process cannot effectively set its own threads priorities. This means a game is unable to hint to the kernel effectively which of its threads should get priority over others. This is often the cause for stuttering in sound for example, because you cant hint that your sound engine thread needs priority over that background IO thread.

On the other hand a process scope is not so much fun if you run other applications at the same time since all the process scope threads in your application will now be seen as a single entity when it competes for CPU time against all the other threads from the other applications. These days the inter thread intra process priority is handled with cgroups but that is not something that I've tried.

Quoting: shirethroneVery interesting read. I like to have background information.
Do developers have to act or the kernel to fix this issue?

This should be a developers fix mainly because what is happening here is that you have a application where several different threads will perform write+read to shared memory, at the same time you have lot's of applications where none of the threads share memory for anyting (like say a web server) so there is no way the kernel might know which of your threads are sharing memory or not so that is not much it can do. So this behaviour should be apparent on any OS as well.

View this comment - View article - View full comments

What's the output from something like cat /proc/cpuinfo |egrep "processor|physical id|core id" | sed 's/^processor/\nprocessor/g' on a Ryzen or FX? Just curios how they tell the system which cores that share the same CCX, which is important to know if you want to optimize your code for architectures such as this.

View this comment - View article - View full comments

Quoting: Mountain Man

Quoting: F.Ultra

Quoting: Mountain ManThere's a SteamOS 2.0? When did that happen?

November 2015 so quite some time ago ;)

That was 2.0?

Yet, 2.0 was when they changed their base from Debian 7 to Debian 8. If I'm not mistaken it was the version they released back when the Steam Machines where to be released.

View this comment - View article - View full comments

Quoting: Mountain ManThere's a SteamOS 2.0? When did that happen?

November 2015 so quite some time ago ;)

View this comment - View article - View full comments

Quoting: Beamboom

Quoting: F.UltraLooks like most negative reviews comes from fiddly controls. Hopefully that is something that they can and/or will improve.

Fiddly controls, camera issues, bad interface, unpolished, multiple bugs... To quote Destructoid:
"I can't remember the last time I had to go to a game's forum to get a bug resolved just so I could advance. It's a lesson in wonderful concept and poor execution."

https://www.destructoid.com/review-diluvion-422788.phtml

I ignored the comments about bugs due to the "to get a bug resolved", too me that sounds like the devs are active and are fixing the bugs as soon as they are found.

View this comment - View article - View full comments

Quoting: BeamboomAnother quite mediocre release with bland reviews getting a Linux port to squeeze out those last dineros out of the project. That's how I see it, unfortunately. :/

http://www.gamerankings.com/pc/194343-diluvion/articles.html

It looks pretty cool, though. I'll give it that.

Looks like most negative reviews comes from fiddly controls. Hopefully that is something that they can and/or will improve.

View this comment - View article - View full comments

Quoting: khalismurWe are happy because Arch is awesome. Nobody compared Arch to Debian or said Debian is not good. If it is also solvable with one command, Debian users should be happy too.
You don't understand that one is happy with their Linux distro??

Because the solution was due to Linux and not due to some specific distro is what badber was referring to.

View this comment - View article - View full comments

Quoting: WendigoI personally don't think it should be the duty of the end customer to ensure payment of the porting companies.
A Linux port of their games gives the original developers a wider customer base and thus a bigger income.
If the developers don't do the ports themselves the porter should be paid per order by the original developer. "Port our game X to platform Y and we pay you X€ for this job."
There should be a one time payment for the porting (+ a software support contract for eliminating bugs after the port).

Basically like it is handled with books.
Translators are usually only paid once by the original author / publishing company and not for every sold book in the additional language.

This has nothing to do with "duty". How many articles do we need from developers that their efforts to port their games to Linux was not worth it before you guys realise that we represent such a tiny fraction of the gaming market?

If i.e Feral would have to wait for publishing houses to pay them for converting games then we would never have gotten any of the games that they have ported so far. Now I don't know exactly how Feral operates but a qualified guess is that they take a financial risk in the hope that game X will sell enough on Linux to be worth the work and then they approach i.e Square Enix and buys the rights for the Linux and Mac versions, where the cost for this rights can be either a one time fee, a percentage of sales or a combination.

Some one have to pay for all of this somehow or the work will not be done, if the Linux gaming market would be huge enough then the publishers would pay for this and none of this discussion that we have would happen but we are not there (yet) so the publishers won't pay. And the porting companies cannot carry the payment since this is their income so all that is left is us the customers. There is no way around this as the situation is right now regardless of what might be "right".

View this comment - View article - View full comments

Quoting: Leopard

Quoting: bubexelYour ideas are just a problem to people to give a try linux. I think companies should pay a fixed price to porting companies and not make them gain cash for the sales.

Then that is porting companies problems.They must do better contracts,why punishing users because of that?

I don't want to say this but these companies are not so Linux dedicated,which is why you stop worshipping them.

Let's take a look at the Aspyr.Look at their direction.They just tied up with some little studios and started promoting Windows and XboxOne versions of this games first.If others get a chance like this,they will storm away from Linux at a glance.The reason of they're porting games to Linux,there is not so much competition here.

They're all doing it for money and they can live on with current payments.

If you are looking for a real hero;take a look for Loki.

Even Valve is not doing that for favor of Linux;they simply scared from MS Store and most possible place was Linux.

If MS says that 'we're closing MS Store' Valve will also stop SteamOS development.

The porting companies have to survive somehow, they are not charities! They cannot get better contracts because the Linux gaming market simply isn't that big so it does not matter one bit how things should be in a perfect world because we are not in that perfect world (at least not yet).

The simple truth is that if we want to have games ported then we must give the porting companies some incentive to do so or they are forced to search for other markets (like OSX) or simply close shop. There simply is no way around this at the moment.

That said I'm personally not troubled by this since I have never bought any games on or for Windows ever.

View this comment - View article - View full comments