Mike, I've been following the fedora-devel mailing list, and I understand why you removed r300 support in Mesa and the kernel. I was working through a bug where OpenGL didn't work at all (even in indirect mode), and, in the process, rebuilt both Mesa and the kernel after removing your fixes. Apparently, I'm one of the lucky ones whose Radeon 9600 works with the experimental driver because it all started working. I'm now thinking of putting together a package (similar to the proprietary one in livna) that would give accelerated 3D to any Radeon users willing to take the risk.
It seems that the only difference in Mesa when the r300 is enabled is that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and that the only difference in the kernel is the drm module is patched to not recognize the r300 PCI ids. It seems that the Mesa problem could be easily fixed, but what is the easiest way to fix the kernel (aside from providing my own (un)patched kernel)? Will X even try to load the DRM module if Mesa doesn't provide r300_dri.so but the kernel does provide the PCI id's? If it doesn't, could we re-enable the r300 PCI ids in the kernel and just ship Mesa without the r300 driver? If it does, is there any other possible solution to the kernel that I'm missing?
I've been using the fglrx driver in earlier version of Fedora for years now and would love to take this chance to move off of it and helping others move off in the process is a bonus.
Thanks, Jonathan Dieter
On Fri, 2006-03-31 at 15:47 +0300, Jonathan Dieter wrote:
It seems that the only difference in Mesa when the r300 is enabled is that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and that the only difference in the kernel is the drm module is patched to not recognize the r300 PCI ids. It seems that the Mesa problem could be easily fixed, but what is the easiest way to fix the kernel (aside from providing my own (un)patched kernel)?
We could make the crippling of R300 _optional_, by doing it with the patch below instead of just by ripping the relevant PCI IDs out.
DaveJ?
--- linux-2.6.16.ppc/drivers/char/drm/radeon_cp.c~ 2006-03-20 05:53:29.000000000 +0000 +++ linux-2.6.16.ppc/drivers/char/drm/radeon_cp.c 2006-03-31 18:26:00.000000000 +0100 @@ -34,6 +34,11 @@ #include "radeon_drv.h" #include "r300_reg.h"
+int radeon_allow_r300; + +MODULE_PARM_DESC(allow_r300, "Allow DRI on Radeon R300 and later cards"); +module_param_named(allow_r300, radeon_allow_r300, int, 0444); + #define RADEON_FIFO_DEBUG 0
static int radeon_do_cleanup_cp(drm_device_t * dev); @@ -2104,6 +2109,11 @@ int radeon_driver_load(struct drm_device drm_radeon_private_t *dev_priv; int ret = 0;
+ if (!radeon_allow_r300 && (flags & CHIP_FAMILY_MASK) >= CHIP_R300) { + printk(KERN_NOTICE "Avoiding DRI on Radeon R300+. Use 'allow_r300=1' module option to override\n"); + return DRM_ERR(ENXIO); + } + dev_priv = drm_alloc(sizeof(drm_radeon_private_t), DRM_MEM_DRIVER); if (dev_priv == NULL) return DRM_ERR(ENOMEM);
On Fri, Mar 31, 2006 at 06:32:44PM +0100, David Woodhouse wrote:
On Fri, 2006-03-31 at 15:47 +0300, Jonathan Dieter wrote:
It seems that the only difference in Mesa when the r300 is enabled is that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and that the only difference in the kernel is the drm module is patched to not recognize the r300 PCI ids. It seems that the Mesa problem could be easily fixed, but what is the easiest way to fix the kernel (aside from providing my own (un)patched kernel)?
We could make the crippling of R300 _optional_, by doing it with the patch below instead of just by ripping the relevant PCI IDs out.
DaveJ?
something got merged yesterday (not yet in the fedora kernel until I rebase), that changed a lot of this.
============================================ commit f3dd5c37382472a8b245ad791ed768771594e60c tree 38c9d13de6187f0b67154d7ab643dbaed55280c2 parent 6e5fca53c72c95da92c092411c7ec81e926af632 author Dave Airlie airlied@linux.ie Sat, 25 Mar 2006 18:09:46 +1100 committer Dave Airlie airlied@linux.ie Sat, 25 Mar 2006 18:09:46 +1100
drm: add new radeon PCI ids..
This adds all the r300 and r400 PCI ids from DRM CVS, it also makes these cards only initialise when the new xorg driver is used, as otherwise the DRM can cause lockups. ============================================
relevant bit being..
+ /* if we require new memory map but we don't have it fail */ + if ((dev_priv->flags & CHIP_NEW_MEMMAP) && !dev_priv->new_memmap) + { + DRM_ERROR("Cannot initialise DRM on this card\nThis card +requires a new X.org DDX\n"); + radeon_do_cleanup_cp(dev); + return DRM_ERR(EINVAL); + }
I'll drop the cripple-radeon patch today, and we'll see what happens.
Dave
On Fri, 2006-03-31 at 13:58 -0500, Dave Jones wrote:
something got merged yesterday (not yet in the fedora kernel until I rebase), that changed a lot of this.
Yeah, I saw that -- but it doesn't disable _everything_ that the old patch disabled. I didn't think it was worth suggesting for FC-5.
On Fri, 2006-03-31 at 13:58 -0500, Dave Jones wrote:
I'll drop the cripple-radeon patch today, and we'll see what happens.
Just in Rawhide, or will this be happening in FC5 as well in a test update?
Jonathan Dieter wrote:
Mike, I've been following the fedora-devel mailing list, and I understand why you removed r300 support in Mesa and the kernel. I was working through a bug where OpenGL didn't work at all (even in indirect mode), and, in the process, rebuilt both Mesa and the kernel after removing your fixes. Apparently, I'm one of the lucky ones whose Radeon 9600 works with the experimental driver because it all started working. I'm now thinking of putting together a package (similar to the proprietary one in livna) that would give accelerated 3D to any Radeon users willing to take the risk.
It seems that the only difference in Mesa when the r300 is enabled is that an extra file (r300_dri.so) is installed in /usr/lib64/dri, and that the only difference in the kernel is the drm module is patched to not recognize the r300 PCI ids.
Correct.
It seems that the Mesa problem could be easily fixed, but what is the easiest way to fix the kernel (aside from providing my own (un)patched kernel)?
The only way, is to unpatch the kernel and rebuild it, and modify Mesa and rebuild it. Mesa drivers are not buildable outside of Mesa currently.
Will X even try to load the DRM module if Mesa doesn't provide
r300_dri.so
but the kernel does provide the PCI id's?
Yep, the X server loads the DRM aparently, as long as Load "dri" is present, which is broken in theory at least, although I don't know if anyone has investigated if there is a good valid reason for that yet or not.
Loading the radeon kernel module causes various R300 hardware to lock up, which is prevented when DRM does not get loaded, which is why we disabled R300 DRM support in the kernel. ;o)
If it doesn't, could we re-enable the r300 PCI ids in the kernel and just ship Mesa without the r300 driver?
"If it doesn't" is the key here. Once someone who can reproduce the failures figures out why and fixes the problem though, then we should be able to re-enable R300 bits in the kernel, unless there are further issues uncovered.
If it does, is there any other possible solution to the kernel that I'm missing?
Yeah, undo the kernel patch, add mesa r300 driver back, and then debug why it locks up for people, produce a patch that fixes it, and submit it to the kernel/dri/mesa/xorg projects as appropriate. ;o)
I've been using the fglrx driver in earlier version of Fedora for years now and would love to take this chance to move off of it and helping others move off in the process is a bonus.
Indeed. I really hope that in X11R7.1 we'll have a much stabler 2D radeon driver. Right now the open source radeon driver's stability and reliability pretty much sucks rocks. The rate of bugs being added to the driver seems to be faster than the rate of bugs being fixed in the driver. Every time new hardware support is added, or new features are added for existing supported hardware, the driver seems to break in ways that don't get discovered early enough to get fixed. The radeon driver source is currently rather humongous and growing daily.
It's really quite a horrendous mess right now.
Shipping a 3D driver which works for some people but causes many other people's 2D desktops to break is very bad. Given the choice between buggy experimental 3D support and a broken 2D experience, and working 2D and no 3D, we'll probably always choose to ship the latter.
benh's fixes in the stable radeon branch improve things for some people having certain problems. Once a new stable radeon driver is released, we will probably throw it into updates-testing for a week then FC5-updates.
If someone wants to make unofficial unsupported Mesa packages and put them somewhere, that's fine IMHO. But Fedora Extras is no more of a broken-driver playground than Core is IMHO.
Make an experimental repository somewhere and call it "Fedora unsupported R300 driver", with a web page that clearly informs people that while using the experimental driver, all bug reports should be filed to X.Org bugzilla directly. That will greatly help the X.Org/DRI/Mesa projects to get the driver in better shape sooner than later.
Hope this helps!
TTYL
devel@lists.stg.fedoraproject.org