Skip to content

A
angle
Switch branch/tag
  1. 01 Oct, 2010 1 commit
  3. 28 Sep, 2010 1 commit
  5. 27 Sep, 2010 2 commits
  7. 24 Sep, 2010 1 commit
  9. 23 Sep, 2010 2 commits
  11. 22 Sep, 2010 4 commits
  13. 21 Sep, 2010 2 commits
  15. 20 Sep, 2010 3 commits
    • I hope this will fix a generateMipmaps crash when needRenderTarget fails. · 9398a6b2
      apatrick@chromium.org authored 
      This fixes this crash in 7.0.524.0 on a user's Windows XP service pack 3 box.

0x014946f3 	[libGLESv2.dll 	- texture.cpp:1382] 	gl::Texture2D::generateMipmaps()
0x0149786f 	[libGLESv2.dll 	- libglesv2.cpp:2114] 	glGenerateMipmap
0x01c53199 	[chrome.dll 	- gles2_cmd_decoder.cc:2437] 	gpu::gles2::GLES2DecoderImpl::DoGenerateMipmap(unsigned int)
0x01c52216 	[chrome.dll 	- gles2_cmd_decoder.cc:2214] 	gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x01c4fa78 	[chrome.dll 	- cmd_parser.cc:56] 	gpu::CommandParser::ProcessCommand()
0x01c4f8ba 	[chrome.dll 	- gpu_processor.cc:100] 	gpu::GPUProcessor::ProcessCommands()
0x01ecdcce 	[chrome.dll 	- callback.h:119] 	CallbackImpl<BrowsingDataRemover,void ( BrowsingDataRemover::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x01c4f2d9 	[chrome.dll 	- callback.h:79] 	CallbackRunner<Tuple0>::Run()
0x01c4edce 	[chrome.dll 	- command_buffer_service.cc:80] 	gpu::CommandBufferService::Flush(int)
0x01d6b9b1 	[chrome.dll 	- gpu_command_buffer_stub.cc:129] 	GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)

This might be glGenerateMipmaps after a device lost.


Review URL: http://codereview.appspot.com/2227044

git-svn-id: https://angleproject.googlecode.com/svn/trunk@429 736b8ea6-26fd-11df-bfd4-992fa37f6226
    • Trying to fix bug crash when eglCreateWindowSurface (or any other code that… · e860f079
      apatrick@chromium.org authored 
      Trying to fix bug crash when eglCreateWindowSurface (or any other code that causes createDevice to be invoked) is called and CreateDevice reports DEVICELOST or NOTAVAILABLE.

This was a Windows XP service pack 3 box.

0x10002545 	[libegl.dll 	- display.cpp:340] 	egl::Display::createDevice()
0x10002912 	[libegl.dll 	- display.cpp:468] 	egl::Display::getDevice()
0x01d6a80f 	[chrome.dll 	- gpu_info_collector_win.cc:29] 	gpu_info_collector::CollectGraphicsInfo(GPUInfo *)
0x01d68eca 	[chrome.dll 	- gpu_thread.cc:104] 	GpuThread::OnEstablishChannel(int)

Previously createDevice only checked for out of memory and the ASSERT(SUCCEEDED(result)) has no effect in release builds.

I simulated the failure in a debugger and discovered a second place where a null dereference would occur in this case.

I don't think this crash is technically correct but it prevents crashes.
Review URL: http://codereview.appspot.com/2217043

git-svn-id: https://angleproject.googlecode.com/svn/trunk@428 736b8ea6-26fd-11df-bfd4-992fa37f6226
    • Texture2D::getRenderTarget does not assume that needsRenderTarget succeeded. · 4d5962cd
      apatrick@chromium.org authored 
      Specifically, it checks that mTexture is not null.

This is to fix this crash that has been happening out in the wild:

0x01444822 	[libGLESv2.dll 	- texture.cpp:1417] 	gl::Texture2D::getRenderTarget(unsigned int)
0x01445615 	[libGLESv2.dll 	- texture.cpp:2048] 	gl::Texture::TextureColorbufferProxy::getRenderTarget()
0x01453bb0 	[libGLESv2.dll 	- context.cpp:1579] 	gl::Context::applyRenderTarget(bool)
0x01455395 	[libGLESv2.dll 	- context.cpp:2413] 	gl::Context::clear(unsigned int)
0x014460c4 	[libGLESv2.dll 	- libglesv2.cpp:611] 	glClear
0x01c53b75 	[chrome.dll 	- gles2_cmd_decoder.cc:3021] 	gpu::gles2::GLES2DecoderImpl::ClearUnclearedRenderbuffers(unsigned int,gpu::gles2::FramebufferManager::FramebufferInfo *)
0x01c53cee 	[chrome.dll 	- gles2_cmd_decoder.cc:3078] 	gpu::gles2::GLES2DecoderImpl::DoFramebufferTexture2D(unsigned int,unsigned int,unsigned int,unsigned int,int)
0x01c57c7d 	[chrome.dll 	- gles2_cmd_decoder_autogen.h:756] 	gpu::gles2::GLES2DecoderImpl::HandleFramebufferTexture2D(unsigned int,gpu::gles2::FramebufferTexture2D const &)
0x01c52197 	[chrome.dll 	- gles2_cmd_decoder.cc:2214] 	gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x01c4fa78 	[chrome.dll 	- cmd_parser.cc:56] 	gpu::CommandParser::ProcessCommand()
0x01c4f8ba 	[chrome.dll 	- gpu_processor.cc:100] 	gpu::GPUProcessor::ProcessCommands()

It was a Windows XP service pack 3 box with Chrome 7.0.524.0. ANGLE was at r418 in this build. I suspect it attempted to glClear after a device lost, which caused needsRenderTarget to fail.

This will hopefully patch it up so it doesn't crash. We'll need to check we aren't assuming mTexture is not null elsewhere.


Review URL: http://codereview.appspot.com/2233045

git-svn-id: https://angleproject.googlecode.com/svn/trunk@427 736b8ea6-26fd-11df-bfd4-992fa37f6226
  17. 16 Sep, 2010 1 commit
  19. 15 Sep, 2010 5 commits
  21. 14 Sep, 2010 2 commits
  23. 11 Sep, 2010 2 commits
  25. 09 Sep, 2010 2 commits
  27. 08 Sep, 2010 1 commit
  29. 07 Sep, 2010 1 commit
  31. 01 Sep, 2010 4 commits
  33. 31 Aug, 2010 3 commits
  35. 30 Aug, 2010 1 commit
    • Implemented GL_NV_fence extension. · d3bd0ad3
      apatrick@chromium.org authored 
      I believe I have implemented all features according to the spec.
The application is to allow the Chrome command buffer scheduler to be smarter about deciding which command buffer to process. For example, if a WebGL app issued a call to ReadPixels, the scheduler will issue a fence and defer executing the ReadPixels until the status goes true. It can continue to work on other command buffers in the meantime.
I tested by modifying the vertex shader demo. After issuing the SwapBuffers i made issue a fence and loop until the status went true and verified it looped several times. I also tested that by calling FinishFence before going into the loop that is did not loop at all.

Review URL: http://codereview.appspot.com/1965043

git-svn-id: https://angleproject.googlecode.com/svn/trunk@405 736b8ea6-26fd-11df-bfd4-992fa37f6226
  37. 28 Aug, 2010 1 commit
  39. 26 Aug, 2010 1 commit