david-gpu

As a Spaniard I am profoundly ashamed that these crashes are happening, when other countries like China, France and Japan seem to manage just fine with their extensive high-speed rail networks.

I bet I am not alone, either.

Consequently, I have zero intention of renewing my Gemini subscription. What a dumb business choice they made.

You would be surprised. Not only because, as you point out, recent graduates often have a negative net worth, but also because people tend to increase their spending in lockstep with their income.

Saving millions takes the intersection of multiple factors: sufficient disposable income, prioritizing investing over lifestyle, long-term discipline to stick to the plan, and luck to keep it all going smoothly.

> “A human error by an [state-owned railway infrastructure company] Adif operator in response to a malfunction in the main signaling system is the likely cause of the accident,” government sources said. This safety system is automated, but when it fails, it switches to manual mode. That is why the trains came to a stop when the automatic safety system failed, and service resumed under human control — and that is where the error occurred, according to initial analyses.

This is not the first time something broadly like that happens. In 2013 another train crashed because there was a section of the track where the operator had to manually adjust the speed, and he didn't.

One would think that the operation of these trains would be fully automated at all times, and with sufficient allowances to handle emergencies safely.

Point in case: Japan has not had a single death due to a crash of a high speed train, even though they have been operating an extensive network for decades.

Your understanding is broadly correct. There is a 3D world, and the GPU computes how it looks like from a particular viewpoint.

In essence, objects are painted back to front, so that in the final image every pixel shows the nearest visible object. The details get complicated, but the idea is simple.

There is more machinery internally than what the user can see. Even "low level" APIs hide quite a lot of the internal complexity.

> Also AFAIK something like a texture sampling operation is indeed a 'fancy instruction'(?)

Yes, and no. The "I want to sample this texture" part looks like a fancy instruction to the shader processor. But there is a fair amount of setup that needs to be done before and after, and that is the responsibility of the device driver. Stuff like: where is the data, how is it arranged in memory, how it is to be sampled, etc.

As you point out, the texture units are coprocessors inside the coprocessor that is the GPU itself. It is turtles all the way down. Think of a GPU as a whole network of processors inside a chip, some of which are hidden from the application programmer.

> I bet this type of GPU/CPU handshaking work could also be baked into the hardware (similar to CPU mirocode) and exposed via a standardized memory mapped IO interface (or whatever the current mechanism is for letting the CPU control the GPU)

Attempts have been made. Last time I checked, they had not been very successful, but I have not kept up with the latest developments after retirement.

The way this normally works is that there is a circular command buffer where the CPU inserts commands and the GPU consumes them. It works; there is nothing wrong with it. It is the obvious way to handle asynchronous coprocessors.

> E.g. a CPU also implements similar protocols to talk to the rest of the computer system (e.g. memory and other CPUs), but this is mainly implemented as "hardware protocols" - drivers "just" offer more flexibility for hardware vendors because they can delegate the standardization into software.

I suspect you underestimate the amount of setup that is necessary to drive a GPU. And the amount of asynchronous resource management involved.

Let me put it this other way: the people doing this for a living for decades know what they are doing. There have been attempts to try to make GPUs that behave more like CPUs in terms of how they are driven, and they have not been very successful so far, to my knowledge. AMD acquired ATI back in 2006, so it is not like there hasn't been enough time for the concept to cook in the oven. See also Intel's Larrabee.

First, GPUs aren't simply "highly parallel CPUs", they also contain a whole lot of fixed function hardware that is specialized for real-time computer graphics. This hardware isn't exposed as "fancy instructions", it is set up in other ways, which is achieved through a device driver.

Second: GPUs are coprocessor, separate from the CPU where another OS is running. This also necessitates a device driver to manage scheduling, synchronization, etc. with the main OS. Because, in case you were not aware, the GPU itself runs its own little operating system, although it is rarely called that.

Would I go as far as "appreciating their beauty"? More like accepting that they are there, let them remind us of what happened, and how we prevent something like that from happening again.

For some young folks it may be an opportunity to pause and think about how sometimes people do not recover from their injuries. Most of us eventually become disabled, and we still need to continue living our lives as best as we can with what we have, which is why public transit, walkability and accessibility are important to preserve.