There are two major package classes in Fedora that provide graphics drivers: xorg-x11-drv-*, and mesa-dri-drivers-*.
In F15, mesa-dri-drivers now only includes drivers with DRI2 support (radeon, nvidia, intel) and the software renderer; if you want all the older drivers you have to install mesa-dri-drivers-dri1. This list is:
i810, mga, r128, savage, sis, tdfx, unichrome
Basically all of this hardware is, ahem, inept. The most featureful device supported by these drivers would be the MGA G550, which just barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce 2, both ~1999 vintage). All the others are back in the DX6 stone age. For comparison, the baseline for the GPU in the phone in your pocket - and that platform layers like clutter more or less expect - is GLES 2.0, which is roughly comparable to DirectX 9. We're rapidly approaching the point where the software renderer is going to be a more satisfying experience than hardware 3d support for these chips, both for features and for performance.
So in my ideal world, we would simply drop the -dri1 subpackage (and for that matter, DRI1 support in the X server).
For 2D we've got an xorg-x11-drivers metapackage that includes, well, pretty much everything, and which is included in comps as a default. This is lame, because it means a bunch of backwater drivers end up as critical path and can never possibly get tested. (Smolt says there are all of 3 savage users. I assume the number of i740 users is actually negative.) The list of video drivers that see any actual use is probably something like:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like to chop the -drivers metapackage down to just this set, and either make a new metapackage in optional for -drivers-retrocomputing or simply list all the drivers there individually. Note that since we're keeping drivers for fbdev and vesa we should still get graphics on most devices even if the user doesn't explicitly ask for a native driver.
So that's the rough plan. Comments appreciated if I'm overlooking anything.
- ajax
Adam Jackson (ajax@redhat.com) said:
There are two major package classes in Fedora that provide graphics drivers: xorg-x11-drv-*, and mesa-dri-drivers-*.
In F15, mesa-dri-drivers now only includes drivers with DRI2 support (radeon, nvidia, intel) and the software renderer; if you want all the older drivers you have to install mesa-dri-drivers-dri1. This list is:
i810, mga, r128, savage, sis, tdfx, unichrome
Basically all of this hardware is, ahem, inept. The most featureful device supported by these drivers would be the MGA G550, which just barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce 2, both ~1999 vintage). All the others are back in the DX6 stone age. For comparison, the baseline for the GPU in the phone in your pocket - and that platform layers like clutter more or less expect - is GLES 2.0, which is roughly comparable to DirectX 9. We're rapidly approaching the point where the software renderer is going to be a more satisfying experience than hardware 3d support for these chips, both for features and for performance.
So in my ideal world, we would simply drop the -dri1 subpackage (and for that matter, DRI1 support in the X server).
For 2D we've got an xorg-x11-drivers metapackage that includes, well, pretty much everything, and which is included in comps as a default. This is lame, because it means a bunch of backwater drivers end up as critical path and can never possibly get tested. (Smolt says there are all of 3 savage users. I assume the number of i740 users is actually negative.) The list of video drivers that see any actual use is probably something like:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like to chop the -drivers metapackage down to just this set, and either make a new metapackage in optional for -drivers-retrocomputing or simply list all the drivers there individually. Note that since we're keeping drivers for fbdev and vesa we should still get graphics on most devices even if the user doesn't explicitly ask for a native driver.
So that's the rough plan. Comments appreciated if I'm overlooking anything.
The question would be how we ensure that these additional drivers are in the install image, or in the installed system, if necessary. Or do we not care if they get vesa? How would users be informed/able to install drivers if necessary? (I don't know that PK search is good here.)
Bill
On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote:
Adam Jackson (ajax@redhat.com) said:
So that's the rough plan. Comments appreciated if I'm overlooking anything.
The question would be how we ensure that these additional drivers are in the install image, or in the installed system, if necessary. Or do we not care if they get vesa? How would users be informed/able to install drivers if necessary? (I don't know that PK search is good here.)
To a first approximation, I deeply do not care. If you're choosing to use an s3virge in 2011 you've already decided to make your life hard.
But if we're trying to be completionists about it, import the data from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for each driver package and teach packagekit or whatever how to cope. Something like this:
http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html
But then, if we had _that_, comps could grow a fourth class for "as-needed" and we'd just list all driver packages there, including cups and webcam drivers and etc. Install image creation would pull them all in; anaconda would filter the available as-needed's based on target hardware.
In that scenario you'd still need to do manual selection of some driver packages for critpathness, but, okay.
- ajax
On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote:
On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote:
Adam Jackson (ajax@redhat.com) said:
So that's the rough plan. Comments appreciated if I'm overlooking anything.
The question would be how we ensure that these additional drivers are in the install image, or in the installed system, if necessary. Or do we not care if they get vesa? How would users be informed/able to install drivers if necessary? (I don't know that PK search is good here.)
To a first approximation, I deeply do not care. If you're choosing to use an s3virge in 2011 you've already decided to make your life hard.
But if we're trying to be completionists about it, import the data from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for each driver package and teach packagekit or whatever how to cope. Something like this:
http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html
But then, if we had _that_, comps could grow a fourth class for "as-needed" and we'd just list all driver packages there, including cups and webcam drivers and etc. Install image creation would pull them all in; anaconda would filter the available as-needed's based on target hardware.
In that scenario you'd still need to do manual selection of some driver packages for critpathness, but, okay.
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Nathaniel
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Nathaniel
You lose it for a couple of strange usecases though:
1) Moving from a card that is up to date in what it supports to an older card that isn't (rare).
2) Moving from one crappy ancient card to another (plausible, but still rare).
The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort.
--CJD
On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote:
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Nathaniel
You lose it for a couple of strange usecases though:
- Moving from a card that is up to date in what it supports to an older
card that isn't (rare).
- Moving from one crappy ancient card to another (plausible, but still
rare).
The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort.
I think losing it in those cases is probably acceptable. My thought is that the disk space for drivers is minimal, lets just support everything (or at least the current stuff) in a single install. My concern isn't moving to and/or between rare old cards. My concern is moving from nouveau to intel or radeon... The "big" drivers should definitely be installed on every system, regardless of its hardware.
Nathaniel
On Tue, Apr 12, 2011 at 02:01:26PM -0400, Nathaniel McCallum wrote:
On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote:
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Nathaniel
You lose it for a couple of strange usecases though:
- Moving from a card that is up to date in what it supports to an older
card that isn't (rare).
- Moving from one crappy ancient card to another (plausible, but still
rare).
The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort.
I think losing it in those cases is probably acceptable. My thought is that the disk space for drivers is minimal, lets just support everything (or at least the current stuff) in a single install. My concern isn't moving to and/or between rare old cards. My concern is moving from nouveau to intel or radeon... The "big" drivers should definitely be installed on every system, regardless of its hardware.
I believe (and maybe I've read this thread to quickly) that that will still be the case. Its only the drivers for old cards with smaller feature sets that are being moved at alll.
--CJD
Hello Nathaniel,
On Tuesday, April 12, 2011, 2:01:26 PM, Nathaniel McCallum wrote:
On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote:
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Nathaniel
You lose it for a couple of strange usecases though:
- Moving from a card that is up to date in what it supports to an older
card that isn't (rare).
- Moving from one crappy ancient card to another (plausible, but still
rare).
The vesa driver should mean some workable video support in either case, and from there, if we were really, truly concerned, we could detect the need for the driver and prompt to install it. That's starting to sound like the bad old days of kudzu though, and I'd be surprised if anyone really felt this was worth that effort.
I think losing it in those cases is probably acceptable. My thought is that the disk space for drivers is minimal, lets just support everything (or at least the current stuff) in a single install. My concern isn't moving to and/or between rare old cards. My concern is moving from nouveau to intel or radeon... The "big" drivers should definitely be installed on every system, regardless of its hardware.
Nathaniel
For the Intel arches, it may make sense to have all kinds of X drivers available by default. For the secondary arches, the user requirements and physical environment.
On zSeries, there is no relevant graphics hardware. When one runs X, it is the application side only via a remove X display server on another system.
For ARM, the root filesystem is set up with an appropriate kernel (likely customized) and a single X display driver. On ARM, system space is typically quite tight.
Heck, even Intel-based netbooks and tablets don't have all _that_ much storage.
Whatever decisions are made should take these differences between arches into account and allow appropriate default and custom setups. Al
On Tuesday, April 12, 2011, 3:04:36 PM, I wrote:
For the Intel arches, it may make sense to have all kinds of X drivers available by default. For the secondary arches, the user requirements and physical environment.
Brain fart - I meant to say "and physical environment differ". Al
On Tue, 2011-04-12 at 13:48 -0400, Nathaniel McCallum wrote:
On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote:
But then, if we had _that_, comps could grow a fourth class for "as-needed" and we'd just list all driver packages there, including cups and webcam drivers and etc. Install image creation would pull them all in; anaconda would filter the available as-needed's based on target hardware.
In that scenario you'd still need to do manual selection of some driver packages for critpathness, but, okay.
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Assuming pk actually had this feature, the next time you booted pk would happily tell you about what driver you're missing.
- ajax
On Tue, 2011-04-12 at 14:00 -0400, Adam Jackson wrote:
On Tue, 2011-04-12 at 13:48 -0400, Nathaniel McCallum wrote:
On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote:
But then, if we had _that_, comps could grow a fourth class for "as-needed" and we'd just list all driver packages there, including cups and webcam drivers and etc. Install image creation would pull them all in; anaconda would filter the available as-needed's based on target hardware.
In that scenario you'd still need to do manual selection of some driver packages for critpathness, but, okay.
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
Assuming pk actually had this feature, the next time you booted pk would happily tell you about what driver you're missing.
*If* it booted to a sane state where pk could tell you this, then yes I agree.
Nathaniel
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
You change the card, the system comes up in VESA, Packagekit (or whatever) notices new hardware and installs the drivers. Seems pretty automatic?
On Tue, 2011-04-12 at 19:06 +0100, Matthew Garrett wrote:
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
You change the card, the system comes up in VESA, Packagekit (or whatever) notices new hardware and installs the drivers. Seems pretty automatic?
Limited to video drivers? yes. I just can't help but think that some will be unable to resist the temptation to do the same thing for firmware. In this case, pk will happily notify you, but you won't have access to the repo to handle the change to the new networking card, etc.
Nathaniel
On Tue, Apr 12, 2011 at 02:09:06PM -0400, Nathaniel McCallum wrote:
Limited to video drivers? yes. I just can't help but think that some will be unable to resist the temptation to do the same thing for firmware. In this case, pk will happily notify you, but you won't have access to the repo to handle the change to the new networking card, etc.
Upstream ship firmware as a single package, and I don't see us wanting to change that.
On Tue, 2011-04-12 at 19:06 +0100, Matthew Garrett wrote:
On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
You change the card, the system comes up in VESA, Packagekit (or whatever) notices new hardware and installs the drivers. Seems pretty automatic?
I should say that about 2.5 years ago I wrote a patch for xorg to print out an inventory of the hardware a given driver supported. http://cgit.freedesktop.org/xorg/xserver/commit/?id=8e368cf5b964f1d29fda0a46...
The patch was subsequently removed by an overzealous committer who thought it would be fun to remove useful functionality he thought xorg didn't need anymore (name concealed to protect the guilty).
That patch above, or a similar version, could be used to automatically generate the PK list from the binary at rpm build time, as well as be useful in a variety of other cases.
Nathaniel
Once upon a time, Nathaniel McCallum nathaniel@natemccallum.com said:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
That has been the case off and on for a long time, with kernels and glibc split for i386/i686, and then kernels for PAE. Old hardware is always going to fall off the tail.
It isn't like the packages are going to be removed, and they'll probably not get any less testing than they do today. Also, since VESA will still be included, it should work on most any hardware.
On Tue, 2011-04-12 at 13:18 -0500, Chris Adams wrote:
Once upon a time, Nathaniel McCallum nathaniel@natemccallum.com said:
With this approach, you have lost a critical feature: the ability for you to change your hardware (or move the software bits to a different computer) and have everything automatically work.
That has been the case off and on for a long time, with kernels and glibc split for i386/i686, and then kernels for PAE. Old hardware is always going to fall off the tail.
It isn't like the packages are going to be removed, and they'll probably not get any less testing than they do today. Also, since VESA will still be included, it should work on most any hardware.
Sure. To be blunt: I'm in support of the move, I just want to make sure we think about the case of hardware changes and not boot to an unusable system...
Nathaniel
On 04/12/2011 01:38 PM, Adam Jackson wrote:
On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote:
Adam Jackson (ajax@redhat.com) said:
So that's the rough plan. Comments appreciated if I'm overlooking anything.
The question would be how we ensure that these additional drivers are in the install image, or in the installed system, if necessary. Or do we not care if they get vesa? How would users be informed/able to install drivers if necessary? (I don't know that PK search is good here.)
To a first approximation, I deeply do not care. If you're choosing to use an s3virge in 2011 you've already decided to make your life hard.
While I don't care about accelerated X support, this hardware darned well better continue working in an "it works" 2D display mode. VESA or whatever is fine.
Why?
Data centers have /plenty/ of ancient video solutions out there, and basic video support is needed.
Jeff
Once upon a time, Jeff Garzik jgarzik@pobox.com said:
Data centers have /plenty/ of ancient video solutions out there, and basic video support is needed.
How many data centers run X on servers? I know I don't; they all boot runlevel 3 and just have a serial console (KVM switches are for Windows machines).
On Tue, 2011-04-12 at 13:19 -0500, Chris Adams wrote:
Once upon a time, Jeff Garzik jgarzik@pobox.com said:
Data centers have /plenty/ of ancient video solutions out there, and basic video support is needed.
How many data centers run X on servers? I know I don't; they all boot runlevel 3 and just have a serial console (KVM switches are for Windows machines).
I run in runlevel 3 so its not turned on, but I do have X installed and I'll start it in the datacenter (on a non-broken machine!) when I'm looking up docs, remoting my workstation to browse my email, etc.
So it might not be running daily, but its there.
Brian
-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Tue, 2011-04-12 at 14:16 -0400, Jeff Garzik wrote:
While I don't care about accelerated X support, this hardware darned well better continue working in an "it works" 2D display mode. VESA or whatever is fine.
You'll notice I included vesa in the standard list. Not that vesa works very well when EFI is involved, but that's an entirely different kettle of excrement.
Data centers have /plenty/ of ancient video solutions out there, and basic video support is needed.
Dude. I know this better than just about anyone. I own the X packaging in RHEL. Trust.
- ajax
On 04/12/2011 03:34 PM, Adam Jackson wrote:
On Tue, 2011-04-12 at 14:16 -0400, Jeff Garzik wrote:
While I don't care about accelerated X support, this hardware darned well better continue working in an "it works" 2D display mode. VESA or whatever is fine.
You'll notice I included vesa in the standard list. Not that vesa works very well when EFI is involved, but that's an entirely different kettle of excrement.
But in that case (if you haven't picked completely braindead hardware) you have a working fbcon that we can fall back to. It'll just be very slow.
On Tue, 12 Apr 2011 20:16:45 +0200, Jeff Garzik wrote:
While I don't care about accelerated X support, this hardware darned well better continue working in an "it works" 2D display mode. VESA or whatever is fine.
VESA is not fine, ancient Free drivers are debuggable code when something crashes, VESA is a proprietary code one cannot debug. It can for example crash in the VESA code due to a bug in Fedora code corrupting its stack etc, this is difficult to debug.
Why is proposed a proprietary code over existing Free drivers?
The size of `retrocomputing' drivers is negligible and the maintenance of them needs to be done anyway.
Jan
On Tue, Apr 12, 2011 at 10:02:33PM +0200, Jan Kratochvil wrote:
On Tue, 12 Apr 2011 20:16:45 +0200, Jeff Garzik wrote:
While I don't care about accelerated X support, this hardware darned well better continue working in an "it works" 2D display mode. VESA or whatever is fine.
VESA is not fine, ancient Free drivers are debuggable code when something crashes, VESA is a proprietary code one cannot debug. It can for example crash in the VESA code due to a bug in Fedora code corrupting its stack etc, this is difficult to debug.
Why is proposed a proprietary code over existing Free drivers?
Have you checked how many of these old drivers rely on BIOS services anyway? In any case, it's vital that VESA work given that it's the only way to bring up hardware that's newer than the install image - increasing its test coverage can only be a good thing.
On Tue, 12 Apr 2011 22:09:36 +0200, Matthew Garrett wrote:
In any case, it's vital that VESA work given that it's the only way to bring up hardware that's newer than the install image - increasing its test coverage can only be a good thing.
It does not make sense to test VESA as we cannot fix VESA. (That is the BIOS part; I doubt the VESA xorg driver needs too much testing.)
Thanks, Jan
On Wed, Apr 13, 2011 at 04:03:48AM +0200, Jan Kratochvil wrote:
On Tue, 12 Apr 2011 22:09:36 +0200, Matthew Garrett wrote:
In any case, it's vital that VESA work given that it's the only way to bring up hardware that's newer than the install image - increasing its test coverage can only be a good thing.
It does not make sense to test VESA as we cannot fix VESA. (That is the BIOS part; I doubt the VESA xorg driver needs too much testing.)
Not so much the vesa driver, but x86emu tends to have a bewildering array of bugs.
On Tue, 2011-04-12 at 13:38 -0400, Adam Jackson wrote:
On Tue, 2011-04-12 at 12:23 -0400, Bill Nottingham wrote:
Adam Jackson (ajax@redhat.com) said:
So that's the rough plan. Comments appreciated if I'm overlooking anything.
The question would be how we ensure that these additional drivers are in the install image, or in the installed system, if necessary. Or do we not care if they get vesa? How would users be informed/able to install drivers if necessary? (I don't know that PK search is good here.)
To a first approximation, I deeply do not care. If you're choosing to use an s3virge in 2011 you've already decided to make your life hard.
But if we're trying to be completionists about it, import the data from /usr/share/hwdata/videoaliases/*.xinf into virtual Provides for each driver package and teach packagekit or whatever how to cope. Something like this:
http://lists.fedoraproject.org/pipermail/devel/2010-April/135004.html
I've been trying to get someone to write something like this (I called it 'HardwareKit' back when kits were cool...) for absolutely ages, but I'm worried it might wind up derailing this thread, which is about a much more modest change. Perhaps we should branch the thread...
On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote:
And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like to chop the -drivers metapackage down to just this set, and either make a new metapackage in optional for -drivers-retrocomputing or simply list all the drivers there individually. Note that since we're keeping drivers for fbdev and vesa we should still get graphics on most devices even if the user doesn't explicitly ask for a native driver.
So that's the rough plan. Comments appreciated if I'm overlooking anything.
Well, the less intrusive alternative is just to make graphics drivers a comps group rather than using a metapackage. Metapackages are generally 'frowned upon' in Fedora anyway, and you're supposed to do stuff with comps groups. Doing it that way would remove the critical path implications; we could then just add the important drivers to critpath individually.
On Tue, Apr 12, 2011 at 5:34 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote:
And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like to chop the -drivers metapackage down to just this set, and either make a new metapackage in optional for -drivers-retrocomputing or simply list all the drivers there individually. Note that since we're keeping drivers for fbdev and vesa we should still get graphics on most devices even if the user doesn't explicitly ask for a native driver.
So that's the rough plan. Comments appreciated if I'm overlooking anything.
Well, the less intrusive alternative is just to make graphics drivers a comps group rather than using a metapackage. Metapackages are generally 'frowned upon' in Fedora anyway, and you're supposed to do stuff with comps groups. Doing it that way would remove the critical path implications; we could then just add the important drivers to critpath individually.
And have the most used drivers that are listed above set as "default" and the retro ones set as optional. That way they're not there by default but they're selectable at install for the couple of people that do wish to use them (provided they do have enough RAM on those machines to actually be able to install..... but that's a different problem entirely!).
Peter
On Tue, 2011-04-12 at 09:34 -0700, Adam Williamson wrote:
On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote:
And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like to chop the -drivers metapackage down to just this set, and either make a new metapackage in optional for -drivers-retrocomputing or simply list all the drivers there individually. Note that since we're keeping drivers for fbdev and vesa we should still get graphics on most devices even if the user doesn't explicitly ask for a native driver.
So that's the rough plan. Comments appreciated if I'm overlooking anything.
Well, the less intrusive alternative is just to make graphics drivers a comps group rather than using a metapackage. Metapackages are generally 'frowned upon' in Fedora anyway, and you're supposed to do stuff with comps groups. Doing it that way would remove the critical path implications; we could then just add the important drivers to critpath individually.
Not that I object, but that's just moving the goalposts from "which drivers in the metapackage" to "which drivers in comps". It doesn't address the construction of the list.
- ajax
On Tue, 2011-04-12 at 13:17 -0400, Adam Jackson wrote:
On Tue, 2011-04-12 at 09:34 -0700, Adam Williamson wrote:
On Tue, 2011-04-12 at 12:12 -0400, Adam Jackson wrote:
And input is even briefer (evdev, synaptics, wacom, vmmouse). I'd like to chop the -drivers metapackage down to just this set, and either make a new metapackage in optional for -drivers-retrocomputing or simply list all the drivers there individually. Note that since we're keeping drivers for fbdev and vesa we should still get graphics on most devices even if the user doesn't explicitly ask for a native driver.
So that's the rough plan. Comments appreciated if I'm overlooking anything.
Well, the less intrusive alternative is just to make graphics drivers a comps group rather than using a metapackage. Metapackages are generally 'frowned upon' in Fedora anyway, and you're supposed to do stuff with comps groups. Doing it that way would remove the critical path implications; we could then just add the important drivers to critpath individually.
Not that I object, but that's just moving the goalposts from "which drivers in the metapackage" to "which drivers in comps". It doesn't address the construction of the list.
Well, I was focusing on this part of your mail:
"For 2D we've got an xorg-x11-drivers metapackage that includes, well, pretty much everything, and which is included in comps as a default. This is lame, because it means a bunch of backwater drivers end up as critical path and can never possibly get tested."
Which suggests the major reason to change this is the critpath implications. My point being that if we do this with comps groups, it completely removes the critpath issue, meaning we could still choose to install lots of drivers by default and not worry about critpath.
It seems you have other good reasons to want to de-emphasize some drivers, but still, if we make the comps change too, it means we don't have to worry about drivers that are well maintained but for niche hardware: we can keep them installed by default and 'fully supported', but still not have to worry about them being critpath. We can still not install by default drivers that we really want to stop caring about.
On 04/12/2011 09:12 AM, Adam Jackson wrote:
There are two major package classes in Fedora that provide graphics drivers: xorg-x11-drv-*, and mesa-dri-drivers-*.
In F15, mesa-dri-drivers now only includes drivers with DRI2 support (radeon, nvidia, intel) and the software renderer; if you want all the older drivers you have to install mesa-dri-drivers-dri1. This list is:
i810, mga, r128, savage, sis, tdfx, unichrome
Basically all of this hardware is, ahem, inept. The most featureful device supported by these drivers would be the MGA G550, which just barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce 2, both ~1999 vintage). All the others are back in the DX6 stone age.
My r128 card (Rage Mobility M3 AGP 2X; pci 1002:4c46) is running DirectX 9.0c (4.09.0000.0904) on Windows ME. The main driver ATI2DRAI.DRV says "DDI Version 7". The machine also runs Fedora 12 using: xorg-x11-server-Xorg.1.7.6-4.fc12.i686 xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.i686 xorg-x11-drv-r128-6.8.1-2.fc12.i686 Such a machine is quite usable.
For comparison, the baseline for the GPU in the phone in your pocket - and that platform layers like clutter more or less expect - is GLES 2.0, which is roughly comparable to DirectX 9. We're rapidly approaching the point where the software renderer is going to be a more satisfying experience than hardware 3d support for these chips, both for features and for performance.
How rapidly? Today, which one leads in "satisfying experience", and by how much?
[snip] So in my ideal world, we would simply drop the -dri1 subpackage (and for that matter, DRI1 support in the X server).
Such a wish would be better justified by statistics on usage (smolt, at least) and support effort (size and rate of change in source commits, number of maintainers with relevant experience, ...)
--
On 4/12/11 11:58 PM, John Reiser wrote:
On 04/12/2011 09:12 AM, Adam Jackson wrote:
Basically all of this hardware is, ahem, inept. The most featureful device supported by these drivers would be the MGA G550, which just barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce 2, both ~1999 vintage). All the others are back in the DX6 stone age.
My r128 card (Rage Mobility M3 AGP 2X; pci 1002:4c46) is running DirectX 9.0c (4.09.0000.0904) on Windows ME. The main driver ATI2DRAI.DRV says "DDI Version 7". The machine also runs Fedora 12 using:
The DX level that the OS claims is not the DX level that the hardware supports. Rage 128 doesn't have any shader hardware. The first ATI card that did was the Radeon 8500, a DX8 part.
If you use any DX9 features on setup, I assure you, they're implemented in software. Which is what I'm proposing for Fedora.
I should emphasize that I'm not proposing the Mesa packaging change (just) because it makes my life easier. I'm proposing it because I think it'll make users' lives better.
For comparison, the baseline for the GPU in the phone in your pocket - and that platform layers like clutter more or less expect - is GLES 2.0, which is roughly comparable to DirectX 9. We're rapidly approaching the point where the software renderer is going to be a more satisfying experience than hardware 3d support for these chips, both for features and for performance.
How rapidly? Today, which one leads in "satisfying experience", and by how much?
F16 timeframe? That's kind of why I bring it up now.
Put it this way: gnome-shell will barely work on your card as it is, if at all, and no DRI1 driver can or will ever handle Composite redirection of GL apps.
I can conjure up some benchmarks if you think they'd be relevant, I suppose.
So in my ideal world, we would simply drop the -dri1 subpackage (and for that matter, DRI1 support in the X server).
Such a wish would be better justified by statistics on usage (smolt, at least) and support effort (size and rate of change in source commits, number of maintainers with relevant experience, ...)
So, in reverse order: the number of maintainers for the DRI1 drivers is approximately 0. Anyone who did have any experience with them is now interested in competent hardware instead. I can probably remember how a Voodoo5 works if you force me, but I'd rather not.
The support effort for keeping them working at their current level is not zero, but it's not large. Breakages mostly happen when mechanical API changes are made internally to Mesa that happen to violate some invariant that the old driver was relying on. Nobody notices breakage like that because nobody has the hardware. Time spent on this level of support is time not spent on hardware people have.
But time spent on this level of support is also time spent on a level of support that is not sufficient for the future. We can either chase bugs in seven DX7-or-worse drivers, for hardware that is on the far end of the bathtub curve; or we can maintain one software-based driver that runs everywhere including in virtual machines, shares most of its internal infrastructure with r600 and nouveau, and already implements better than DX9-level functionality.
I know which one I'd prefer.
---
But then, smolt. Sigh. Smolt. What a travesty.
You would hope that a result like:
http://smolt.fedoraproject.org/reports/view_devices?device=MGA&search=Su...
would mean there's one report for each of those device, but no. And then you'd hope that you could click on the first device and get a uniquified list, but nooooo:
http://smolt.fedoraproject.org/reports/view_device/MGA%20G200%20AGP
The one thing - the _one_ thing - I'd want out of smolt is a query by PCI ID tuple, and that doesn't exist.
Even this page:
http://smolt.fedoraproject.org/static/stats/by_class_VIDEO.html
is nonsense. As of just now, the sum of the (unlabeled) column immediately right of the vendor name is 38553. The "total count" above is 432462 and the percentage of systems reporting a video device is 17.7%, but 38553 is not 17.7% of 432462. Not even close.
Assuming that 38553 is anywhere close to a meaningful number, we then get:
nvidia: 38.6% (14888) ati: 34.2% (13176) intel: 19.1% (7347)
So that's 92% of the installed base as a ballpark, but not corrected for mach64, rage128, i740, i810, or (ha!) nv1. Of the remaining 3142 systems where DRI1 support might work:
matrox: 11.0% (347) s3: 14.4% (451) sis: 20.1% (633) 3dfx: 2.6% (81) via: 20.4% (640) total: 68.5% (2152)
Which is an overestimate:
- mga includes pre-G200 devices, P-series, and M-series - savage includes all S3 chips, including pre-Savage devices like Virge and 968, and post-savage4 like savage2000 and chrome cards - sis includes all sis variants where we only have 3d support for the 300 series (see 'man sis' for the breakdown) - 3dfx includes pre-voodoo3 devices - via includes chrome9
But I have no idea how much of an overestimate, because smolt appears to be full of lies. Searching for devices with the word "voodoo" in the name should return something other than an empty set, if there are 81 3dfx devices, but of course:
http://smolt.fedoraproject.org/reports/view_devices?device=voodoo&search...
So in a sense, these numbers are completely untrustworthy. But if we decide to trust them anyway, something like 8% of users will suddenly discover that their GL driver got a lot more capable, if they notice at all. Personally I suspect it's more like 0.8%.
- ajax
Adam Jackson wrote:
On 4/12/11 11:58 PM, John Reiser wrote:
On 04/12/2011 09:12 AM, Adam Jackson wrote:
For comparison, the baseline for the GPU in the phone in your pocket - and that platform layers like clutter more or less expect - is GLES 2.0, which is roughly comparable to DirectX 9. We're rapidly approaching the point where the software renderer is going to be a more satisfying experience than hardware 3d support for these chips, both for features and for performance.
How rapidly? Today, which one leads in "satisfying experience", and by how much?
F16 timeframe? That's kind of why I bring it up now.
Will F16 finally ship the llvmpipe as the default software renderer?
(I can see the llvmpipe beat ancient cards easily, judging from the benchmarks I've seen so far, but the existing software pipes are really really slow.)
Kevin Kofler
On 4/13/11 5:43 PM, Kevin Kofler wrote:
Will F16 finally ship the llvmpipe as the default software renderer?
If by F16, you mean F15, then yes.
http://fedoraproject.org/wiki/Docs/Beats/Xorg
- ajax
Adam Jackson wrote:
On 4/13/11 5:43 PM, Kevin Kofler wrote:
Will F16 finally ship the llvmpipe as the default software renderer?
If by F16, you mean F15, then yes.
Hmmm, really?
When I look at upstream mesa's code, I see this: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/targets/dri-swrast/Ma...
This sure looks like it builds swrastg using the softpipe, not the llvmpipe. I also don't see any Fedora patch which would be changing this.
Now I'm not going to claim that I know my way around the Mesa codebase, so what am I missing?
Kevin Kofler
On 4/13/11 7:17 PM, Kevin Kofler wrote:
Adam Jackson wrote:
On 4/13/11 5:43 PM, Kevin Kofler wrote:
Will F16 finally ship the llvmpipe as the default software renderer?
If by F16, you mean F15, then yes.
Hmmm, really?
I don't know. Let's ask the machine:
synephrine:~% DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on llvmpipe synephrine:~% rpm -q mesa-dri-drivers mesa-dri-drivers-7.11-0.6.20110412.0.fc15.x86_64
- ajax
On Wed, 2011-04-13 at 19:57 -0400, Adam Jackson wrote:
On 4/13/11 7:17 PM, Kevin Kofler wrote:
Adam Jackson wrote:
On 4/13/11 5:43 PM, Kevin Kofler wrote:
Will F16 finally ship the llvmpipe as the default software renderer?
If by F16, you mean F15, then yes.
Hmmm, really?
I don't know. Let's ask the machine:
synephrine:~% DISPLAY=:0 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on llvmpipe synephrine:~% rpm -q mesa-dri-drivers mesa-dri-drivers-7.11-0.6.20110412.0.fc15.x86_64
In the interests of general public enlightenment, it would've been nice if you'd answered KK's question "what am I missing", i.e., where's the magic bit which makes llvmpipe the default? Knowledge is always a good thing :)
On 4/13/11 11:58 PM, Adam Williamson wrote:
In the interests of general public enlightenment, it would've been nice if you'd answered KK's question "what am I missing", i.e., where's the magic bit which makes llvmpipe the default? Knowledge is always a good thing :)
The specfile contains this stanza, after it has built OSMesa:
# now build the rest of mesa %configure %{common_flags} \ --disable-glw \ --disable-glut \ --disable-gl-osmesa \ --with-driver=dri \ --with-dri-driverdir=%{_libdir}/dri \ --with-state-trackers=dri,glx \ --enable-egl \ --enable-gles1 \ --enable-gles2 \ --disable-gallium-intel \ --disable-gallium-svga \ --disable-gallium-egl \ %if %{with_hardware} --enable-gallium-llvm \ --enable-gallium-radeon \ --enable-gallium-r600 \ --enable-gallium-nouveau \ %else --disable-gallium-llvm \ --disable-gallium-radeon \ --disable-gallium-r600 \ --disable-gallium-nouveau \ %endif %{?dri_drivers}
The --enable-gallium-llvm bit, in particular, is key. There's some small magic later where it renames swrastg_dri.so to be swrast_dri.so because that's the name the X server and libGL are expecting, and that's not perfect yet in that the debuginfo search gets a little confused, but in the main I've tried to be pretty clear in the operation of the Mesa spec, despite the utter malignancy of the Mesa buildsystem (any of them, take your pick, there's like five now). If I've failed in any way to document sufficiently our work in the specfile, please, do let me know.
But - as an aside - you're right. I was a little irked at being asked whether I'd actually done the thing I'd said I'd done, had tested that I'd done, had documented that I'd done, had claimed in public that I'd done, and had been doubted of without any evidence of the inquisitor having made even cursory investigation into the matter. It was wrong of me to assume that someone reading the spec would look for the string /llvm/i when looking for how to enable the LLVM support in Mesa, to assume that someone would read the spec to learn how the package was built, or to assume that someone would try to test a software GL path like Xvfb or vesa to see if I was in fact telling the truth before doubting my honesty. I was unnecessarily short in my reply, and for that, I apologize. In the future I'll be less succinct.
(No, I won't.)
- ajax
On 04/12/2011 06:12 PM, Adam Jackson wrote:
There are two major package classes in Fedora that provide graphics drivers: xorg-x11-drv-*, and mesa-dri-drivers-*.
In F15, mesa-dri-drivers now only includes drivers with DRI2 support (radeon, nvidia, intel) and the software renderer; if you want all the older drivers you have to install mesa-dri-drivers-dri1. This list is:
i810, mga, r128, savage, sis, tdfx, unichrome
Basically all of this hardware is, ahem, inept. The most featureful device supported by these drivers would be the MGA G550, which just barely manages to do DirectX 7 (comparable to a Radeon 7000 or GeForce 2, both ~1999 vintage). All the others are back in the DX6 stone age. For comparison, the baseline for the GPU in the phone in your pocket - and that platform layers like clutter more or less expect - is GLES 2.0, which is roughly comparable to DirectX 9. We're rapidly approaching the point where the software renderer is going to be a more satisfying experience than hardware 3d support for these chips, both for features and for performance.
So in my ideal world, we would simply drop the -dri1 subpackage (and for that matter, DRI1 support in the X server).
For 2D we've got an xorg-x11-drivers metapackage that includes, well, pretty much everything, and which is included in comps as a default. This is lame, because it means a bunch of backwater drivers end up as critical path and can never possibly get tested. (Smolt says there are all of 3 savage users. I assume the number of i740 users is actually negative.) The list of video drivers that see any actual use is probably something like:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
Would this affect the way KVM and specifically qemu-kvm in it's default setup for video using the cirrus driver would work? Just wondering if there would be any implications for the virt guys in that regard.
Thanks & regards, Phil
On 4/13/11 5:14 AM, Phil Knirsch wrote:
On 04/12/2011 06:12 PM, Adam Jackson wrote:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
Would this affect the way KVM and specifically qemu-kvm in it's default setup for video using the cirrus driver would work? Just wondering if there would be any implications for the virt guys in that regard.
"cirrus" is in that list for precisely that reason.
- ajax
Adam Jackson (ajax@redhat.com) said:
On 4/13/11 5:14 AM, Phil Knirsch wrote:
On 04/12/2011 06:12 PM, Adam Jackson wrote:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
Would this affect the way KVM and specifically qemu-kvm in it's default setup for video using the cirrus driver would work? Just wondering if there would be any implications for the virt guys in that regard.
"cirrus" is in that list for precisely that reason.
... should we work on making qemu/kvm default to something more modern/sane? (qxl, vmware?) Does it not end up mattering (or do we need cirrus for legacy OS support)?
Bill
On 4/13/11 9:09 AM, Bill Nottingham wrote:
... should we work on making qemu/kvm default to something more modern/sane? (qxl, vmware?) Does it not end up mattering (or do we need cirrus for legacy OS support)?
It ends up being a function of the guest OS - vmware's Windows driver will refuse to run on anything but vmware's hypervisor, etc - which means that's really more of a virt-manager question.
That said, the dumb vesa support in kvm is quite possibly a better choice as a default than cirrus, as the latter is limited (by the choice of chip emulated!) to 1024x768.
- ajax
On 04/13/2011 03:10 PM, Adam Jackson wrote:
On 4/13/11 9:09 AM, Bill Nottingham wrote:
... should we work on making qemu/kvm default to something more modern/sane? (qxl, vmware?) Does it not end up mattering (or do we need cirrus for legacy OS support)?
It ends up being a function of the guest OS - vmware's Windows driver will refuse to run on anything but vmware's hypervisor, etc - which means that's really more of a virt-manager question.
Hm, odd. When i switch from cirrus to the vmware display driver it seems to work quite nicely here on my box (RHEL-6 host) and Xorg.log.0 clearly shows it using the vmware driver in the guest, too. And i'm pretty sure we didn't do any hacks in RHEL-6 to make this work specifically as the default was and is cirrus driver (as limited as that may be).
Thanks & regards, Phil
On 4/13/11 11:02 AM, Phil Knirsch wrote:
On 04/13/2011 03:10 PM, Adam Jackson wrote:
On 4/13/11 9:09 AM, Bill Nottingham wrote:
... should we work on making qemu/kvm default to something more modern/sane? (qxl, vmware?) Does it not end up mattering (or do we need cirrus for legacy OS support)?
It ends up being a function of the guest OS - vmware's Windows driver will refuse to run on anything but vmware's hypervisor, etc - which means that's really more of a virt-manager question.
Hm, odd. When i switch from cirrus to the vmware display driver it seems to work quite nicely here on my box (RHEL-6 host) and Xorg.log.0 clearly shows it using the vmware driver in the guest, too. And i'm pretty sure we didn't do any hacks in RHEL-6 to make this work specifically as the default was and is cirrus driver (as limited as that may be).
I said "vmware's Windows driver" for a reason.
- ajax
Dne 12.4.2011 18:12, Adam Jackson napsal(a):
negative.) The list of video drivers that see any actual use is probably something like:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
A word from your Xorg bugmaster. I think even this list is too generous .. I haven't found any Fedora bug for -ast, only 3 hopelessly ignored bugs for -sis, -geode is alive only because of OLPC (and yes, that's a good reason enough to keep it around), and outside of KVM emulation I don't remember I've ever seen a -cirrus bug.
Matěj
On 4/13/11 10:25 AM, Matej Cepl wrote:
Dne 12.4.2011 18:12, Adam Jackson napsal(a):
negative.) The list of video drivers that see any actual use is probably something like:
ast, ati, cirrus, fbdev, geode, intel, mga, nouveau, openchrome, qxl, sis/xgi, vesa, vmware
A word from your Xorg bugmaster. I think even this list is too generous .. I haven't found any Fedora bug for -ast, only 3 hopelessly ignored bugs for -sis, -geode is alive only because of OLPC (and yes, that's a good reason enough to keep it around), and outside of KVM emulation I don't remember I've ever seen a -cirrus bug.
ast I only included because I know there's currently shipping server hardware with it. The rest... yeah, pretty much.
- ajax