On Mit, 2003-01-15 at 01:34, Vladimir Dergachev wrote: > On Tue, 15 Jan 2003, Michel [ISO-8859-1] Dänzer wrote: > > > On Die, 2003-01-14 at 23:54, Vladimir Dergachev wrote: > > > > > > Mike, what do you think about setting up a separate (entire) tree > > > someplace else like SF ? > > > > > > The reason I am thinking about it is that it looks like I finally fixed > > > the problem that GATOS memory controller changes induced in DRI Mesa > > > driver. The fix is simple but it is not likely to merged anytime soon into > > > either XFree86 or DRI trees as it breaks compatibility with older modules. > > > > I'm confident that we can find a solution for this which provides > > backwards compatibility or at least prevents the worst failure > > scenarios. Let's work together on integrating this into the DRI tree. > > > > Well, the easiest way to explain the solution (non-compatible with older > modules) is to add a field "mem_base" to the struct with other fields like > frontOffset and backOffset. > > The current driver behaves as if this field was set to 0. > > GATOS driver sets its to physical location of PCI aperture as seen from > the CPU side, though it can be set to anything as long as the following > domains do not interesect with system RAM. > > MC_FB_LOCATION is set to mem_base to position framebuffer memory starting > with mem_base from the point of view of Radeon's memory controller. > > MC_AGP_LOCATION is set to mem_base + sizeof of video aperture (which is > typically larger than the framebuffer). > > After these changes membase is used to follows: > > * mem_base is added to frontOffset, backOffset and depthOffset when used > in CP stream > > * mem_base is added to all texture offset references (which are > presumably in either video or AGP memory) > > * mem_base is added to offset of anything that is in AGP memory > (like indirect or index buffers) > > * mem_base is written into a few of other registers (DISPLAY_BASE and an > overlay one... don't remember offhand) that specify location in video > memory. Note: the naming of such registers is not consistent. Some > are true offsets, i.e. MC_FB_LOCATION is added by hardware and some are > not. > > * DRI Mesa drivers use regular offset (and not offset+membase) for > reading pixels from the framebuffer - this is the bug that I fixed > recently. > > Current GATOS implementation does not use mem_base as a separate field > as I did not want to mess with struct declaration (I have not been able to > pinpoint where it is and how it is distributed between various parts of > DRI infrastructure). Instead, I used the fact that frontOffset in > regular XFree86 driver is hardcoded to be always 0. So if one implements > the scheme above it is possible to recover membase by looking at the value > of frontOffset. A hack, of course, - but it works.
A patch would probably help me understand this better, but basically it sounds to me like it shouldn't be too hard for the new DRM to support new and old X servers. Supporting old 3D drivers with the new scheme might be harder I guess. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
