rjmccall posted:

gpu hardware is the absolute worst and half of why gpu drivers are always terrible is that they are full of terrible workarounds for the broken-rear end hardware. they do not want to give you a specification for the hardware because an honest specification would have to say stuff like "never put a bundle with operations 1 and 2 immediately after a bundle with operation 3 or the gpu will hard lock"

rjmccall posted:

the vast majority of cpu errata involve system facilities where it's more understandable, like to take the first entries from the first google hit for intel errata:
- a specific system register used in virtualization sometimes reports incorrect information
- writing directly to the page table without invalidating existing entries can gently caress things up
- invalid encodings similar to certain virtualization instructions trigger the wrong exception

gpus get super basic poo poo wrong all the time

JawnV6 posted:

even then, 50%+ errata only apply before a ucode patch is applied, but BIOS authors still need to be aware & avoid those situations so they're published

way back when i was proximate to GPU workers, the bar for bugs was staggering. CPU's kinda sorta need to be rock solid, GPU's kicking out incorrect results in the lower bits of a division is "uhhh so is there a driver workaround?"

Qwertycoatl posted:

having worked at two hardware companies: hardware is full of bugs and it's firmware writers' job to desperately try to hide all the shittiness from users

The Management posted:

hardware is just software that's been etched into silicon. it's just as buggy. and it turns out that if you wait long enough, all hardware bugs become software's problem so #yolo

Qwertycoatl posted:

yeah, fairly often i come across people who think hardware isn't buggy. i don't know whether to laugh or drink

lancemantis posted:

so i was doing some ML stuff at work and we have a bunch of servers with as many titans as we can fit/buy at the time because there are shortages shoved into them for this purpose

outside of the display card, OSes and GPGPU libraries have no real concept of handling scheduling so processes can't share cards; if someone starts using one they're going to bogart the whole thing no matter what they're doing

this is really great in a research environment because people love repls and jupiter notebooks so they will hold onto cards even when their program is doing absolutely nothing

i used to have a script to grab a card and loop forever on demonstration days so I wouldn't be surprised by finding no free resources

fritz posted:

it's so horrible

i wonder how the big hpc systems do it

The Management posted:

hardware is just software that's been etched into silicon. it's just as buggy. and it turns out that if you wait long enough, all hardware bugs become software's problem so #yolo

Beast of Bourbon posted:

the biggest of the big games might have direct support from amd/nvidia but when i was working on some AAA "big" games but not like...super mega huge, we'd have an nvidia or amd rep come by the studio with a handful of new cards and be like "hey can you give these to the graphics guys to make sure they all work with your, here's my business card, let me know if you guys want to do a marketing promo or something"

the programmers would take those cards home and put them in their gaming rigs, and we'd just continue working on whatever 3 year old graphics cards were in the work computers.

Qwertycoatl posted:

i used to work for a company making a now-defunct mobile gpu (i just did video stuff, not 3d, so don't blame me too hard please)

we ran into a problem with a game that didn't render properly because they had some code like

code:

switch (gpu_type) {
  case MALI:
   render_things_using_mali_workarounds();
   break;
  case POWERVR:
   render_things_using_powervr_workarounds();
   break;
.....
  default:
   // don't bother rendering anything lol
}

and we weren't in the list

actually there's no point to this story but i've typed it now so here you go, my experience of gpu-related shittiness

Suspicious Dish posted:

also please remember that gamers suck. they are extremely gullible to marketing while barely understanding what game developers actually do.

gamers generally have a lot of misconceptions about how graphics and gpus actually work because marketing for these companies relies on tricking people into thinking "numbers and specs matter"

nvidia absolutely loves when /r/pcmasterrace continues to spew garbage about gigabit clock speeds and the number of smx per sli slot because they can sell more things to more idiots but it makes it hard to figure out how any of this poo poo actually works.

Volmarias posted:

I would love an idea of what to actually know about that does not require me to be a professional in the field.

PCjr sidecar posted:

tell your server monkeys to use nvidia-smi to set compute mode to default/shared instead of exclusive (usually will make things worse when inexperienced people are actually using the cards; welcome to the social)

ADINSX posted:

Other than "poo poo should just work right", and "poo poo should be debug-able" what features would you wanna see in some theoretical next generation of graphics cards?

Comfy Fleece Sweater posted:

sucks my dick and tells me I'm a good boy

Suspicious Dish posted:

since their shader compiler has to run real-time and be fast and can't do that much in terms of optimization)

Suspicious Dish posted:

webgl is honestly pretty cool to get started with and it's where i do all my side project work

feedmegin posted:

Why

Suspicious Dish posted:

random side-project update

android ships a software libgl called "pixelflinger": https://android.googlesource.com/platform/system/core/+/master/libpixelflinger/

i thought it died out years ago since it was really only meant as a hw bringup kind of thing, but apparently some hardware drivers still use it in a fallback path or something, because i just got a call stack on my android tablet which had pixelflinger in it

The Management posted:

wait, they still make android tablets?

The Management posted:

wait, they still make android tablets?

Suspicious Dish posted:

random side-project update

android ships a software libgl called "pixelflinger": https://android.googlesource.com/platform/system/core/+/master/libpixelflinger/

i thought it died out years ago since it was really only meant as a hw bringup kind of thing, but apparently some hardware drivers still use it in a fallback path or something, because i just got a call stack on my android tablet which had pixelflinger in it

Suspicious Dish posted:

hi i'm a gpu guy i work on the grpahics at video games and previously i worked on the mali gpu driver to try and make it not suck (i wasnt successful)

Harik posted:

apparently it's still a thing, since Android Backstage still has talks about it in 2017.


oh man, MALI. god that pile of bad decisions never fails to piss me off. quick background for people who don't work with embedded poo poo:

ARM is both an instruction set (really a range of them) and an implementation. Everybody licenses one of their cores in verilog/vhdl source form then buys a bunch of random perhepherals like upgraded memory controllers or sound codecs and mashes them together then poops the whole thing out to a fab like gloflo or samsung. this means there's a lot of very very bad ARM processors out there.

Harik posted:

MALI came about because there were approximately 17 billion competing GPU companies selling incompatible modules to ARM. remember the good old days when games only worked on some subset of phones?

Harik posted:

ARM bought falanx and started shipping MALI with their cores, to start some sort of standardization. Yay, great. Problem: GPUs are memory hungry, and ARM didn't bother with things like "standards for embedded graphics memory access" so every individual SOC has to roll their own memory management.

naturally the place to do this is in the graphics library, not in the graphics driver. there's no such thing as a "MALI" graphics library, because it can't do anything at all because it has no RAM. instead, there's X-brand MALI graphics library, compiled against X-brand bioniC or libC or elibC or whatever they make their BSP against, and you can never upgrade your software unless the SOC vendor deigns to support a design that's not their current one.

Harik posted:

to compound this, nearly every lovely SOC has at least one autist on staff who thinks they know all about GPUs because they have a liquid cooled AMD Titan they use for playing shootmans and makes "improvements" to the HDL or driver layer (they are never improvements)

people keep trying to make an open-sores version (LIMA) but the completely fractured nature of the mali landscape and developer-hostile attitude of everyone involved make it super slow going.

OP which mali project were you working on?

Suspicious Dish posted:

lol, they never left, buddy. the latest disaster was samsung patching the mali driver to break it for literally everybody in the galaxy s8.

Suspicious Dish posted:

nah, mali standardized on UMP a while back, which is a kernel driver that hands out carve-out chunks to the gpu. it's bad, but at least it's standard now.

Suspicious Dish posted:

the company i was at before paid something to the tune of $200,000 to arm for the source code for their mali 450 utgard driver and my job was to literally just fix bugs and get it to work on the embedded deivce we were shipping.

also the main developer of lima literally put out a blog post to insult me, lol.

quote:

In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead. Unfortunately it takes a long time for calendar changes to gain widespread adoption, and just like more than 300 years went by before the last Protestant nation implemented Greg's proposal, we will have to wait a while until all religions and operating system kernels acknowledge the inherent advantages of the Rockchip system. Until then we need to translate dates read from (and written to) Rockchip hardware back to the Gregorian format.

Harik posted:

i guess I should find the best -400 MP4 implementation out there and replace this SOCs garbage kernel driver with theirs and use their libraries. Already had to do it once to get sound working. how garbage is this soc? it has my all-time favorite kernel commit message:]

quote:

In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar insufficiently represented reality, and changed the rules about calculating leap years to account for this. Similarly, in A.D. 2013 Rockchip hardware engineers found that the new Gregorian calendar still contained flaws, and that the month of November should be counted up to 31 days instead. Unfortunately it takes a long time for calendar changes to gain widespread adoption, and just like more than 300 years went by before the last Protestant nation implemented Greg's proposal, we will have to wait a while until all religions and operating system kernels acknowledge the inherent advantages of the Rockchip system. Until then we need to translate dates read from (and written to) Rockchip hardware back to the Gregorian format.

some nerd posted:

Well, perhaps I'm having a sense of humour failure, but IMO in a setting which is supposed to be for information, jokes should not be present. People reading patch notes, release notes, and other informational material should be able to assume that everything written there is 100% sincere.

anthonypants posted: