On Wed, Mar 20, 2002 at 11:27:39PM +0000, Michael wrote: > On Wed, Mar 20, 2002 at 01:51:06PM -0800, Ian Romanick wrote: > > > Michael also implemented agp support for radeon with a similar simplistic > > > strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think > > > these turned out to be artefacts rather than anything serious. In any case I > > > think he decided to wait on some forthcoming reorganization of the texture > > > management code in all the drivers... (nudge nudge, wink wink) > > > > Heh...which is actually why I was asking. :) There are a number of code > > paths in my code that I can't test on the Radeon (one of my two development > > platforms) without AGP texturing. > > That's confusing, since 'AGP' is really already there, it's not enabled as such, > you just allocate from the RADEON_AGP_HEAP instead of the RADEON_CARD_HEAP. > (Confusing because if your code replaces the mm in the radeon driver, > you'll be writing the code you're asking to be committed?) > > The fix for current code (in all trunks afaiaa) is that > RADEON_AGP_TEX_OFFSET is 0x02000000 and it should be 0x04000000 (at > least on my radeon - I don't know what that does to 64mb radeons, > 7500's, mobilities etc? - the 0x02000000 figure is left over from the > r128 by the looks of it, so perhaps it is a constant?) > > Beyond that, there's no magic that I found that needs to be done, so you > can ignore the 'fixup agp texture offset' that's in the #if 0 part of > radeon_texmem, you just add the mmAlloc offset to the heap offset in the > same way card local textures are done. This is the part that needs fixing. Looking back at the mailing list archives, if the code that's '#if 0'ed out is re-enabled, the driver will happily allocate AGP memory and explode. Since this is device-dependent, it doesn't really fall directly into the work that I'm doing now (see below). In any case, I'll find the patch and take a look at it.
I mainly wanted to make sure that the version sent out to the list is the "latest" version. > The patch is in the archives of this list so you could grab that > (next to nothing has changed in this area in TCL) I can probably dig it > up if you can't find it. > > That said, I've been implementing utah-glx swapping c/w AGP texturing in > a way that only the overrun goes into AGP even as these messages > arrived. It sounds like you are doing much the same...which is a waste > of one of our efforts - are you saying that IBM are letting you release > your code now? There was quite a bit if discussion about this at the 3/18 IRC meeting, but I'll recap. I do not have permission to release any code /yet/. We are still going through our internal process to get approval from legal to make source code contributions to the DRI project. That said, I personally believe that it is only a matter of time until this approval is given. I have been working for some weeks on this project, but I have been very quite about what I'm doing. The main reason for my silence is to avoid "when can we see your code?" type questions, because I would not have any answers. I have been working to factor out the /existing/ texture management code from the existing drivers. I've been using the MGA and Radeon drivers as my proof-of-concept cases. Once that is done, ANYONE can easilly experiment with different texture memory management schemes. -- Tell that to the Marines! _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
