ninepoints

I would suggest framing distributed systems analysis in terms of PACELC instead of CAP: https://en.wikipedia.org/wiki/PACELC_theorem

> It is quite normal to reward the first movers to your platform (PayPal even gave away free money to grow their user base)

The cognitive dissonance here is astounding. Surely you can see how the analogy isn't even remotely 1-1.

Nothing. I'm an unabashed NFT hater/skeptic if it wasn't immediately obvious

Because architectural simplicity is valuable and some operating systems deliver input events on a particular thread.

And by "owning" what's meant is a signed hash of some URL that fits in a few kilobytes at most.

Yes... do you know how long this takes for, say, a modest 100k shaders?

> F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat.

With much pain. Have you seen the shader pipeline we have to deal with going from HLSL to Metal? And no, translating the entire body of shader work to MSL is not an option.

Complete transaction anonymity is not a feature. There are no protections against wash trading, and you have no way to gauge true market demand or pricing from transaction volume data alone.

The explanation is simply that there are people that have bought in that want others to buy in also so they can liquidate for a profit. Meanwhile, others are susceptible to what amounts to FOMO-driven investment. The same sentiment that drove the beanie-baby craze, the dot-com boom, the subprime mortgage crisis, the current metaverse craze, and so on. Nothing new under the sun.

Look up "gravitational lensing"

Hard to imagine how an economic system that has literally no real safeguards against wash trading is "safer" in any sense.

Stating the obvious, but the recourse is to not bother with crypto at all and stick with insured and better safeguarded financial mechanisms.

> TFA article

??

You're kidding. The OpenGL implementation/support of Mac is pretty nonexistent/poor.

Their minds :)

> Vulkan is not officially supported on OSX

And neither is OpenGL

Compute shaders are used heavily in the AAA games and film industry.

Is the audience mainly folks in the scientific computing or academic world (aka folks that use CUDA mainly)? I went into it as a graphics engineer and started to get that sense haha (good job putting it together though)

TBH I haven't looked at the quiche implementation specifically (not being as familiar with rust) so I should check that out.

The main issue I saw with other implementations were mainly of the performance/optimization variety. The "blessed path" were definitely connection streams and I was seeing throughput drops when experimenting with datagrams.

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

My point is that there are plenty of engineers that work with graphics pipelines that don’t actually think about the 3d stuff that much. It’s one of many available avenues of specialization.

My pleasure! Thanks for reading and your comments

You're missing the big idea a bit. Coroutines in C++ can be used to implement generators or goroutines or async/await, etc. They are intended for library authors as a lower level construct. See for example: https://www.jeremyong.com/cpp/2021/01/04/cpp20-coroutines-a-...

It sounds like you’re quite nearly there actually! One important skill imo is the ability to treat a certain layer of the stack or process like a black box (inputs and outputs). A fully generalized scene pipeline is layer upon layer of boxes, many of which will be opaque when you start off. How are clouds rendered? Fog? Reflections? Shadows? Ambient light? Each of these areas is an active research topic and you definitely couldn’t hope to understand all of it all at once.

Don’t be too down on yourself. There’s actually more overlap between graphics programming and other disciplines than you might image. Imagine the gpu is your “server” and each cpu core is your “client.” We have a difficult job of feeding tons of data to keep the server occupied. We have to worry about memory hazards, as well as cpu-cpu synchronization and cpu-gpu synchronization. Like server engineers, we think about pipelining, data consistency, caching, compression, and more. The assets themselves need to be streamed from disk/network to memory, so that’s another systems programming concern.

This all happens independently of the actual kernels/shaders we dispatch on the GPU itself (where the 3d math and all that comes into play). There are definitely rendering programmers that specialize more in the stuff above though.

Great points but I want to say that this is partially true. Yes you’ll see code in the shader assembly needed to sample a texture for example, but it will use instructions for vertex interpolation you just don’t have access to directly if you cut the pipeline for a visibility buffer technique. Also for barycentrics, we can query that from the hardware rasterizer, but the tradeoff there is storage. Also, if you do this in compute, unless you have access to the recently added compute derivatives, you’re still responsible for managing the bookkeeping needed to compute the finite differences.

The general trend has been towards having general compute yes, but check the ISA and read your shader disassemblies before drawing any conclusions.

Awesome! Note that there are better writeups for learning the specific implementation details for any given technique, and this article was mainly written to give people a rough “mental model” when assessing a whitepaper or siggraph talk or something. If I have time I’ll go back and add a section with references to the core techniques I see in use today.

Hey author here :) I actually deliberately kept the tiled lighting section hopefully devoid of any consideration for deferred vs forward since as you say we can (and do) do tiled light culling with both algorithms. Quad overshading and the use of "helper lanes" is worth mentioning in the article maybe as a footnote. It certainly is another way in which the GPU's silicon can be underutilized, but I'd hesitate to say it is the "main reason" for deferred so much as "one of the reasons". I definitely struggled to walk the balance between summarizing the concerns at a coarse level, vs providing all the gory details. So to your point, definitely wasn't comprehensive, there's RTR4 for that :). "... for young bloods" is in the title after all

I wrote this article you might like: https://github.com/jeremyong/cpp_nn_in_a_weekend/blob/master...

No dependencies. Just straight C++. The code is heavily annotated, doesn't use any matrix libraries or anything, and gets 92% accuracy or something without any fancy techniques on the MNIST handwritten digits database.

The mods emailed me a couple hours ago and said my account was mistakenly flagged as a "spam" account but its been since corrected. Thanks!