oddity

There are a whole lot of steps in between having a netlist and having useable hardware. Normally, if you're a large company, you have a small army of engineers handle that process and occasionally tell your architecture people that they need to fix up their designs here or there. When you target an FPGA, which is really more of an abstraction on top of silicon just like CPUs or GPUs are an abstraction on top of silicon, you're effectively paying them to do this process for you and mediate it via the software stack.

There's plenty to debate about where the boundary should be, but an almost universal constant is that ecosystems ossify around interfaces, so hardware companies will generally see giving up control as a borderline existential threat unless they're in the business of fishing pennies out of the gutter for margins.

I've started learning Godot to replace Unity for the prototyping role, but under no circumstances would I ship a game in stock Godot except for a game jam.

The stock editor workflow is solid enough and overall fairly pleasant, but the documentation is abysmal, features aren't up to par with the Unity of even a decade ago, and code quality is "improving". I also have absolutely no clue why the world needed an even worse rehash of python that has absolutely no compatibility with any of the python ecosystem. I've read their blog post. I still do not understand.

Godot 4 looks much more promising on the feature front, GDNative is passable, and at the very least, you can fix the engine yourself if you need to. I don't feel much of a sense of loss from ditching Unity.

The race to the bottom was absolutely Apple's fault. Software distribution over the internet existed before the App Store. Even Steam existed before the App Store.

But Apple based the App Store on iTunes, where the songs were 99 cents and curation was a token effort. It took years for Apple to recognize that people needed to be able to find the good apps more than a few hours after they released onto the store.

Driver developers would like for it to be their concern and their concern only, but this doesn't scale when an application developer needs their app to run on hardware from vendors with different levels of driver quality. Vulkan and DX12 were built with the assumption that application developers would take on more of the burden that the driver developers were doing for them (or not doing, in the case of some vendors). The problem is that hardware vendors will always build a lower level as long as it's economical to do so.

AMD GPUs starting with GCN 1.2 include a microcoded hardware scheduler for virtualizing queues. NVIDIA also has a custom (slightly different functionality) control processor (https://riscv.org/wp-content/uploads/2017/05/Tue1345pm-NVIDI...). NVIDIA is certainly the worst of the two for this, but in both cases they're convenient places to shove proprietary secrets while still keeping the driver open source. But even if you see an open source driver on one platform, you have very little guarantee that similar optimizations are running when you use a closed source driver on an entirely different platform.

But, honestly, open source driver/firmware is a low bar. Some of the nastier secrets are in _hardware_. Things like instruction X halving the throughput of a seemingly unrelated shader only on hardware Y might not be obvious unless someone tells you, and they won't tell you in public because it might give away IP. These are the kinds of things you'd hope to find in microbenchmarks, but the search space at the API level is so large that I doubt anyone could come up with a reasonable model on their own. Smaller (or even larger) devs just can't microbenchmark at the scale needed to find these issues.

I don't think hardware vendors are in the wrong for this. Hardware vendors have very understandable motives to guard their IP for competitive and forward-compatibility reasons. Honestly, I think most of the development in graphics APIs has been for the better overall, but that doesn't change that using these APIs is undeniably miserable. With CPUs, we dodge the problem by recommending that people minimize context switches (an IP boundary between different layers of the computing stack) so that most people can assume that most of the code that ran is theirs when they measure things. For the same reasons, I recommend that most people minimize graphics API exposure.

Most GPUs are not self-sufficient to the degree that CPUs are. Where on a CPU, I can spawn an arbitrary child process/thread running (almost) any code with customized communication between the threads/processes, on a GPU, the hardware (and/or driver) implements the process loading and scheduling logic, usually restricted to a pattern that suits graphics applications. This means that there's a greater surface area for the graphics APIs to have unintuitive behavior.

GPU-driven rendering relies on some of the limited ability for the application programmer to schedule more work for the GPU _on_ the GPU (example: https://www.advances.realtimerendering.com/s2015/aaltonenhaa...). Bindless rendering refers to the ability for the GPU shader to use resources on the GPU without having to announce to the driver that it intends to use those resources. Essentially, I'm saying that the layers between the application and its shaders are so opaque that for most ordinary people, the most reasonable solution is to use less of them wherever possible so that they can actually intuit the numbers they're seeing through microbenchmarking. In both cases, there's a code complexity and performance penalty, so if you're trying to get peak performance (like a AAA might), then there are good reasons to not do it. This is on top of portability concerns since not all hardware supports all the features that might be needed to do this.

If you're just trying to get into graphics though, I'd recommend starting with webgpu (where these techniques aren't possible, yet). The API is relatively clean and easy to work with compared to everything else, and I'm assuming performance won't be the primary concern.

Performance, at the level of a single frame, is a complicated multi-system interaction where only a few layers are visible, and small bubbles can cascade into missed frames. None of the IHVs are incentivized to make all layers visible, so I'd argue that how hardware operates is not more or less understood by the application developer unless they have the influence to talk to the IHVs directly.

I'm not saying that the APIs can't be used to get good enough performance, but I am saying that it's a fiendishly hard problem, and even harder if you're not one of the handful to get (more) complete information. Perhaps much more so than the CPU world where microbenchmarking is more mature.

Even if the driver were a thin layer over DMA talking to the hardware such that every button being pressed was obvious, the performance characteristics of the buttons the driver pushes are not unless you can see their RTL or otherwise know the right combination to push to hit the right potholes.

Except, we're not in that situation, and even for mostly transparent drivers there can be an opaque firmware blob in between you and the hardware. Without changing the economics, pushing the API lower only pushes the implementation of the opaque behavior lower.

For most games that people might want to make with Godot, it's probably good enough. Not everything needs to be perf-optimal.

Also, the driver source being open doesn't mean that all their secrets are too.

Sadly, it's even more complicated than what's described here. There are a lot of undocumented fast paths and nonorthogonalities between features where you can really only learn about them by talking to your friendly neighborhood driver engineer in a backdoor conversation (that only a select few developers have access to). Otherwise, it's easy to miss a lot of spooky action at a distance. Vulkan and DX12 might have been sold as "low-level" APIs but they didn't (and can't) do much to address the fundamental economic issues that push hardware engineers to build patchwork architectures.

I'm half of the opinion that writing an efficient Vulkan or DX12 renderer has not been and cannot be done. If you're not one of the developers shipping a AAA title with enough weight to get attention from the RGBs, you're probably better off going as bindless and gpu-driven as you can. It's not optimal (or entirely possible on some architectures), but it probably has the most consistent behavior across architectures when it's supported.

Well, one of the authors is from NVIDIA, and the paper already mentions CUDA, and it's only to argue that CUDA is a good point of reference but doesn't do what the authors need it do (shader programming). SYCL doesn't add anything to that conversation other than being yet another example.

This isn't a case of a standard coming along to a crowded market. Rather, this is the opposite scenario. USB-C won and now they have to deal with the fallout of unifying all the things past, present, and future.

Certainly, Apple's crippling of PWAs and total control of browsers on their platform is a problem, but I've seen enough to know that what (web) devs really want is Chrome (or, more accurately, a monoculture). Whether it's Chromium in a browser (Chrome, Edge, Opera) or Chromium in an app shell (Electron), your stack is never good enough unless it's Chrome. Hopefully both Apple and Google have their worst aspects reined in at approximately the same time because otherwise we're just going to move the problem to the web layer.

WebGPU is a much more approachable API than Vulkan or DirectX 12 and is more portable than either (or Metal, which is secretly the best graphics API available today if you can put up with Apple). If you're trying to hack something together or write something nominally portable like you could in the good old days of OpenGL, I'd recommend starting with WebGPU. *

However, it's not at all a viable replacement and it's not clear it has a path to become one in its current state. WebGPU is limited to a least common denominator of features that sets it back at least half a decade of hardware and API advancement. Some of these features (like raw pointers to buffers) would be challenging to adapt to the safety requirements expected of WebGPU.

Then, you have to consider that it's yet another layer of indirection on top of a stack that's already filled with more magic than any one developer or company can keep in their head(s). It's another layer removed from the driver written by hardware vendors, too, so hitting the fast paths gets a little harder. Plenty of devs are already hesitant to move from DX12 to Vulkan, so if they move to WebGPU, it'll start with baseline support for browsers and not much else, then maybe expand if WebGPU somehow goes deeper into the hardware stack.

* I need to asterisk this because, to be honest, I think the whole paradigm behind all these APIs is complete and utter garbage but that's a much longer conversation and has no obvious resolution in sight.

On the Android side, this would be a small but welcome improvement. Though, with smartphones approaching commodity status, I'm sure we'll see more and more upstart phone vendors that go out of business 2-3 years in to dodge support requirements. I'd be curious if the regulators have measures against this. I'd expect not. I'm also a bit wary of legislation that would require hardware vendors to be good at software. They're different skill sets and there's a risk that any such measure would stifle smaller companies that serve more niche markets.

For any vendor that locks down hardware to a specific OS like Apple, I think this does very, very little. For a personal example, Apple botched the battery management software in iOS 14 causing several older model (but recently bought and healthy battery-wise) iPhones I own to drain from 100% to 0% in 2 hours with no app use and from 100% to 10% in seconds if apps like Podcasts or Mail try to sync. These phones are nominally supported, but unusable. Apple's approach to responding to user (or developer) bugs is notoriously useless unless you get media attention, and their user-interface philosophy is that no problems happen ever and if they were to happen, you the customer should not be allowed to know the information you would need to solve them. Apple is up to 14.7 and soon 14.8 and still has not fixed all the battery management issues they introduced with 14.0

If this were a PC, I would just roll back the OS, but with iOS devices, Apple requires sign off with their servers and only allows the most recent version (+/- a security update) to be installed. They do this for security, supposedly, but don't seem to care that they prevent people like me from running alternative software that might fix the problems that make their otherwise perfectly functional devices unusable. Unlike their M1 Macs running on the same architecture, they don't even give the option. Their phones ship with special fuses that get blown when given to customers to lock them down at the hardware level. That's how far they go.

Right to repair is hollow without the right to install alternative firmware and software.

I'm not a professional artist or marketer, but I suspect the main reason we see the pursuit of realism in games is that it's easy to communicate and coordinate, so it reduces uncertainty across the board. Developing a style is hard and requires a lot of coordination across different teams to understand and internalize what approximations are being made where. At scale with hundreds of artists, it becomes very difficult. If, instead, the approximations are enforced by the tech and the goal the artists need to consider is just to create something realistic, then that's easy to get started with without needing a concept artist to dictate everything. There's probably a crossover point of team size where realism has lower risk and lower cost. In practice, I think what we see is that the more creatively-minded large studios shoot for 90% of assets being "realistic" with some strong stylistic choices for the last 10% that really defines the look.

On the marketing side, there's something to be said for knowing that your visual style will be uncontroversial for the most critical time period for getting sales (launch). Looking horrible 10 years from now doesn't really matter if you're trying to recoup your investment today. It has slowed down now because a lot of the low hanging fruit has been done, but a decade or so ago, graphical features were one more reason marketing could point to for someone to buy a game. Some people really do buy games because they look pretty. Even today, there are games notable only for being benchmarks.

This isn't because of the writing though. The whole article, start to finish, is about alternatives to lithium ion batteries, of which a derivative of durian is an option. Judging by the URL (https://www.bbc.com/future/article/20200724-the-battery-made...), BBC tried several titles until they found the one that got the most clicks. I don't think the author would have picked the current title if they had the choice.

It is. From the article:

> Vincent Gomes, a chemical engineer at the University of Sydney, and his team, including Labna Shabnam, are turning waste from the world’s smelliest fruit, durian, and the world’s largest fruit, jackfruit, into a supercapacitor that can charge mobile phones, tablets and laptops within minutes.

> Supercapacitors are an alternative way of storing energy. They act like reservoirs, able to quickly charge and then discharge energy in bursts. They tend to be made out of expensive materials like graphene, but Gomes’ team has turned inedible parts of durian and jackfruit into carbon aerogels – porous super-light solids – with “exceptional” natural energy storage properties. They heated, freeze-dried and then baked the inedible spongey core of each fruit in an oven at temperatures of more than 1,500C (2732F). The black, highly porous, ultralight structures they were left with could then be fashioned into electrodes of a low-cost supercapacitor.

Chip development cycles are long enough that sometimes the only response companies have is to downplay their competitor's innovations until they have their own version. The hilarious part is that sometimes it works.

A 64/128 core variant would effectively be a revival of their Xeon Phi line, which, in its later days, was basically this. It seems inevitable we'll see it again. My guess is it'll happen after Intel gets comfortable enough with chiplets to ship decently binned parts at a reasonable price (probably by sharing chiplets with laptop chips or some other high-volume product)

I think mass market tech media doesn't know how to interpret the impact of efficiency cores or big/little designs for average PC users since the best effort example they've seen so far was Apple's M1, which changed other things at the same time. Meanwhile, enthusiast tech media doesn't care because their existing reference frame is almost exclusively performance cores. I think they'll be more inclined to see the first generation or two as a gimmick, and then a laptop-only thing if Intel catches up on the performance core side.

Indeed. I also expect this failure mode will be undetected for a long time due to how our sense of hearing works. My last neuroscience class was many years ago, but I do remember that in some sense, we hear what we expect to hear (more so than vision if I recall correctly, though there is plenty that happens in our vision processing) in that our ears tune for particular frequencies to filter out ambiguities.

Suppose a person says something that the codec interprets differently. Perhaps they have one of the many ever evolving accents that almost certainly were not and absolutely could not possibly be included in the training set (ongoing vowel shifts might be a big cause of this). The algorithm removes the ambiguity, but the listener can't tell because they hear themselves through their own sense of hearing. Assume the user has somehow overcome the odd psychological effects that come hearing the computer generated audio played back, if that audio is mixed with what the person is already hearing, it's likely they still won't notice because they still hear themselves. They would have to listen to a recording some time later and detect that the recording doesn't match up with what they thought they said... which happens all the time because memory is incredibly lossy and maleable.

Most of the time, it won't matter. People have context (assuming they're actually listening, which is a whole other tier of hearing what you expect to hear) and people pick the wrong word or pronounce things incorrectly (as in not recognizable to the listener as what the speaker intended) all the time. But it'll be really hard to know that the recording doesn't record what was actually said. You need to record a local accurate copy, the receiver's processed copy, and know to look for it in what will likely be many hours of audio. It's also possible that "the algorithm said that" will be a common enough argument due to other factors (incorrect memory and increasing awareness of ML-based algorithms) that it'll out number the cases where it really happens.

> But only Apple and Google are big enough to fight the other bad actors

"big" is not the deciding factor. Amazon and Microsoft are also big. They do not decide what's on your phone. Apple's and Google's stores are big by default because Apple and Google have control of the platform. It's not the other way around. It's also not binary. If the store is decoupled, they will have less control, but not no control. Influence is weighted by user-base.

> Sure, their interests may not always be aligned with mine, but we are much more likely to be aligned than mine with the bad actors

Their interests are more aligned because they sell you the platform. They have many more ways to do this that aren't dependent on a quality app store. A store that survives on just the store is even more aligned to maximizing loyalty and trust in that store.

> And if I decide that I no longer want Apple to play that role, then I can go buy an Andoproid device, or whatever

Maybe you can, but for most people in the world, a phone is a significant investment and not a choice you can easily switch when you've already spent significant money in the ecosystem.

> It’s like cryptography. Either it’s broken, or it’s not

It's not. Even now, there are practical limits to what Apple can demand of its developers. Less control means less power, not no power. A store filled with bad apps is not a store most people will willingly buy from, unless there is external pressure forcing them. I don't think there's really much of an argument there. What this discussion is really about is the Facebooks of the world that have tremendous influence and also do shady things. Already, we see that Facebook plays by different rules with different stores, with greater tracking on Google platforms. This wouldn't change if Apple's store were still big enough to matter, but if Apple's power were weakened there's a risk that Facebook (for example) might have enough power to not care. So, this is what it's really about: some people trust Apple more than Facebook and want Apple to have total power in that relationship by being bigger than Facebook. This necessarily piggybacks off of the power given by people who do not care about or trust Apple, gained by means that are not the quality of the store. These people will likely stay with Apple regardless of how much Apple abuses its trust, but yet the people that do trust Apple think their trust matters.

Oh I wish avoiding code cleanup was the worst of it. I've seen people totally ignore the most easily fixable bugs. Everyone knew what they were and how to fix them, but no one wants to be that person who spent time working on the bug that was only affecting 5% of users if it meant that any of the bugs that were affecting 95% of users were even a day later. Ignoring the ROI, the fact you even need to have that conversation adds cost.

Where it becomes more insidious is in planning for broader efforts, where even the ROI is nebulous. People seem hesitant to invest in experimenting to estimate ROI, which limits the topics and questions teams even bother to ask and gives a very skewed, short-sighted view to management.

What splitting the app store from the OS does is encourage stores to compete on the basis of quality of the store and not the quality of the store + OS + hardware. Apple and Google will have less leverage, but all the qualities of an aggregator will still apply. Google doesn't own the websites they index or the internet they're served over, but they still have tremendous control over the web.

We see this even in the PC space: people will refuse to buy games not on Steam and many of the stores that sprung up a few years ago (Origin and UPlay) have since conceded and narrowed in scope.

Some apps will bypass the Apple/Google store, advertise themselves, and supply their own infrastructure for distribution. When that happens, Apple and Google will no longer have control. Implicit in the argument that they should have control is the assumption that these two companies are the only two enforcement bodies that can be trusted. As should be evident by now, you do not control Apple or Google and have no recourse if they break your trust. These companies care, first and foremost about their profit margin. It is naïve to think that consumer choice reflects Apple's or Google's stewardship of the store. Not everyone buys a phone because they like the walled garden.

I used to think sideloading was/third-party stores were a problem because of what you describe, but I've come to believe that it's the most free-market solution available to curtail some of the excesses of these gatekeepers while minimizing design-by-government.

Ugh. This mentality is fine when you want to ship an MVP but it's absolutely poisonous to the team and the project if you hold on to it. You need some slack for people to address the problems they think need solving without needing to justify why they're solving it. From a team perspective, it helps prevent burnout and encourages development, and from a project perspective it's essential to preventing management-driven tunnel vision by allowing the team to explore and prove out things that management doesn't understand yet. I've seen a lot of data-driven projects starve because of a fear of collecting new data, and it's totally invisible to management because they're hitting the KPIs they set for themselves.

Prioritize, yes, but don't starve lesser priorities. Let individuals decide, say, 10%-20% of their effort spend and don't question it. That figure, conveniently, corresponds to the Friday they're spending not productively working anyway.

I'm extremely bullish on AR/VR, neurotech, and smart wearables over the next decade or two, but this article seems oddly focused on AR glasses replacing phones. We're definitely seeing the phone separate into pieces closer to the body (wireless earbuds and watches), with the phone serving as a hub. The Apple Watch is almost where the original iPhone was in terms of technical capability (and has already passed some of the iPods, minus a headphone jack), but it lacks the large screen, large battery, and large compute power of modern phones. This should sound familiar: this was the main difference between the iphone and laptops at the time. Compute power and battery sizes can maybe reach good enough levels to replace the phone's role as a hub for most people within the next decade, but it's not clear anything can be done about the screen without expanding along or beyond the wrist. This, to me, is the value proposition of an AR HUD (which, maybe, absorbs or emerges from the growing smart earbud/headphone category). When looking at it as a compute element, I don't know if putting the brains on one's head (ironically) will be compelling vs the flexibility of storing it in a pocket or purse or strapped to some other body part with better ability to bear the extra load. I doubt AR glasses will gain brains fast enough to displace phones before something else takes its place. Strictly viewed as a device for viewing/hearing things controlled by some other device the user owns, the biggest challenge for glasses replacing the phone screen will be competition from all the other displays we're putting everywhere we look (living rooms, cars, pockets, etc...) It's possible AR wins by some benefit of economics (fewer screens!), but it's also possible that it loses because of inertia.

I have a lot more to say on this, but half a century from now, I think we'll certainly look back at the phone as a weird transitional device with a lot of odd UX compromises, but as it was (and still is) for laptops, desktops, and mainframes before them, the phone will probably not go away in some niches for decades (if ever). It's still a huge question to me whether over-eye AR will be the leading form factor that replaces them, and I'm unconvinced that the mass market future is AR glasses alone.

Given the price of these systems and the current value proposition, I think it's more likely that they only do it when someone else is paying for it. Think business class. You wouldn't exactly say you were "forced" into business class.

Absolutely! A common example I like to use is Java. It might be hard to imagine now, but there was a time where Java (and then C#) were pitched as a replacements to C++ (even the name "C#" supposedly derived from "C++++"). There was no reason to write native code any more, many people said. And, they were kind of right. Many people were writing applications in C++ because they thought they had to, even though they weren't writing C++ in the style needed to make proper use of it. A lot of old C++ code bases today look like much more verbose Java applets. This peeling, when it happens, is usually good for everyone since languages (and tools) evolve to better fit the domains in which they are most used and happens so gradually that few notice. The inverse also happens, but with more conflict: you can see this today in Python (and other dynamic languages) adopting typing features aimed at assisting tooling for large code bases, well beyond the traditional learning or glue scripting mentality for which they were designed. This often results fierce debates around language features (like static typing vs dynamic typing) that are really proxy battles for the usage intent of the language.

Unfortunately, I think the "replacing X language" mentality happens because it's the easiest point to start with. The field of programming and computers is so vast now that most (all?) people have a very narrow view and it's easy to assume it's universal. I've lost track of all the "things all programmers should read/know/do" articles.

Anecdotally, everything I've seen (hardware drivers) has been in (MISRA) C or a subset of C++. Ironically, many of the alternatives require too much discipline to keep devs happy. MISRA C at least lets them pretend they're in their happy place.

(I'm assuming you're coming from C and don't already know C++ because of the linked article) If the ecosystem that's available is sufficient for your needs on the platforms you care about and you're not interested in easy compatibility with a C/C++ codebase or your existing C knowledge, I would recommend Rust over C++ whenever possible (C is a different question since it fills a slightly different niche and doesn't really have a solid alternative yet imo). Rust has a much simpler and well-chosen set and interaction of features than C++, but it does that by dropping many of the compatibility constraints of C and C++ (and making assumptions that are easier to make in 2021 than 30+ years ago). Compiler errors also more honestly reflect the learning curve, so it can feel more punishing at the start, but has a shorter learning curve to reach functionally correct code, where with C++ you might easily have been using it for 10+ years and still learn you've been doing something wrong the whole time.

That's a big set of ifs, though. It's possible that the compiler errors are discouraging enough that C++ might feel like a more comfortable choice (I would encourage you to not let this be your reason unless you're just interested in solving a one-time problem). I keep checking in on Rust to see how small and dependency free I can get the compiled binary, and I usually need a mess of nightly features. The ecosystem is also still a mess. There are a few great libraries, but otherwise it's a minefield of 0.x releases for most dependencies (admittedly, some of the most important ones are autogenerated bindings where the version number is meaningless). Bindings are really easy to write with Rust, however, and it's one of the few languages that really gets that right, but it's nowhere near as convenient as calling/using C or C++ from C++. Most of these issues are consequences of C and C++ having the existing inertia, but it is what it is. Some people want to ship things and not join a community.

If you're trying to get a job or just learn: learn both. C++ isn't going to go away completely any time soon, but, with every month that passes, there are fewer and fewer technical reasons to justify starting a new project in it vs Rust. Choosing an inferior tool because it's the only one you understand might often be the correct choice, but it's not a choice you want to have to make.

Sigh.

I'm annoyed by articles like this where the subtext is that the people involved are either fools or evil. And, there's no doubt that much of the Trumpverse has detached from anything I recognize as sanity, but there should at least be some effort put into _why_ the people interested in it might feel the way they do.

Made in China? Sure. Everything's made in China. So what? Some company in China making budget phones isn't the one taking their "free speech" apps away.

Its App Store is insecure? So what? It's like people have forgotten that this is a group with strong overlap with the people that complain about the liberal nanny state.

Is it really too hard to see that the "Freedom" this is about is freedom from the US tech sector and not China, or that the US tech sector might be a more immediate problem in their minds?

Now, is it a scam? A grift? I don't know. Overpromises from a guy who doesn't really know what he's doing but has strong feelings served with a side of self-benefit is what I'd expect from the Trumpverse, but there's no actual analysis beyond stating that these phones can't do what phones backed by trillion dollar companies can do. This kind of article is just lazy.