On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca <jfons...@vmware.com> wrote:
> Dave,
>
> I don't oppose this new method -- it shouldn't be necessary to add fencing
> just to use pb_cache --, but this method adds a new way of doing the same
> thing.
>
> Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what
> about doing:
>
> boolean
> pb_cache_is_buffer_compat()
> {
> void map;
>
> map = pb_map(buf->buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER);
> if (map) {
> /* TODO: cache the map value for the first map */
> pb_unmap(buf->buffer);
> return TRUE;
> }
>
> return FALSE;
> }Hi Jose I've used your scheme but I'm not sure 100% of its correctness since we might expect different behaviour from maps that are referenced in flushed command streams and maps referenced in the current command stream. I've pushed the r300g bits that do it correctly and we haven't seen any regressions. So my next bit is to bail out after is_busy check to avoid kernel overheads for checking all the buffers, but I'm a bit worried it might change behaviour of the fenced/cached use case, so I'd appreciate a bit of a review of it. If this isn't possible I'm tempted to create pb_bufmgr_busy_cached and do it all there, I think nouveau could use something similiar. Dave.
0001-gallium-add-is_busy-flag-to-cached-bufmgr.patch
Description: Binary data
------------------------------------------------------------------------------ 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
