[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



This sounds like a quality of implementation problem in the driver on
this platform. The working group's stance on this has been very clear
in the past; the tests will not be modified to work around bugs in
WebGL implementations or graphics drivers. (You'll recall that I
violated this rule once, was correctly called out on it, and reverted
the change to the test.)

-Ken



On Wed, Apr 3, 2013 at 5:03 PM, Gregg Tavares <gman@google.com> wrote:
>> It's only changing the sampler's texture unit via uniform1i that tickles
>> the driver into giving an OOM.
>
> A driver that reports OOM on calling uniform1i is not a driver I'd be
> willing to pass on to web devs.
>
>
>
> On Wed, Apr 3, 2013 at 4:45 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>>
>> The devices are otherwise quite capable. I had to adjust the testcase I
>> wrote for it a couple times to get it to reproduce. For example, changing
>> the test to use bindTexture to change the texture to draw to the screen
>> makes this problem go away. It's only changing the sampler's texture unit
>> via uniform1i that tickles the driver into giving an OOM.
>>
>> I'll note that this is most likely not actually out of system memory,
>> since one of the devices has 2GB of RAM. Rather, it's probably just running
>> out of room for some subsection in the driver.
>>
>> -Jeff
>>
>> ----- 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 2:28:26 PM
>> Subject: 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?
>>
>>
>>
>>
>>
>> -Jeff
>>
>>
>>
>> ----- 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.
>>
>> Thoughts?
>>
>> -Jeff
>>
>> -----------------------------------------------------------
>> 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
>> -----------------------------------------------------------
>>
>>
>>
>

-----------------------------------------------------------
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
-----------------------------------------------------------