On Tue, 2010-03-02 at 04:02 +0100, Roland Scheidegger wrote:
> On 02.03.2010 00:18, Joakim Sindholt wrote:
> > On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> >> Hi,
> >>
> >> this branch turns vertex element into a cso, so instead of
> >> set_vertex_elements there's now the triad of
> >> create/bind/delete_vertex_elements_state. I have converted all the
> >> drivers except nouveau (I didn't do it because Christoph Bumiller
> >> already did nv50, but I can give the rest of them a shot), though that
> >> doesn't necessarily mean they are optimized for it (the idea is of
> >> course to precalculate state on create, not just copy the pipe structs
> >> and do everything on bind) - only i965g really does something close to
> >> it (though still emits the state always). Drivers doing both hw vertex
> >> shaders and using draw in some circumstances of course will have to
> >> store both representations on create.
> >> Also note that util_draw_vertex_buffer semantics have changed a bit
> >> (caller needs to set vertex element state, which is a bit odd).
> >>
> >> Roland
> > 
> > Can I still do things like:
> > element 0: -> vbo 5
> > element 1: -> vbo 2
> > and then set_vertex_buffers() with an array { zeros, zeros, vbo 2, zeros
> > zeros, vbo 5 } ?
> > 
> 
> The branch doesn't change pipe_vertex_element itself (except
> nr_components got removed as that's really derived from the associated
> pipe_format), only how those vertex elements are set. Hence you can do
> exactly the same things you could do before. Though I'm not quite sure
> what your zeros mean, if that's just a unused vbo it should be ok, but
> it is probably not ok to just pass in a null pointer for a unused
> pipe_vertex_buffer.
> 
> Roland

I did just mean empty buffers, but they're not actual buffers. I wrote
"zeros" because I literally just zero out everything in that particular
struct. There's no sense in binding 6 vbos when I really only have 2


------------------------------------------------------------------------------
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

Reply via email to