@nprofile1q... yeah but I'm not very traumatized :)

@nprofile1q... @nprofile1q... this is really easy to explain though, they shipped an image based on the development image and they forgot to remove the config / didn't think about it. Almost all these kinds of things are "what is the most convenient configuration for dev" becoming "oops we shipped it"

@nprofile1q... it's hard also just due to logistics. like the core foundation of the cloud is this idea of commodity compute, but that means in order to actually use a new sku it needs to roll out globally, or near to it. larger, more powerful individual instances would be super useful to some workloads, but cloud providers can't/don't want to give you those kinds of hardware allocations, and if they do it's regionally dependent anyway which makes it worthless.

@nprofile1q... @nprofile1q... nerds v.s. frat boys is entirely a USA meme tbh (even ignoring that fraternities are of course, entirely american)

@nprofile1q... @nprofile1q... Yep! The problem with discard (and similarly, shader depth writes) is that it means the GPU does not know statically ahead of time whether the fragment shader should write depth or not, so it can no longer rely on that information for all the early depth rejection trickery that GPUs do for opaque surfaces based on their geometry alone. There's a lot more subtlety but basically it just turns off optimisations.

@nprofile1q... @nprofile1q... yes I believe so, minimal changes across the existing platform and it magically works for larger worlds. But with a perf hit and still having world space dependent precision.

@nprofile1q... @nprofile1q... yea but people do in fact do that. Looking at you Godot "large world" mode :')

@nprofile1q... @nprofile1q... still slightly painful on the GPU, though.

@nprofile1q... tbh i expect a lot of that is largely because rendering features are a lot easier