MindSpunk

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

What exactly is the difference between these?

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 McMurtry is a race car so it's not surprising it's that light. However it still pays a price compared to its contemporaries (go look at the weights of various LMP1 or LMP2 cars, even old cars like the Mazda 787B was ~850kg iirc). The only number I've found so far is "under 1000kg" so I assume it's probably quite close to that 1000kg number.

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.

Acceleration is about the only selling point of a sports EV.

They're so ungodly heavy because of the batteries that they handle like barges. They need giant tyres and so much ESC and software control because these things weigh almost 2000kg or more. You can try and work around it but there's only so much that can be done to make 2000kg take a corner.

Looking at where sports cars will be in 10 years with ICEs being regulated out of existence makes me very sad because it seems like we're about to see the death of the lightweight sports car.

Do we really need to jump onto a tangent about evil cars and evil car infrastructure on a post about b-splines and curve sections?

Everything in the article applies equally to trains and rails.

We get enough complaining about evil car-centric city designs on the posts directly about cars thanks.

Alternatively, in the same socket and without the 3D stacked cache: https://www.cpu-monkey.com/en/compare_cpu-apple_m4-vs-amd_ry... with double the cores.

And in laptop form compared with a m4 max: https://www.cpu-monkey.com/en/compare_cpu-apple_m4_max_14_cp...

Drawing lots of single pixels with alpha blending is probably one of the least efficient ways to use the rasterizer though. A good compute shader implementation would be substantially faster.

M-series have a substantially wider memory bus allowing much higher throughput. It's not really an x86/M-series thing, rather it's a packaging limitation. Apple integrates the memory into the same package as the CPU, the vast majority of x86 CPUs are socketed with socketed memory.

Apple are able to push a wider bus at higher frequencies because they aren't limited by signal integrity problems you encounter trying to do the same over sockets and motherboard traces. x86 CPUs like the Ryzen AI Max 395+, when packaged without socketed memory, are able to push equally wide busses at high frequencies.

Been having a nice break over the new year, thank you :)

I can't argue with sticking on IPv4 when you have no need for IPv6. However, people saying no NAT means no firewall really bothers me because it's just wrong and usually gets thrown around as part of a point around "who needs IPv6 anyway".

The two layers IMO don't make a practical difference. A deny by default firewall will fail closed, unless poorly configured. A poorly configured firewall for IPv4 with NAT can still leave machines exposed. This is not an IPv4/IPv6 problem this is down to your router. However you do expose what used to be private addresses with IPv6, but there's not much to do with the address that couldn't be done with your IPv4 address assuming sane firewalls that both stacks run.

On the other side of the coin IPv6 being ubiquitous would make my life much easier. I self host a few things across a few different machines. IPv6 offers me a much simpler solution, both to managing firewalls and not needing to fight over port 80/443, but also because I can't get a public IPv4 address from my ISP without spending ungodly amounts of money. They support IPv6 but many of the services I host don't support it. I have to use a second site + machine, wireguard tunnels, and nginx socket proxies to expose stuff publicly (this is cheaper than the public IPv4 address from my ISP).

My point about DHCPv6 is to say that if you want to use DHCP in IPv6 you can. It's right there, it's just not the default.

IPv6 doesn't make things substantially harder, just different. But people don't want to learn new things because, to be fair, they don't need them. But people who do need IPv6 are stuck behind garbage ISPs and this "not my problem" attitude throwing around ignorant arguments. Complaints about long addresses really get me too :), use a DNS.

> - I don't have a shortage of IPv4. Maybe my ISP or my VPN host do, I don't know. I have a roomy 10.0.0.0/8 to work with.

What happens when multiple devices in your /8 want to listen on port 80 and 443 on the public address? Only one of them can. Now you're running a proxy.

> - Every host routable from anywhere on the Internet? No thanks. Maybe I've been irreparably corrupted by being behind NAT for too long but I like the idea of a gateway between my well kept garden and the jungle and my network topology being hidden.

It's called a firewall. You want a firewall. IPv6 also has a firewall. NAT is not a firewall. NAT is usually configured as part of your firewall, but is not a firewall.

> - Stateless auto configuration. What ? No, no, I want my ducks neatly in a row, not wandering about. Again maybe my brain is rotten from years of DHCP usage but yes, I want stateful configuration and I want all devices on my network to automatically use my internal DNS server thank you very much.

DHCPv6

> - My ISP gives me a /64, what am I supposed to do with that anyways?

What are you supposed to do with a /8? Do you have several million computers?

> - What happens if my ISP decides to change my prefix ? How do my routing rules need to change? I have no idea.

What happens if your ISP changes your IPv4 address?

If I'm interpreting that correctly they're using an IL2CPP compilation system that hooks into Roslyn and not using .NET Core's AOT technology. It's possible to ship C# on consoles, obviously, because Unity already does it with their own IL2CPP backend that's stuck on the old .NET versions. My point is that CoreCLR can't be used because of console certification requirements. I certainly wasn't commenting on C# as language for games. I think C# is, as of late, becoming a very powerful language for games with all the Span and similar tools to minimize GC pressure.

Do you have examples? As far as I'm aware based on current info there's at least one current console vendor that requires all native code to be generated by their SDK.

CoreCLR doesn't help on console platforms because you can't ship the JIT runtime. To my knowledge CoreCLR's AOT solution won't work because of SDK and build requirements for shipping builds on consoles. I believe some consoles require that all shipped native code must have been compiled with the SDK compiler. Even if you fork the CoreCLR AOT system so you can build for the consoles (the code can't be open because of NDAs) you wouldn't be allowed to ship the binary. IL2CPP is the only path forward there. CoreCLR is only viable on PC.

WebGPU is far from cheap and has to do a substantial amount of extra work to translate to the underlying API in a safe manner. It's not 1:1 with Vulkan and diverges in a few places. WebGPU uses automatic synchronization and must spend a decent amount of CPU time resolving barriers.

You can't just ship a WebGPU implementation in the driver because the last-mile of getting the <canvas> on screen is handled by the browser in entirely browser specific ways. You'd require very tight coordination between the driver and browsers, and you still wouldn't be saving much because the overhead you get from WebGPU isn't because of API translation, rather it's the cost to make the API safe to expose in a browser.

While this is 100% true for the system allocator, hitting OOM there you're likely hosed, it isn't true if you're using arenas. I work on games and being able to respond to OOM is important as in many places I'm allocating from arenas that it is very possible to exhaust under normal conditions.

Have you considered if someone wants to make a compositor where each window is projected onto a facet of a hyper cube and must place windows in 4 dimensions? These are important use cases we should support, we should make cross platform software as difficult possible to develop for Linux by removing features that have been standard on desktop operating systems for decades.