Oh, thanks. It's not a black box for me, so I must have glazed right over it.

View this comment - View article - View full comments

Quoting: Liam Dawe

Quoting: Luke_Nukemmore than one person

Good to know, have adjusted the text to be clear.

Thanks mate. Tried to find a button or link to send article feedback but couldn't see one.

View this comment - View article - View full comments

Quoting: slaapliedjeThis just reminds me of all the talks about Windows switching kernels to use Linux. How many little weird things out there like RGB lighting or special features require Windows applications (not even talking drivers here) to configure all the features that wod never work with different kernel drivers?

So much of this stuff would be trivial for the actual vendors to implement rather than community members trying to reverse engineer stuff. Gettign the backlight for these keyboards working was as simple as possible, all the work was already done at the kernel level and only the init sequence and a struct was needed. Same for the extra fn-keys. So trivial it was annoying because ASUS could have bloody well done it in an hour or less.

The same can be said about the per-key RGB stuff. I painstakingly used wireshark and ASUS Armory Crate to set each individual key and capture the packet, then create a spreadsheet of how it all works. ASUS could have released an OSS lib for this, or even just a document.

Do you know how long it would take ASUS to fix sound for all these laptops? They have the specs, all the kernel framework is laid out bare and ready, it would take maybe 15 minutes per laptop with the spec handy. Instead we have to fart about with trying to divine the secrets of the inner working by trial and fire.

View this comment - View article - View full comments

Jones here.

Just a quick amendment regarding

QuoteJones also mentioned to us that they're "also working on sound fixes for some of these latops, such as G14 and G15. Though time is slim, and the work hard. GX502 had sound fixes for audio jacks merged a while ago.".

"they're" is more than one person, the prime mover for the G14 sound is ZappeL (on our discord), but they have a lot on their plate right now with starting a business. A lot of the work is helped by many people contributing in various ways from providing dumps of settings, dumps from windows, testing etc. the Realtek stuff is a frustrating mess with a lot of vendor specific stuff.

View this comment - View article - View full comments

Quoting: dpanterBTRFS as default on a desktop distro... guess we'll find out how that experiment turns out before long.

openSUSE has been using it by default for years. It works fine and is a lifesaver with snapper and the ability to boot previous snaps.

View this comment - View article - View full comments

Quoting: X6205Honestly, i am suprised that all those gameplay/walkthrough videos are not ilegal. How many people decide to watch gameplay instead of pay for the game and streamer got money from it. WTF? This cannot in any way benefit the publisher/developer. YT and others should at least demonetize these types of videos if not remove them completelly. It's like uploading full a movie. But then.. i call YouTube the biggest warez source :) All those full lenght movies uploaed by random people, full lenght movie/game sountracks or other music albums. And the same appliest for full gameplay (not short reviews).

IMO YouTube deserves shutdown for years of tolerating ilegal content. But i guess.. DMCA and others are scared of giants like Google. It's easier to bully average joe for downloading movie torrent.

Uh... Alex? Fancy seeing you here.

View this comment - View article - View full comments

They'll do only what helps them. That means they'll never let go of games, that doesn't help them in any way what-so-ever.

You might notice their browser has all their services integrated (or just available as shortcuts permanently) and has advertising on the new-tab info page by default.

View this comment - View article - View full comments

They really should open their drivers up under GPL. It would save them and others so many headaches, plus gain some extra contributors. From what I recall of a discussion somewhere (ha! my friends uncles sister heard) they won't due to their drivers being a competitive edge.

View this comment - View article - View full comments

Just compared this driver to the vulkan beta `455.22.04`. The vk beta driver is so much more smoother for gaming in reverse-PRIME.

View this comment - View article - View full comments

It's worth quoting some reverse-PRIME info from the Nvidia forums where agoins (an Nvidia dev) posts:

QuoteSee above for the possible cause of the stutter that you are seeing. The FPS drop you are seeing may be related to overhead introduced by PRIME Render Offload and Reverse PRIME. In order for a PRIME Render Offload app to be shown on the iGPU’s desktop, the contents of the window have to be copied across the PCIe bus into system memory, incurring bandwidth overhead. Then, in order for the iGPU’s desktop to be displayed on a dGPU output, Reverse PRIME has to copy that region of the desktop across the PCIe bus again into video memory, incurring more bandwidth overhead. These two combined can result in significant bandwidth usage that could affect performance, especially for laptops and eGPUs that are limited to 2-4 PCIe lanes.

A future driver release will introduce an optimization that avoids the overhead from both PRIME Render Offload and Reverse PRIME for fullscreen, unoccluded, unredirected windows, where the dGPU can just display the app’s contents directly. In this case, the bandwidth overhead should be no more than a native desktop.

QuoteI’m not exactly sure how Windows implements cross-GPU multi-monitor support behind the scenes, but I wouldn’t rule out that the framebuffer is being copied. At the very least, an app rendered on the dGPU would have to be copied to be displayed on an iGPU output, and vice versa. If the dGPU output has the desktop rendered separately, it could at least avoid the double-copy scenario described in #31.

On Linux, the implementation mainly has to do with the historical limitations of X. X requires the desktop to be controlled by a single protocol screen, which is controlled by a single GPU. Generally, apps will run on one X protocol screen at a time. As such, the compositor for example is one X / OpenGL client that renders into the framebuffer on one GPU.

The ability to use a second GPU for additional monitors or for offloaded rendering is a later addition. Since only the protocol screen can receive X protocol and control the desktop, the rendered desktop has to be copied over to the secondary GPU to be displayed on its outputs. Note that the secondary GPU is in control of its own outputs, it just isn’t in control of the desktop. Similarly, rendering offloaded to the secondary GPU needs to be copied to the protocol screen’s GPU in order to be included on the desktop.

The above is true for standard PRIME Display Offload too, where the NVIDIA dGPU is controlling the X protocol screen and the iGPU is the secondary GPU. “Reverse PRIME” is just a special case of PRIME Display Offload where the roles are reversed.

It is possible to set up a separate X screen for each GPU, in which case each GPU will be responsible for all of the rendering on its own monitors. However, apps can’t be dragged between them, since the framebuffers are independent.

So a future driver will enable reverse-PRIME gaming in fullscreen to be at maximum speed. The above details why X11 isn't exactly the best solution too, so it kind of mystifies me as to why they are sticking with it.

QuoteAs a protocol, Wayland’s compositor-centric approach should be theoretically more capable of a more efficient implementation (do composition separately on each GPU, resulting in a unified desktop and no redundant copies), but it’s up to the compositor to implement something sophisticated.

View this comment - View article - View full comments