> 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.
Wouldn't this just end up reinventing the fenced bufmgr? Basically cached needs a list of all destroyed buffers (ideally in destruction order, so it can do the stopping optimization when expiring buffers), while the busy mechanism needs a list of all used buffers (destroyed or not) in usage order. So it seems it would need two lists, and essentially result in something that replicates fenced inside cached. BTW, right now I think all drivers use a single GPU context in userspace. Even Nouveau multiplexes Gallium contexts on a single channel (this is probably broken though). ------------------------------------------------------------------------------ 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
