mesa3d-dev

[Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Roland S. <sr...@vm...>]

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

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Roland S. <sr...@vm...>]

On 01.03.2010 19:02, 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).

Ok, I've converted nv30/nv40 too. Not that they'd precalculate any hw
state...

Roland

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Corbin S. <mos...@gm...>]

R300 could benefit. I will push a patch to make it more useful after the
merge.

Posting from a mobile, pardon my terseness. ~ C.

On Mar 1, 2010 11:32 AM, "Roland Scheidegger" <sr...@vm...> wrote:

On 01.03.2010 19:02, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cs...
Ok, I've converted nv30/nv40 too. Not that they'd precalculate any hw
state...


Roland

------------------------------------------------------------------------------
Download Int...

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Joakim S. <ba...@zh...>]

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

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Roland S. <sr...@vm...>]

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

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Joakim S. <ba...@zh...>]

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

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Keith W. <ke...@vm...>]

On Mon, 2010-03-01 at 20:18 -0800, Joakim Sindholt wrote:
> 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
> 

Yes, this looks legal to me.

Keith

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Keith W. <ke...@vm...>]

On Mon, 2010-03-01 at 10:02 -0800, 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,

The branch looks good to me, happy to see it merged when you're ready to
go.

Keith

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Roland S. <sr...@vm...>]

On 02.03.2010 11:37, Keith Whitwell wrote:
> On Mon, 2010-03-01 at 10:02 -0800, 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,
> 
> The branch looks good to me, happy to see it merged when you're ready to
> go.

There's actually something in the cso code I was a bit unsure about,
I've looked at it again and indeed it seems wrong. The problem is that
the count value itself isn't stored for the comparison. So in the
unlikely case the hash value is the same for pipe_vertex_elements with
different counts, the comparison itself will also be the same as long as
the first few elements are identical. Which seems very wrong. The
easiest way to fix would probably be to just store the count alongside
the pipe_vertex_element data, but that would need an additional copy of
the incoming data in cso_set_vertex_elements. Hmm...

Roland