> I have some doubts about this patch though. It is impossible to satisfy > both DONTBLOCK and UNSYNCHRONIZED flags simultaneously, so the result of > specifying both is implementation dependent. Why should UNSYNCHRONIZED > be favored over DONTBLOCK?
I think that is the correct choice given the current codebase. In particular, vbo_exec_draw.c uses GL_MAP_UNSYNCHRONIZED_BIT | MESA_MAP_NOWAIT_BIT, which the Gallium state tracker translates to PIPE_BUFFER_USAGE_UNSYNCHRONIZED | PIPE_BUFFER_USAGE_DONTBLOCK. It uses that because it is using the buffer in subparts and knows that it never submitted the part it is writing to. Thus, in this case, UNSYNCHRONIZED should be favored. I think it also makes more sense to do things this way as DONTBLOCK doesn't intuitively mean "tell me if the buffer is used by the GPU by failing", but rather "avoid waiting and fail instead if necessary". Thus, if UNSYNCHRONIZED is specified, DONTBLOCK can be satisfied by ignoring it. ------------------------------------------------------------------------------ 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
