[Mesa-dev] [PATCH] vbo: count min/max_index before vbo->draw_prims

[Liu Aleaxander]

On Sun, Dec 25, 2011 at 8:03 AM, Eric Anholt <eric at anholt.net> wrote:
> On Thu, 22 Dec 2011 18:55:50 +0800, Yuanhan Liu <yuanhan.liu at linux.intel.com> wrote:
>> For the case that index data is stored in element array buffer object,
>> and user called glMultiDrawElements, count the min/max_index before
>> calling vbo->draw_prims. vbo_get_minmax_index() isn't friendly to this
>> case. So do it while building the prim info.
>>
>> Signed-off-by: Yuanhan Liu <yuanhan.liu at linux.intel.com>
>
> I'm really failing to understand what this commit is for.  Does it fix
> some testcase?

Sorry, my bad. I should note something more about this issue. And
yes, it does fixes something. Say for following case:

GLubyte indices_data[] = {0, 1, 2, 3, 4, 5, 6,    1, 7, 8, 9, 10, 11};
GLsizei count[] = {7, 6}
GLvoid * indices_off[2] = {0, 7};

/* here copy the indices data into Element Array Buffer Object */
.....glBind..glBufferData....

/* Here call glMulitDrawElements */
glMultiDrawElements(GL_LINE_STRIP, count,
                                GL_UNSIGNED_BYTE,
                                indices_off, 2);

The current code in brw_draw.c would just count the min_index
and max_index of the first prim, thus got a min_index of 0, and
max_index of 6. This is not right, thus the second prim(and any
 later, if you have more than 2 prim to render) rendered incorrectly.

I found it's a little ugly to add those code similar in this patch at
brw_draw_prims(), then I figured out a way to add it at the caller,
vbo_validated_multidrawelements(). I guess it's reasonable, since
the prim info is built at there.

Also, it fixes some intel oglc primbuff test cases.

That's the detailed info. Sorry again I didn't put it into the commit
message. Will not do it again.

Thanks,
Yuanhan Liu


> Is it improving performance somewhere?  It appears to be
> "unconditionally compute a total min/max index for a multiple-primitive
> draw call", but I don't understand why we would unconditionally need
> that.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>