Inaccurate Z-buffer results from FrameBuffer with glReadPixels()

[acidtonic]

I am a developer with an application that runs into strangeness when ran on a rasberryPi3 with a stock rasbian install once hardware acceleration is enabled. The software renderer however performs as expected which leads me to believe this is a bug with the driver and not my code.

I have a mouse selection algorithm which reads the Z value of the pixel under the mouse and if closer than zFar it calls gluUnproject and checks whether the Z value is between -1.0 and 1.0. As far as I'm aware this is quite standard practice yet I'm now getting odd values as soon as I turn on hardware rendering which breaks mouse handling. Turn it off and values are correct again. Normally I'd consider my code but the application runs on multiple architectures and other systems without issues.

In C++ the minimal use case is basically...

//Scene setup in projection mode then glFrustum with aspect boilerplate, zNear 0.1f  zFar 100000.0f
//Before this Render some pixels with Z set to -2000.0f.
//Transform it however you please, then mouse over it.

GLint rendered_viewport[4];
GLdouble  rendered_modelview[16];
GLdouble  rendered_projection[16]; 
GLfloat winX, winY, winZ;
//Read in the rendered_ variables from glGet calls... [not listing these]
glGetIntegerv( GL_VIEWPORT, viewport );
winX = event.xmotion.x; //X11 mouse event
winY = (float)viewport[3] - event.xmotion.y; //Proper Z invert here found in opengl manuals. 
glReadPixels( winX, winY, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &winZ);
gluUnProject( winX, winY, winZ, rendered_modelview, rendered_projection, rendered_viewport, &posX, &posY, &posZ);
if (posZ >= -1 && posZ <= 1.0) {
    //When mousing over the drawn pixels, we should land here once unprojecting
    //(Normally from here you'd then run whatever picking algorithm if multiple objects)
} else {
    //When not mousing over we should land here.
    //But when hardware acceleration is turned on, Z is larger than 1.0 when mousing over.
    //However it's not garbage, random, or anything else hinting at undefined behavior.
}

Since I'm also using quite boilerplate X11 window creation code I'll simply state that I'm obtaining a 24 bit framebuffer and the calls to query the provided surface seem to confirm it's 24 bits. Is there anything else I could be missing here on my end or is this a driver bug?

Thanks!

[anholt]

If you are rendering to a texture, then there was a bug in 11.2 that broke sub-image accesses of small sizes of textures. That's the only relevant bug I know. I'd probably loop over the screen doing readpixels like that one and then visualize it, to see what might be going on.

[anholt]

Have you looked into this any more? I can't do anything about this without full sample code, or at least an apitrace so I could compare results between vc4 and other drivers.

[anholt]

closing due to inactivity. Feel free to reopen if you can get an apitrace showing an issue.