Quoting: ShmerlBasically, don't rush to buy it, until someone (Intel I assume?) will add such scheduler for Linux (if you are even considering it). In general Intel are good at doing it though so it should appear at some point.

Linux has been doing this for years for big.LITTLE, asymmetric multiprocessing is nothing new for Linux.

View this comment - View article - View full comments

Quoting: SalvatosDue to "appropriate controller input icons" alone, I feel like a lot of games will fall short of Verified. I rarely see the right icons for my DualShock.

Same with me, but note that they need the game to show the Deck's icons correctly (i.e. xbox icons), not all controllers!

View this comment - View article - View full comments

Quoting: Arehandoro

Quoting: robvv

Quoting: ArehandoroNo different to the fact that if Steam were to go bust all our games would not work either, not downloadable.

Assuming that you have many of your games already downloaded, they will still work just fine (except some Feral titles). Some may require the Goldberg emulator to run but that's about it.

Without Goldberg Emulator after a giving time you wouldn't be able to log in to Steam, and not all games work directly with the executable without Steam. Not counting all the features integrated that games have that rely on Steam.

If Steam shuts down, I have no doubt some open source project will spring up and implement the API. People won't just let so many games go to waste.

View this comment - View article - View full comments

Speaking of wasteland, I just started playing Wasteland 2 (DC) for the first time since a few weeks ago. Damn it's a good game!

View this comment - View article - View full comments

Quoting: 3zekieleventfd is actually efficient enough for its purpose I would expect. But the issue is, the inner counter is - by spec - maintained by the kernel. So it means many round trips between kernel and user space ... Which will limit perf, and I guess that is why you can not just poll it as much as you want. And that is the syscall spec, can't do much about it.
Futexes on the other hand were made so that you only go to kernel space if you can not take the lock ownership/if the semaphore is at 0 (basically a yield). So you have much less round trips with futexes. They are also stored as a simple `intptr` (an address) whereas eventfd looks like that:
struct eventfd_ctx {
struct kref kref;
wait_queue_head_t wqh;
/*
 * Every time that a write(2) is performed on an eventfd, the
 * value of the __u64 being written is added to "count" and a
 * wakeup is performed on "wqh". A read(2) will return the "count"
 * value to userspace, and will reset "count" to zero. The kernel
 * side eventfd_signal() also, adds to the "count" counter and
 * issue a wakeup.
 */
__u64 count;
unsigned int flags;
int id;
};
From the look of it, eventfd will be more real time (you will wake up as soon as something happens if you have the priority), whereas futex side, you will wake up at your next quantum clearly (I only see mechanism unsuspending you, nothing scheduling you). Futexes also do not hold a list of who is waiting, they are just a counter. So the first one who comes and retake the lock wins seems. It's coherent since the scheduler is fair anyway.
So I would say, they just fill purposes that are orthogonal. I would typically use eventfd for IO related waits, or if I need something a bit more real time. And futexes for all the rest.

Ack. I don't know eventfds well enough to actually have a proposal to improve it. But agreed, having futexes go through the kernel unconditionally is completely in contradiction with them being futexes, so a new syscall is reasonable.

View this comment - View article - View full comments

Quoting: 3zekielShort answer: they kinda already tried that at first, and judged it to be a dead end.

Fair enough.

Quoting: 3zekielLong answer:
Modifying an existing (set of) syscall(s) is extremely limited. You can not break compatibility in any way, since that would break thousands of apps, with no way for users to fix it. Contrary to libraries, you can not just install another kernel, or use a lightweight container to fix a kernel ABI breakage. So all issues with that syscall set are pretty much set in stone.

Sure, but that doesn't mean you cannot provide the same functionality more efficiently. The point was eventfd doesn't scale, and making that scale doesn't necessarily have to interfere with its functionality.

Quoting: 3zekielMore generally, it seems more natural and clean to use a tool that is actually made to fix your issue. File descriptors (which eventfd is based on) are made to deal with file-like stuff (that's a lot of stuff in Linux). Futexes are made to deal with synchronization issues. Futexes are also made to be used in large numbers, file descriptors... not that much (the overhead in memory and so on).

Everything is a file. In fact the few things that Unix didn't make a file turned out to be the most problematic areas (pids and signals notably). At least the pid problem is remedied with fds (pidfd), and if signals aren't already, I'm sure they will be turned into fds too.

I said all that to say that given how central fds are, it's worthwhile to make sure eventfd is actually efficient, rather than keep trying to work around it.

View this comment - View article - View full comments

Quoting: jordicomaWhat? A functionality coming from windows world that its good?

It's not necessarily good. If windows has feature X, games will depend on it. Now it may have been better if games did Y instead, but that doesn't exist and they are stuck with X.

Just because Linux now needs a way to implement X doesn't mean that X was the best option, just that because of windows we are now stuck with it.

View this comment - View article - View full comments

I wonder why they didn't instead try and make eventfd more efficient?

View this comment - View article - View full comments

Quoting: GuestWhy make parts readily available if you’re telling us it’s a bad idea to replace them?

To be fair, they did mention a few times in the video to "leave it to the professionals", which sounds like they do think it's ok to repair / change parts, just not by any rando with a screw driver.

View this comment - View article - View full comments

Quoting: elmapul

Quoting: ShabbyX

Quoting: BielFPs

Quoting: ShabbyX

Quoting: BielFPs... that Phasmophobia requires Cortana to use the voice functions of the game, ...

Wow, that's so braindead.

They did this to take advantage of the Cortana's AI, despite the "Windows dependency" part, I think this was actually pretty smart of them.

That's a sure way of making sure your game is completely unplayable in 5 years is what that is.

at the worst case scenario, they disable this feature and the game do work.
you seem like someone who prefer an game to never exist than to exit for a few time.

Disclaimer, I know nothing about this game, if the feature is entirely optional, then sure, that's fine.

If it's a core part of the game, then making it depend on some tech existing and shipping by the operating system is braindead. API's change, technologies change, it's not like the Cortana API has been standardized. In a few years Cortana will change enough that the game would be borked.

Adding voice recognition to games is a smart idea, sure. Just the technology used to implement it was wrong. They could have used some third party library (open source preferable of course) they could ship and not worry about it changing.

Again, if the feature can be disabled and is entirely optional, then sure, go nuts.

View this comment - View article - View full comments