[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



I suppose I was unclear:

Good:
gl.activeTexture(gl.TEXTURE0);
gl.uniform1i(loc_uTexUnit, 0);
for (var j = 0; j < 3; j++) {
  for (var i = 0; i < 1000; i++) {
    gl.bindTexture(gl.TEXTURE_2D, (i % 2) ? texA : texB);
    gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4);
  }
  gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4));
}

Bad:
gl.activeTexture(gl.TEXTURE0);
gl.bindTexture(gl.TEXTURE_2D, texA);
gl.activeTexture(gl.TEXTURE1);
gl.bindTexture(gl.TEXTURE_2D, texB);
for (var j = 0; j < 3; j++) {
  for (var i = 0; i < 1000; i++) {
    gl.uniform1i(loc_uTexUnit, i % 2);
    gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4);
  }
  gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4));
}

This is the sort of pipeline filling that would generally warrant a glFlush anyways.

-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 5:03:55 PM
Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test


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