[PATCH] retrace: support depth/stencil attachment for gles

[José Fonseca]

I fixed this and pushed the change.

BTW, on your first first version you said:

   "TODO: this still seems to fall over w/ z24_s8, somehow ends up
attempting to glReadPixels() with GL_FLOAT type.  Still trying to
untangle all the logic here... gles really doesn't make it easy."

I understand why and how to fix this.  See the following comment on the
code if you're interested:

           /* FIXME: NV_read_depth_stencil states that type must match the
             * internal format, whereas we always request GL_FLOAT, as
that's
             * what we want.  To fix this we should probe the adequate type
             * here, and then manually convert the pixels to float after
             * glReadPixels */

Jose


On Thu, Sep 3, 2015 at 10:44 PM, José Fonseca <jose.r.fonseca at gmail.com>
wrote:

> Thanks for the update.
>
> Before submiting I did basic check with NVIDIA proprietary drivers (which
> supports NV_read_depth_stencil), and your patch causes reading the back
> buffer (ie, no framebuffer bound) to regress.
>
> Before your patch glretrace would do to get the back buffer contents:
>
>   glReadPixels(x = 0, y = 0, width = 300, height = 300, format = GL_RGBA ,
> type = GL_UNSIGNED_BYTE, pixels)
>   glGetError() = GL_NO_ERROR
>
> After your patch glretrace does:
>
>   glReadPixels(x = 0, y = 0, width = 300, height = 300, format = GL_RGB,
> type = GL_UNSIGNED_BYTE, pixels)
>   486: message: major api error 1282: GL_INVALID_OPERATION error
> generated. Invalid <format> parameter for current read framebuffer
>   glGetError() = GL_INVALID_OPERATION
>
> This is basic functionality so it must not regress.
>
> You can repro this yourself by doing
>
>    wget
> http://people.freedesktop.org/~jrfonseca/traces/egl_gles2_tri_glsl.trace
>    glretrace -D 486 egl_gles2_tri_glsl.trace
>
> (One has to use glretrace instead of eglretrace because NVIDIA drivers
> usually only supports GLES context via GLX.)
>
> I haven't tried with Mesa.  You might need to use
>
>    eglretrace -D 486 egl_gles2_tri_glsl.trace
>
> Also please run https://github.com/apitrace/apitrace-tests tests -- I
> just beefed them up to cover this case.
>
> Jose
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150904/56b12530/attachment-0001.html>