[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: > > On Wed, 30 Jan 2002, deek wrote: > > > > > > > Vladimir Dergachev scribbled: > > > > > <__snipped_> > > >> > > > > > > I've implemented this (easier than software CCE) scheme. If you want to > > > please try the latest ati.2 CVS code at http://gatos.sf.net - or just take > > > a look at it. > > > > > > Basically I put in info->accel->Sync(pScrn) at entrance points into Xv > > > driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and > > > PutVideo are all "control" calls, perfomance is not critical. PutImage > > > should, arguably, take more time during image trasfer.. And if you are > > > playing Quake and watching DVD at the same you are making problems for > > > yourself anyway ;) (And the faster the card the less noticable any > > > > > slowdown from extra Sync calls will be) > > > > > > I've checked this out. > > Seems that there is a buggaboo in the radeon implementation. > > I don't know if the same would apply for R128, seems that it > > might. > > > > GATOS Radeon driver has the proper handling of memory controller. > Consequently, usual drm modules will not work - you need to use drm-kernel > package available at http://gatos.sf.net/ > >Vladimir Dergachev Is there any reason the drivers can't be merged? Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Keith Whitwell wrote: > Vladimir Dergachev wrote: > > > > On Wed, 30 Jan 2002, deek wrote: > > > > > > > > > > > Vladimir Dergachev scribbled: > > > > > > > <__snipped_> > > > >> > > > > > > > > I've implemented this (easier than software CCE) scheme. If you want to > > > > please try the latest ati.2 CVS code at http://gatos.sf.net - or just take > > > > a look at it. > > > > > > > > Basically I put in info->accel->Sync(pScrn) at entrance points into Xv > > > > driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and > > > > PutVideo are all "control" calls, perfomance is not critical. PutImage > > > > should, arguably, take more time during image trasfer.. And if you are > > > > playing Quake and watching DVD at the same you are making problems for > > > > yourself anyway ;) (And the faster the card the less noticable any > > > > > > > slowdown from extra Sync calls will be) > > > > > > > > > I've checked this out. > > > Seems that there is a buggaboo in the radeon implementation. > > > I don't know if the same would apply for R128, seems that it > > > might. > > > > > > > GATOS Radeon driver has the proper handling of memory controller. > > Consequently, usual drm modules will not work - you need to use drm-kernel > > package available at http://gatos.sf.net/ > > > >Vladimir Dergachev > > Is there any reason the drivers can't be merged? No reason at all, in fact that's what I intend to push for. Hopefully this would be done right now so there is plenty of time till next release to move around components. The main GATOS CVS branch is quite stable. As for memory controller I'll either e-mail a separate patch to Jens Owens, or it will go into the main XFree tree together with the rest of GATOS patch. Regardless of the way it is merged the driver major version will need to be bumped. GATOS drivers does this but only minor - as I did not want to upload a mesa radeon driver just because of the version change. Vladimir Dergachev > > Keith > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Daryll Strauss wrote: > On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote: > > Regardless of the way it is merged the driver major version will need to > > be bumped. GATOS drivers does this but only minor - as I did not want to > > upload a mesa radeon driver just because of the version change. > > I'm afraid I haven't been following this discussion closely enough, but > I found this statement sort of odd, so I thought I'd comment. > > Version numbers for kernel interfaces are rather different than those > for normal software packages. In normal software packages they are more > of a vanity thing. A minor version number bump means small things > changed, and a major one means hey we did big things. In kernel drivers > they are really important as they describe the API between the kernel > and the user space application. There are very strict rules about which > version numbers are changed when. > > The major version of a driver should be incremented if and only if there > are incompatible changes to the driver that prevent older versions from > working. You obviously want to minimize these sorts of changes, so that > you don't break compatability. For example, lets say we found a big > security hole in an IOCTL. The first thing we'd try to do is rewrite the > function so avoid the hole. Maybe even in a way that's really slow. As > long as the interface remains the same that's fine. We might add a new > interface that's fast again, but keep the old one around for backward > compatability. If that's completely impossible then we remove the IOCTL > and bump the major version number. > > If you add or change functionality, but the old drivers still work, then > a minor version number should be bumped. Drivers will check for a > matching major number and minor number that is greater than or equal to > the one they need. So, again if we go back to that security problem. If > we rewrote the old IOCTL to be slow but secure and added a new one that > is safe and fast, the minor number would be bumped. > > If you just fix a bug or make some really small change that doesn't > impact the interface, then you bump the third digit. Third digits are > ignored by the software and are really just documentation. I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the "slightly" broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Vladimir Dergachev > > (These paragraphs might be good for a FAQ/Doc somewhere) > > So, the thing that struck me as odd, is that you said you only bumped > the minor version because you didn't want to break Mesa. If your changes > do work with Mesa, than bumping the minor version is the right thing to > do. We're trying REALLY hard not to change the kernel interfaces. Linus > kicked our asses pretty severely about not being careful with kernel > version numbers. (Rightfully so) Weve been told in no uncertain terms > that if we didn't get this stuff under control it would be removed from > the kernel tree. So we should be very careful about how this Gatos > functionality is added. It sounds like it should be possible to do it > without breaking the API if we put our thinking caps on. > >- |Daryll > > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Daryll Strauss wrote: > On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: > > I completely agree with you.. but I did not give you details :)) > > > > What happens is that if you try to use older drm driver with GATOS 2d > > driver the GATOS driver will notice and complain. But if you use GATOS drm > > driver with older 4.2.0 2d driver you will get a lockup. > > > > The reason is that the changes involve programming Radeon's memory > > controller to place AGP aperture after the end of the framebuffer and not > > at the start of PCI space as it is done currently. Both 2d driver and drm > > driver have to agree on this - which is why a bump in major version is > > necessary. > > > > The reason I did not do it is that the mesa driver checks major version as > > well. Hence it will complain if it is bumped. Since I did not want to open > > a new CVS module just for changing version in mesa driver I decided to go > > the "slightly" broken way under assumption that few people with install > > GATOS drm-kernel but will forget to install GATOS 2d driver. > > > > Does this make sense ? > > Sure does, but it sounds like we could change the Mesa drivers to have the > same behavior as the GATOS drivers. If they see version x.y they use the > old offset for AGP and if they see x.y+1 they use the new one. This > would be much better than bumping the major version number. > > I may be glossing over details, in fact I probably am, but putting some > effort into this is probably required if we want to be good Linux citizens. That's a good idea.. Except that it wont' work. Mesa driver is distributed with XFree86 anyway, so when GATOS patch gets merged in everything will work ok. The problem is that I don't know how drm driver can check the version of 2d driver that attempts to initialize it - if you know how please let me know. Without this, first thing after we include mew drm driver into Linux kernel we'll have people downloading it and getting a lockup with 4.2.0 or earlier. Vladimir Dergachev > > - |Daryll > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Daryll Strauss wrote: > > On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: > > I completely agree with you.. but I did not give you details :)) > > > > What happens is that if you try to use older drm driver with GATOS 2d > > driver the GATOS driver will notice and complain. But if you use GATOS drm > > driver with older 4.2.0 2d driver you will get a lockup. > > > > The reason is that the changes involve programming Radeon's memory > > controller to place AGP aperture after the end of the framebuffer and not > > at the start of PCI space as it is done currently. Both 2d driver and drm > > driver have to agree on this - which is why a bump in major version is > > necessary. > > > > The reason I did not do it is that the mesa driver checks major version as > > well. Hence it will complain if it is bumped. Since I did not want to open > > a new CVS module just for changing version in mesa driver I decided to go > > the "slightly" broken way under assumption that few people with install > > GATOS drm-kernel but will forget to install GATOS 2d driver. > > > > Does this make sense ? > > Sure does, but it sounds like we could change the Mesa drivers to have the > same behavior as the GATOS drivers. If they see version x.y they use the > old offset for AGP and if they see x.y+1 they use the new one. This > would be much better than bumping the major version number. > > I may be glossing over details, in fact I probably am, but putting some > effort into this is probably required if we want to be good Linux citizens. Daryll, wake up to what you're saying. How daft to suggest this without considering the consequences after all the discussions about backwards compatibility we've had. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
> The assumption was only made for experimental GATOS drivers. It is a > practical one. More people come and ask: "I upgraded to GATOS driver and > DRI won't work anymore !" Answer: RTFM, upgrade drm driver. It's already been determined that: "I just upgraded my kernel, and DRI won't work anymore!" "RTFM, upgrade your X server" "I just upgraded my X server, and DRI doesn't work anymore!" "RTFM, upgrade your kernel" just doesn't cut it. You aren't allowed to do anything that requires a response of "RTFM, upgrade ..." Start thinking of alternatives... -- Gareth ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Gareth Hughes wrote: > > The assumption was only made for experimental GATOS drivers. It is a > > practical one. More people come and ask: "I upgraded to GATOS driver and > > DRI won't work anymore !" Answer: RTFM, upgrade drm driver. > > It's already been determined that: > > "I just upgraded my kernel, and DRI won't work anymore!" > "RTFM, upgrade your X server" > > "I just upgraded my X server, and DRI doesn't work anymore!" > "RTFM, upgrade your kernel" > > just doesn't cut it. You aren't allowed to do anything that > requires a response of "RTFM, upgrade ..." > > Start thinking of alternatives... Gareth, the current driver is broken. If someone wants to use video capture they _need_ both GATOS 2d driver and GATOS drm driver, period. What's so wrong about upgrading ? Also, I can make drm driver work nice with older 2d drivers - as soon as someone will show me a way to tell the version of the 2d driver that is accessing the drm driver. best Vladimir Dergachev > > -- Gareth > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
> Gareth, the current driver is broken. If someone wants to use video > capture they _need_ both GATOS 2d driver and GATOS drm driver, period. > > What's so wrong about upgrading ? Guaranteed, someone will get a mismatch -- your changes may go back into the stock kernel, breaking DRI CVS or whatever, who knows. Forcing everyone to upgrade their kernel, 2D and 3D drivers to the right magic revision is a recipe for disaster, one that the kernel people have already kicked our arses over (rightly so). > Also, I can make drm driver work nice with older 2d drivers - as soon as > someone will show me a way to tell the version of the 2d driver that is > accessing the drm driver. Sounds like it'll need a 2D driver upgrade :-) -- Gareth ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Gareth Hughes wrote: > > Gareth, the current driver is broken. If someone wants to use video > > capture they _need_ both GATOS 2d driver and GATOS drm driver, period. > > > > What's so wrong about upgrading ? > > Guaranteed, someone will get a mismatch -- your changes may go back > into the stock kernel, breaking DRI CVS or whatever, who knows. Forcing > everyone to upgrade their kernel, 2D and 3D drivers to the right magic > revision is a recipe for disaster, one that the kernel people have > already kicked our arses over (rightly so). > > > Also, I can make drm driver work nice with older 2d drivers - as soon as > > someone will show me a way to tell the version of the 2d driver that is > > accessing the drm driver. > > Sounds like it'll need a 2D driver upgrade :-) > So what are you proposing ? Not to fix it ? We have a system where a driver is split in three components all of which have to agree on the hardware state. There is just so much you can do for backward compatibility. You can do less if you can't find one component version from another one. As for Linus not wanting to accept it, 2.4 has dropped most nat filters except for ftp and most of them aren't back yet. So I don't buy this argument. Vladimir Dergachev > -- Gareth > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: > > On Wed, 30 Jan 2002, Gareth Hughes wrote: > > > > Gareth, the current driver is broken. If someone wants to use video > > > capture they _need_ both GATOS 2d driver and GATOS drm driver, period. > > > > > > What's so wrong about upgrading ? > > > > Guaranteed, someone will get a mismatch -- your changes may go back > > into the stock kernel, breaking DRI CVS or whatever, who knows. Forcing > > everyone to upgrade their kernel, 2D and 3D drivers to the right magic > > revision is a recipe for disaster, one that the kernel people have > > already kicked our arses over (rightly so). > > > > > Also, I can make drm driver work nice with older 2d drivers - as soon as > > > someone will show me a way to tell the version of the 2d driver that is > > > accessing the drm driver. > > > > Sounds like it'll need a 2D driver upgrade :-) > > > > So what are you proposing ? Not to fix it ? We have a system where a > driver is split in three components all of which have to agree on the > hardware state. There is just so much you can do for backward > compatibility. You can do less if you can't find one component version > from another one. Do it the old way by default, and if you receive some new ioctl, do it the new way. > As for Linus not wanting to accept it, 2.4 has dropped most nat filters > except for ftp and most of them aren't back yet. So I don't buy this > argument. Trust us. It's the right thing to do, whether Linus or anybody else says so. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
>> The assumption was only made for experimental GATOS drivers. It is a >> practical one. More people come and ask: "I upgraded to GATOS driver and >> DRI won't work anymore !" Answer: RTFM, upgrade drm driver. > >It's already been determined that: > >"I just upgraded my kernel, and DRI won't work anymore!" >"RTFM, upgrade your X server" > >"I just upgraded my X server, and DRI doesn't work anymore!" >"RTFM, upgrade your kernel" > >just doesn't cut it. You aren't allowed to do anything that >requires a response of "RTFM, upgrade ..." Hrm... My understanding is that the problem is related to the setting of MC_AGP_LOCATION (and eventually MC_FB_LOCATION) by the DRM kernel driver, right ? Well... The easy fix is to move that change to the XFree driver before DRM is inited and have the kernel one just read back the value to know which XFree driver version initialized it. I will have to play with those values on Macs as well because of some problems with UniNorth (I basically have to put the ring read ptr in normal RAM, not AGP RAM, and I need the radeon to do a normal PCI busmaster cycle to write it, not an AGP cycle). Ben. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
I think this discussion is really interesting cause it discuss about the biggest problem the DRI project has to deal with: compatibility. The ideas Ian suggested here may fix the problem, but may also create a big confusion in the driver code. I'm just thinking about what will happened after multiples releases of a driver. It will need to deal with more than just the newest DRM version and its predecessor, but with all previous releases of DRM. The result will probably be a huge if-else extra meat-balls spaghetti to deal with all those versions. (Maybe I'm wrong, I don't know if the changes between DRM versions are so dramastic). Something that will need a lot of work, but may fix the problem forever, would be to extract more stuff from the kernel module and try to put it in user space. I think it might be possible to keep in the kernel just what matters about memory allocation and file manipulation, and to use a shared memory scheme in user-space for doing full busmastering and DMA buffer management. I know it sounds a bit fictive, but I would like to know your opinion on this and why it hasn't been that way from the beginning. Security issues? Speed (probably not cause it would requires less IOCTLs)? Anyway, by having more of DRI stuff in user-space, it we'll be easier to have a DRM kernel module that don't requires big changes anytime a new feature is added to the driver, and users would probably just need to upgrade their 2D/3D drivers to benefit from those features. Karl On Thu, 2002-01-31 at 15:37, Ian Romanick wrote: > I've been watching this thread for awhile now, and I think it's time for me > to inject my $0.02 worth. First, let me make sure that I've got things > straight here. > > Changes have been made to the 2D X driver to support video capture on Radeon > cards. To support this change, the way that video memory (or is it register > space?) is mapped must be changed. A portion of this initialization is done > in the 2D X driver and the rest is done in the DRM portion (in the kernel). > Both parts must agree on how memory is to be mapped, or the system will > crash. Am I correct so far? > > Forgive my lack of understanding, but I thought that the DRM mapped > everything in the places where non-kernel drivers told it to map. Isn't > that the point of all the drmAddMap calls? Or do the drmAddMap calls just > provide the physical-to-virtual mapping, and the mapping that is causing the > problem here is some sort of physical-to-physical (using AGP hardware, > perhaps) mapping? > > The crux of the problem is that the DRM portion is distributed with the > kernel sources and the 2D X driver portion is distributed with the XFree86 > sources. The odds that users will have matched versions are much, much > worse then Vegas odds. Therefore, each part (DRM and 2D X driver) have to > magically detect what the other part is capable of doing, and magically do > the right thing. > > Here are the possible version combinations: > > 1. New DRM + new 2D X driver > 2. Old DRM + new 2D X driver > 3. New DRM + old 2D X driver > 4. Old DRM + old 2D X driver > > Case 4 is trivial, and I won't consider it any further. > > In the remaining cases, each the DRM and the 2D X driver need some way to > determine the capabilities of the other part so that they can know how to do > the mapping. I believe that there is already some mechanism for determining > the DRM version (drmGetVersion?). This makes cases 1 and 2 trivial. The > new 2D X driver will determine the DRM version, and either setup the new > mapping and support video capture, or log a message (or something similar) > so that the user knows that video capture is unavailable. Here we have the > potential for reduced functionality, but at least the system won't crash. > > The tricky case, and the case that Vladimir is stuck on, is number 3. How > does the DRM know what the 2D X driver is going to do? Jens and Keith have > suggested using a new set of IOCTLs. By this I assume that he meant having > a new IOCTL number for an old IOCTL, and the new IOCTL would do the same > thing. Simply by using the new entry point the DRM would know that the > caller (i.e., the 2D X driver) is "new." Jens & Keith, is this what you > meant? If so, which IOCTL(s) would need "new" versions? > DRM_IOCTL_RADEON_CP_INIT? > > Vladimir has suggested an alternative. Adding a new IOCTL so that the 2D X > driver would explicitly tell the DRM which version it is. I'm not sure that > I like this so much as presents to possibility for a whole new can of worms > in the future. Would it maybe better to add a new IOCTL to specifically say > "Hey, use the new style memory layout"? > > So, when the 2D driver detects that the DRM is "new," it would use some form > of new IOCTL. The DRM would then know that the 2D driver is also "new," and > the DRM would perform the mapping accordingly. Otherwise, the 2D driver > detects the old DRM version and disables video capture
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Thu, Jan 31, 2002 at 09:05:59AM +, Keith Whitwell wrote: >Vladimir Dergachev wrote: >> >> On Wed, 30 Jan 2002, Gareth Hughes wrote: >> >> > > The assumption was only made for experimental GATOS drivers. It is a >> > > practical one. More people come and ask: "I upgraded to GATOS driver and >> > > DRI won't work anymore !" Answer: RTFM, upgrade drm driver. >> > >> > It's already been determined that: >> > >> > "I just upgraded my kernel, and DRI won't work anymore!" >> > "RTFM, upgrade your X server" >> > >> > "I just upgraded my X server, and DRI doesn't work anymore!" >> > "RTFM, upgrade your kernel" >> > >> > just doesn't cut it. You aren't allowed to do anything that >> > requires a response of "RTFM, upgrade ..." >> > >> > Start thinking of alternatives... >> >> Gareth, the current driver is broken. If someone wants to use video >> capture they _need_ both GATOS 2d driver and GATOS drm driver, period. >> >> What's so wrong about upgrading ? >> >> Also, I can make drm driver work nice with older 2d drivers - as soon as >> someone will show me a way to tell the version of the 2d driver that is >> accessing the drm driver. > >Perhaps you should assume it is the older version until you know otherwise. I agree. I think it would be useful to have a way for the 2D driver to tell the drm driver what version it is, but if a 2D driver doesn't, you have to assume an older version. Older X servers and applications must work with newer kernel drivers. David -- David Dawes Email: [EMAIL PROTECTED] Tungsten Graphics, Inc http://www.tungstengraphics.com Founder/President, Release Engineer Phone: +1 570 764 0288 The XFree86 Project, Inc http://www.xfree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: > As for Linus not wanting to accept it, 2.4 has dropped most nat filters > except for ftp and most of them aren't back yet. So I don't buy this > argument. Vladimir, This is no joke. We absolutely need compatability. Large amounts of developer pain don't even begin to compare to the enormous number of headaches incompatability causes our users. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, Jan 30, 2002 at 08:27:49PM -0700, Jens Owen wrote: | This is no joke. We absolutely need compatability. Large amounts of | developer pain don't even begin to compare to the enormous number of | headaches incompatability causes our users. Not to mention that Linus will almost certainly throw DRM out of the kernel if we don't maintain compatibility (or at least a versioning system that detects incompatibilities and falls back to a previously-supported configuration). Allen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: > Also, I can make drm driver work nice with older 2d drivers - as soon as > someone will show me a way to tell the version of the 2d driver that is > accessing the drm driver. How about using a new set of IOCTL numbers for the new interface--then you'll know whether you have an old or new driver accessing it. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
> That's too bad because this will imply a _lot_ of hair in the drivers. That's the way it has to be, for the DRM code to remain in the stock kernel distro. Linus has make this crystal clear. > The fact is that we have a driver split several ways: 3 portions from > XFree tree (2d, 2d and drm), capture (km, GATOS) and kernel framebuffer. > > The only right way, IMO, is to simply request that all driver versions > must match. Maybe it is good idea to change drm to allow driver libraries, > where we do not simply request radeon driver but, "radeon driver version > X.Y.Z" The only safe way to ensure this is to distribute the drivers (all parts) as a separate package. There are obviously pros and cons to doing it that way. > Now, I'll be the first to agree that for this particular change (memory > controller) we can get by with one extra IOCTL or poking in the card's > registers or even passing invormation in the lower bits of aperture > addresses MS-Windows style. > > The problem is what the code is going look like.. And the more important > question is: what it will look like after another change like that ? > > This memory controller patch is not the last change that would make DRM > incompatible with older drivers. Let me see: >* TV out might cause it to happen again (I don't know as this code has > not been written yet) >* 8500 3d driver might do it too. >* whatever ATI might come up with next. Perhaps, if we were able to start from scratch, we could come up with a clean way to avoid these problems. Unfortunately, a lot of the early design decisions were made when, quite frankly, we didn't understand the current -- and future -- hardware well enough. > So, it is possible to make this change work, but I do not see this worth > it in the end. What you're suggesting boils down to shipping the DRI drivers (incl. the DRM portions) as a separete package. If you can't maintain backwards compatibility, this is the way it will be. End of story. -- Gareth ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Fri, 1 Feb 2002, Gareth Hughes wrote: > > That's too bad because this will imply a _lot_ of hair in the drivers. > > That's the way it has to be, for the DRM code to remain in the stock > kernel distro. Linus has make this crystal clear. > > > The fact is that we have a driver split several ways: 3 portions from > > XFree tree (2d, 2d and drm), capture (km, GATOS) and kernel framebuffer. > > > > The only right way, IMO, is to simply request that all driver versions > > must match. Maybe it is good idea to change drm to allow driver libraries, > > where we do not simply request radeon driver but, "radeon driver version > > X.Y.Z" > > The only safe way to ensure this is to distribute the drivers (all parts) > as a separate package. There are obviously pros and cons to doing it > that way. > > > Now, I'll be the first to agree that for this particular change (memory > > controller) we can get by with one extra IOCTL or poking in the card's > > registers or even passing invormation in the lower bits of aperture > > addresses MS-Windows style. > > > > The problem is what the code is going look like.. And the more important > > question is: what it will look like after another change like that ? > > > > This memory controller patch is not the last change that would make DRM > > incompatible with older drivers. Let me see: > >* TV out might cause it to happen again (I don't know as this code has > > not been written yet) > >* 8500 3d driver might do it too. > >* whatever ATI might come up with next. > > Perhaps, if we were able to start from scratch, we could come up with a > clean way to avoid these problems. Unfortunately, a lot of the early > design decisions were made when, quite frankly, we didn't understand > the current -- and future -- hardware well enough. I can't believe I am hearing this. The major benifit of free software is that if there is a new and better design you can try it out and then everyone can upgrade. It's not as if we are charging them money they way Microsoft does. Are you saying that progress stops with the inclusion of the driver into the kernel tree ? Could it be that you misunderstood Linus and he meant: during stable series ? As for understanding the hardware - you can't possibly understand which has not been released yet. Heck, with the state of things that is now, we often don't know details about the hardware that was just released. > > > So, it is possible to make this change work, but I do not see this worth > > it in the end. > > What you're suggesting boils down to shipping the DRI drivers (incl. the > DRM portions) as a separete package. If you can't maintain backwards > compatibility, this is the way it will be. End of story. What about including both old and new drivers in the kernel simultaneously ? And make them register the PCI ids instead of pretend they don't access the device ? This way will have radeon_X.o for DRM modules and Xserver will simply attempt to load the correct version (and remove wrong one if it is loaded). Vladimir Dergachev > > -- Gareth > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
> Kevin said: > - If we want to update the DRM drivers in the Linux kernel to say DRM > version y', which supports the new XFree86 4.3.0 drivers (DDX version > x'), then DRM version y' MUST also support the older DDX version x > drivers as well for backwards compatibility. Two other points I wanted to add. We don't have to keep this backward compatability forever. It is acceptable to remove obsolete interfaces after a reasonable period of time. Reasonable is at least 2 or 3 XFree releases so that's probably 18-24 months later. This will help avoid the buildup of old code in the drivers. It's also acceptable to have compile options that turn old interfaces on and off as long as you've got one set of sources that can be built with all the interfaces turned on. That way if the user is concerned about memory and kernel bloat they can pick specific interfaces and compile their kernel that way, but then it is up to them to make sure they're running matching versions of everything. I wouldn't bother with this unless there's major interface changes that represent a significant amount of code, but it is an option. - |Daryll ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, Jan 30, 2002 at 10:43:20PM -0500, Vladimir Dergachev wrote: > > > On Wed, 30 Jan 2002, Jens Owen wrote: > > > Vladimir Dergachev wrote: > > > > > Also, I can make drm driver work nice with older 2d drivers - as soon as > > > someone will show me a way to tell the version of the 2d driver that is > > > accessing the drm driver. > > > > How about using a new set of IOCTL numbers for the new interface--then > > you'll know whether you have an old or new driver accessing it. > > > > Jens, it is not a new interface. It is simply a matter of moving AGP and > framebuffer apertures within cards internal address space. If it is moved > the buffers (texture, ring buffer, indirect, etc) need to have their > addresses adjusted. (that was the place where documentation was wrong.. > it named those fields as "offsets" but they are absolute addresses). Once > it is setup and the buffer addresses are ok everything goes in as before. > But if any component gets the wrong idea and tells the card "go get a texture > from the wrong place" it all locks up. > > To reiterate it is simply a matter of initializing the card. > > The problem arises from the fact that initialization is done both in 2d > driver and drm driver. DRM initializes the ring buffer and 2d driver sets up > framebuffer and passes down various buffers - texture, stencil, depth, > etc. If either is wrong lockup results. Vladimir, I know what you're talking about with respect to the initialization; however, the problem that Jens and others are trying to point out is that we must keep backwards compatibility. Let's see if I can explain what is going on here: Assumptions: - The current XFree86 4.2.0 drivers have been released (let's call these DDX version x) - The Linux kernel currently has DRM drivers (or soon will have) that work with DDX version x (let's call these DRM version y) IIRC, the rule that we worked out with Linus is: - If we want to update the DRM drivers in the Linux kernel to say DRM version y', which supports the new XFree86 4.3.0 drivers (DDX version x'), then DRM version y' MUST also support the older DDX version x drivers as well for backwards compatibility. One way that this can be accomplished is by adding new IOCTLs for those entry points that have new functionality or slightly modified and non-backwards compatible functionality. For example, if the current IOCTL assumes that the framebuffer start address is at 0, and instead you need an IOCTL to read the FB start addr from a variable passed in (or from the SAREA), then in the new DRM driver, you need to have two IOCTLs: the first IOCTL is the same as the one in the old DRM driver, which assumes that the FB start addr is at 0; and, the second IOCTL is the one that reads it from a variable. The underlying code in the new DRM driver can be modified so that almost all of it is shared between the two IOCTLs; however, we still need both entry points so that we maintain backwards compatibility. I hope this explanation helps. Please correct me if I've misinterpreted the rule. I'm trying to put it in it's simplest terms so as to minimize confusion. Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
