[Mesa-dev] [PATCH] vbo: introduce vbo_get_minmax_indices function
Roland Scheidegger
sroland at vmware.com
Wed Jan 4 10:09:07 PST 2012
Am 04.01.2012 04:20, schrieb Yuanhan Liu:
> On Tue, Jan 03, 2012 at 08:25:31PM +0100, Roland Scheidegger wrote:
>> Ah index scanning...
>> I don't like that this will map/unmap the ib once for each prim,
> Me either :)
>
>> though
>> I don't really see a nice way to avoid that (I think if you have to
>
> Well, I thought a while, we may do some combine to reduce some
> map/unmap.
Yes, as long as the ranges are sequential it's not that bad.
You could get really fancy and merge all ranges (which would also avoid
having to scan some indices multiple times when the ranges overlap) but
that's not what I would qualify as "nice".
So I'm just not sure it's worth bothering for this (hopefully) corner case.
Roland
>
>
>> actually map the ib, you lose anyway). Hopefully won't hit that
>> performance hog often...
>> A comment inline.
>>
>>
>> Am 31.12.2011 07:32, schrieb Yuanhan Liu:
> [snip]...
>
>>> + for (i = 0; i < nr_prims; i++) {
>>> + tmp_ib.ptr = ib->ptr + prims[i].start * vbo_sizeof_ib_type(ib->type);
>> I think you should not use a temporary ib. Figuring out the correct
>> start offset clearly looks like it should be handled by
>> vbo_get_minmax_index() itself (it should have done this previously
>> probably, as there might never have been a guarantee that it is always 0
>> even if there's only a single primitive).
>
> Nice suggestion, thanks! Will fix it in the next patch.
>
> --
> Yuanhan Liu
>>
>>> + vbo_get_minmax_index(ctx, &prims[i], &tmp_ib, &tmp_min, &tmp_max);
>>> + *min_index = MIN2(*min_index, tmp_min);
>>> + *max_index = MAX2(*max_index, tmp_max);
>>> + }
>>> +}
>>> +
>>>
>>> /**
>>> * Check that element 'j' of the array has reasonable data.
>>
>> Otherwise looks ok to me.
>>
>> Roland
More information about the mesa-dev
mailing list