Re: breaking the ATI closed source driver...
Dave Airlie wrote: Hi all, I'm just wondering do we have a general feeling from a DRI perspective on breaking the ATI driver (which is DRI based) from a drm point of view, From a kernel POV it isn't an issue, it seems to be an idea to break em every so often just to keep them on their toes... but the DRM restructing code will break their DRM module I think, I'm just wondering should I bother worrying at all.. Why do you feel it will break their code? If it does, they have the option to either update their driver to match the new code or fork off the old code & continue to use that. I wouldn't be suprised if they've already constructed a fork at some point, as they seem to have done so for the rest of the code. Keith --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
> > Why do you feel it will break their code? If it does, they have the option to > either update their driver to match the new code or fork off the old code & > continue to use that. I wouldn't be suprised if they've already constructed a > fork at some point, as they seem to have done so for the rest of the code. Well I think some of their code may try and use the stub interfaces and the like and we'll change how they work.. what I think we can do is if we modify how the stub hooking works we just use different names .. they also made a mistake in their distro where they include drm.h from the kernel which there is no need for they should distribute their own.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
Dave Airlie wrote: Why do you feel it will break their code? If it does, they have the option to either update their driver to match the new code or fork off the old code & continue to use that. I wouldn't be suprised if they've already constructed a fork at some point, as they seem to have done so for the rest of the code. Well I think some of their code may try and use the stub interfaces and the like and we'll change how they work.. what I think we can do is if we modify how the stub hooking works we just use different names .. they also made a mistake in their distro where they include drm.h from the kernel which there is no need for they should distribute their own.. Well... however they are working, they're grown-up enough to deal with the evolution of our codebase one way or another. Unless they actually make some comment I don't think we need to try and guess what might or might not be convenient for them. Keith --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
Dave Airlie wrote: Hi all, I'm just wondering do we have a general feeling from a DRI perspective on breaking the ATI driver (which is DRI based) from a drm point of view, The ATI proprietary driver *IS* broken right now - I am running FC2, with X updated from the mainline Xorg CVS, and just bought a 9600 to replace my aging 7500. The flgrx driver from ATI segfaults inside PictureInit. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
David D. Hagood wrote: Dave Airlie wrote: Hi all, I'm just wondering do we have a general feeling from a DRI perspective on breaking the ATI driver (which is DRI based) from a drm point of view, The ATI proprietary driver *IS* broken right now - I am running FC2, with X updated from the mainline Xorg CVS, and just bought a 9600 to replace my aging 7500. The flgrx driver from ATI segfaults inside PictureInit. Interesting but unlikely to be related to drm changes, first and foremost as the driver you are using won't contain any of the changes that Dave is talking about. If ATI ever picks up these changes, it will be up to them to validate that their code works with the rework to the DRM - which will probably be a simple task. I hope this thread doesn't start some misconception that these changes are breaking an existing binary interface - because one doesn't exist! Though this is precisely my argument against introducing one in the form of a split core/subdriver model for DRM. Keith --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
Keith Whitwell wrote: Interesting but unlikely to be related to drm changes, first and ... I hope this thread doesn't start some misconception that these changes are breaking an existing binary interface - because one doesn't exist! Though this is precisely my argument against introducing one in the form of a split core/subdriver model for DRM. That was not my intention, rather my intention was to demonstrate that, regardless of DRM changes, the ATI proprietary driver is broken now - therefor concern about DRM changes breaking it are currently irrelevant. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
David D. Hagood wrote: Keith Whitwell wrote: Interesting but unlikely to be related to drm changes, first and ... I hope this thread doesn't start some misconception that these changes are breaking an existing binary interface - because one doesn't exist! Though this is precisely my argument against introducing one in the form of a split core/subdriver model for DRM. That was not my intention, rather my intention was to demonstrate that, regardless of DRM changes, the ATI proprietary driver is broken now - therefor concern about DRM changes breaking it are currently irrelevant. OK fair enough. Sorry for the misunderstanding. Keith --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
On Sun, Aug 29, 2004 at 08:48:32AM -0500, David D. Hagood wrote: > Dave Airlie wrote: > >Hi all, > >I'm just wondering do we have a general feeling from a DRI > >perspective on breaking the ATI driver (which is DRI based) from a drm > >point of view, > > > > The ATI proprietary driver *IS* broken right now - I am running FC2, > with X updated from the mainline Xorg CVS, and just bought a 9600 to > replace my aging 7500. The flgrx driver from ATI segfaults inside > PictureInit. If you're using the Fedora kernel, it could be a number of things. It could be a 4K stacksize issue, like what bit the nvidia driver. Or it could be their bastardised agpgart implementation not playing nicely with the not-built-as-a-module agpgart in the kernel. Or it could be any number of other things. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
Dave Jones wrote: If you're using the Fedora kernel, it could be a number of things. It could be a 4K stacksize issue, like what bit the nvidia driver. Or it could be their bastardised agpgart implementation not playing nicely with the not-built-as-a-module agpgart in the kernel. Or it could be any number of other things. I fell back to XF4.3, and the driver doesn't segv at start - this would tend to eliminate the kernel issues. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
> I fell back to XF4.3, and the driver doesn't segv at start - this would tend > to eliminate the kernel issues. I got someone to open Xorg bug 1249 on irc.. let Xorg sort it out :-) Dave. > > > --- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
On Sun, 2004-08-29 at 11:41 +0100, Keith Whitwell wrote: > Dave Airlie wrote: > >>Why do you feel it will break their code? If it does, they have the option to > >>either update their driver to match the new code or fork off the old code & > >>continue to use that. I wouldn't be suprised if they've already constructed a > >>fork at some point, as they seem to have done so for the rest of the code. > > > > > > Well I think some of their code may try and use the stub interfaces and > > the like and we'll change how they work.. what I think we can do is if we > > modify how the stub hooking works we just use different names .. > > > > they also made a mistake in their distro where they include drm.h from the > > kernel which there is no need for they should distribute their own.. > > Well... however they are working, they're grown-up enough to deal with the > evolution of our codebase one way or another. Unless they actually make some > comment I don't think we need to try and guess what might or might not be > convenient for them. I'd agree on that. As some of you know already, I have a fulltime job at ATI's Linux team now. I'll continue being active in the DRI and X communities as time permits. If you have any development related questions or suggestions about the proprietary ATI drivers, please don't hesitate to contact my manager Matthew Tippett <[EMAIL PROTECTED]> and CC me at [EMAIL PROTECTED] -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
> > As some of you know already, I have a fulltime job at ATI's Linux team > now. I'll continue being active in the DRI and X communities as time > permits. If you have any development related questions or suggestions > about the proprietary ATI drivers, please don't hesitate to contact my > manager Matthew Tippett <[EMAIL PROTECTED]> and CC me at [EMAIL PROTECTED] Good someone who knows the DRI could really help them I'd say.. if you have any ideas for drm or anything like that feel free to ask, I personally have no problems with making closed source drivers on the DRM work as well as possible... and any suggestions from ATI or whomever will be taken on board at the same level... and if that r300 spec ends up in the dumpster Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
On Fri, Sep 03, 2004 at 01:11:54AM -0400, Michel Dänzer wrote: Hi Michel, > > Well... however they are working, they're grown-up enough to deal with the > > evolution of our codebase one way or another. Unless they actually make some > > comment I don't think we need to try and guess what might or might not be > > convenient for them. > > I'd agree on that. > > As some of you know already, I have a fulltime job at ATI's Linux team > now. I'll continue being active in the DRI and X communities as time > permits. Congrats, hope you'll do some good things there. > If you have any development related questions or suggestions > about the proprietary ATI drivers, please don't hesitate to contact my > manager Matthew Tippett <[EMAIL PROTECTED]> and CC me at [EMAIL PROTECTED] I'd really like to see the day arrive when third party vendors don't have to ship their own agpgart implementations at all. I've heard three possible reasons in the past explaining the reasoning behind why vendors feel the need to ship their own :- 1. 'We want to support every kernel out there, and old kernels dont have an up to date agpgart driver'. This is totally bogus IMO, as end users should be *encouraged* to be running something recent anyway. Take for example ATi's current driver. It has binary modules for the following Red Hat kernels.. 2.4.18-17.7 2.4.18-17.8 2.4.20-8 2.4.20-8bigmem 2.4.20-8smp 2.4.20-28.8 2.4.20-28-8.bigmem 2.4.20-28.8-smp 2.4.20-28.9 2.4.20-28.9-bigmem 2.4.20-28.9smp All of these kernels have known security problems, which were subsequently fixed in later errata kernels. (The final for Red Hat 7 & 8 was 2.4.20-24.7/8 I believe. Encouraging use of 2.4.18 is a *bad* idea. These users really need to be upgrading. Likewise, RHL9's final errata kernel was at 2.4.20-30.9 (The Fedora-legacy project has also since released a 2.4.20-35.9 I believe). Encouraging the use of ancient kernels with known problems isn't going to do the name of Linux as a secure operating system any favours. 2. 'The in-kernel AGPGART doesn't have all the features our driver requires'. Newsflash: I take patches. Sifting through the ATI mashed-up agpgart is quite painful, as there are so many changes in there ifdef'd to hell and back that its hard to see whats really needed and what isn't. So, lets talk. Tell me what you need from the kernel GART driver. If it makes sense, I'll merge patches in a heartbeat. 3. "Our binary part has workarounds for various chipset/card combinations that we'd rather weren't public" Great, so having users who use the in-kernel gart scratch their heads when cards lock-up for no reason, and then think 'ati sucks, I'm only buying nvidia from now on' is better than being open and explaining incompatibilities ? We all know hardware isn't perfect. Lets work around it, and move on, rather than hide these secrets away. >From what I gather the bulk of these workarounds are of the form 'fast writes dont work in this mode' etc, which really is trivial stuff given the negligable benchmarking difference these seem to make anyway. Of the three binary vendor drivers I've looked at (Matrox Parhelia, NVIDIA, ATI) the only ones who seem to actually document workarounds and such is Matrox. There are some clues in the ATI driver too (amusingly, including Matrox workarounds) but I'd really like to see these written cleanly, without ifdefs, and with an explanation as to what the hell is going on, so we know why we're poking random bits of config space for 'compatability reasons'. Finally, pushing all these little bits back upstream is going to make *your* lives easier too. You'll no longer have to worry about this huge chunk of code, and making it work everywhere. You'll gain further independance against what kernel your driver is running against. Your users won't have to worry about whether agpgart is built-in or modular. (This is a real pain for Fedora/RHEL users, as we make it built-in so that things like the amd64 IOMMU, and framebuffers that use agp mappings work correctly). What do I get out of this ? A smaller inbox from users mailing me that 'I used the ati driver, and agpgart blew up, its your fault'. Or at least, if I do continue to get those mails and agpgart blows up, it's more likely it *will* be my fault. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
Dave Jones wrote: 2. 'The in-kernel AGPGART doesn't have all the features our driver requires'. Newsflash: I take patches. Sifting through the ATI mashed-up agpgart is quite painful, as there are so many changes in there ifdef'd to hell and back that its hard to see whats really needed and what isn't. So, lets talk. Tell me what you need from the kernel GART driver. If it makes sense, I'll merge patches in a heartbeat. (I'm about to show total ignorance of how agpgart works. Beware!) One problem I've always had with AGP support on Linux is that when you have a 256MB aperture, that consumes 256MB of physical memory, whether it's being actively used or not. In the future, it would be nice if drivers that use AGP could do something more dynamic. At the very least, not having physical pages backing part of the aperture until needed would be great. Ideally a driver could say, "I want this page to back this part of the aperture." That would make things like APPLE_client_storage or ARB_vertex_buffer_objects truly zero-copy. In fact, I think that's how it works on OS X. I seem to recall some discussions a few years ago about why this is difficult on x86, but I don't remember the reasons. I can still dream. :) Finally, pushing all these little bits back upstream is going to make *your* lives easier too. You'll no longer have to worry about this huge chunk of code, and making it work everywhere. You'll gain further independance against what kernel your driver is running against. Your users won't have to worry about whether agpgart is built-in or modular. (This is a real pain for Fedora/RHEL users, as we make it built-in so that things like the amd64 IOMMU, and framebuffers that use agp mappings work correctly). Sounds like what I've been saying about libGL.so for years. :) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
Ian Romanick wrote: Dave Jones wrote: 2. 'The in-kernel AGPGART doesn't have all the features our driver requires'. Newsflash: I take patches. Sifting through the ATI mashed-up agpgart is quite painful, as there are so many changes in there ifdef'd to hell and back that its hard to see whats really needed and what isn't. So, lets talk. Tell me what you need from the kernel GART driver. If it makes sense, I'll merge patches in a heartbeat. (I'm about to show total ignorance of how agpgart works. Beware!) One problem I've always had with AGP support on Linux is that when you have a 256MB aperture, that consumes 256MB of physical memory, whether it's being actively used or not. In the future, it would be nice if drivers that use AGP could do something more dynamic. At the very least, not having physical pages backing part of the aperture until needed would be great. Ideally a driver could say, "I want this page to back this part of the aperture." That would make things like APPLE_client_storage or ARB_vertex_buffer_objects truly zero-copy. In fact, I think that's how it works on OS X. I seem to recall some discussions a few years ago about why this is difficult on x86, but I don't remember the reasons. I can still dream. :) This sort of stuff motivated the design of the agpgart interface from the beginnning. It was an attempt to allow every possible perversion of this idea, as proposed/demanded by various vendors, that led to the quite complex interface that agpgart ended up with. (For some reason I remember XiG as being one of the most strident...) Some irony then that most vendors end up not using it, and that the opensource drivers don't make use of the complexities of the interface... In other words, I'm pretty sure agpgart can do this stuff already - you just need to wrap your mind around the interface. Keith --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
