Another New KMS Graphics Driver Tips Up

[allquixotic]

ZzzzzzzZZzzzzz.... if only RadeonSI got as much love as 14 year old hardware...

[bridgman]

I could point out that HD7xxx has had KMS support for a while (ie a whole pile more love already) but I imagine what you really mean is "if only radeonsi got 1000x more love than 14 year old hardware instead of the 100x or so it gets today" so that the high level of functionality expected for the new card could be implemented as quickly as the modesetting-only expectations for 14 year old hardware" ?

[allquixotic]

I could point out that HD7xxx has had KMS support for a while (ie a whole pile more love already) but I imagine what you really mean is "if only radeonsi got 1000x more love than 14 year old hardware instead of the 100x or so it gets today" so that the high level of functionality expected for the new card could be implemented as quickly as the modesetting-only expectations for 14 year old hardware" ?

Yep. You read my mind. I'm so demanding, aren't I?! Wanting things that aren't there and not having the means to contribute more than bug reports, and continually complaining about it on these here forums. Well right now there's not very much to test, so I get to contribute zippo.

I'm sure some of the open source guys sometimes ask themselves why they work so hard for such an ungrateful user base that is perennially dissatisfied with the underperforming, buggy and feature-deprived effort (in the discerning opinion of the users, of course) that they roll out. Hey, it's a valid sentiment. 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. And who knows, by the time the driver support is there, hardware accelerated graphics might be obsoleted, either by advances in internet connectivity leading to everything being run by services similar to OnLive, or maybe we'll go back into a few decades of CPU-based rendering... it's hard to see where the tech is going. But in the here and now, I don't feel confident that I can get what I need to run this hardware the way I want to, and that is seriously making me reconsider my choice of brand.

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. 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.

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 want my card to do what it's capable of, on Linux, 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.

[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.