There's reserve tanks or more generally reserve fuel for emergencies. Other than that there's no propulsion backup for when the fuel runs out, instead redundancy comes from multiple independent fuel tanks.
They've stated in their patch notes that they made a change specifically to run on the steam deck. Regardless of what they say now, they have actively supported linux in the past and so should be liable for breaking the game for those customers.
Still user's problem if they manage or not manage to run the game through whatever translation and emulation layers they have instead of using official system requirements.
If the developer actively points out that they made changes so the software works on a specific platform and then actively disabled support for that platform later, I think people that can’t use the software anymore should get a refund.
I don't think this is accurate. Easy Anti-Cheat has supported Linux for a long time, many years before this. I doubt they were years and years out of date, updated, and allowing Linux was turned on by default in the new version. What they likely mean is they ticked the box in this game update to let it run on Linux.
Why would they specifically mention the Steam Deck? EAC doesn't have separate flags for Linux and Steam Deck. It's almost certain they intentionally allowed it to run on Linux. They call out Steam Deck by name because it is a popular handheld that has greatly increased the # of Linux users, not because an EAC update allowed it to work by chance.
And it's still not an active support decision. They allowed it - but it's your business. Whenever people gets problems or successes running through Proton, this is never a publisher's issue.
.. that must have been some atrocious telemetry data correlating cheaters and Linux. I wish they’d released a report on it — I mean, fuck Ubisoft, but at least we’d have data to argue about rather than this copout of a release note from them.
More than that. Rust requires that a program can be compiled from multiple crates, with those crates all targeting different editions. This limits a lot of breaking changes you might want to make. APIs can never really be removed.
I've seen this claimed before, and just going by SiFive's specint claims the P870 at 2.6GHz should match Zen 3.
But for SiFive's last silicon, the HiFive Premier P550, they claimed a specint2006 of 8.65/GHz. That should put the silicon only about 20% slower than an intel i5-6400. But if you look at geekbench scores it's about an order of magnitude slower.
Correct me if I'm wrong, but Tenstorrent has yet to ship any of their own cores? They do make very similar claims to SiFive.
Personally I'm very skeptical that these cores will be anywhere near Zen 3. I recon their performance claims are based on best-case CPU simulation, rather than a real measurement. I'd expect Raspberry Pi 4 levels of performance, a bit over double SiFive's current state of the art. An impressive improvement, but nowhere near Zen 3.
The P870 is probably faster than the Cortex-X1 in my phone, which would put it on a similar per level to Zen1.
When I had brief access to a very early P870 devboard running at 2GHz it scored 2% worse than an 2.86GHz Cortex-X1 in the 7-zip benchmark compression (it was a 40% worse in decompression, but that has NEON optimized Arm assembly path and non for RISC-V).
Because this was very early hardware still in bringup I expect them to get closer to the announced 2.7GHz.
But yeah, the RISC-V geekbench scores of publically available RISC-V processors are suprizingly low and idk why.
Part of it is the lack of RVV support is certain workloads, but that doesn't explain the entire gap.
When I looked at ST scalar performance my self it looked more comparible to similarly sized Arm CPUs.
I think I'll have to order a Pi5 (Cortex-A76) and investigate where it performes different to the SpacemiT K3 (SpacemiT X100).
On paper they should be very similar, both 2.4GHz, 4-wide decode, 3xALU, 1xBranch, (although the A76 has those on 4 execution units, while the X100 has 3 with one sharing ALU and Branch support), 2x load/store, 2xFP.
The biggest obvious difference (appart from ISA), may be the cache setup after L1, with the K3 having a 4Mib L2 shared between 8 cores (no L3) and the Pi5 having a 512KiB L2 and a 2MB L3 shared between 8 cores.
Well, there is some speculation regarding these chips so no sense arguing too much about it.
That said, the SpacemiT K3 is already faster than a Pi 4 and even substantially faster than a Pi 5 for multi-core and vector stuff. And that is before counting the other 8 “AI cores” it has.
These chips will be quite a bit faster than a K3, so certainly much faster than a Pi 4.
Given how appalling the thermal throttling behaviour is on the Neo - sustained workloads can lose up to 50% performance, making it substantially slower than an M1 Air - you should instead be asking for a fan in the Neo.
Fans are a good addition if they only activate during peak load, but my experience with Dell is that the hardware and firmware design is so poor that the fans always operate at near full speed.
To add to the long list of caveats: This also breaks assumptions GUI toolkit and applications make about only one of their windows being focused at a time: `gtk_application_get_active_window`, `QApplication::activeWindow`, etc.
This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible.
For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering.
Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
> Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
You're right that they avoid unnecessary painting but it is not this granular anymore. It used to be but rendering is so much faster these days where it is cheaper to just render a bit more than tracking dirty regions. It's easily visible on Android where you can enable "Show view updates" and see the entire textbox view updates when the cursor flashes. The docs say the same thing.
Wow, that's quite silly - and might partially explain some of the worsening battery life on Android. GTK4 also removes such an API, but just like those docs say, dirty rects are still calculated internally. You can enable the same visual debugging in GTK4 and see that dirty rects are done the same as they always have been.
Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.
> Wow, that's quite silly - and might partially explain some of the worsening battery life on Android.
It's likely the same on iOS. You'd have to try implementing it to really see why it isn't practical.
Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region. Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.
> Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.
Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.
> Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region.
The way this is done everywhere is to invalidate the entire area of the button. Buttons usually change background on hover/click anyway, so it just doesn't make sense to do more. Text input is special because these widgets can be very large, sometimes spanning the whole screen, so you want fine-grained dirty regions.
> Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.
I've never heard of anyone adding a general Widget-Level cache, considering that most UI elements don't change position that would be quite expensive. In any case the rendering is still a "pure" function regardless of whether you're using dirty regions or not, so not sure what you're trying to say here.
> Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.
That is definitely weird, but it still clearly shows that the regions are being tracked.
> That doesn't mean that the process stops, it runs indefinitely because it has to.
The processes don't stop, no, but they do pause and go idle, waiting for the next event to come in. Not sure what that has to do with this.
> The DOM does this. React does this.
What does react have to do with any of this discussion, and what do you mean by "this"?
> Did you know CSS even invokes the GPU for certain tasks?
Whether the GPU or CPU does work is unrelated to how frequently and how much of the screen is rendered. Damage regions work just fine for GPU-based rendering.
> You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.
Part of my job is maintaining a retained mode UI library. I've literally written some of the parts that handle damage regions, as well as the GPU-based rendering. But do go on about how I don't know how any of this works.
Arc Raiders is a great example for why UE5 is the reason games run poorly. It neither uses Nanite nor Lumen. Valorant goes even further and uses a custom forward renderer. The studios that care about performance avoid using the big headline features of UE5.
reply