Menu
▾
▴
Re: [PATCH] Clean up and document drm_ttm.c APIs. drm_bind_ttm -> drm_ttm_bind.
|
From: <th...@tu...> - 2007-12-21 12:21:19
|
Keith Packard wrote: >On Mon, 2007-12-17 at 21:07 +0000, Keith Whitwell wrote: > > >>Keith Packard wrote: >> >> >>>Here are some proposed cleanups and documentation for the drm_ttm.c APIs. >>> >>>One thing I didn't change was the name of drm_ttm_fixup_caching, which is >>>clearly a badly named function. Can anyone explain why you wouldn't just >>>always use drm_ttm_unbind instead? The only difference is that >>>drm_ttm_unbind makes sure the object is evicted before flushing caches >>>and marking it as unbound. >>> >>> >>Looks good Keith. There are a couple of places where you need >>s/flat/flag otherwise looking great. >> >> > >heh. thanks for the spelling fixes. > > > >>I can't help with the question above unfortunately... >> >> > > > Keith, This is purely an optimization. Buffers that are evicted due to a memory aperture space shortage ends up in a state where they are unbound from the aperture, but retain the uncached state assuming the next operation on them will be "validate". In that case they are just bound back. However, if they are instead accessed by the cpu, the caching state needs to be fixed up. Hence the name. The caching fixup is, as you know, a very costly operation. The test application here was "tuxracer" and heavy texture thrashing forced by an AGP aperture of 10-12MB. The frame rate should not show a noticable decrease compared to the no texture thrashing case. >Yeah, I'll leave it alone for now. If we can sort out that and the whole >ttm_bo_handle_validate -> ttm_bo_do_validate -> >ttm_buffer_object_validate chain, I'd feel better about that part of the >code. > > drm_bo_handle_validate() needed to be split for the superioctl, and drm_bo_do_validate() was created. It's possible this can be simplified. >Now I'm puzzling through the fence portions, and trying to figure out >why the flushing code is so mystic. > > The fencing system needs to make sure the EXE TYPE flag of the fence has signaled before trying to determine whether other fence TYPE flags are signaled as well. Two typical applications that need to be taken into consideration: 1) Intel read/write sync flushes must be issued after the EXE TYPE flag has signaled, so we flush the correct operation. This was implemented and optimized for the case where the kernel needed to evict a texture (read flush) and didn't want to wait for the flush operation to pass down the command queue, effectively causing a command queue flush and 3D engine idle. As discussed before we ended up not using the sync flush code... 2) Unichrome type hardware: To guarante for example HighQualityVideo engine idle, the EXE type fence must have signaled, and the engine must signal HQV engine idle using a hardware flag. .. So if the caller for example wants to wait for a Intel read type fence to signal, the code must first make sure the EXE flag has signaled, then and only then it indicates to the device dependant code that a flush is needed, and either sleep-waits or polls the device dependant code for flushing to complete. Hope this clarifies things a little. /Thomas > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------- >SF.Net email is sponsored by: >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services >for just about anything Open Source. >http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > >------------------------------------------------------------------------ > >-- >_______________________________________________ >Dri-devel mailing list >Dri...@li... >https://lists.sourceforge.net/lists/listinfo/dri-devel > > |