Good point!

That wouldn't really work for me, as I tend to really like RPGs with their menu-based combat, and such games do tend to be HUD-heavy.

(Keeping the game turn based, with an option to control the battle speed, can help with the visual overload issue.)

It is certainly possible to write code that runs faster on an iGPU than on a dGPU by taking advantage of faster
CPU<->GPU transfer speeds on the iGPU, or other performance differences between the devices.

In fact, I have even found a case where a software renderer is faster than using the integrated GPU (and probably faster than a dGPU): the glxinfo program. (Granted. glxinfo doesn't actually display anything; all it does is check what capabilities the graphics hardware/driver supports, but the point still stands, even if it's not a typical use case.)

I do play rpgs too, just with turned off radar and similar things. I dislike those as it reminds me of a submarine sim and break the immersion for me. Usually they say where to go if one pays attention so it's not that hard. Games that offer these options to turn things off have a huge plus in my book. Also games like Kingdom come deliverance etc with hardcore mode aka pretty much hud-less mode is just my thing. Immersion ftw! Oldschool rpgs, jrpgs and dungeon crawlers on the other hand, yea they could be tricky to declutter without some mods for minimalists I reckon.

Certainly, though we moved from games to synthetic benchmark/utility territory. I waited for a decade for apu magic to happen and materialise on the software side, but it didn't happen. Interconnect on the same die will always have minimal latency, just like hbm2 stacks of memory next to the gpu die have way lower latency and power consumption than gddr6 modules sitting mere 7cm away from the gpu die. That alone won't offset the slower system memory, syncing, etc in the case of an apu. However a modern dGPU sitting on x16 lane with a decent modern cpu is not that unresponsive nor lacks bandwidth. APUs are not meant to compete in performance with dGPUs. It's like a different league, they have their own bottlenecks and throttles/limitations, for the sake of mobility/size/power consumption/price/etc, although they improved a lot in recent years as expected.

Iirc there were some programs that benefited from having an intel iGPU specifically, I think it was from adobe or some other company, don't remember exactly. Those programs were not 3d games though for sure. Unfortunately I don't have any weak dGPU in the league of my strongest APU to duel them in a benchmark of sorts. Would be fun deathmatch tho I'm sure.

By the way, benchmark of glxinfo on a Raspberry Pi (with output redirected to /dev/null, to eliminate the cost of actually writing the output to the terminal window):
* On hardware, .650 seconds.
* With llvmpipe, .280 seconds.

(Also, I note that godot3 will refuse to start on hardware, even though it seems like it should (the Pi 4 is supposed to support OpenGL ES 3.0 (and even 3.1), but godot3 claims the support is missing), but will start with llvmpipe.)

That's fine, and that would indeed improve things, but the problem is that such a setup (especially given the target audience would likely be in the sun alot) is not really fit for purpose. I'm not 100% sure, but i think all they'd need to do is have a blank frame every so often, too. I haven't looked too deeply into what's causing the burn. Still in the realm of theory, not in practice. I'd have to look at the schems, but the big picture is to try to get as much into cache territory as possible on CPU, anyway. In reality, the RAM is a huge bottleneck without the memory controller, which is something AMD learned the hard way a long, long time ago. Unfortunately, Microsoft seems to be the only ones (on the software side of things) actually trying to do something about this, and I honestly think it was accidental on their part. GNU and whomever now owns LLVM are really, really behind the ball on this one. There's alot more promise to fixing this issue on the software side of things, than the hardware side. The APUs have managed to make some things playable that you would never have expected to be playable, too. While indeed it's not magic, you'll find that, indeed, the bottleneck is caching and the like. We've gotten to the point that it's not how much RAM, but how much cache and how fast the RAM is. Moreover, bottlenecks tend to follow the Pareto distribution, as well, which means that once you manage to get the whole thing in cache almost all the other memory hogging things are just textures, models, etc which the GPU is focused on, and isn't going to grab nearly as much per second as everyone thinks it will. Except these APU drivers actually do reduce latency. Another thing is the age old trick of making sure your game and only the bare minimum services are running, because task-switching is killer on your caches. You're never going to see max clock-rates, regardless with any of the technology. Something has to lock up for syncing somewhere at some point, and that'll be where you spend most of your down time, anyway. This is another reason why the APUs can present magic. The trick is to get some sort of external connector to allow direct connections (yeah, not easy, i'm aware, and would likely require re-pasting) of the GPU and CPU as external entities still sharing that MCU. Obviously we need proper "desktop-grade" APUs to see the tech fully flourish, because, as you said, they're cutting costs in them, yet. Caches need to be expanded and coders need to start looking at their code sizes, and compiler makers need to start improving linking. Microsoft can import functions based on whether or not they're actually used, and GCC and such cannot, which is a huge bottleneck issue to be had. I wouldn't rely on reviews, especially after semi-recently we had a nice little thread here where people were complaining about vsync, only for vsync to be invented and called something else ("enhanced sync" or something like that: they basically just took stability features away from vsync that weren't necessary and should not have been part of vsync to begin with) by the GPU-making companies. And reviewers i found were all eating it up like it's fancy new technology. It was like watching someone invent "enhanced dicast tires" where you could separate the inner-tube from the tire treads, and calling it new technology, and everyone going gaga over it.

APU is an integrated CPU-GPU combo that actually acknowledges what they share, basically. From what i've seen based on complaints when it first came out on GOG, it seemed the initial reports were going in the direction that it was the bandwidth between the CPU and the GPU that was the problem. In theory, this means indeed some integrated GPUs could handle it way, way better than separate units. However, then it'd be hard to not call it an APU. The truth is a bit more complex than that, but the big picture really is the integration between the two. At the end of the day, you're looking at the same, age-old threading issues no matter what hardware you use. At the same time, though, how long you spend between syncs is really, really important (so that data-transfer rate).

I mean, you gotta think of it this way. You have a CPU that only goes so fast, a GPU that only goes so fast (and their individual cores can thread, but for the sake of simplicity we'll just treat it like a single thread in each), and they also have to communicate with one another to discover how, where, and what goes on that screen. The GPU's job is to put it there, and the CPU's job is to tell it what to put where and how. If the CPU's choking on AI code, GPU's going to end up waiting for the CPU to hurry the hell up. If the GPU's choking, the CPU could end up waiting for the GPU, which also means the game logic is running slower, too. Sometimes, they both have to do another task of sending and receiving lots of data like textures, which means, while they're both busy, they're also hurrying up and waiting to do their real jobs.

This, of course, all gets magnified when you realize there's multiple cores, multiple threads, threads locking other threads for syncing (yeah, sometimes threading makes things run slower), unrelated processes, separate hardware (yeah, the SPU could use some stuff to do, too, and we all gotta wait for the hard drive to load the textures and models), and dare we wait for the next packet in an online game, or are we using non-blocking sockets?
Yeah, 'cause all that's sync-heavy. Send request, wait for response. Going to be much, much slower over PCI or any of the other buses. This sharing does indeed improve things, because most people (it took me forever to realize this, too) don't realize exactly how much graphics get processed on the CPU side, anyway. CPU still does alot.

Yeah, the 'big thing' for APUs is the layering technology that AMD especially has been developing. That would involve a CPU layer, a RAM layer, and an iGPU layer on the same chip. The RAM layer would effectively be a massive level 4 cache between the two processors. There is some basic use of it announced/ released already as 'V cache' on Zen3 but its longer term applications for APUs is pretty obvious.

Would still be unlikely to make APUs truly competitive with discrete systems though. The bottleneck would shift from slow/ limited memory bandwidth to balancing heat dissipation/ power to cores and frequency; and the RAM layer would likely have to be expensive- HBM for 'commercial' RAM, if not actual SRAM like the V cache is. Should still give a lot better performance than current APUs though.

Indeed. My gut reactions is to find a way to separate them, long term, so they can be drop and replace, and at the same time not have them tied to each other (so you could upgrade one part without upgrading the other). However, that's not realistic.

Given the space between the CPU and the RAM as it is, and all the talk about how "ram is cheap" (from all the anti-optimization coders out there), i think it's high time we consider actually givving the CPU dededicated separate memory controller for VRAM instead. When you have separated GPU, like with most desktop applications, you are still using some old tech transfer mechanisms and this all has to be shared with the other hardware. I remember a microcontroller I have had a unique setup in that you used memory operations to send certain commands and address certain areas of vram, because it was wired such that the external RAM MCU was hooked directly to the GPU (all low clocked and low tech, mind you). The hardest part of this route is figuring out what programs should have permission to run the instructions. There's also an incredibly opportunity here to get rid of graphics drivers altogether by dropping this into shaders and coming up with a standard "calling convention" between shaders and the CPU.

I'll stand corrected: i just discovered the -flto option, which is disabled by default. This is a huge oversite, and i noticed the libc object file on my system was not compiled with -flto, demonstrating the problem of it not being enabled by default.

Dunno man. It felt really cheap in my hand.

Like a 10$ Walmart game pad.

oh thats low :O
is it really that bad?

ah so have no actual example or statistics , well we can label it as a false myth then

Yes. I held one in my hands once or twice, and the first thing i said to my GF who owned it was "I sure as hell hope you paid no more than 15 bucks for this." Fortunately for her, it was a gift. Wasn't all that fun to play with, either. Something funky with the left stick or dpad or something, i remember, but i forget what. Had some weird feedback system, too.

hmm glad i havent got it then , it looks niche anyway probably not many games use it , the xbox type controller i have is supported by nearly every modern games and easy to get used to