<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - WebGL Conformance conformance/textures/texture-size-limit.html -> OUT_OF_MEMORY" href="https://bugs.freedesktop.org/show_bug.cgi?id=89818#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - WebGL Conformance conformance/textures/texture-size-limit.html -> OUT_OF_MEMORY" href="https://bugs.freedesktop.org/show_bug.cgi?id=89818">bug 89818</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>It is not really llvmpipe specific, it is more or less luck this passes with softpipe, the actual logic refusing too large textures is very similar. But softpipe announces a limit of 4k for cube maps, whereas llvmpipe says 8k. It is true though that with the memory limit we impose (1GB) we can't actually even handle a 2 (with mips) or 4 channel (even without mips) (with just 8 bits per channel, uncompressed) cube map, but this isn't required unless I'm missing something, and it is quite ok to simply say out_of_memory (this could be queried via proxy textures). That the test only ever tries to submit the smallest mip levels doesn't matter, we allocate the whole thing in any case. I'm inclined to mark this as NOTABUG, the test looks bogus. If you'd try the same with, say, RGBA32F textures, you'd see this fail on softpipe as well. (We could, of course, increase the limit, but even twice that would not quite be enough for what the tests wants - not sure if all the math would be unsigned-safe to increase it further to the required "some bytes more than than 2GB due to padding" but in any case I don't think we really want to do that.)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>