On Tue, Mar 9, 2010 at 11:30 AM, Luca Barbieri <luca.barbi...@gmail.com> wrote: >> The fencing solution isn't near as efficent from what I can see, as it >> is designed around fences not buffer busy, I'll see if I can give it a try, >> but I suspect it look and smell like a hack. > > The problem I see is that while fenced is guaranteed to make at most > one fence_signalled query for a busy buffer per allocation, cached > could potentially query the busy status of _all_ destroyed buffers for > every allocation. > > The reason of this is that fenced orders the buffers in fence order > and stops at the first busy one, only handing them to the lower layer > (e.g. cached) once they are no longer busy. > > If kernel calls are used instead of userspace fencing, the problem > probably gets worse. > > So IMHO it should be much more efficient to use fenced over cached > (perhaps with slab between them too). >
We can do this optimisation with busy as well. As long as you add things to the busy list at the end, and stop testing after the first busy call. At least for a single linear GPU context, which is all I expect this code will ever be handling. Dave. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
