Eric Anholt wrote: > On Fri, 2008-02-29 at 16:03 +0100, Thomas Hellström wrote: > >> Hi. >> >> I've pushed the intel-post-reloc branch with the following stuff: >> >> 1) Full backwards compatibility. >> 2) A new reloc type 1, which is applied _after_ all validations and with >> slightly different format. >> 3) If the buffer is idle, type 1 relocations are performed using the new >> kmap_atomic_prot_pfn if it's available. >> 4) If the buffer is busy, It's never mapped, and relocations are >> performed using a single dword 2D blit, and we never have to idle the >> buffer. This comes at a cost of an additional single MI_FLUSH after all >> blit-relocations have been performed. >> >> This could help avoid pre-validation relocation processing, race >> conditions due to the relocatee not being on the unfenced list when >> relocs are applied and unnecessary buffer idling. >> > > What are the performance results of using this? We've thought about > doing this before, but cworth's experiments with it in the 2d driver > were supposedly not too impressive. (but then, applying relocations to > currently in-flight buffers is sufficiently rare I think that it > probably doesn't matter) > I've tried this only with a patched version of the old i915tex driver and the cost of applying relocations for typical 3D use seems to be very small. Can't see any big performance- or CPU usage impact when I turn off the PRESUMED_OFFSET hint. However, re-running the relocation application 100 times per batch-buffer made gears framerate drop from 1050 or so to around 800. System cpu up from 14 to 40, so there is an impact. (These were kmap-applied relocs, not blitted ones). For blitted relocations, It's hard to tell, except that if they're forcefully used for applications like gears, there's no visible negative impact on framerate when swhitching off PRESUMED_OFFSET.
/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
