There is no "real" GPU virtualization available for regular consumer, as both AMD and NVIDIA are gatekeeping it for their server oriented gpus. This is the same story with Intel gatekeeping ECC ram for decades.

Even if you run games in container you still need to expose the DRM char/block device if you want vulkan,opengl to actually work.

https://en.wikipedia.org/wiki/GPU_virtualization#mediated

You are wrong, Pascal has always allowed pure raw pointer and data manipulation as well as self memory management, the strong type enforcement and auto management for some types (strings, dynamic arrays) is just on the surface so you don't shoot yourself in the foot but it never stops you from doing any low level programming.

sounds like it's designed to be that way, yes.

They announce the product but you can't even pre-order it, a typical pi experience.

I can pre order on the Pi Hut right now if that website is available to you.

I used to have a lot of cavities due to poor oral hygiene, after I had a complications with my wisdom tooth, I really decided to step up my game and take care of my teeth. Brush 3 times per day, 15 minutes after every meal. Floss two times per day. Reduce soda intake. Reduce sugar intake.

Cavity free for 4 years now. I switched dentist and after several visists she accused me of seeing another dentist because I didn't have any new cavities. Anyway ...

> I think, much like even-versioned releases of Delphi -- which were famously half-baked and buggy, and you'd inevitably end up dealing with a confluence of bugs until the odd-released version came out a year or two later

I still remember, like some XE(n) version had a really unstable ide/debugger and they didn't even bother fixing it, you had to wait till the next version was released (and you had to pay for it) for the bug to be fixed. There was even some guy that decompiled the ide and offered free fixes online for some more annoying bugs.

I'm pretty sure that's Andreas Hausladen (idefixpack.de) Huge thanks to him!

nothing magic about Result keyword, it's just an implicit pointer, you can avoid it completely by using explicit pointers.

It's not magic in how it works, it's just magic in it's syntax. It's a variable you don't have to declare. It's ripe for abuse / mistakes and would be one of the things I'd have lints for and watch closely in PRs.

Nim has the same result variable[1] and I absolutely love it.

It helps avoid the classic "oh, I forgot to return it" bug. Also makes the code more succinct and saves you from having to type an extra line for explicit return.

I kind of get why you would be wary of it, as it is a special variable but compared to other messed up stuff like for example Rust treating a line without semicolon as implicit return, it is a relatively tame solution for this problem and can be easily figured out.

Did you ever had any actual bugs caused by the use of result?

[1] https://nim-by-example.github.io/variables/result/

If you forgot to return a value, a function shouldn't have compiled. In Nim you can easily forget to return something or have a hole in your branching and get a defaulted value, instead of a compiler error.

In some cases an implicitly declared variable feels neat and convenient, but I'm not sure it's worth it.

Ha, I'm quite used to Rust's last-expression-is-the-value and I also get why some would think it's weird but I find it actually works quite well in practice. Each language has its gymnastics and special moves, I guess. Back to Pascal, I'm not opposed to Result usage per se and I understand the appeal since it's what I grew on. My concerns are more about code maintenance in long-ish functions - I don't have a particular example of mis-usage, but I'd be wary of late reassignments overriding a previously set value. Separating exit points from return value assignment could let code become hard to follow and create situations where it's easy to misread the actual outcome.

Imho if cpu manufacturers figure out how to slap a large cache on the same die (something like amd 3D V-Cache but much more) we may actually see graphic cards become obsolete in favor of software rendering.

Specialized silicon will always beat general purpose silicon.

It is true that a chip like this probably could render pretty decent 3d in software though. I wonder if combining this with the GPU in a clever way could allow more people to experience real time raytracing?

> Specialized silicon will always beat general purpose silicon.

The whole history of PCs is repeatedly proving otherwise. The NES had hardware sprites. Then Carmack & Romero showed up and proved you can have smooth side scrolling in software, on an underpowered CPU. The whole concept of a PPU was thus rendered obsolete. Repeat for discrete FPUs, discrete sound cards, RAID cards (ZFS), and so on.

Specialised silicon will beat general purpose silicon at the given task, until general purpose silicon + software catches up. You need to keep pouring in proportional R&D effort for the specialised silicon to stay ahead.

What keeps GPUs relevant is that they're in fact much more general than what the "G" originally stood for.

CPU’s have integrated a lot of specialized silicon as transistor budgets increased. x86 treats integer and floating point arithmetic as separate things because the math coprocessor used to be a separate and optional chip. Now days it’s GPU cores making the migration, but that’s hardly going to be the end of it.

When the second generation of EPYC came out, linus ran a "software rendered" version of crysis that did all rendering on CPU cores instead of GPU shader units. At 640x480 it ran alright.

Possibly - there are a lot of ray tracing algoeithms that don't really work well on GPUs (anything MCMC, for instance). But context and time aware denoising seems to be able to compensate.

GPU is a bandwidth monster, CPU is a latency monster. You can't have both on the same silicon.

Every console SoC designed by AMD proves you wrong.

APU has two parts, there is no GPUCPU hybrid in the same functional package, they are separate modules.

I just took apart my unit CP1300EPFCLCD and it indeed has the yellow silicone. There's also a lot of white silicone but only to keep wires in place.

My solution is to just inspect the unit every once a year to see if any yellow glue is turning brown just like in the video. Meh ...

Edit: A closer look showed that some parts of the glue already turned brown. It seems to be affected by heat because the parts that are brown are the parts making direct contact with the board/components.

so how do you go about removing/cleaning that glue?

That's what the video is showing.

no it doesn't. It just shows the location where you can find the glue. How do you actually remove it? Do you soke it in ethanol and pick it apart or how ?