On Sat, Mar 13, 2010 at 4:33 AM, Luca Barbieri <luca.barbi...@gmail.com> wrote: > Actually, why is the state tracker doing the min/max computation at all? > > If the driver does the index lookup itself, as opposed to using an > hardware index buffer, (e.g. the nouveau drivers do this in some > cases) this is unnecessary and slow. > > Would completely removing the call to vbo_get_minmax_index break anything? > > Also, how about removing the max_index field in pipe_vertex_buffer? > This seems to be set to the same value for all vertex buffers, and the > value is then passed to draw_range_elements too. > Isn't the value passed to draw_range_elements sufficient? >
It's really only needed for the special (but common) case where the vertex data isn't in a GL VBO at all, but just sitting in regular memory. The state tracker currently has the task of wrapping those regions of memory in user_buffers, and needs this computation to figure out what memory to wrap in that way. User buffers are a useful concept for avoiding a data copy, and can be implemented one of three ways in the driver: a) for drivers doing swtnl, just access the wrapped memory directly b) for drivers with hwtnl but unsophisticated memory managers, upload the userbuffer contents to a real buffer, then use that. c) for drivers with sophisticated memory managers, instruct the kernel to allow the hardware to access these pages directly and do whatever memory management tricks necessary to avoid the contents being clobbered by subsequent CPU accesses. It's a difficult trick to avoid extra data copies in a layered stack like gallium, and user_buffers are an attempt to avoid one source of them. But for any such technique, the mesa state tracker will need to figure out what memory is being referred to by those non-VBO vertex buffers and to do that requires knowing the index min/max values. Keith ------------------------------------------------------------------------------ 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
