More security restrictions yes, that will work, but unless you actually go airgap all the code, there's an access point somewhere which can be vulnerable, either through the network or through the human init?

Zero debuginfo-related warnings on any driver (except the usual "buffer location is VIDMEM" spam), NV is fine, intel is fine, my (RDNA) AMD card is fine on both Windows and Linux, user with a Vega 64 isn't fine.

We dug into it together and it literally swaps the colours somewhere, and the user said that it crashes randomly on games (confirmed by others, not one-off HW failure), does the same colourswap or have very glitched rendering.

I guess the only salvation is that people usually play DX games under Windows and the bug didn't happen over DX11. But the same rendering restricted to even standard GL3.3 just got BGRA-swapped.

Talk about overengineering :P Multithreaded vector initialisation instead of just...skipping it?

For perf reasons it's the equivalent of shooting your leg off to lose weight. You're flushing the instruction cache and breaking prefetch, leading to a huge stall. Then you do it again. And again. It hasn't been in vogue since the 80s...

2. The ability to "cheat" on calling conventions.

3. The ability for techniques like threaded code, and in general, better cache-awareness.

4. Less mov's.

5. Guaranteeing no spilling in important loops.

6. Compilers don't do well with flags registers and you can't read/write them in high level languages. You're hoping your `if (result < a) { carry = 1; }` becomes a direct flag test. Especially important in bignum, you can't really utilise adcx/adox directly from high-level code.

7. Hot/cold layout without PGO. Yes PGO is good but sometimes you know better and PGO isn't very suitable for "configurable" code.

8. Computed goto. See https://github.com/python/cpython/issues/128563 , who doesn't like 10% free performance?

9. Exploiting uninitialised memory for classic party tricks like not initialising a buffer fully (let's say you have a library function with a return buffer. You don't want dynamic allocations for some reason. You can simulate this with a pointer return into a let's say a static 4KB buffer and a count return, you only initialise it until the count. Caller has the responsibility not to overread.)

All of these were dropped on x64, on x64 (and ARM) you get standard calling conventions for just about everything with proper unwind tables for functions.

It doesn't really "cheat" on the registers unless it inlines a function entirely. LLVM has support for custom calling conventions and pragmas to specify them, this is used by GHC on Haskell and other things, but it's practically unheard of in "normal" C/C++ code.

On Linux at least you can use Mesa to fix it up. On Windows you're.... out of luck I guess unless someone writes a binarypatch or something?

I wouldn't call it great support, NV "just works"

All those one-shot games and product demos are clones of existing things, and while they're very impressive, they aren't exactly new ideas, you know?

Of course all this might change and the labs might figure out the secret to creativity, but as things stand today, humans can keep "moving up" the value stack to just make more complex things.

So the first iteration of the design is always slightly wonky, so it remains fun :)

yeah where the pixel work and the vert count is magnitudes higher. I forgot to mention in my comment that I was talking about low-poly / pixel stuff like this, with a very simple PS and being pretty much API bound or memory-bound in perf

esp when all the caps are missing but all the punctuation are perfectly present

Yes, but my point is that.... go on github, you'll find tons of decomps. And many more done just privately too. One of the No Man's Sky devtalks start with "yeah we decompiled the terrain generation from this other game, implemented it in our prototype, it didn't work okay, here's how we've learnt from it to make something better". This was in 2016. More recently, this has been going on way more openly, even full AI-assisted decomps thrown up onto GitHub casually. It might be the letter of law or included in Terms of Service but no one cares really.

For occlusion culling it's a bit more tricky because you can either do it on the CPU in broadly two ways, either do low-res raycasting / software rendering like in the article on the CPU and cull based on that. This is an adaptive workload, you can give it more threads or CPU power and it scales for better culling which results in less pixels rendered on the GPU.

You can also use GPU culling but that's more complicated to do and that uses the GPU which creates a catch-22 - you want to use GPU culling to reduce GPU load but integrated GPUs don't cope well with compute shaders and memory bandwidth in general, so doing a culling pass might wipe out any culling gains you might have.

And dedicated GPUs have the raw power and memory bandwidth to just submit everything in your frustum and get most of it depth-rejected.

I wonder if it would be even faster to create a connectivity graph on the CPU, like each chunk knows whether a neighbour is visible and vice versa. On rendering the chunk graph is walked and the visible chunks are submitted, kind of like a primitive garbage collector to determine liveness. The culling would be worse but I presume traversing a fairly small (few thousand elements) list is quite a bit cheaper than rendering the "mipped" occlusion boxes, but do let me know if this is wrong.