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.

We don't have a tool or a ruleset to determine whether something is "conscious" or "has real understanding", as the other user put it. And, thus, the statement "X has real understanding" is unfalsifiable.

It is also a thought-terminating cliche [0], because by opening that can of worms the conversation is automatically derailed, as we just saw exemplified here.

[0] https://en.wikipedia.org/wiki/Thought-terminating_clich%C3%A...

Bonus points if it is able to discriminate between human understanding and nonhuman understanding, without vaguely referring to biology.

Failing that, the question seems to me unfalsifiable as per Popper.

That is an unfalsifiable non-argument, a thought-terminating cliché.

You can do it backwards. You declare the properties you want the resulting program/function to have, using a proof assistant like Lean, then prove that a program exists that meets those requirements, and the proof assistant spits two things: a confirmation that the proof is valid, and a piece of code that implements the proof, in the form of computer code.

At least that's how the proof assistant Coq would often be used. You still have the challenge of ensuring that you have defined the properties you really want in the first place, but at least it solves the part where you want the code to meet the specification.

Those who spend time thinking about a problem, then writing design notes, specifications, and test plans, and focus on the implementation last. For these people, AI agents primarily act like an extension to their existing toolchain, and thus like the analogy of "AI as the new compiler".

The other side are people who don't like writing specifications and such, and rather prefer to sit down figure things out as they start coding. For them, an agent feels radically different from a compiler.

In both instances the AI agent is still the same tool, with the same real-world capabilities and limitations. It is not like one camp is blind, they just have very different workflows.

It also seems to me like many in the "sit down and code" camp then slowly figure out that doing some planning ahead of time helps them get better results, and they see this as another AI-led paradigm shift, when in reality it is how many other programmers have worked for decades.

That is not a concern with pay-as-you-go models like DeepSeek. It is stupid inexpensive.

From the viewpoint of a pedestrian, having more "drivers" that don't get distracted on their phone sounds blissful.

There are real concerns about the additional pro-car lobbying we will likely experience, as Waymo will discourage people directly and indirectly from taking transit and cycle, but I hope we can coexist.

To put it bluntly: yes. The upside is that people stick around for a long time, so you get to know your coworkers, and people treat each other nicely.

> If those employees were uneasy was part of that driven by lack of opportunities for their skill set?

Definitely. Sometimes people are unhappy with their job but they don't want to move. So they either stick with a job they don't like, or get out of the GPU niche. Nowadays more people work remotely, so there is more mobility than there used to be, but you still have a very short list of places where you realistically want to work at, so people rarely burn any bridges.

> I'd imagine this is a niche where everyone knows each other no?

Yeah, it is a pretty small world. People are usually hired straight out of college, or they are poached from a competitor.

There is a lot of specialized knowledge, so it takes years for people to really be productive. I left AMD/Qualcomm after nine years and I was finally beginning to understand how that GPU worked. I then spent five years at NVidia and left frustrated with how little I had managed to learn about that behemoth. They are immensely complex systems.

> I wonder if this legacy would allow easier decomps of Xbox 360 software to run on Adreno GPUs?

Oh, such a good question! Let me think.

I don't know how much of the hardware was exposed in the XBox 360. If it was all standard DirecX, then the underlying hardware won't matter (modulo performance). But if they exposed some of the internal quirks, such as the aforementioned GMem, that could be easier to emulate on hardware of the same family. But only if that new hardware also exposes those hardware features, which is not a given.

Way back around 2008, AMD was bleeding money after its acquisition of ATI. They wanted to divest of their Handheld division, which was the business unit that was producing chips for smartphones. From what I heard through the grapevine, Qualcomm was interested only in some part of it, particularly the GPU IP, but AMD wanted to sell the whole thing, and eventually lowered the price enough that Qualcomm sealed the deal. I was just a nobody, so take that with a grain of salt.

At the time the purchase was finalized in 2009, the GPU was a miniaturized version of the Xenos GPU from the XBox 360; all the basic parts were there, but the tile memory (GMem) was colocated with the rest of the GPU instead of being in a separate chip. That's what was marketed as the Adreno 200 GPU. It was a pretty quirky shader architecture where each clock issued two instructions: a SIMD vec4, and a scalar op, in VLIW manner, not superscalar. A lot of the time utilization was poor because the compiler couldn't find a way to pack two useful instructions in that manner. But I digress.

Back to the Qualcomm acquisition. It was a very tense period for the workers. Our salaries at AMD had been frozen for a while, and Qualcomm refused to bump our pay. I wish we, the workers, had built a common front to negotiate, but we didn't. As part of the contract, AMD was not allowed to hire us back, so most of us went along and got swallowed into Qualcomm reluctantly.

Qualcomm had been working on their own GPU design for a number of years, largely through people they had poached from S3 Graphics, IIRC. Anyhow, they had not been able to actually ship their own IP and were still entirely reliant on AMD's GPU designs, so the acquisition made a lot of sense to them. Qualcomm's latest GPU IP was called QShader, and it featured a remarkably sane scalar-based unified architecture; it was a very significant improvement in programmability.

After the acquisition there was a slow process of merging QShader with AMD's Xenos derivative, with the goal of producing a hybrid that would eventually be marketed as Adreno 300. In essence, they took the fixed-function blocks from Xenos, from its command processor to its texture units, while the shading processor was brought in from QShader. That first Adreno 300 (codenamed "Oxili") was a momumental effort from all involved, and while it had some teething problems, it was the foundation for all future Adreno GPUs in Snapdragon chips. And, hey, it even made it to Mars! [0].

Twenty years later and Adreno GPUs still ship with that Xenos-style tile-based rendering architecture. I can't believe that Andy Gruber, the chief architect behind it, doesn't have a Wikipedia page.

[0] https://en.wikipedia.org/wiki/Ingenuity_(helicopter) [1]