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. > 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. Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
