From: Gareth H. <ga...@nv...> - 2002-01-30 23:17:31
|
> 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 |
From: Vladimir D. <vo...@mi...> - 2002-01-30 23:53:46
|
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 > |
From: Jens O. <je...@tu...> - 2002-01-31 03:29:26
|
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 / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Shawn S. <sp...@sh...> - 2002-01-31 04:32:29
|
I dont know if this is coming, or if there's any interest. But X just *dies* using the CPU to redraw 2D and 3D just isn't even worth using on this P200. I have a Mach64 chipset: ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB There is no DRI support for this card (at the moment). Is there anyone out there working on such a driver? I'm sure a lot of us users would be very happy ;) Shawn. |
From: Vladimir D. <vo...@mi...> - 2002-01-31 04:57:13
|
On Wed, 30 Jan 2002, Shawn Starr wrote: > > I dont know if this is coming, or if there's any interest. But X just > *dies* using the CPU to redraw 2D and 3D just isn't even worth using on > this P200. > > I have a Mach64 chipset: > > ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB > > There is no DRI support for this card (at the moment). Is there anyone out > there working on such a driver? I'm sure a lot of us users would be very > happy ;) > I do not have GT, but I do have GTB (Rage II+DVD) and X seem to work ok with it. Are you using KDE by any chance ? Something in it (lots of eye candy I bet) manages to slow down even the fastest cards. Why don't you try twm first and see if it is any better. Next try Enlightenment.. I suggest "Blue Metal" scheme as it is less pixmap intensive. Also reducing your resolution to 640x480 might speed up things as well. Vladimir Dergachev > Shawn. > > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Shawn S. <sp...@sh...> - 2002-01-31 05:21:27
|
GNOME 1.4.x still, but running TuxRacer totally blew up X/system. I compared this to win2k and it just blew it out of the water HARD :( On Wed, 30 Jan 2002, Vladimir Dergachev wrote: > > > On Wed, 30 Jan 2002, Shawn Starr wrote: > > > > > I dont know if this is coming, or if there's any interest. But X just > > *dies* using the CPU to redraw 2D and 3D just isn't even worth using on > > this P200. > > > > I have a Mach64 chipset: > > > > ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB > > > > There is no DRI support for this card (at the moment). Is there anyone out > > there working on such a driver? I'm sure a lot of us users would be very > > happy ;) > > > > I do not have GT, but I do have GTB (Rage II+DVD) and X seem to work ok > with it. Are you using KDE by any chance ? Something in it (lots of > eye candy I bet) manages to slow down even the fastest cards. > > Why don't you try twm first and see if it is any better. Next try > Enlightenment.. I suggest "Blue Metal" scheme as it is less pixmap > intensive. Also reducing your resolution to 640x480 might speed up things > as well. > > Vladimir Dergachev > > > Shawn. > > > > > > _______________________________________________ > > Dri-devel mailing list > > Dri...@li... > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > |
From: F. <j_r...@ya...> - 2002-01-31 10:13:03
|
Shawn, On 2002.01.31 04:33 Shawn Starr wrote: > > I dont know if this is coming, or if there's any interest. But X just > *dies* using the CPU to redraw 2D and 3D just isn't even worth using on > this P200. > > I have a Mach64 chipset: > > ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB > > There is no DRI support for this card (at the moment). Is there anyone > out > there working on such a driver? I'm sure a lot of us users would be very > happy ;) > > Shawn. > > The 2D problems you notice must be some configuration problem of yours. The 3D support is own is way. Check at http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/html/hardware.html#MACH64 if you want to help. But be warned that at this moment there is no DMA yet which means that you only have your 2 MB for everything (buffers, textures,...) so the driver at the current state is pretty unusable for you. To have a idea of what have been done so far check this archive http://mefriss1.swan.ac.uk/~jfonseca/dri/archive/dri-devel-mach64.mbox.bz2 Regards, Jose Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Allen A. <ak...@po...> - 2002-01-31 05:05:10
|
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 |
From: Vladimir D. <vo...@mi...> - 2002-01-31 19:06:23
|
On Wed, 30 Jan 2002, Jens Owen wrote: > 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 Having slept over this... Is it possible to include a new ioctl specifically to exchange versioning info ? Something along the lines of struct { int uc_type; /* user component type */ int uc_major, un_minor, uc_subminor; /* uc component info */ int drm_major, drm_minor, drm_subminor; /* place to return drm version info */ } drm_version_t; And have application (X at the moment) call it before doing anything with drm ? thanks ! Vladimir Dergachev > > -- /\ > Jens Owen / \/\ _ > je...@tu... / \ \ \ Steamboat Springs, Colorado > > _______________________________________________ > Gatos-devel mailing list > Gat...@li... > https://lists.sourceforge.net/lists/listinfo/gatos-devel > |
From: Keith W. <ke...@tu...> - 2002-01-31 09:13:13
|
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 |
From: Ian R. <id...@us...> - 2002-01-31 20:37:32
|
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 support, or the DRM gets the old IOCTL and performs the mapping the old way. Now, if all (or at least all the important parts) of the above is correct, is there any reason why we should not move forward with this solution? At first blush, there don't seem to be any horrible pitfalls, and I don't really see any other way that will keep us out of trouble with Linus and with our users. There is (at least) one remaining issue. In the case where a user has the new 2D part and wants to use video capture but doesn't have a new enough DRM, how do we effectively inform them? I don't think that just logging a message to the X log / syslog is good enough. Is there any other way? Could we do something perverted like "capture" a screen of text that says "You must upgrade your DRM to use video capture"? :) -- Tell that to the Marines! |
From: Jens O. <je...@tu...> - 2002-02-01 03:41:01
|
Ian Romanick wrote: > 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 If the client side 3D drivers are affected, you would also need to factor old and new 3D drivers in to make 8 cases--but I certainly hope the new DRM driver will support both old and new user space drivers simultaneously [cases 1&3]. If so, adding the 3D driver would just be redundant. > 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. Good idea. The DRM minor should be bumped anyway, and the new 2D driver could check to see if the minor number was >= the version it needed for video support. > 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? This is a possibility--but it might be easier to just have a new IOCTL in the manner you or Vladimir have suggested below. > 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"? Either would work. Vladimir could reuse his versioning for other changes--but keeping track of what changes worked with which version would get confusing. Your suggestion is simple and might make maintenance easier. > 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 support, or the DRM > gets the old IOCTL and performs the mapping the old way. Exactly. You could do this with Vladimir's IOCTL as well as long as the DRM assumes a base level version if the IOCTL is not used that identifies the old 2D driver. > Now, if all (or at least all the important parts) of the above is correct, > is there any reason why we should not move forward with this solution? At > first blush, there don't seem to be any horrible pitfalls, and I don't > really see any other way that will keep us out of trouble with Linus and > with our users. Ian, I like your suggestion--but we both have to keep in mind that Vladimir is doing the leg work on this one. If his solution is backwards compatible then I'd be inclined to go with what he and Kevin Martin and Marc La France work out. They are the ones currently maintaining the ATI driver code base. > There is (at least) one remaining issue. In the case where a user has the > new 2D part and wants to use video capture but doesn't have a new enough > DRM, how do we effectively inform them? I don't think that just logging a > message to the X log / syslog is good enough. Is there any other way? > Could we do something perverted like "capture" a screen of text that says > "You must upgrade your DRM to use video capture"? :) I would imagine the video capture API has error handling. I would recommend both logging the failure and returning an error code to the client. The client usually has the best ability to gracefully handle and report failures. Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: James H. <oo...@an...> - 2002-02-05 14:50:55
|
Is there a guide on how to setup DRI? I have never managed to set it up correctly... These combination problems would go away is someone wrote a clear installation guide... Here is a list of questions I think it should answer and exactly how to do it. Where do I get my sources from.... ( Note it is preferable to be able to use "reference" sources, Having to use someone "special kernel" or different "xfree86 tree" is a pain in the butt when compiling these things. Provide patches for snapshoots rather than alturnative trees, its much easier to patch a stock tree, with several patches, than than an alturnate tree with stock patches. Alturnative trees, oftain are lag weeks behind stock trees. Personally I think Alturnative trees are great for developers, but of no use for production. ) What do I have to do to enable kernel modules mknod which devices modes etc... Do I have to run any daemon? Do I need any new magic config files in /etc if so what. What do I have to do to the Xfree86 site.def to get it to compile dri What do I have to do to my XFree86config to get it to use DRI. Most people get a working config they way they like and don;t want to go back to scratch generating a new one... What options have to be added. (use of colour on a web page to hightlight sections.... etc etc. Trouble shooting.... My config does not work, how to I check I have all the right compatible bits etc. James |
From: Jose F. <j_r...@ya...> - 2002-02-05 15:30:48
|
On Tue, 2002-02-05 at 14:50, James Hawtin wrote: > Is there a guide on how to setup DRI? I have never managed to ... > ... to go to the DRI website and search for documentation? ;-) Check http://dri.sourceforge.net/doc.phtml It covers most of your questions! > James > Jose Fonseca |
From: Brian P. <br...@tu...> - 2002-02-05 15:35:17
|
Jose Fonseca wrote: > > On Tue, 2002-02-05 at 14:50, James Hawtin wrote: > > Is there a guide on how to setup DRI? I have never managed to ... > > > > ... to go to the DRI website and search for documentation? ;-) > > Check http://dri.sourceforge.net/doc.phtml > > It covers most of your questions! > > > James > > > > Jose Fonseca The DRI compilation guide is out of date and that's been throwing people off. I'm putting "update the DRI compilation guide" on my to-do list. -Brian |
From: Karl L. <kle...@ma...> - 2002-02-01 15:59:41
|
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 support, or the DRM > gets the old IOCTL and performs the mapping the old way. > > Now, if all (or at least all the important parts) of the above is correct, > is there any reason why we should not move forward with this solution? At > first blush, there don't seem to be any horrible pitfalls, and I don't > really see any other way that will keep us out of trouble with Linus and > with our users. > > There is (at least) one remaining issue. In the case where a user has the > new 2D part and wants to use video capture but doesn't have a new enough > DRM, how do we effectively inform them? I don't think that just logging a > message to the X log / syslog is good enough. Is there any other way? > Could we do something perverted like "capture" a screen of text that says > "You must upgrade your DRM to use video capture"? :) > > -- > Tell that to the Marines! > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |