map user space memory as gart memory for intel integrated graphics chip

[Austin Yuan]

On 12/8/05, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
> On Iau, 2005-12-08 at 19:52 +0800, Austin Yuan wrote:
> > buffer. Because the interface of "alloc_by_type" only receives a
> > simple parameter "type", here I hide the user space address into
> > "type" and re-get it in alloc_userspace_memory.
>
> That should probably be fixed by extending the API to pass both
>
> > I use this interface to easily implement XAA readpixmap/imagewrite
> > driver interfaces, and get a better performance. Here, I didn't attach
> > the patch for i810 driver. I just want to get some comments about it,
> > and if you think it makes sense, I'd like to make it more generic.
> >
> > Any comments are appreciated, thanks.
>
>
> The one thing I don't understand looking at this is that I understood
> AGP pages should be marked uncached. However user space pages may exist
> in many mappings and the CPU also requires all mappings of a page are
> consistent.
>
> Does i8xx need the page uncached or is it enough to wbinvd the pages in
> question on writing and invalidate them before reading, or does the i8xx
> in fact take full part in the cache coherency ?


I read through the spec, and just get a rough concept and don't
understand very well about it.

The mapping of gart memory has two types, one is non-snooped, and
another is snooped. Intel Linux gart driver only uses non-snooped
type, and the meaning is that physical address backing the gart
targets non-snooped main memory. My experiment uses this type. For
snooped memory, it targets cacheable main memory (cause snoop on
processor bus). I haven't understood the explanation about it. It says
this type memory must not be targeted by the processor through
graphics memory range, and such accesses will not be snooped after
translation. And accesses via instruction stream are permitted, yet
treated as unsnooped main memory. This removes restrictions regarding
instruction stream overfetches into dissimilar graphics memory region.


>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>