These two tests fail on i965: KHR-NoContext.es32.robustness.readnpixels KHR-NoContext.es32.robustness.getnuniform The readnpixels test does: PFNGLREADNPIXELS pReadnPixels = (PFNGLREADNPIXELS)context->getRenderContext().getProcAddress("glReadnPixels"); and then calls that function pointer...but ends up in generic_nop(). It looks like the suffixless versions aren't getting exposed correctly, despite being part of ES 3.2. There's a fair bit of complex aliasing going on for ARB/KHR/suffixless, and I'm getting a bit lost trying to figure out the right mapi/glapi/gen XML snippets to do the right thing.
It looks like these 2 tests fail for different reasons: - 'readnpix' hits generic_nop (glapi issue) - 'getnuniform', problem seems to be that according to Mesa these uniforms are inactive and therefore no uniformstorage is available. I can see that linker reserves explicit locations correctly (inputf : 11, inputi : 12, inputu : 13) but opt_dead_code removes the variables: --- 8< --- Removed declaration of inputf@0x34f1f80 Removed declaration of inputu@0x34f26b0 Removed declaration of inputi@0x34f2540 --- 8< --- If I modify opt_dead_code to not remove those variables the test passes. I hacked it like this: --- 8< --- + if (entry->var->data.explicit_location) + continue; --- 8< --- It seems compiler/linker should realize that they are written to shared values so we should not optimize those away.
(In reply to Tapani Pälli from comment #1) > It seems compiler/linker should realize that they are written to shared > values so we should not optimize those away. and alternative theory: since we never write these out to any buffer maybe it is just ok to optimize these away and test should be changed instead :)
(In reply to Tapani Pälli from comment #2) > (In reply to Tapani Pälli from comment #1) > > It seems compiler/linker should realize that they are written to shared > > values so we should not optimize those away. > > and alternative theory: since we never write these out to any buffer maybe > it is just ok to optimize these away and test should be changed instead :) I've created issue about this and sent a fix proposal for getnuniform test: https://gitlab.khronos.org/Tracker/vk-gl-cts/issues/1036
(In reply to Kenneth Graunke from comment #0) > The readnpixels test does: > > PFNGLREADNPIXELS pReadnPixels = > (PFNGLREADNPIXELS)context->getRenderContext(). > getProcAddress("glReadnPixels"); > > and then calls that function pointer...but ends up in generic_nop(). It does not actually call it, instead it calls api via "gl.readnPixels", gl contains the API functions that have been resolved already earlier. The pReadnPixels would actually work if it would be utilized, I changed test to use that and it passes. I'm wanted to write this down here so that I won't forget this. Will need to figure out how context functions in 'gl.*' get resolved.
Updating status ... my fix to dEQP went in and now we pass 'getnuniform' test, but readnpixels still fails. I did a separate GLES 3.2 app that utilizes these entrypoints, they are being exposed and work correctly. Also dEQP has tests that call these entrypoints and those tests are passing. So, as said in comment #4 there seems to be something going wrong with how the api functions are resolved by the test suite.
OK .. after yet another gdb session I think now I got it. What is happening is that when the test suite generates functions from khronos xml, it first sets gl.readnPixels to glReadnPixelsKHR but later on replaces this same pointer with glReadnPixelsEXT (which Mesa does not support). This is a bit unfortunate, maybe it should check if the function was already succesfully resolved. Will attempt this.
OK, sent a fix to vk-gl-cts suite to reorder EXT and KHR resolving so that KHR is preferred over EXT. It might be this is not the only case where such reordering is required and maybe more elegant fix to generator scripts is required.
This is now fixed in opengl-es-cts-3.2.4 by following commit, resolving this one as NOTOURBUG. --- 8< --- commit c693c85a5f9983caab94c3973e6dc0efaae57b0c Author: Tapani Pälli <tapani.palli@intel.com> Date: Thu Apr 5 08:13:46 2018 +0300 Prefer KHR entrypoints instead of EXT for robustness tests When resolving function entrypoints, framework resolves EXT entrypoints after KHR to the same pointers. There are drivers that implement only KHR entrypoints, prefer KHR over EXT so that KHR entrypoints will be the ones used if both extensions are supported by the driver. Components: OpenGL ES VK-GL-CTS issue: 1107 Affects: KHR-NoContext.es32.robustness.getnuniform KHR-NoContext.es32.robustness.readnpixels Change-Id: Iec5f7cbdd53061e105b3445f7613ee41fccc4553 Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.