On Mon, Feb 27, 2012 at 2:37 PM, Brian Paul <<a href="mailto:brianp@vmware.com">brianp@vmware.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On 02/27/2012 03:02 PM, Anuj Phogat wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> On Mon, Feb 27, 2012 at 10:54 AM, Anuj Phogat <<a href="mailto:anuj.phogat@gmail.com" target="_blank">anuj.phogat@gmail.com</a> </div><div class="im"> <mailto:<a href="mailto:anuj.phogat@gmail.com" target="_blank">anuj.phogat@gmail.com</a>>> wrote: On Mon, Feb 27, 2012 at 7:44 AM, Brian Paul <<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a> </div><div class="im"> <mailto:<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>>> wrote: On 02/23/2012 08:27 PM, Anuj Phogat wrote: Intel driver throws GL_OUT_OF_MEMORY and assertion failure / segmentation fault with large textures. Reproduces the errors reported in: </div> <a href="https://bugs.freedesktop.org/__show_bug.cgi?id=44970" target="_blank">https://bugs.freedesktop.org/__show_bug.cgi?id=44970</a> <<a href="https://bugs.freedesktop.org/show_bug.cgi?id=44970" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=44970</a>> <a href="https://bugs.freedesktop.org/__show_bug.cgi?id=46303" target="_blank">https://bugs.freedesktop.org/__show_bug.cgi?id=46303</a><div class="im"> <<a href="https://bugs.freedesktop.org/show_bug.cgi?id=46303" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=46303</a>> Signed-off-by: Anuj Phogat<<a href="mailto:anuj.phogat@gmail.com" target="_blank">anuj.phogat@gmail.com</a> </div> <mailto:<a href="mailto:anuj.phogat@gmail.com" target="_blank">anuj.phogat@gmail.com</a>>><div class="im"> --- V3: Added the test using proxy textures, deleted redundant code, data array allocation based on size returned ToDo: getMaxTarget, getProxyTarget and isValidTexSize functions can be added as piglit utility functions in piglit-util-gl.c I will do it in a separate patch. tests/all.tests | 1 + tests/bugs/CMakeLists.gl.txt | 1 + tests/bugs/large-textures.c | 352 </div> ++++++++++++++++++++++++++++++__++++++++++++<div><div class="h5"> 3 files changed, 354 insertions(+), 0 deletions(-) create mode 100644 tests/bugs/large-textures.c diff --git a/tests/bugs/large-textures.c b/tests/bugs/large-textures.c new file mode 100644 index 0000000..c43f51e --- /dev/null +++ b/tests/bugs/large-textures.c @@ -0,0 +1,352 @@ The test should be moved to test/texturing/. I think we agreed to move away from the tests/bugs/ directory. [...] +void piglit_init(int argc, char **argv) +{ + GLuint tex; + int i, j; + + glMatrixMode(GL_PROJECTION); + glPushMatrix(); + glLoadIdentity(); + glOrtho(0, piglit_width, 0, piglit_height, -1, 1); + glMatrixMode(GL_MODELVIEW); + glPushMatrix(); + glLoadIdentity(); + glClearColor(0.2, 0.2, 0.2, 1.0); + glClear(GL_COLOR_BUFFER_BIT); + + for ( i = 0; i< ARRAY_SIZE(target); i++) { + + glGenTextures(1,&tex); + glBindTexture(target[i], tex); + glTexParameteri(target[i], GL_TEXTURE_MIN_FILTER, GL_NEAREST); + glTexParameteri(target[i], GL_TEXTURE_MAG_FILTER, GL_NEAREST); + + for (j = 0; j< ARRAY_SIZE(internalformat); j++) { + + if (internalformat[j] == GL_RGBA16F || + internalformat[j] == GL_RGBA32F) + </div></div> piglit_require_extension("GL___ARB_texture_float");<div><div class="h5"> I think you should simply skip the float formats if GL_ARB_texture_float is not supported (don't exit with SKIP result). Yes. That's the right thing i should do. I ran the test with NVIDIA's driver. Here's what it printed: GL_PROXY_TEXTURE_1D, Internal Format = GL_RGBA8, Largest Texture Size = 16384 GL_PROXY_TEXTURE_1D, Internal Format = GL_RGBA16, Largest Texture Size = 16384 GL_PROXY_TEXTURE_1D, Internal Format = GL_RGBA32F, Largest Texture Size = 16384 GL_PROXY_TEXTURE_2D, Internal Format = GL_RGBA8, Largest Texture Size = 16384 GL_PROXY_TEXTURE_2D, Internal Format = GL_RGBA16, Largest Texture Size = 16384 GL_PROXY_TEXTURE_2D, Internal Format = GL_RGBA32F, Largest Texture Size = 16384 GL_PROXY_TEXTURE_CUBE_MAP, Internal Format = GL_RGBA8, Largest Texture Size = 16384 GL_PROXY_TEXTURE_CUBE_MAP, Internal Format = GL_RGBA16, Largest Texture Size = 16384 GL_PROXY_TEXTURE_CUBE_MAP, Internal Format = GL_RGBA32F, Largest Texture Size = 16384 GL_PROXY_TEXTURE_3D, Internal Format = GL_RGBA8, Largest Texture Size = 2048 GL_PROXY_TEXTURE_3D, Internal Format = GL_RGBA16, Largest Texture Size = 2048 GL_PROXY_TEXTURE_3D, Internal Format = GL_RGBA32F, Largest Texture Size = 2048 GL_TEXTURE_1D, Internal Format = GL_RGBA8, Largest Texture Size = 16384 Unexpected GL error: GL_INVALID_VALUE 0x501 GL_TEXTURE_1D, Internal Format = GL_RGBA16, Largest Texture Size = 16384 Unexpected GL error: GL_INVALID_VALUE 0x501 GL_TEXTURE_1D, Internal Format = GL_RGBA32F, Largest Texture Size = 16384 Unexpected GL error: GL_INVALID_VALUE 0x501 GL_TEXTURE_2D, Internal Format = GL_RGBA8, Largest Texture Size = 16384 Unexpected GL error: GL_INVALID_VALUE 0x501 GL_TEXTURE_2D, Internal Format = GL_RGBA16, Largest Texture Size = 16384 Unexpected GL error: GL_INVALID_VALUE 0x501 GL_TEXTURE_2D, Internal Format = GL_RGBA32F, Largest Texture Size = 16384 Unexpected GL error: GL_INVALID_VALUE 0x501 Unexpected GL error: GL_INVALID_VALUE 0x501 Unexpected GL error: GL_INVALID_VALUE 0x501 Unexpected GL error: GL_INVALID_VALUE 0x501 Unexpected GL error: GL_INVALID_VALUE 0x501 Unexpected GL error: GL_INVALID_VALUE 0x501 GL_TEXTURE_CUBE_MAP, Internal Format = GL_RGBA16, Largest Texture Size = 16384 [I killed it here after 10+ minutes of runtime] I don't know what's causing the INVALID_VALUE error. GL_INVALID_VALUE error is thrown by the driver when we test with textures larger than maximum supported size. So, this is an expected error. </div></div></blockquote> I haven't double-checked the code, but why are you testing a texture size that's larger than the advertised max size? </blockquote><div>Just to verify that such a case is handled properly in mesa. There was a bug relevant to this case:</div> <div><a href="https://bugs.freedesktop.org/show_bug.cgi?id=44970">https://bugs.freedesktop.org/show_bug.cgi?id=44970</a></div><div>If you suggest, this case can be moved to texture-border test i'm developing currently. </div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> OK, I'm looking at the loop at line 186:<div class="im"> for (side = maxSide - 100; side < maxSide + 2; side++) { </div> switch (target) { case GL_TEXTURE_1D: I guess I don't understand why you're doing that. It seems to me you just have to query the max texture size (both via glGetIntegerv() and the proxy test) then try to create a texture of that size. Testing 102 other size variations isn't necessary.</blockquote> <div>I originally put that loop starting from maxSide/2 to detect the texture size where driver segfaults or starts throwing GL_OUT_OF_MEMORY. But that makes it a huge loop and i was anyway not able to conclude on a specific texture size which causes segfault. So, now it makes sense to remove this loop.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Another expected error is GL_OUT_OF_MEMORY when driver is unable to map a previously created large texture in glSubTexImage1D/2D/3D. I will include both these errors as expected errors and put a comment about it. The test runs _extremely_ slowly. It looks like the driver is allocating some really large image buffers so we're falling back to virtual memory. I don't know a way around this. On one hand, it's good to test this, but nobody wants to wait 10+ minutes for the outcome. The purpose of this test case is to make sure that driver doesn't segfault with large textures and throws relevant errors in case it is unable to allocate memory or map large textures. I am able to identify few issues in intel driver using this test case. If nVidia driver takes a long time to run the test, there's a possibility that they are not handling such cases properly. May be they should return GL_OUT_OF_MEMORY in that case. or we can comment out GL_RGBA16 and GL_RGBA32F and put a comment informing users about the time test takes with those formats. </blockquote> </div> Let's try taking out the 102-iteration loop and see what happens.</blockquote><div>I'll send out an updated patch. Thanks for testing on NVIDIA.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I noticed below listed comment in tests/texturing/tex3d-maxsize.c which might explain the issue you are seeing on nvidia driver: [...] /* use proxy texture to find working max texture size */ find_max_tex3d_size(maxsize, &width, &height, &depth); #ifdef NVIDIA_HACK /* XXX NVIDIA's proxy texture mechanism is broken. * If this code is enabled, a smaller texture is used and * the test passes. Only halving the texture size isn't enough: * we try to allocate a gigantic texture which typically brings * the machine to its knees, swapping, then dying. */ width /= 4; height /= 4; depth /= 4; #endif [...] </blockquote> </div> I wish I'd have noted which version of NVIDIA driver that was. I don't see any problem with driver 280.13 so we could probably remove that code (it's disabled anyway). -Brian </blockquote></div>