Re: DRM memory manager on cards with hardware contexts

[Thomas Hellström]

Benjamin Herrenschmidt wrote: On Tue, 2006-09-19 at 12:49 +0200, Thomas Hellström wrote: Benjamin Herrenschmidt wrote: On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: But this should be the same problem encountered by the agpgart driver? x86 and x86-64 calls change_page_attr() to take care of this. On powerpc it is simply a noop. (<asm/agp.h>) Possibly. We sort-of ignore the issue for now on PowerPC and happen to be lucky most of the time because 32 bits PowerPC aren't that agressive at prefetching... I haven't looked at change_page_attr() implementation on x86 but I know they also map the linear mapping with large pages. I don't know what happens if you start trying to change a single page attribute. x86 can breakup that large page into 4k pages, so maybe that's what happens. Yes, I think that's what happens. I know some Athlon chips had a big issue with this some time ago. I notice there are special functions in <agp.h> to alloc / free GATT pages, so the general idea might be to have a pool of uncached pages in the future for powerpc? Even better would perhaps be to have pages that aren't mapped for the kernel. (like highmem pages on x86). Yes, that's exactly what I'm thinking about doing. However, this is only a problem for AGP. Right. For objects that are in video memory but can also be moved back to main memory (what I call "evicted") under pressure by the memory manager, one thing I was wondering is, do we have to bother about cache settings at all ? I don't think so. We are not doing vram yet in the TTM code, but I think a general "eviction" would consist of 1) locking mmap_sems for all processes mapping the buffer. 2) zap the page table. Any attempt to access will be blocked by mmap_sem in nopage(). 3) Copy contents from vram to system using either PCI SG or video-><blit>->AGP-><flip>->system. 4) Wait for completion. 5) release the mmap sem. The page table will be refilled using nopage(). A copy back might be more efficient since in come situations we don't have to wait for completion (If the copy is done using the command queue.) Intel chips for instance have the possibility to flip cached pages into AGP for use with the video blitter. That is, have them mapped non-cacheable when in vram and cacheable when in main memory. Is there any reason why there would be a problem with userland having the same buffer being sometimes cacheable and non-cacheable ? I don't think so as long as userland isn't using cache tricks and whatever primitive is used to do the copy to/from vram properly accounts for it. I agree. Ben. /Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel