On Sat, Mar 13, 2010 at 11:40 AM, Luca Barbieri <luca.barbi...@gmail.com> wrote: >> 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. > > Isn't the min/max value only required to compute a sensible value for > the maximum user buffer length? (the base pointer is passed to > gl*Pointer)
Yes, I think that's what I was trying to say. > The fact is, that we don't need to know how large the user buffer is > if the CPU is accessing it (or if we have a very advanced driver that > faults memory in the GPU VM on demand, and/or a mechanism to let the > GPU share the process address space). Even for software t&l, it's pretty important, see below. > As you said, this happens for instance with swtnl, but also with > drivers that scan the index buffer and copy the referenced vertex for > each index onto the GPU FIFO themselves (e.g. nv50 and experimental > versions of nv30/nv40). Having user-buffers with undefined size establishes a connection inside the driver between two things which could previously be fully understood separately - the vertex buffer is now no longer fully defined without reference to an index buffer. Effectively the user buffer become just unqualified pointers and we are back to the GL world pre-VBOs. In your examples, scanning and uploading (or transforming) per-index is only something which is sensible in special cases - eg where there are very few indices or sparse access to a large vertex buffer that hasn't already been uploaded/transformed. But you can't even know if the vertex buffer is sparse until you know how big it is, ie. what max_index is... Typical usage is the opposite - vertices are referenced more than once in a mesh and the efficient thing to do is: - for software tnl, transform all the vertices in the vertex buffer (requires knowing max_index) and then apply the indices to the transformed vertices - for hardware tnl, upload the vertex buffer in entirety (or better still, the referenced subrange). > So couldn't we pass ~0 or similar as the user buffer length, and have > the driver use an auxiliary module on draw calls to determine the real > length, if necessary? > Of course, drivers that upload user buffers on creation (if any > exists) would need to be changed to only do that on draw calls. My feeling is that user buffers are a pretty significant concession to legacy GL vertex arrays in the interface. If there was any change to them, it would be more along the lines of getting rid of them entirely and forcing the state trackers to use proper buffers for everything. They are a nice way to accomodate old-style GL arrays, but they don't have many other uses and are already on shaky ground semantically. In summary, I'm not 100% comfortable with the current userbuffer concept, and I'd be *really* uncomfortable with the idea of buffers who's size we don't know or which could change size when a new index buffer is bound... 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
