fwiw: no idea on the other anime adaptions quality

Platform bugs, build issues, distro differences, implicitly relying on behavior of Windows. It's not just "use Linux API", there's a lot of effort to ship properly. Lots of effort for a tiny user base. There's more users now, but proton is probably a better target than native Linux for games.

You can run KDE but depending on the app and containerization you open you'll get a Qt environment, a Qt environment that doesn't respect the system theme, random GTK apps that don't follow the system theme, random GTK apps that only follow a light/dark mode toggle. The GTK apps render their own window decorations too. Sometimes the cursor will change size and theme depending on the window it's on top of.

That's not at all how that works. DirectX12 isn't slow by any stretch of the imagination. In my personal and professional experience Vulkan is about on par depending on the driver. The main differences are in CPU cost, the GPU ultimately runs basically the same code.

There's no magic Vulkan can pull out of thin air to be faster than DX12, they're both doing basically the same thing and they're not far off the "speed of light" for driving the GPU hardware.

It's just as reductive as the person they're replying to.

It's a production 2.0L 4-cylinder engine making (in the most powerful config) 350kw. From the factory. Insane.

Daewoo put one in a FWD car in the mid 2000s for some reason too.

It's no different than a bug in an unsafe pure Rust function.

I'm choosing to ignore that libc is typically dynamically linked, but linking in foreign code and marking it safe is a choice to trust the code. Under dynamic linking anything could get linked in, unlike static linking. At least a static link only includes the code you (theoretically) audited and decided is safe.

You can't have safe dynamic linking, dynamic linking requires you to trust the library you load with no ability to verify.

There is no ICE in a Mirai.

Really depends on the game.

There's no easy way around this problem. It never came up as much in the OpenGL/D3D11 era because we didn't make as many shaders back then. Shader graphs and letting artists author shaders really opened pandoras box on this problem, but OpenGL was already on its way out by the time these techniques were proliferating so Vulkan gets lumped in as the cause.

But in reality the exhaustive pre-compile will compile way more than will be used by any given game session (on average) and waste lots of time. Also you would have to recompile every time the user upgraded their driver version or changed hardware. And you're likely to churn a lot of customers if you smack them with a 30+ minute loading screen.

Precisely which shaders get used by the game can only be correctly discovered at runtime in many games, it depends on the precise state of the game/renderer and the quality settings and often hardware vendor if there are vendor-specific code paths.

Some games will get QA to play a bunch of the game, or maybe setup automated scripts to fly through all the levels and log which shaders get used. Then that log gets replayed in a startup pre-compile loading screen so you're at least pre-compiling shaders you know will be used.

For Vulkan you already ship "pre-compiled" shaders in SPIR-V form. The SPIR-V needs to be compiled to GPU ISA before it can run.

You can't, in general, pre-compile the SPIR-V to GPU ISA because you don't know the target device you're running on until the app launches. You would have to precompile ISA for every GPU you ever plan to run on, for every platform, for every driver version they've ever released that you will run on. Also you need to know when new hardware and drivers come out and have pre-compiled ISA ready for them.

Steam tries to do this. They store pre-compiled ISA tagged with the GPU+Driver+Platform, then ship it to you. Kinda works if they have the shaders for a game compiled for your GPU/Driver/Platform. In reality your cache hit rate will be spotty and plenty of people are going to stutter.

OpenGL/DirectX11 still has this problem too, but it's all hidden in the driver. Drivers would do a lot of heroics to hide compilation stutter. They'd still often fail though and developers had no way to really manage it out outside of some truly disgusting hacks.

In performance even the aging Zen2 would demolish the best Tegra you could get at the time.

You should note that the Switch, the only major handheld console for the last 10 years, is the only one using a Tegra.

And from everything I've heard Nvidia is a garbage hardware partner who you absolutely don't want to base your entire business on because they will screw you. The consoles all use custom AMD SOCs, if you're going to that deep level of partnering you'd want a partner who isn't out to stab you.

If I recall correctly JMS wrote basically every episode after season 1, where as season 1 had a few guest writers. The guest written episodes did not do well, including episode 14 which is probably the worst episode in the entire series.

cuMemAlloc -> vmaAllocate + VMA_MEMORY_USAGE_GPU_ONLY

cuMemAllocHost -> vmaAllocate + VMA_MEMORY_USAGE_CPU_ONLY

It seems like the functionality is the same, just the memory usage is implicit in cuMemAlloc instead of being typed out? If it's that big of a deal write a wrapper function and be done with it?

Usage flags never come up in CUDA because everything is just a bag-of-bytes buffer. Vulkan needs to deal with render targets and textures too which historically had to be placed in special memory regions, and are still accessed through big blocks of fixed function hardware that are very much still relevant. And each of the ~6 different GPU vendors across 10+ years of generational iterations does this all differently and has different memory architectures and performance cliffs.

It's cumbersome, but can also be wrapped (i.e. VMA). Who cares if the "easy mode" comes in vulkan.h or vma.h, someone's got to implement it anyway. At least if it's in vma.h I can fix issues, unlike if we trusted all the vendors to do it right (they wont).

The weight of the batteries isn't going anywhere anytime soon. I expect car makers will prioritize range. I think the engineering to make an EV truly light like an old Integra Type R (1100kg) will be obscenely expensive and sacrifice so much on practicality it just won't be a viable product as a road car.

The car would be so compromised to be that light nobody will make the car, at least at an affordable price. You'll end up with a limited range, limited power, uncomfortable car for a price way out of line with what you're getting.

I think you could make a ~150kw-180kw EV pretty light, but considering the ongoing power pissing contest in modern cars I'm not sure how well it would market test.

So I expect the market will stick to heavy cars with big power because it's easier to build and easier to sell.