[Nouveau] Coordinate systems on on nv10-era cards

[Ilia Mirkin]

Just to close the loop on this, I tracked down what the issue was --
vbo state updates weren't happening properly, which in turn messed all
sorts of things up. Fixed in
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8867ffbf95808dfa82029ad89d1571799a242d4d

On Fri, Aug 15, 2014 at 3:00 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> So I did a lot more debugging on this. I wrote a program that draws a
> triangle to an fbo, and then blits that to fb 0. If I draw the
> triangle with
>
>   glBegin(GL_TRIANGLES);
>     glColor3f(1, 0, 0); glVertex3f(-0.6*128 + 128, -0.75*128 + 128, 0.5);
>     glColor3f(0, 1, 0); glVertex3f(0.6*128 + 128, -0.75*128 + 128, 0);
>     glColor3f(0, 0, 1); glVertex3f(128, 0.75*128 + 128, 0);
>   glEnd();
>
> Then all is well. However if I do:
>
>   float verts[3][6] = {
>     { -0.6*128 + 128, -0.75*128 + 128, 0.5, 1, 0, 0 },
>     { 0.6*128 + 128, -0.75*128 + 128, 0, 0, 1, 0 },
>     { 128, 0.75*128 + 128, 0, 0, 0, 1 },
>   };
>
>   glVertexPointer(3, GL_FLOAT, 24, verts);
>   glColorPointer(3, GL_FLOAT, 24, &verts[0][3]);
>   glEnableClientState(GL_VERTEX_ARRAY);
>   glEnableClientState(GL_COLOR_ARRAY);
>
>   glDrawArrays(GL_TRIANGLES, 0, 3);
>
>   glDisableClientState(GL_VERTEX_ARRAY);
>   glDisableClientState(GL_COLOR_ARRAY);
>
> Then I see the failure. Looking at the pushbuf for where the blit
> happens (after the draw), for the working case, I'm seeing
>
> PB: 0x00002c22   NV17_3D.VTXBUF_FMT[0] = { TYPE = V32_FLOAT | FIELDS =
> 2 | STRIDE = 44 }
> PB: 0x00002c22   NV17_3D.VTXBUF_FMT[0x3] = { TYPE = V32_FLOAT | FIELDS
> = 2 | STRIDE = 44 }
>
> (0 = position, 3 = texcoord0)
>
> and for the bad case:
>
> PB: 0x00000c32   NV17_3D.VTXBUF_FMT[0] = { TYPE = V32_FLOAT | FIELDS =
> 3 | STRIDE = 12 }
> PB: 0x00000c32   NV17_3D.VTXBUF_FMT[0x1] = { TYPE = V32_FLOAT | FIELDS
> = 3 | STRIDE = 12 }
>
> (1 = color) which is the exact same setup as the one used to perform
> the draw. I'm guessing whatever meta_BlitFramebuffer is doing isn't
> sufficiently overriding the original vbo setup. (Although the actual
> addresses of the buffers are now different, so it's not completely
> ignoring the vertices used for the blit...)
>
> I'll keep looking at this, but if anyone has any ideas, let me know.
>
>
> On Sun, Aug 10, 2014 at 7:32 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Hello,
>>
>> I'm trying to debug why fbo-copyteximage-simple is failing, and I'm...
>> failing. It's an extremely simple test. I'm pretty sure that the
>> copyteximage part of it has nothing to do with the failure, at least
>> it behaves identically when I just return tex instead of copiex_tex.
>>
>> Without any modifications, the test just renders one big red square. I
>> think there's something wrong with the coordinate systems since if I
>> change
>>
>> glColor4fv(red);
>> piglit_draw_rect(0, 0, TEX_WIDTH / 2, TEX_HEIGHT / 2);
>>
>> to instead be
>>
>> piglit_draw_rect(1, 1, TEX_WIDTH / 2, TEX_HEIGHT / 2);
>>
>> Then the result is all black. So I think that the coordinates are
>> being scaled up somewhere they're not supposed to be (or, conversely,
>> not being scaled down when they are supposed to be). The projection
>> matrix sent to the card is {x - 128, y - 128, z * 32767.5, 1 }. Should
>> it be scaling the coordinates down to the -1, 1 range instead? i.e. is
>> get_viewport_scale() just totally wrong? Or something in
>> nv10_emit_projection?
>>
>> Ideas welcome :)
>>
>>   -ilia