|
76d3e6e0
|
2012-10-31T19:55:33
|
|
Rename renderer namespace to rx
Trac #21999
Author: Shannon Woods
Signed-off-by: Daniel Koch
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1379 736b8ea6-26fd-11df-bfd4-992fa37f6226
|
|
|
2507f41e
|
2012-10-31T18:46:48
|
|
Split Renderer into version independent interface and Renderer9 implementation.
TRAC #21963
Signed-off-by: Daniel Koch
Author: Nicolas Capens
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1358 736b8ea6-26fd-11df-bfd4-992fa37f6226
|
|
|
ef21ab29
|
2012-10-31T17:52:47
|
|
Move query and sync support to Renderer
Trac #21727
git-svn-id: https://angleproject.googlecode.com/svn/branches/dx11proto@1331 736b8ea6-26fd-11df-bfd4-992fa37f6226
|
|
563c0a53
|
2012-03-23T21:18:42
|
|
Fence has pointer to the associated egl::Display.
I think the assumption that getDisplay() returns a valid display in the Fence destructor is wrong.
I'm trying to fix a crash in the field that looks like this:
Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000000 )
0x69582e38 [libglesv2.dll - fence.cpp:27 gl::Fence::~Fence()
0x69582f29 [libglesv2.dll + 0x00022f29] gl::Fence::`scalar deleting destructor'(unsigned int)
0x6958077d [libglesv2.dll - context.cpp:1020 gl::Context::deleteFence(unsigned int)
0x69582b9b [libglesv2.dll - context.cpp:195 gl::Context::~Context()
0x69582dcb [libglesv2.dll + 0x00022dcb] gl::Context::`scalar deleting destructor'(unsigned int)
0x69582df2 [libglesv2.dll - context.cpp:4259 glDestroyContext
0x73166ab8 [libegl.dll - display.cpp:768 egl::Display::destroyContext(gl::Context *)
0x73168393 [libegl.dll - libegl.cpp:861 eglDestroyContext
0x6e18f1db [chrome.dll - gl_context_egl.cc:76 gfx::GLContextEGL::Destroy()
0x6e18f40d [chrome.dll - gl_context_egl.cc:43 gfx::GLContextEGL::~GLContextEGL()
Here's the disassembly:
69582E21 push esi
69582E22 mov esi,ecx
69582E24 cmp dword ptr [esi+4],0
69582E28 mov dword ptr [esi],695CBBE0h
69582E2E je 69582E3F
69582E30 call 695743F5 // this is getDisplay()
69582E35 push dword ptr [esi+4]
69582E38 mov edx,dword ptr [eax] // crashes here because EAX is zero
69582E3A mov ecx,eax
69582E3C call dword ptr [edx+24h] // this is freeEventQuery()
69582E3F pop esi
69582E40 ret
It looks like getDisplay() returns null.
http://code.google.com/p/chromium/issues/detail?id=117817
Review URL: https://codereview.appspot.com/5875044
git-svn-id: https://angleproject.googlecode.com/svn/trunk@1008 736b8ea6-26fd-11df-bfd4-992fa37f6226
|
|
|
f289ee8d
|
2012-01-11T20:03:29
|
|
Allocate D3D queries from a pool for the Display.
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
|
|
|
6f5c5fc0
|
2011-11-09T17:46:39
|
|
Check for all device lost errors.
TRAC #18606
Signed-off-by: Daniel Koch
Author: Shannon Woods
git-svn-id: https://angleproject.googlecode.com/svn/trunk@844 736b8ea6-26fd-11df-bfd4-992fa37f6226
|
|
|
d3bd0ad3
|
2010-08-30T18:55:36
|
|
Implemented GL_NV_fence extension.
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
|