Quoting: damarrin

Quoting: ShabbyX

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!

The SD has ABXY buttons, but not RB/LT etc. For some reason, Valve decided to take these from Playstation and they’re L1,R2 and so on. Plus, the shape of the d-pad is very different to the one from Xbox 360, which still seems to me as the most popular controller, so the icons will still be wrong if a dev does nothing.

I personally wish they would use full blown Playstation buttons. Never really used an Xbox controller except at friends places (I did have one for my rpi at some point). They just do not feel right in hand, Dualshock tends to feel way better, and D-Pad was quite mushy on the x360, so not a big loss I would say ? And considering the outcry every time a game dev removes the ps button when they port to PC, I doubt I am the only one who prefers dualshock. I also don't think x360 is all that popular ? Maybe in US, but worldwide I highly doubt it. Maybe it had some extra usage due to being easier to setup at some point, but I don't think it was out of love.

View this comment - View article - View full comments

Quoting: Purple Library GuyInteresting that they finally caved on GBM. I wonder why, and why now?

What @Hooly said, plus they were very very alone. As I understood, even the Android world has gone GBM.
As far as I understand EGLStream was supposed to be standard outside of GNU/Linux ... But nah, it's not. So considering technically it is a mixed bag between both, might as well go with the flow.

View this comment - View article - View full comments

Quoting: ShabbyXSure, 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.

I think here the point is more that eventfd does not scale for that particular purpose. And I guess that is very general to thread synchronization because all synchronization (mutexes, semaphore) in Linux has been made around futexes for quite a while.

Quoting: ShabbyXEverything 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.

Well, you can see futexes as an extremely low overhead fd too. For signals ... They are a different beast. They basically break the illusion of user space applications that all their context is safe at every point. That nothing will come and trash their current state. Basically, you bring in kernel like issues in user space. They have their use sometime, but the only way to fix em, is not to use them really. Turning them to fd won't fix anything. You can read the comments about signals in kernel code, you will see how much the kernel devs love them :)

Quoting: ShabbyXI 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.

eventfd 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.

View this comment - View article - View full comments

Quoting: ShabbyXI wonder why they didn't instead try and make eventfd more efficient?

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

Long 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.

More 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). Futexes are generally made to be accessed many times too - they were made to deal with heavily multi threaded workloads synchronization. So, futexes are in principle a better tool for the task at hand, but they actually miss a couple of syscalls around them to match the need. Well, the solution which has been chosen is to add a syscall to be able to wait on multiple futexes, which is the need here. Futex2 is kinda misnamed from what I saw of the patch, as it just adds syscalls around futexes, not a whole new concept/object - at least that's what I saw. The need of waiting on multiple futexes is also sound, and seems reasonable to me. So solving that need once and for all does seem like the thing to do. And it gives a cleaner/better solution to the problem at hand than eventd.

View this comment - View article - View full comments

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

Well, saying that gaming has not been the scientific focus on Linux would not be a big surprise right ?
From there on, it figures that for at least some cases windows has some better mechanism for gaming related workloads. Also, this just takes some ideas from windows and extend a linux idea (futexes), not an implementation from the windows syscall itself.

Generally speaking, all OSes have their pro and cons, and looking at your neighbor for some inspiration is always a good idea. As long as you do not blindly copy :)

View this comment - View article - View full comments

Quoting: MohandevirIs Pipewire the solution to the long standing audio degradation issue with PulseAudio, when it comes to in-home streaming from a Linux host?

I have to disable all HDMI audio devices in Pavucontrol of the host computer to prevent that from happening.

I am not sure for in home streaming, but for local audio, it already solved quite a few quality issues and bugs for me. In particular, with the latest bluetooth work, LDAC is finally working properly for me. And overall audio seems to be less prone to crackling which I had with pulse.
Hope this helps.

View this comment - View article - View full comments

Quoting: subIntel will have a hard time to reestablish trust in the reliability of their manufacturing processes.

"Real man have fabs" is a thing from the 90's. With more and more complicated processes, you're
better off leaving it to external partners. The risks nowadays seem to outweigh the advantages by far.

Hmmm I would not be so categorical. The reason why they fell behind was much more a shitty management than bad engineering or even business model (having their own fab). They also did change course in the opening of their fabs to others, which seem like a sane idea.
Having your own fab avoid being stuck in a shortage as an example... It can also allow you to have better integration, more iterative passes on your design. So it is nothing to laugh at either.
As for the quality of their nodes, in term of density, their superfin node fell somewhere between TSMC's 5 and 7. So the renaming might actually make complete sense, they simply align relative to the naming used by TSMC. It has been years that the "nm" at the end of the name did not mean anything anymore. And it tended to cause confusion. Confusion that some other founders did use to their advantage.
Now, Intel is still relatively late for TSMC's 3nm equivalent, but it seems they are finally on track to catch up.

View this comment - View article - View full comments

Quoting: Lofty

Quoting: subAnd we're left with a system that runs with a graphics driver blob only.

*meh*

And runs windows games via a compatibility layer. So how much left is running FOSS, not to mention any DRM that gets added to the kernel for compatibilities sake and potentially invasive anti-cheat if it is not handled properly.

The future of Linux gaming is sounding more free and open all the time .. :whistle:

yeah, not an ideal world. Nvidia is on an open source streak though it seems. So one can dream for the driver.

For the compat layer, I think it is a good first step. Espsically, I highly doubt Nvidia will be big enough to suddenly lock everything to their solution, but it might just be the drop that make a dev support linux.

View this comment - View article - View full comments

Quoting: CatKiller

Quoting: slaapliedjeMaybe if we ask nicely they'll do it.

I suspect that the more they have open source development, the more open source development they'll want to do. It's fundamentally really pragmatic. Baby steps.

Seeing that open sourcing something did not kill the company is indeed likely to give more voice to those who prefer open source inside the company.
Now it will also depend on what you want to open source. Kernel/vulkan driver, I think this is the sense of history. But for their money makers, especially those who could be reused by competitors .... More complicated. CUDA, I have doubts, albeit it is not impossible (but one of the core advantage of CUDA is to be nvidia only, as it ends up giving much nicer code compared to more generic approaches until now.) DLSS, I have insanely high doubts for the short and mid term, as they have something fairly unique (the NN and its training set), yet mot that hard to flat out reuse by competitors. As such, the cost of open source is potentially high, whereas the benefit is low.
Conversely, driver opening cost is likely very low (pretty much riskless, only some legal stuff), but potential gain is high (user satisfaction, secure boot, image, and lower maintenance cost). So I have good hope that it will come.

View this comment - View article - View full comments

Quoting: Purple Library GuyWhat I'm wondering is if industries like say animation might be looking at moving towards ARM and that might be part of what's driving this kind of thing.

I think Apple M1 showed that it is possible to live without x86 and it created some appetites ... Imagine if Nvidia does manage to buy ARM, then make some kind of laptop, with Nvidia GPU inside. They do not have to pay either for CPU, not even a license, neither for the OS. So they can capture much more value than if using x86, or third party ARM, and losedows. (a losedows OEM license costs around 50€, so it is nothing to laugh at). If you have good x86 compat layer, relying on custom ARM chip with good HW accel for it, and you ride on Valve's proton for the rest, it seems awfully possible now. From business perspective at least, it makes sense.

View this comment - View article - View full comments