apocalypses

Saying WebGPU “only” adds compute shaders is crazy reductive and misses the point entirely for how valuable an addition this is, from general purpose compute through to simplification of rendering pipelines through compositing passes etc.

In any case it’s not true anyway. WebGPU also does away with the global state driver, which has always been a productivity headache/source of bugs within OpenGL, and gives better abstractions with pipelines and command buffers.

I massively disagree. It would have taken the author approximately 1 minute to write the following high quality hack-n-slash commit message:

``` Big rewrites

* Rewrote X

* Deleted Y

* Refactored Z ```

Done

There’s address sanitizer on newer versions of visual studio now but in my experience getting it to actually work with all of your projects’ dependencies can be very hit and miss. Windows Debug build config also does a lot more memory checking (part of the reason it’s so slow) so you’re not totally screwed for automated tools.

Really interesting article. For me this was an important takeaway:

Although it should fail gracefully, it does not need to be optimised for failure.

Apple

One thing LLVM bitcode still can’t do is retain information about preprocessor directives, eg any platform specific code for AVX2 vs SSE4 etc. So unless you aim to write intrinsic free code it’s usually less performance/reliable to rely on compiler automatic vectorisation, which results in worse codegen overall.

Though worth noting only for specific AVX-512 CPUs.

Though you can still have vectorised support for regular precision for AVX2.

I have my own USB-C crappy story. I have a 2020 MacBook Pro 16” with bootcamp installed. Recently I bought a USB-C hub, if I try to boot into windows (hold alt at Apple logo) the machine literally cannot boot. At all. I have to disconnect the hub in order to make any progress.

Depends on what you’re comparing to what. Big spinning lidars on cars are still expensive (few thousand dollars) but are coming down on price. Handheld 3D scanners on the other hand might start to become obseleted by a combination of cheap phone camera + lidar (really tof) sensors that are evidently cheap enough to put on phones. They can actually produce really high quality (SLAM) maps - Apple has figured out that they can have a much faster initial mapping phase by not having to do monocular mapping for their AR. So I guess I’m saying it’s cheaper and a bit worse, but it’s rapidly getting better.

I work at a company that does lidar SLAM. You can actually produce really high quality maps/slam with lidar/tof sensors, and it’s a lot more robust/dense than visual/imu mapping.

Maybe I screwed it up, I’m not the best developer ever. I took their sample code to extract the depth data from front camera and this worked - switching to .back caused it to return a nil device, so didn’t really know where to go after that.

I've had a play around with the new ipad. The big problem is (as far as I can see), absolutely no way for a developer to get access to the underlying depth data.

I'm assuming it's coming in the next version of iOS, because you _can_ get access to the faceid depth data in a useful format.

Swift can also auto vectorise these simple loops, but only with the right combination of compiler flags.

https://swift.godbolt.org/z/JmtOMx

I found this very interesting, particular the comparison to x264 (which I had never heard of).

Looking into it I found x264 looked really easy to use with a nice C api but was encode only - does anyone know of a library very similar to x264 which is both encode/decode?