NotCamelCase

How do you like that machine besides? I am kinda considering getting one (or Steam Deck), but very short battery time puts me off.

Would it be incorrect to call such associating with brands/ "loving" a company more (or less) an American thing? Why even spend any moment of your finite life pondering over behaviors of random companies, let alone defending one over another?

It's also difficult for both SW teams' and HW teams' visions to converge, even under the same company, such that the product can be put to use to maximize performance and programmability WRT another, already-established product.

Different constraints and challenges on both sides of the aisle give rise to compromises which end up with lowered performance or lowered ease of use. This is one area where great authority over the entire stack lends you lots of leeways, e.g. Apple designing Metal API and the HW for it.

Wait, you don't default to presume that anyone online whose immediate response on anything is 'What about X?' is not a troll? Wow!

To me, one of the most remarkable aspects of this story and reading others' comments is how relatively quickly people seem to have picked up Linux despite the lack of modern high-speed internet and one-click away forums and networks we all enjoy today. I guess that's an inevitable outcome if the market is ripe for some change no matter the opposing forces, like missing features, strong alternatives or no commercial support, etc.

You can request Windows to zero out every GPU memory allocation, but it's more of a driver thing that's not exposed in APIs. Such option is likely to be off by default in drivers as it might induce additional, unintended overhead. In practice, you are likely to see memory cleared more often than not due to other reasons, though.

You can't just peek another process' GPU memory thru UMD app, either. Per-process virtual memory mechanisms similar to CPUs are also present in GPUs, which is the whole reason that resources are explicitly imported/exported across APIs via special API calls.

Because online, drama tops non-drama? This is the worst aspect of this site being more Reddit-like for me.

Having to pay for a compiler sounds a little funny through the lens of 2022; I wonder if the majority of people buying these software/packages at the time found the idea strange, too.

I am in the same boat. Save for a few games, modern games bore me to death and completely pass by me. I play maybe ~2h a month, if any. Actually, this is true for me when it comes to modern movies and music as well.

Is there more to it other than the fact that as one gets older, one has higher expectations? I keep wondering about it...

I guess you're referring to variable-length encodings support? It's fixed as in they only implement RV32IMF subset here. Even then, code density may be source of bottlenecks along the way.

This is an amazing project considering the scope of work required on both sides of the aisle -- HW and SW.

I find choice of RISC-V pretty interesting for this use case as it's a fixed-size ISA and there is a significant amount of of auxiliary data usually passed from drivers to HW in typical GPU settings, even for GPGPU scenarios alone. If you look at one of their papers, it shows how they pass extra texture parameters via CSRs. I think this might come to be bottleneck and limiting factor in the design for future expansions. I am currently doing a similar work (>10x smaller in comparison) on a more limited feature set, so I am really curious how it'll turn out to be.

Have you looked up LFSRs yet? https://en.wikipedia.org/wiki/Linear-feedback_shift_register

They are quite efficient for both HW and SW implementations.

As if Polish wasn't hard enough! That pronunciation is very confusing when you learn the language through English, e.g. 'wino' is Polish for 'wine'.

Funny, because first I used this form and then changed it to use 'However' because well, that'd be claiming us Homo Sapiens are known to have two hands, which is problematic and no sane economist would say so.

I am referring to the ones who appear on TV in finance/market-related programs, but I can't stand economists-speak. They love to ambiguate everything they said a minute ago. I don't mean that they bloat everything with technical terms -- somethings are just complicated. Rather, simply voicing opposite claims constantly and avoiding giving a straight answer (for the sake of protection from getting sued? manipulation?).

Example: "I think that a meteor bigger than the Sun is on its way to hit the Earth could be bad news for the economy. However, it may also mean that markets will flourish."

Open source or not, I think this'll (hope so!) lead to a much better FPGA development flow within Xilinx ecosystem in not-so-distant future.

SW-based simulation is mostly about functional correctness and robustness of an implementation. Even with cycle-accurate simulations there is a lot of data you can't just extrapolate from simulation results pertaining to timing and performance constraints. And that's where emulating CPU/GPU/ASIC designs generally help the most.

I pondered on the same subject recently as I was implementing the same algorithm (i.e. Mandelbrot set) on the CPU (scalar vs SIMD) and GPU compute using fixed-point and floating-point for comparisons (if interested: https://tayfunkayhan.wordpress.com/2020/06/03/mandelbrot-in-...).

It bothers me how little progress has been done on "shading" languages front compared to overall many-core computation models and capabilities over the years. And, that is despite the fact that shaders are very often where the most time is spent in modern workloads.

Compute with Vulkan is another story. It offers some nice abstractions, but it shows that it's mostly intended for async-compute/work-offloading for rendering, IMO. Too much fruction.

Yep, that's not what I intended to hint at, either. What I mean is, it boils down to the familiar problem of diminishing returns to have huge caches inside GPUs.

Number of drawcalls is usually not a problem because it saturates memory, though. It is often because of CPU overhead it incurs and (possibly redundant) commands-processing work on GPUs front-end causing bubbles in the whole pipeline. Where DX12/Vulkan-esque APIs help immensely is the first part mostly -- CPU overhead.

Memory interfacing of GPU commands-streaming/processing front-ends and system memory are very efficient, employing pre-fetching, etc.

Why aren't there e.g. 16 GB of L1D$ inside our CPUs? It'd be blazingly fast! :)

Although memory access patterns of typical GPU workloads are very different than those of CPU workloads, there are GPU-local, hierarchical caches similar to CPUs for different purposes that are exclusive to shader cores/computation units, which can be even partitioned dynamically. The struggle on the GPU side is keeping all the cores busy while servicing memory requests efficiently. Sharing memory across small group of threads run in lockstep, for example, is a great way of doing it.

This got me thinking in the other direction..

If I were a very determined, ultimate Bond villain* who set out to destroy the whole universe, what are my options? How bad can I fuck it up for all ? Back-to-back mega nuclear explosions occurring simultaneously on all planets within reach? Could that start chain reactions around our galaxy that'd bring it all down? What else?

* Funnily enough, I just started reading 'From Russia with Love' whose first few chapters deal with the unusually vicious nature of our henchman.

Rust doesn't have function/operator overloading yet or it won't have it at all? I am vastly for clarity and simplicity over vague, implicit stuff but doing e.g vector operations can get very unreadable very quickly without it.

Good point, thanks for your insights!

> You don't go and fail some random component in the system.

I always wondered if they did that, something akin to fuzzing tests in SW. Wouldn't it be useful to detect unexpected situations that'd be catastrophic? Or the benefits from it wouldn't outweigh the cost/time loss?

Of course, I can chase return registers by myself all day long, problem is I don't want to. Then again, what about pointers? PODs? strings? If you use VS debugger, you can see how distinctly it can display these, which is as different as night and day to me.

Having been using gdb (have to!) for a while again, one immediately comes to appreciate the wonder that is VS debugger.

> the additional step to make it ready for silicon is comparatively small

Yep, you just change the target platform and re-compile!

I tried Oculus only once, the first one that was sold world-wide, I believe. It was cool, but that was basically it for me. My main concern with it has always been the fact that it requires putting a device on my head for non-significant amount of time and I'm not sure about its health effects. Anybody know any research or studies that were done to this end?

I like how some people pin the recent success of AMD on that one person, even if he doesn't claim it himself.

Is it because of not truly knowing what it takes to do VLSI nowadays or just hoping that if one man did it, it can be done again?