On Thu, Mar 13, 2014 at 6:42 AM, Francisco Jerez <curroje...@riseup.net> wrote: > Ilia Mirkin <imir...@alum.mit.edu> writes: > >> Hi Francisco, >> >> I'm looking at some piglit failures on nv10... full run at >> >> http://people.freedesktop.org/~imirkin/nv10-comparison/problems.html >> >> The specific one is: >> >> http://people.freedesktop.org/~imirkin/nv10-comparison/nv18-imirkin/spec/!OpenGL%201.1/copyteximage%201D.html >> >> Which fails in nouveau_choose_tex_format for GL_DEPTH24_STENCIL8. And >> indeed, that case isn't handled. Looking through the #defines, I see a >> NV20_3D_TEX_FORMAT_FORMAT_Z24 but not for the earlier versions. And >> even in the nv20 case, it's not actually used in the driver. >> >> Does that mean that EXT_packed_depth_stencil should never have been >> enabled on nouveau? I do see that it's a valid renderbuffer format >> though. [It is now always enabled, since commit a92b9e60, but at the >> time of the commit, it was also enabled for everything. >> >> Any advice? >> > > AFAICT EXT_packed_depth_stencil only requires the implementation to > support GL_DEPTH_STENCIL for texturing if ARB_depth_texture is supported > in addition -- which, as you guessed correctly, could be supported on > nv20 or higher. > > Shouldn't the piglit test be checking if the implementation supports > depth texturing before doing that?
Mmmaybe. But that's not such a big deal -- worst case, the piglit should get a gl error of some sort. Sounds like the real issue is that mesa core is letting the values through to the driver. I'll re-read EXT_packed_depth_stencil more carefully, I didn't see the ARB_depth_texture dependency, but I only scanned it very quickly. Thanks, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
