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.
best
Vladimir Dergachev
>
> --
> 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: Take your first step towards giving
> your online business a competitive advantage. Test-drive a Thawte SSL
> certificate - our easy online guide will show you how. Click here to get
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
