jshap70's comments

DVI is a very large spec. It supports everything from pure VGA over it's analog pins as well as full fledged HDMI (its actually the other way around, HDMI is secretly just DVI). Finding monitors which support all of the simpler modes is an issue, whereas finding monitors which support old school VGA is fairly easy.

the reason for the change to GPL in 5.9: https://lwn.net/Articles/827596/

it's a little frustrating that things which used to be kosher, like nvidia and nvidia_uvm linking are all of a sudden not because they got caught up in this crossfire.

RISC-V is inherently a customizable ISA though, whereas ARM implementations are very specific about what they require to be called an "ARM processor". This wouldnt change from this acq.

no. they're isolated for a reason, with the RISC-V processor being used as the controller to manage the behavior of the other parts of the chip. beyond just licensing ARM is expensive because it's required to implement a lot. With that chip being RISC-V they can make it as minimal and perfectly tuned as possible, so it's slow when it can afford to be cheap and fast when it needs to be.

you do realize that Nvidia is a major backer of RISC-V and already uses it on GPU's Turing and newer?

> GPUs are generally black boxes that you throw code at.

umm... what? what does that even mean? lol

I could kind of maybe begin understand your argument from the Graphics side, as users mostly interact with it at an API level, however keep in mind that shaders are languages the same way "cpu languages" work. It's all still compiled to assembly, and there's no reason that you couldn't make an open instruction set for a GPU the same as a CPU. This is especially obvious when it comes to Compute workloads, as you're probably just writing "regular code".

Now, that said, would it be a good idea? I don't really see the benefit. A barebones GPU ISA would be too stripped back to do anything at all, and one with the specific accelerations needed to be useful will always want to be kept under wraps.

title makes it justifiable for systems to both be hard to modify and difficult to use

I think so, but that issue was fixed w/in a few days

You also inherit an entire chain of trust over code you yourself didn't write nor did anyone actually validate. The issue with leftpad.js wasn't that it was stupid, it was that it was dangerous.

this is laughably hyperbolic

this link in the article was cooler than the article itself: https://www.riaa.com/u-s-sales-database/ (be sure to change the metric to inflation adjusted revenue)

there's a really interesting story around Lauda Air flight 004 where Boeing attempted to write it off as pilot error but Niki Lauda basically threatened to go fly one himself and recreate the conditions as proof it was not. Eventually Boeing conceded and he didn't have to actually risk himself or another of his planes, but still an interesting anecdote.

yeah... I don't know what numbers you're looking at but that's not true in the general case. and this isn't firmware, it's microcode. firmware is already on the chip. microcode is used so the os can take advantage of chip specific features, like security patches or even acceleration.

because there's a lot of proprietary stuff in microcode that's used for accelerations. gfx drivers too. it's the reason the closed amd drivers are so much faster than the open mesa ones.

you talk about enabling signed firmware like it was done for a proprietary reason and not a massive security one. take a look at the fake Pascal gpu's on ebay where people are flashing unsigned firmware to old Fermi cards to fake windows into thinking they're actual Pascal cards...

that said, youre right that it's not good that the nouveau driver is so far behind the proprietary one, and Im not trying to say that nvidia isn't at fault for that, just that it's a more complicated issue that people tend to portray it as.

also:

http://download.nvidia.com/open-gpu-doc/MemoryTweakTable/1/M...

http://download.nvidia.com/open-gpu-doc/MemoryClockTable/1/M...

> Related to Nvidia's refusal to work with everyone else on Wayland support, no doubt.

this is more complicated than I can really comment on, but from my understanding it was not an issue of nvidia's refusal to work on it so much as it was an issue of nvidia not being allowed a seat at the table to discuss it. the wayland protocol was effectively demanding a ground up rewrite with no ability for compromise purely because nvidia being closed source meant they weren't entitled to an opinion. which is... wow

I'm sorry that's the typical experience you've had with the driver, though I'm a little surprised by that actually. I don't run x on ubuntu, but I know there were some issues in the past where they were attempting to "smartly" configure the driver for certain setups and instead end up causing headaches. Though that is really my main issue with ubuntu in general, that they try to "help" you because they know best, and also one of the reasons I don't run it. I just use the runfile installer and let it auto-generate the base xconfig.

that was 1 doc out of many on http://download.nvidia.com/open-gpu-doc/

multiple docs have been updated in this past year

full disclosure that I work for nvidia, but not on drivers. many driver devs internally do actually contribute to nouveau as well. please don't make baseless claims simply because you're angry.

I'm sure this discussion will be civil