Yeah probably not. A large amount of posts and videos from social medias are blocked in Vietnam, it's still a communist country with very low level of free speech and press freedom, albeit still better than China.
TBH that looks pretty decent to me. GPU programming is very very complicated. A simple kernel in torch is hundreds to thousands of LOCs, with much worse style.
I agree with some poster above, the code looks hard simply because the problem is very hard, not because they want to write it that way.
I don't know why you brought up VAC as an example. It is a horrible AC, so bad so that an entire service (FaceIT) was built to capitalize on that.
VAC is still a laughing joke in CS2, literally unplayable when you reached 15k+. Riot Vanguard is extremely invasive, but it's leaps and bounds a head of VAC.
And Valve's banning waves long after the fact doesn't improve the players experience at all. CS2 is F2P, alts are easy to get, cheating happens in alost every single high-ranked game, players experience is shit.
I think your understanding of MoE is wrong. Depending on the settings, each token can actually be routed to multiple experts, called experts choice architecture. This makes it easier to parallelize the inference (each expert on a different device for example), but it's not simply just keeping one expert in memory.
Whether you think infinity exists or not is up to you, but transfinite mathematics is very useful, it's used to prove theorems like Goodstein's sequence in a surprisingly elegant way. This sequence doesn't really have anything to do with infinity as first glance.
> self-advertised as uncompromising privacy focused OS
> didn't even compromise even a bit (negotiation is already a compromise) against a country who is notorious for advocating for privacy-invasive policies in recent years
> get lectured by yc high-horse rider on the obligation blah blah, even when by and large this move doesn't materially affect the end-users in any substantial way
I used 4chan style because most of the times 4chan commenters have more sense than yc these days. Many people here do live in glass houses.
Vulkan was one of the hardest thing I've ever tried to learn. It's so unintuitive and tedious that seemingly drains the joy out of programming. Tiny brain =(
You don't have a tiny brain. Vulkan is a low-level chip abstraction API, and is about as joyful to use as a low-level USB API. For a more fun experience with very small amounts of source code needed to get started, I'd recommend trying OpenGL (especially pre-2.0 when they introduced shaders and started down the GPU-programming path), but the industry is dead-set on killing OpenGL for some reason.
Tbh, OpenGL sucks just as much as Vulkan, just in different ways. It's time to admit that Khronos is simply terrible at designing 3D APIs ;) (probably because there are too many cooks involved)
Vulkan is definitely a major pain and very difficult to learn... But once you've created an init function, a create buffer function, a create material function etc which you do once you can largely then just ignore it and write at a higher level.
I don't like Vulkan. I keep thinking did nobody look at this and think 'there must be a better way' but it's what we've got and mostly it's just learn it and write the code once
People wanted more direct control over the GPU and memory, instead of having the drivers do that hard work.
To fix this AMD developed Mantle in 2013. This inspired others: Apple released Metal in 2014, Microsoft released DX12 in 2015, and Khronos released Vulkan in 2016 based on Mantle. They're all kind of similar (some APIs better than others IMO).
OpenGL did get some extensions to improve it too but in the end all the big engines just use the other 3.
When I first tried to learn Vulkan, I felt the exact same way. As I was following the various Vulkan tutorials online, I felt that I was just copying the code, without understanding any of it and internalizing the concepts. So, I decided to learn WebGPU (via the Google Dawn implementation), which has a similar "modern" API to Vulkan, but much more simplified.
The commonalities to both are:
- Instances and devices
- Shaders and programs
- Pipelines
- Bind groups (in WebGPU) and descriptor sets (in Vulkan)
- GPU memory (textures, texture views, and buffers)
- Command buffers
Once I was comfortable with WebGPU, I eventually felt restrained by its limited feature set. The restrictions of WebGPU gave me the motivation to go back to Vulkan. Now, I'm learning Vulkan again, and this time, the high-level concepts are familiar to me from WebGPU.
Some limitations of WebGPU are its lack of push constants, and the "pipeline explosion" problem (which Vulkan tries to solve with the pipeline library, dynamic state, and shader object extensions). Meanwhile, Vulkan requires you to manage synchronization explicitly with fences and semaphores, which required an additional learning curve for me, coming from WebGPU. Vulkan also does not provide an allocator (most people use the VMA library).
SDL_GPU is another API at a similar abstraction level to WebGPU, and could also be another easier choice for learning than Vulkan, to get started. Therefore, if you're still interested in learning graphics programming, WebGPU or SDL_GPU could be good to check out.
Exactly the reason why I haven't switched from OpenGL to Vulkan. Vulkan is just ridiculously overengineered. Cuda shows that allocation of GPU memory and copy from host to device can be one-liners, yet in Vulkan it's an incredible amount of boilerplate to go through. Modern Vulkan fixes a lot of issues, like getting rid of pipelines, render passes, bindings, etc., but there is still much more to fix before it's usable.
I think anyone who ever looked at typical Vulcan code examples would reach the same conclusion: it's not for application/game developers.
I really hope SDL3 or wgpu could be the abstraction layer that settles all these down. I personally bet on SDL3 just because they have support from Valve, a company that has reasons to care about cross platform gaming. But I would look into wgpu too (...if I were better at rust, sigh)
Yep. Most of the engine and "game from scratch" tutorials on Youtube, etc, use this style of having OpenGL code strewn around the app.
With Vulkan this is borderline impossible and it becomes messy quite quickly. It's very low level. Unlike OpenGL, one really needs an abstraction layer on top, so you either gotta use a library or write your own in the end.
This reminds of a friend I had in college. We were assigned to the same group coding an advanced calculator in C. This guy didn't know anything about programming (he was mostly focused on his side biz of selling collector sneakers), so we assigned him to do all the testing, his job was to come up with weird equations and weird but valid way to present them to the calculator. And this dude somehow managed to crash almost all of our iterations except the few last ones. Really put the joke about a programmer, a tester, and a customer walk into a bar into perspective.
I love that he ended up making a very valuable contribution despite not knowing how to program -- other groups would have just been mad at him, had him do nothing, or had him do programming and gotten mad when it was crap or not finished.
Of course there will be fallout, but much less severe than a meltdown on land. Water is extremely effective in containing radiation, and the ocean is so huge it will be dilutet to neligible amount very quickly.
> the ocean is so huge it will be dilutet to neligible amount very quickly.
Are you basing this on actually knowing this, because it sounds doubtful to me. The ocean would probably dilute a bit, maybe even a bunch, but it'll also lead to contamination of everything around there, the bottom, the animals, and so on, the radiation doesn't suddenly "disappear" in "thin" water.
Source: I used to live there.
reply