Thanks to XBMC and Team Xecuter my first Xbox definitely was an XXXbox. 😬

It’s fine, it’s not like we have a finite amount of fuel to put into them, we will always find more. /s

I wish they weren’t so expensive though.

IMO the biggest incentive of all is that the battery exists for the life of the vehicle and can be recycled at the end (the lithium inside does not disappear!), vs the gas which is literally burning money away.

Agreed, what Bambu did is essentially steal the work of everybody and close it up, and go against anyone trying to reopen it.

To be fair though, the reason Bambu Lab printers work so well for most is in large part due to the walled garden approach.

I still disagree with it and will vote with my wallet by avoiding them, but I can see the appeal if you don’t know any better (or just don’t care!).

Prusa kind of tries to navigate both sides of the issue (not everything is open source anymore), so you can still get caught there.

They were running ZFS software raid. So … maybe just use the raid controller instead?

It is generally a bad idea to do that nowadays, because it ties you forever to that controller. If it dies you will need to find an exact replacement or accept that the whole array is lost. With software raid you can run any hardware.

Wendell from Level1Techs is a good reference:

https://youtube.com/watch?v=l55GfAwa8RI

https://youtube.com/watch?v=Q_JOtEBFHDs

BTW: good score, you will have fun with those for sure.

That and the game can flag frames that are too different (camera cuts) to mitigate this problem.

What the game supplies is the current frame + motion vectors, but the framegen bits take over how the frames are displayed onscreen. This is where the extra latency comes from, at worst you are seeing one true frame behind what the game is rendering, while the presentation layer generates the intermediate frame(s).

That is not strictly true, the actual latency increase is half the original frame rate. Because the input is not just the frame image but also the motion vectors (in which direction the pixel moved) for the current frame. Frame gen also knows a lot about the image, like which bits have transparent pixels (which move in multiple directions at once) and when the game is done with the frame yet still has to wait for the GPU (time which can be used for more work with little impact).

Frame gen is much more involved than the old “motion smoothing” of televisions, the so called “soap opera” mode, which did increase the latency much more and had no knowledge of how the source image was built, so processing was much more involved.

Stuff like DLSS5 is supposed to use the same inputs (source images and motion vectors), now that is magic to me.

Last time I installed Arch it used systemd-boot which only shows text. If you use grub in UEFI mode you can get those graphics too.