As long as you can draw 2D triangles there's nothing stopping you from drawing a "3D" scene with a software transform pipeline. Depth sorting gets fun without a z-buffer though.

Exposing the hardware primitives directly is not an abstraction, so in reality all you end up having to do is implement your own Vulkan instead if you want to support more than 1 GPU. And your app won't work on new GPUs without shipping an update.

If you want a common API to target all GPUs you get Vulkan again. GPU hardware is too diverse to go much lower than Vulkan without just moving the hardware abstraction into your app instead.

Apple could've chosen to offer no tools and leave it to the community to build their own. I think that's reasonable. I don't expect Microsoft to bring MSVC to Linux.

But Apple take the explicit position that you must purchase a Mac in order to ship apps for iOS.

I have nothing against the hardware. I despise how artificial the problem is. It's not even like Apple just refuse to provide tools and leave it up to the community. They force you to use a Mac in the terms of service.

For context I work on the mobile team for a large AAA game engine. This is going to colour my opinion because we're very Windows centric, but my experience wouldn't exist if it weren't for Apple. I need to sync code on two different machines and build half the project on Windows and the other half on the Mac. If we could just build and debug the iPhone on Windows none of this mess would be needed.

We don't develop for MacOS, we develop for iOS. Just debugging the app requires several hoops across multiple machines because of Apple's policy here. Just because a base spec Mac Mini is cheap doesn't make this whole problem any less stupid. I don't need a vendor's special-sauce computer to build for consoles. Cross compilation and remote debugging has existed for decades, this problem should not exist.

Calling it more affordable because Mac Minis aren't junk anymore is really just accepting Apple's ridiculous requirement because "I guess it could be worse right?".

Forcing people onto Macs is such a pathetic way of extracting rent from developers and makes workflows worse. No you can't just build and debug your app from your Windows or Linux workstation because we want you to buy hardware you don't need. Sorry we only support Xcode on the latest version of MacOS, how else will your build machine roll out of the OS support window and make you replace a functioning machine?

It's especially nice when you work on projects that aren't iOS/Apple native and you don't get Mac workstations. You end up with this wonderful mess of shared machines and half assed tools because you just need the bare minimum to push a build to a phone.

This really gets to the core of what I think Rust is about, you can add compiler checked constraints to your APIs that your C and C++ code can't. It's up to you to use them effectively. Rust's ability to keep your safe code safe is a measure of the language, but also your architecture. The buck has to stop somewhere for the language to prove safety, Rust lets you decide rather than the language itself.

It happens to also benefit the Linux gaming crowd, but it's still ultimately self-interest driving the work. The engineers doing the work are probably doing it for the altruistic reasons, but ultimately Valve is writing the cheques.

Any sane router also uses a firewall for IPv6. A correctly configured router will deny inbound traffic for both v4 and v6. You are not less secure on IPv6.

- Wavefront: AMD, comes from their hardware naming

- Warp: Nvidia, comes from their hardware naming for largely the same concept

Both of these were implementation detail until Microsoft and Khronos enshrined them in the shader programming model independent of the hardware implementation so you get

- Subgroup: Khronos' name for the abstract model that maps to the hardware

- Wave: Microsoft's name for the same

They all describe mostly the same thing so they all get used and you get the naming mess. Doesn't help that you'll have the API spec use wave/subgroup, but the vendor profilers will use warp/wavefront in the names of their hardware counters.

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.