On Mon, 2009-08-10 at 12:40 -0700, Maciej Cencora wrote:
> Dnia poniedziałek, 29 czerwca 2009 o 12:24:54 Keith Whitwell napisał(a):
> > On Sat, 2009-06-27 at 14:57 -0700, Maciej Cencora wrote:
> > > Hi,
> > >
> > > while playing with r300 driver I've stumbled upon a problem with
> > > splitting vertexes.
> > >
> > > Let's say we get rendering operation where number of indexes in index
> > > buffer is 80000 and max_index is 20000. We are calling vbo_split_prims
> > > because number of indexes exceeds hw limit.
> > > In flush_vertex (vbo_split_inplace.c) function the split->ib is not null,
> > > so the max_index (20000) won't be changed. In the end the draw_prims
> > > functions will be called with inappropriate max_index number.
> > >
> > > I'm seeing this behaviour with UT2004 demo on current r300 driver.
> > >
> > > I think the solution would be to always calculate min/max_index numbers
> > > just like in the !split->ib path but I want to be sure before I commit
> > > the patch.
> >
> > This seems reasonable to me - I haven't looked at this in a while
> > though, and suspect this might be just one of several niggles in this
> > code.
> >
> > Keith
>
> There is one more (even bigger) problem with the vbo_split_inplace code. The
> behavior is completely bogus when there's an index buffer, because in flush
> function we don't use index buffer at all. For cases when max_index >= ib-
> >count we end with incorrect rendering in the worst case, for max_index < ib-
> >count we end with GPU trying to read outside of VBOs resulting in GPU lockup.
> I've tried to come up with a proper solution but failed. I'd really
> appreciate
> if someone could take a look at this.
We handle this correctly in gallium, though it's a major performance hit
if you end up having to do it & we try pretty hard to avoid it (though
there is always more that could be done).
A first question is to ask why you're splitting the vertex data up in
the first place? If you're just passing it off to hardware, why not
improve the hardware upload path and avoid the need to split?
If you're relying on swtnl, then I guess you're out of luck short of
rewriting the TNL module. In that case, you may want to pull some code
from Gallium (or consider moving to Gallium and getting all the other
benefits).
The code in question (draw_pt_vcache.c & friends) basically walks the
element list, building a set of new vertex buffers and element lists.
Basically:
for each triangle in primitive
get three source index numbers
for each source index {
check index-mapping cache for this index
if (!present) {
copy that vertex from source vertex buffer to tail of dest
update index cache to map source index to dest_vert_count++
}
append index-map[source-index] to end of dest_index_list
flush & restart triangle if out of space
}
So it's a lot of work & is definitely a noticeable performance hit.
Are you really sure you need to be splitting vertex buffers?
Keith
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
