MindSpunk

If you want to get pedantic the hardware rasterizer in your GPU doesn't rasterize "3D triangles" either. Any notion of '3D' comes from how you project your vertices when transforming them through your coordinate spaces. Though the perspective divide needed to make perspective projection work is baked in, but otherwise NDC is a 2D space. Z only exists for the depth buffer/depth test and perspective correct interpolation. The "shape" of the triangle on screen isn't affected by it.

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.

You could try and do this today, to an extent. You could skip Vulkan and talk to the kernel driver in your app directly. vulkan-1.dll is regular user-mode code, there's nothing special about it. Nobody does this because it's a colossal amount of work for a small pay off. Your code becomes completely un-portable.

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.

The Apple developer terms of service require all app submissions to come from a Mac.

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'm not really sure how any machine is more affordable than the $0 it should cost because you shouldn't need a Mac. It's absolutely true that you can get by with a base spec Mac Mini, but often you can't with bigger projects and the cost skyrockets because Apple prices memory like kidneys (current market conditions aside, they've always done it).

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?".

Why should you need a Mac to build for iOS at all? What makes Apple so special here? Cross-compilation toolchains aren't forbidden alien technology.

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.

Curious why you'd move from C# to Rust. C# has you covered mostly for memory safety so I would guess performance or lots of shared memory across threads?

This is the answer I think. The correctness of your safe code is dependent on the diligence of the unsafe code except for the most simple cases. A kernel is going to have a pretty high unsafe to safe ratio compared to most usermode apps.

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.

Valve is just hedging against Microsoft having a big red button to kill Steam. They've built their kingdom on top of Microsoft, and Microsoft would love to have it for themselves I'm sure. It's in Valve's best interest to divorce themselves from Windows to protect themselves from Microsoft.

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.

Reminder that Valve's liberal refund policy only exists because they were sued by the Australian government.

Consoles ban JITs too.

NAT is not a security device. A firewall, which will be part of any sane router's NAT implementation, is a security device. NAT is not a firewall, but is often part of one.

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.

All the names for waves come from different hardware and software vendors adopting names for the same or similar concept.

- 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.

Not recommending the Steins;Gate anime adaption is pretty wild, it's an incredibly highly rated Anime series. The story telling language of a VN and an Anime are very different so it's no surprise they don't perfectly capture the complexities of the other medium. They don't have to be the same to be worth watching.

fwiw: no idea on the other anime adaptions quality

The hard part of Linux ports isn't the first 90% (Using the Linux APIs). It's the second 90%.

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.

As if you don't get a jumble of UI frameworks on Linux too.

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.

Converting directX into Vulkan (potentially very large performance gains)

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.

Being so absolutist is silly but their counter argument is very weak. Can I invalidate any memory safe language by dredging up old bug reports? Java had a bug once I guess it's over, everyone back to C. The argument is so thin it's hard to tell what they're trying to say.

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

fwiw, the M139 engine they're putting on those AMGs is completely insane.

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

Toyota with the G family and JZ family + Nissan with the RB family too. They were prolific in RWD cars.

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

Yes? That's called a bug? The standard library incorrectly labelled something as safe, and then changed it. The root was an unsafe FFI call which was incorrectly marked as safe.

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.

What is a safe ABI? An ABI can't control whether one or both parties either end of the interface are honest.

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

You're both wrong, the Mirai uses a fuel cell as the voltage source for an otherwise EV drive train. The Mirai is an EV with a fuel cell instead of a battery.

There is no ICE in a Mirai.

I remember Star Wars Jedi Survivor had a 5-6 minute shader pre-compile on my 5950X. I heard of people well into the 30 minute mark on lower core count machines. Battlefield 6 was a few minutes on my 9950X, higher again on lower core count CPUs.

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.

Yes, many games do that too. Depending on how many shaders the game uses and how fast the user's CPU is an exhaustive pre-compile could take half an hour or more.

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.

Depends what you're precompiling.

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.

The CPUs in their SOCs were not up to snuff for a non-portable game console until very recently. They used (and largely still do I believe) off the shelf ARM Cortex designs. The SOC fabric is their own, but the cores are standard.

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.

It pains me how important TKO is for Ivanova's character because it's otherwise got to be one of, if not the worst episodes in the whole show's run.

It's probably worth watching TNG before DS9. The contrast between TNG and DS9 with DS9's darker tone is an important part of the show. Probably the best episode in the whole series, "In The Pale Moonlight", is made all the better when you've seen what they're contrasting against.

The first season is definitely the most conventional (for the time) and I think that reflects in some of JMS's statements saying the show was still getting onto its feet through the first season. Having the serialized story was very unfamiliar territory for Hollywood television back then, they were learning on their feet.

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.

WGPU is just a layer over the top of the native APIs on any given platform so unless Zed's DirectX/Metal renderers were particularly bad it's unlikely WGPU will be better here.