Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]

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

On Wed, Mar 10, 2010 at 7:11 AM, Brian Paul <br...@vm...> wrote:
>>> get_arrays_bounds: Handling 2 attrs
>>> attr 0: stride 16 size 12 start (nil) end 0xfffffffc
>>> attr 1: stride 16 size 4 start 0xc end (nil)
>>> buffer range: (nil) 0xfffffffc range -4 max index 4294967295
>
> Can you post the patch you used to print this info, Corbin?

Inlined:

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 8a6e1ed..7ae152c 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -293,6 +293,8 @@ get_arrays_bounds(const struct st_vertex_program *vp,
    const GLubyte *high_addr = NULL;
    GLuint attr;

+   debug_printf("get_arrays_bounds: Handling %u attrs\n", vpv->num_inputs);
+
    for (attr = 0; attr < vpv->num_inputs; attr++) {
       const GLuint mesaAttr = vp->index_to_input[attr];
       const GLint stride = arrays[mesaAttr]->StrideB;
@@ -301,6 +303,8 @@ get_arrays_bounds(const struct st_vertex_program *vp,
                            _mesa_sizeof_type(arrays[mesaAttr]->Type));
       const GLubyte *end = start + (max_index * stride) + sz;

+      debug_printf("attr %u: stride %d size %u start %p end %p\n",
attr, stride, sz, start, end);
+
       if (attr == 0) {
          low_addr = start;
          high_addr = end;
@@ -348,7 +352,7 @@ setup_interleaved_attribs(GLcontext *ctx,
          const GLubyte *low, *high;

          get_arrays_bounds(vp, vpv, arrays, max_index, &low, &high);
-         /*printf("buffer range: %p %p  %d\n", low, high, high-low);*/
+         printf("buffer range: %p %p range %d max index %u\n", low,
high, high-low, max_index);

          offset0 = low;
          if (userSpace) {


>>> So right here (from device.ok) we have interleaved userspace VBO, that is
>>> being
>>> prepped inside core Mesa. Two delightful things here; the first attr
>>> seems way
>>> off-base, it shouldn't dare be giving us bad pointers, and the second
>>> attr's
>>> pointers don't even line up!
>>
>> In VBO rendering, the pointers are really just offsets into the VBO, so
>> should be interpreted as numbers.
>>
>> The first attribute has what looks like a small negative number.  I
>> don't know if that's legal or not in GL - I suspect it is probably not
>> legal and should be rejected in the mesa validation code.
>
> This would have come in via the 'ptr' argument to one of the
> glVertex/Color/etcPointer() functions.  We never check for negative pointer
> values.

Just started digging into this again, finally have spare time (if only
for a few days.) I will hopefully have a followup soon.

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>