Jerome Glisse wrote: > On Fri, 16 May 2008 11:16:26 +0200 > Thomas Hellström <[EMAIL PROTECTED]> wrote: > >> Now if you want to map paging-capable VRAM, >> that's what the on-card VRAM aperture page table is for. You stated that >> it's a bad idea to use it. Why? >> > > If there is aperture page table than the solution you propose will work. > I was thinking here to GPU process virtual address space each associated > with their own page table. >
But isn't this really a way to avoid / handle relocations, that should be dealt with in the driver-specific execbuf call? What TTM does it to put the buffer somewhere in physical VRAM, and optionally sets up a user-space or kernel mapping to it. It assumes nothing about private context GPU mappings of the VRAM pages. That's really up to the driver to deal with. > > >> Could you describe what steps needs to be taken by the driver when the >> 2D driver wants to write a single pixel to the >> VRAM front buffer, with the pwrite approach, to ensure that the pixel >> ends up in the right location? >> > > For EXA i intend to favor upload/download from screen which use blit > to ram. Anyway if going through pwrite/pread path for doing that you > pread the proper page in which the pixel stands. Do the math. pwrite > the page back. Of course this is inefficient toward reading one dword > and writing it back. But there should not be any fallback on hw i am > interested in so i see this as an opportunity to not map vram and so > not have to worry about tlb flush, partial vram access through aperture > (i think on some hw more than half of the vram is unaccessible through > the aperture), cache coherency and cache policy on vram mapping. > > Cache coherency and caching policy is a non-issue with user-space VRAM mappings. I think with the pwrite approach you will run into severe performance problems if used for long-lived buffers. Think EXA, vertical lines, perhaps no tiling. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
