On Mon, Jun 23, 2003 at 10:41:00AM +0100, Keith Whitwell wrote: > José Fonseca wrote: > >On Mon, Jun 23, 2003 at 08:20:31AM +0100, Keith Whitwell wrote: > > > >>José Fonseca wrote: > >> > >>>The Gamma DRM driver is quite peculiar in several aspects. I'd like to > >>>know if those differences are result of experiments which might be worth > >>>to generalise to other drivers or if instead it's mostly deprecated and > >>>should be made more equal to the others. > >> > >>It is mostly deprecated and should be made more equal to the others. > >> > >> > >>>For one instance, the Gamma is the only one uses the freelists which the > >>>source of other drivers refer it would be used there too. On the other > >>>hand most of the gamma source duplicates source in the DRM templates. > >> > >>Hmm -- for a long time there was #if __HAVE_OLD_DMA in the drm templates, > >>giving a more complex dma engine. The gamma driver was the only one to > >>define it and I recently moved that code into gamma_* files -- so now it > >>probably does look like duplication. > >> > >> > >>>The current oddity situation is not very convenient since it limits the > >>>kind of changes (either janitorial or architectural) one can do without > >>>breaking the gamma driver. > >> > >>The alternatives are 1) fix the gamma driver (hard) or 2) fork the gamma > >>driver off - move everything it needs into a gamma_*.[ch] file and > >>continue developing everything else independently. > >> > >> > >>>I for one want to write a general API for DMA buffer pools to be shared > >>>by all drivers, but I need some advice concerning what my position > >>>towards the Gamma source code should be. > >> > >>I'd like to just remove the whole driver, but unfortunately it doesn't > >>seem to be an option. With a card it should only be a week or two's work > >>to get it in line with the other drivers, or seperating it from the other > >>drivers would take a day or two, but be messier. > > > > > >Well I wouldn't want to remove the driver as a matter of principle - we > >already support a small subset of the existing 3D cards and I wouldn't > >want to see that number further reduced. Seperating it from the other > >drivers would indeed be very messier and difficult to maintain in the > >future. > > > >So what I'm going to do is to focus on the all other drivers now and in > >the end get the gamma in line with them. It's not feasible to do make > >this while keeping binary compability (the gamma driver even exposes > >read interface for the file), i.e., the driver will refuse to work with > >previous versions. This shouldn't be a problem attending the appereantly > >very low number of users of this driver. > > > >BTW, do we have a owner of such card among the subscribers which can do > >some testing when the time comes? > > I think Alan Cox. Alan Hourihane had one, but I think it died -- I find it > very hard to keep gamma details in my head for some reason.
Yes. My GMX2000 board died a while ago, although I have another board but it only has a single MX rasterizer whereas the GMX2000 has dual MX's. Alan. ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
