[Nouveau] Coordinate systems on on nv10-era cards

[Ilia Mirkin]

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