Nouveau - Aug 2014 - Coordinate systems on on nv10-era cards

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

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

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