ASSERT on locking surface in pool default in d3d9

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run ToT chrome (with patch to disable EXT_texture_storage)
2. Visit http://webglsamples.googlecode.com/hg/aquarium/aquarium.html

What is the expected output? What do you see instead?
GPU process asserts on line 137 of Texture.cpp. Debug runtime gives Direct3D9: 
(ERROR) :Lock is not supported for textures allocated with POOL_DEFAULT unless 
they are marked D3DUSAGE_DYNAMIC

Please use labels and text to provide additional information.

003ae078 5f9b512d libglesv2!_wassert(wchar_t * expr = 0x5fb02a80 
"(((HRESULT)(result)) >= 0)", wchar_t * filename = 0x5fb02a50 
".\libGLESv2\Texture.cpp", unsigned int lineno = 0x89)+0xb64 
[f:\dd\vctools\crt_bld\self_x86\crt\src\assert.c @ 335]
003ae098 5f9ba617 libglesv2!gl::Image::lock(struct _D3DLOCKED_RECT * lockedRect 
= 0x003ae0b4, struct tagRECT * rect = 0x00000000)+0x9d 
[d:\src\chrome\src\third_party\angle\src\libglesv2\texture.cpp @ 137]
003ae0c4 5f9bbe34 libglesv2!gl::Texture::subImage(int xoffset = 0, int yoffset 
= 0, int width = 512, int height = 128, unsigned int format = 0x1908, unsigned 
int type = 0x1401, int unpackAlignment = 4, void * pixels = 0x08599000, class 
gl::Image * image = 0x06499420)+0xb7 
[d:\src\chrome\src\third_party\angle\src\libglesv2\texture.cpp @ 1476]
003ae0f4 5f986f29 libglesv2!gl::Texture2D::subImage(int level = 0, int xoffset 
= 0, int yoffset = 0, int width = 512, int height = 128, unsigned int format = 
0x1908, unsigned int type = 0x1401, int unpackAlignment = 4, void * pixels = 
0x08599000)+0x44 [d:\src\chrome\src\third_party\angle\src\libglesv2\texture.cpp 
@ 1847]
003ae158 53030008 libglesv2!glTexSubImage2D(unsigned int target = 0xde1, int 
level = 0, int xoffset = 0, int yoffset = 0, int width = 512, int height = 128, 
unsigned int format = 0x1908, unsigned int type = 0x1401, void * pixels = 
0x08599000)+0x279 
[d:\src\chrome\src\third_party\angle\src\libglesv2\libglesv2.cpp @ 5227]
003ae260 53030513 
chrome_515e0000!gpu::gles2::GLES2DecoderImpl::DoTexSubImage2D(unsigned int 
target = 0xde1, int level = 0, int xoffset = 0, int yoffset = 0, int width = 
512, int height = 128, unsigned int format = 0x1908, unsigned int type = 
0x1401, void * data = 0x08599000)+0x318 
[d:\src\chrome\src\gpu\command_buffer\service\gles2_cmd_decoder.cc @ 6785]
003ae310 5301c9f2 
chrome_515e0000!gpu::gles2::GLES2DecoderImpl::HandleTexSubImage2D(unsigned int 
immediate_data_size = 0, struct gpu::gles2::TexSubImage2D * c = 
0x04401e60)+0x363 
[d:\src\chrome\src\gpu\command_buffer\service\gles2_cmd_decoder.cc @ 6837]
003ae47c 52fda3a0 
chrome_515e0000!gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int command = 
0x17f, unsigned int arg_count = 0xb, void * cmd_data = 0x04401e60)+0xd92 
[d:\src\chrome\src\gpu\command_buffer\service\gles2_cmd_decoder.cc @ 2922]
003ae5e4 530424a2 
chrome_515e0000!gpu::CommandParser::ProcessCommand(void)+0x1d0 
[d:\src\chrome\src\gpu\command_buffer\service\cmd_parser.cc @ 57]
003ae774 54c4cdc1 chrome_515e0000!gpu::GpuScheduler::PutChanged(void)+0x282 
[d:\src\chrome\src\gpu\command_buffer\service\gpu_scheduler.cc @ 68]

Original issue reported on code.google.com by jbauman@chromium.org on 13 Dec 2011 at 1:51

[GoogleCodeExporter]

Disabling GL_ANGLE_texture_usage seems to make it work.

Original comment by jbauman@chromium.org on 13 Dec 2011 at 2:24

[GoogleCodeExporter]

GL_ANGLE_texture_usage depends on EXT_texture_storage. So the latter should not 
be disabled without also disabling the former.

Original comment by nicolas....@gmail.com on 13 Dec 2011 at 3:20

[GoogleCodeExporter]

Ok, that's not really clear from reading the spec. Also, it shouldn't misbehave 
this badly if you use use TexImage2D to allocate the texture (which the spec 
says should work). I'll send out a patch to disable this extension temporarily.

Original comment by j...@baumanfamily.com on 13 Dec 2011 at 3:31

[GoogleCodeExporter]

Err, that was me.

Original comment by jbauman@chromium.org on 13 Dec 2011 at 3:31

[GoogleCodeExporter]

No, texture_usage really should work with regular textures as well.

John - can you elaborate a bit more on how you are using it?

Original comment by dan...@transgaming.com on 13 Dec 2011 at 7:15

[GoogleCodeExporter]

I'm not certain exactly how we're using it, but the patch to WebKit to enable 
it is at https://bugs.webkit.org/show_bug.cgi?id=73621 .

I think we just set the texture usage to GL_FRAMEBUFFER_ATTACHMENT_ANGLE for 
some textures before we initialize them with TexImage2D. Later we upload some 
data to them with TexSubImage2D.

Original comment by jbauman@chromium.org on 13 Dec 2011 at 7:48

[GoogleCodeExporter]

Sorry, those extensions indeed don't depend on each other.

What might be happening is that Image::setManagedSurface is called even though 
the (renderable) surface is not in the managed pool...

Original comment by nicolas....@gmail.com on 13 Dec 2011 at 8:44

[GoogleCodeExporter]

This one is probably fixed by r912

Original comment by dan...@transgaming.com on 13 Dec 2011 at 10:48

[GoogleCodeExporter]

Original comment by dan...@transgaming.com on 16 Dec 2011 at 11:38

• Changed state: Fixed