DaPorkchop_

joined 2 years ago
[–] [email protected] 1 points 8 hours ago

Thinking of a modern GPU as a "graphics processor" is a bit misleading. GPUs haven't been purely graphics processors for 15 years or so, they've morphed into general-purpose parallel compute processors with a few graphics-specific things implemented in hardware as separate components (e.g. rasterization, fragment blending).

Those hardware stages generally take so little time compared to the rest of the graphics pipeline that it normally makes the most sense to have far more silicon dedicated to general-purpose shader cores than the fixed-function graphics hardware. A single rasterizer unit might be able to produce up to 16 shader threads worth of fragments per cycle, so even if your fragment shader is very simple and only takes 8 cycles per pixel, you can keep 8x16 cores busy with only one rasterizer in this example.

The result is that GPUs are basically just a chip packed full of a staggering number of fully programmable floating-point and integer ALUs, with only a little bit of fixed hardware dedicated to graphics squeezed in between. Any application which doesn't need the graphics stuff and just wants to run a program on thousands of threads in parallel can simply ignore the graphics hardware and stick to the programmable shader cores, and still be able to leverage nearly all of the chip's computational power. Heck, a growing number of games are bypassing the fixed-function hardware for some parts of rendering (e.g. compositing with compute shaders instead of drawing screen-sized rectangles, etc.) because it's faster to simply start a bunch of threads and read+write a bunch of pixels in software.

[–] [email protected] 1 points 1 day ago (2 children)

The "B" in "Boot" looks really off, the inside of the big "O" is lighter than the rest of the sign, and the kerning on the bottom text is all over the place.

[–] [email protected] -3 points 3 days ago (7 children)
[–] [email protected] 12 points 3 days ago (1 children)

The suggestion and response are both meant humorously. It clearly isn't actually a good answer because it doesn't actually solve the problem, except in some passive-agressive far-off-in-the-future way.

[–] [email protected] 3 points 4 days ago

I follow a huge number of artists on Bandcamp which I mostly discovered through Chiptunes=WIN (which unfortunately seems to have erased itself from the internet), and the occasional collab album is enough to keep gradually discovering new artists.

[–] [email protected] 5 points 4 days ago

KDE user here, I still use X11 to play old Minecraft versions. LWJGL2 uses xrandr to read (and sometimes modify? wtf) display configurations on Linux, and the last few times I've tried it on Wayland it kept screwing the whole desktop up.

[–] [email protected] 5 points 4 days ago (1 children)

In the future, you can generally solve these sorts of build errors by just installing the development package for whatever library is missing. On Debian-based systems, that would be something along the lines of sudo apt install libecm<tab><tab> see what appears, choose one which looks reasonable with -dev suffix

[–] [email protected] 4 points 4 days ago (2 children)

It takes like half a second on my Fairphone 3, and the CPU in this thing is absolute dogshit. I also doubt that the power consumption is particularly significant compared to the overhead of parsing, executing and JIT-compiling the 14MiB of JavaScript frameworks on the actual website.

[–] [email protected] 1 points 1 week ago

nobody expects the ottoman Inquisition

[–] [email protected] 3 points 1 week ago (1 children)

Wait really? I use (((triple parentheses))) quite often to indicate sarcastic emphasis on a word. Damn racists ruining my punctuation >:(

[–] [email protected] 1 points 1 week ago (1 children)

Nouveau is dead, it's been replaced with Zink on NVK.

[–] [email protected] 9 points 1 week ago (1 children)

True, but there are also some legitimate applications for 100s of gigabytes of RAM. I've been working on a thing for processing historical OpenStreetMap data and it is quite a few orders of magnitude faster to fill the database by loading the 300GiB or so of point data into memory, sorting it in memory, and then partitioning and compressing it into pre-sorted table files which RocksDB can ingest directly without additional processing. I had to get 24x16GiB of RAM in order to do that, though.

view more: next ›