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 <imir...@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 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau