[ Finally got some debugging time for the other DRI problem I've seen,
namely hugely flashing textures in tuxracer on i830, but _only_ iff MTRR
support is compiled into the kernel ]
On Wed, 14 May 2003, Linus Torvalds wrote:
>
> reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
> reg01: base=0x3f800000 (1016MB), size= 8MB: uncachable, count=1
> reg02: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=2
I added some debugging code to print out the memory ranges as mapped by
the X server, and it maps this WC area two different ways: some parts end
up being mapped with "map->type" being 0 (_DRM_FRAME_BUFFER), and other
parts being mapped with "map->type" being 3 (_DRM_AGP).
For the i830, there should be absolutely no difference between these two
types: they are exactly the same as far as the hw is concerned, one is
just pre-allocated by the BIOS.
HOWEVER, we do very different things for them in drm_vm.h:
if (boot_cpu_data.x86 > 3 && map->type != _DRM_AGP) {
pgprot_val(vma->vm_page_prot) |= _PAGE_PCD;
pgprot_val(vma->vm_page_prot) &= ~_PAGE_PWT;
}
if for _DRM_AGP memory (the high part of the "frame buffer"), we will mark
the mapping cacheable. Which sounds really wrong, considering the fact
that the MTRR has marked it as being WC.
Comments?
(I don't have direct access to the machine right now, so I can't test
whether just doing the above unconditionally can help, but it looks like a
bug either way. It just fundamentally cannot be right to consider part of
the AGP aperture as doing something different on an i830 setup)
[ Also, can somebody tell me why ADVANCE_LP_RING() doesn't need a
DRM_WRITEMEMORYBARRIER() before updating the ring pointer? I _assume_
it's actually correct simply because we know that intel will always
flush the write queue before doing a uncached write, and nobody else
ever uses this chipset? Even so, that sounds like something that might
change in future Intel chips.. ]
Linus
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
