[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test

On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
It's true, but this test generates over a thousand different draw calls, which is unusual.

Unusual for a test? It's not for a standard webgl app.
I don't think it's a good idea for the test to mandate something like this succeeds, since that'll mean adding flushing heuristics to the implementation.

Does the device in question run most webgl content otherwise or does it run out of memory on lots of examples where other devices do not?  I'd much prefer not supporting WebGL on devices that behave really poorly than pass on those issues to Web devs.

My point is, even though the spec allows making every function a no-op and making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance tests require more than that even though that's not part of the spec.

So, the question is, what should the similar requirements be for the WebGL Conformance Tests? It seems like there should be some minimum requirements. What should they be?



----- Original Message -----
From: "Gregg Tavares" <gman@google.com>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "public webgl" <public_webgl@khronos.org>
Sent: Wednesday, April 3, 2013 9:13:43 AM
Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test

IIRC the tests have been written to use a reasonable (less than 60meg) amount of memory.

The spec unfortunately makes it possible for every function to generate GL_OUT_OF_MEMORY period and still be technically spec compliant.

In other words, according to the spec an implementation could to this

GLenum glGetErrror() { return GL_OUT_OF_MEMORY; }
void glBindBuffer(...) { /* no-op */ }

void glBindTexture(...) { /* no-op */ }
void glTexImage2D(...) { /* no-op */ }
void glDrawArrays(...) { /* no-op */ }

And be valid according to the spec :-(

On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert@mozilla.com > wrote:

On some mobile devices, we're hitting a couple errors followed by a gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. This is AFAIK spec-compliant behavior, so I believe the test should be changed to gl.flush() after each draw call, which seems to have fixed it for me.



You are currently subscribed to public_webgl@khronos.org .
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl