El Sáb 20 Oct 2001 17:54, Leif Delgass escribió: > > I have a remaining problem. I have nowere defined AGP_APER_SIZE_MASK, so, > > I've added the definition to the atiregs.h file: > > > > AGP_APER_SIZE_MASK 0x0000003ful > > Yeah, that's right. Sorry, I forgot about that. As Gareth said, I think > the card can use either 8 or 16 Megs of AGP memory. My card is the 8M > variety, but I think there are some that have 16M. > > I agree about getting this into CVS. Since your patch is against the > current CVS, I think we should start by tagging a new branch > (mach64-0-0-2-branch) from the HEAD and applying the patch. The CVS > policies page has instructions on starting a new branch. Keith Whitwell > offered to set up CVS access, so I guess we'll need a list of sourceforge > IDs (mine is 'ldelgass'). I'm also on a dialup at this point, but once > you have a full tree checked out it's not too painful to update.
OK. Mine is 'mteira'. So we need to tag a new branch from the trunk: cvs rtag -b mach64-0-0-2-branch Checkout it again: cvs co -b mach64-0-0-2-branch Apply our patch over this checkouted branch. patch -p0 < here-the-patch-name And finally, update the branch with this code: cvs update -r mach64-0-0-2-branch So, do you think this is the best way? I've written all the commands for you to check them, I've never made it before. > > Then it's really a question of identifying what needs to be done and > dividing up the work. I'm still trying to familiarize myself with the > various parts of the driver and looking at the Utah and r128/radeon code, > and I have the programmer's guide without the 3D stuff. Since it may take > me a little while to get up to speed, I'd be happy doing bug hunting and > submitting small patches via the list if CVS accounts are limited. I > think the key is to keep the discussions going and to make sure we don't > duplicate work. I think that I'm in the same conditions than you are. To say the truth, the work I've made in the mach64 DRI have been very little (in quantity, but not in time). The adaptation to the DRI trunk was only a question of patience and care and the DMA question was also a question of observation (and never based in my experience). So, it would be nice if someone really familiar with the DRI trunk could help in this development. Perhaps Gareth Hughes and Frank Earl, that has fighted the Mach64 for a long time, if they were not too busy. Anyway, I also can try, but the progress will be slower (anyeway late will be better than never). Perhaps the first task, as I said before, will be taking out the MACH64_WRITE accesses made from the Mesa library. For that, I suppose that we have to setup some DMA buffers from the DRI driver (there is already a DRI framework to deal with this issues, I think). I'm studing the R128 DRI driver and Mesa part to see how to made this. Anyway, I'm not ready yet to make this work. If any other person feel more qualified or with the needed knowledge to make it, please, go for it. Best regards. -- Manuel Teira _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
