Another New KMS Graphics Driver Tips Up

[bridgman]

I sometimes ask myself why I spend $550 and up on video cards every 2 years for a company that will probably not decently support my purchases with 100% working Linux graphics drivers on release day until 20 or more years from now, if indeed they ever get there.

I don't really understand how a rational person can look at open source driver progress in the last 4-5 years and even consider a question like that. The open source driver stack has picked up support for 9 years of hardware introductions in less than 5 years, with the 10th (SI) pretty close. New hardware already has launch time support when the GPU architecture doesn't change drastically (Ontario, Llano and Trinity for example) and by next year should have launch time support even on new GPU cores.

None of this is news (and it's not obvious at all if you sample over a shorter period), it's just steady progress over 4-5 years and includes major improvements to the common code from Intel, Red Hat and community developers. Once we are done catching up with our hardware development and proprietary driver work (probably another year) we should be able to spend relatively more time on features / performance and relatively less time chasing new hardware.

I guess someday the volunteer developers will figure it's not worth their effort and pack up, and the open source division at AMD will get shut down, and I'll stop buying AMD video cards and just use Intel because it bloody works... everything comes to an end.

Sure, or the open source team at Intel could get shut down, or a meteor could fall on your home, or the NVidia driver team could be eaten by a pack of rabid weasels. Anything is possible, the question is what is likely. If anything I expect to see more developers working on the open source drivers in the future.

I mean, that is, unless true excellence can actually be obtained with the open drivers? Excellence is extremely hard to define, but there's a certain point of quality after which adding more doesn't really make it any better; you've already completely satisfied your users. Proprietary-ness exempted, the best example I can think of is the Windows Nvidia binary driver. On the open source side, the closest I can think of is the Apache web server. Mesa is nowhere near sniffing the quality of either of those products though.

Are you really talking about quality in the last paragraph, or features/performance ? You say "Intel just works" but Intel, AMD and NVidia open source drivers all use pretty much the same Mesa code.

I wish I didn't have to be so demanding, but AMD imposes it upon themselves by releasing such good cards. You put it out there like a bait, and like a fool fish I bite the bait. What do you expect? That said, this fish is getting a little smarter after being caught and released a few times.

I've said this a few times over the years so hopefully this won't come as a surprise, but I wouldn't be buying high end cards yet if I was only planning on using them with the open source drivers, even if I could magically run the Intel open source stack on AMD or NVidia hardware.

You can see from the benchmarks that a hardware maxes out around the same point irrespective of vendor (which kinda makes sense because of all the common code), although that point goes up every couple of years as developers add complexity to gain performance. I think the last big jump in "bottleneck performance" was when Marek (pretty sure it was him, apologies if not) moved some of the driver code into a second thread so that the driver could use more than one CPU core. The open source stack isn't quite at the point where complexity needs to go up significantly for a small increase in performance, but it's not that far away either.

I want my card to do what it's capable of, on Linux...

... which requires a *lot* more driver complexity for high end hardware than for midrange hardware given the relative performance of CPUs and GPUs today. This is the primary reason high-end GPU vendors still offer proprietary Linux drivers - they allow code sharing across multiple OSes as a way of dealing with the high development costs associated with full featured, high performance drivers.

...with open source drivers that mostly work, but for which I can contribute to if I have a pet peeve bug -- either with a patch or a good bug report (I've got a few actual bug reports under my belt that have been fixed, so thankfully my day job in QA is paying off for the community ). Unfortunately I can't really make much out of a KMS driver and drawing triangles in EGL, so until I can run some actual applications on RadeonSI, you won't see any bug reports from me.

Yep, getting a new architecture running is tough, and you can't really write docs that are correct until you have the driver & hardware running together. It will get easier once open source driver development starts to happen at the same time as proprietary driver work and it becomes possible to use the big-ass RTL emulators to find out why the HW isn't behaving like we think it should. That's why we've focused so much on catching up with new HW.

[AJenbo]

Yes, http://ftp.no.debian.org/pub/unix/Ne...anuals/matrox/

I have 1064spec.pdf in addition to those as well.

Grate seams by biggest issue here would be finding G200 hardware as store only offere G450 here

[airlied]

Wow, the G200 is a 14-year-old graphics card and its seeing new device driver development work in the open source community.

If you read the article of course you'd realise it isn't a 14-year old GPU, in fact they have released 6 server variants over the past 5-6 years integerated into remote management consoles in servers.

So these chips are being sold in major quantities and in fact for RHEL we'd have more installs on these and radeon RN50s than anything else I'd guess.

Dave.

[curaga]

RH/Fedora actually plans to ship no UMS drivers in the future, so they're writing KMS drivers for the hardware they care about. Without xf86-video-mga (say, if you're not running X), the only other option is matroxfb which doesn't support the G200.

Also, you can do things like power down the graphics chip during DPMS to save energy. And since it's a server that's not typically attached to a monitor, that's basically always.

DPMS is a good point, I forgot about that. That also explains why they think an unaccelerated KMS is better than EXA UMS: desire to lose UMS altogether. I wonder why there hasn't been a Phoronix post on that

Though, the matroxfb help text definitely mentions several G200 chips:

Say Y here if you have a Matrox Millennium, Matrox Millennium II,
Matrox Mystique, Matrox Mystique 220, Matrox Productiva G100, Matrox
Mystique G200, Matrox Millennium G200, Matrox Marvel G200 video,
Matrox G400, G450 or G550 card in your box.

[scottishduck]

An SiS KMS driver would be nice...

[Kano]

@bridgman

do you really think that the intel (classic) mesa codebase shares much with the other gallium based drivers?

[Gusar]

An SiS KMS driver would be nice...

Yeah, but not one that only works with xf86-video-modesetting. Because SiS cards have have a hardware overlay for video presentation, so there should be a DDX that supports at least that.

[airlied]

@bridgman

do you really think that the intel (classic) mesa codebase shares much with the other gallium based drivers?

Yes it shares quite a lot of code, the whole GLSL compiler, the mesa GL API layer, the mesa GL->driver interface code.

Dave.

[mjg59]

- flicker free boot
- faster VT switch
- kernel errors visible if X hangs

Now, which of these is important in a server?

Userspace modesetting is incompatible with UEFI Secure Boot, so if you want to run X on a server using it then KMS is the only option.

[bridgman]

this makes me sad :-( for Linux only low-end... they always push open-source in the low-end corner.

It shouldn't make you sad. Besides, midrange cards are actually a better fit than low end cards. I think you've said this yourself in the past as well.

Optimizing a driver to take full advantage of high end hardware without getting bottlenecked on CPU usage is a *lot* of work, doesn't significantly benefit users of low end and midrange hardware, and adds a lot of complexity to the stack which makes it harder to maintain for everyone. Doesn't mean it won't happen, just that it doesn't seem like a smart thing to spend a lot of time until the more broadly useful areas have been addressed.

thats just a crime!

Sure it's a crime, like when you take the elevator to the 50th floor you have to go past the 25th floor on the way. Criminal.