Skip to content

A
angle
Switch branch/tag
  1. 17 Jan, 2012 1 commit
  3. 13 Jan, 2012 1 commit
  5. 11 Jan, 2012 1 commit
    • Allocate D3D queries from a pool for the Display. · f289ee8d
      apatrick@chromium.org authored 
      This is a workaround for an Intel bug.

The crash looks like this:

0x5f816c53	 [d3d9.dll	 + 0x00036c53]	CQuery::~CQuery()
0x5f816bec	 [d3d9.dll	 + 0x00036bec]	CQuery::`vector deleting
destructor'(unsigned int)
0x5f7e8129	 [d3d9.dll	 + 0x00008129]	CBaseObject::~CBaseObject()
0x5f9e19c7	 [libglesv2.dll	 + 0x000319c7]	gl::Fence::`vector deleting
destructor'(unsigned int)
0x5f9de78e	 [libglesv2.dll	 - context.cpp:975]	gl::Context::deleteFence(unsigned
int)
0x5f9e1491	 [libglesv2.dll	 - context.cpp:198]	gl::Context::~Context()
0x5f9e182f	 [libglesv2.dll	 - context.cpp:3936]	glDestroyContext
0x717654ec	 [libegl.dll	 -
display.cpp:749]	egl::Display::destroyContext(gl::Context *)
0x7176a3da	 [libegl.dll	 - libegl.cpp:907]	eglDestroyContext
0x64fbaf33	 [chrome.dll	 - gl_context_egl.cc:75]	gfx::GLContextEGL::Destroy()

The vendor ID is always 8086 (Intel). Not an XP issue - it's happening on Win
7.

With this change, D3D queries are only released when the display is destroyed or reset or if a very high number of D3D queries have been allocated.

Tested by stepping exercising the NV_fence entry points in a debugger.
Review URL: http://codereview.appspot.com/5534065

git-svn-id: https://angleproject.googlecode.com/svn/trunk@941 736b8ea6-26fd-11df-bfd4-992fa37f6226
  7. 10 Jan, 2012 1 commit
    • Move Context::sync to Display::sync. · a5ddde91
      apatrick@chromium.org authored 
      This is a workaround for an Intel bug.

The crash looks like this:

0x5f816c53	 [d3d9.dll	 + 0x00036c53]	CQuery::~CQuery()
0x5f816bec	 [d3d9.dll	 + 0x00036bec]	CQuery::`vector deleting
destructor'(unsigned int)
0x5f7e8129	 [d3d9.dll	 + 0x00008129]	CBaseObject::~CBaseObject()
0x5f9e19c7	 [libglesv2.dll	 + 0x000319c7]	gl::Fence::`vector deleting
destructor'(unsigned int)
0x5f9de78e	 [libglesv2.dll	 - context.cpp:975]	gl::Context::deleteFence(unsigned
int)
0x5f9e1491	 [libglesv2.dll	 - context.cpp:198]	gl::Context::~Context()
0x5f9e182f	 [libglesv2.dll	 - context.cpp:3936]	glDestroyContext
0x717654ec	 [libegl.dll	 -
display.cpp:749]	egl::Display::destroyContext(gl::Context *)
0x7176a3da	 [libegl.dll	 - libegl.cpp:907]	eglDestroyContext
0x64fbaf33	 [chrome.dll	 - gl_context_egl.cc:75]	gfx::GLContextEGL::Destroy()

This is a crash in deleteFence but the same could happen in flush. Fix for the former to follow.

The vendor ID is always 8086 (Intel). Not an XP issue - it's happening on Win
7.

Tested by stepping through a call to glFinish in the debugger and ensuring that
it sleeps but eventually returns.
Review URL: http://codereview.appspot.com/5503094

git-svn-id: https://angleproject.googlecode.com/svn/trunk@940 736b8ea6-26fd-11df-bfd4-992fa37f6226
  9. 06 Jan, 2012 1 commit
  11. 05 Jan, 2012 1 commit
  13. 22 Dec, 2011 6 commits
  15. 16 Dec, 2011 12 commits
  17. 13 Dec, 2011 6 commits
  19. 12 Dec, 2011 1 commit
  21. 07 Dec, 2011 3 commits
  23. 06 Dec, 2011 1 commit
    • Implemented EGL_NV_post_sub_buffer. · f4490e22
      apatrick@chromium.org authored 
      The change to the sample is just to demonstrate how I tested it. I won't check in the stuff under samples/.

It's not clear to me what eglPostSubBufferNV should do if EGL_POST_SUB_BUFFER_SUPPORTED_NV is false. At the moment it fails silently as though it was called on the wrong surface type:

 "If <surface> is a back-buffered surface, then the requested portion
    of the color buffer is copied to the native window associated with
    that surface. If <surface> is a single-buffered window, pixmap, or
    pbuffer surface, eglSwapBuffers and eglPostSubBufferNV have no
    effect."
Review URL: http://codereview.appspot.com/5345050

git-svn-id: https://angleproject.googlecode.com/svn/trunk@902 736b8ea6-26fd-11df-bfd4-992fa37f6226
  25. 29 Nov, 2011 5 commits