AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Remove mac buffer impl war

Browse Source 
BUG=skia:

Review URL: https://codereview.chromium.org/1419203002
This commit is contained in:
joshualitt 2015-10-23 07:33:54 -07:00 committed by Commit bot
parent 33eefcd58b
commit ccdbc1d062
2 changed files with 2 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
include/gpu/gl/GrGLConfig.h
View File

@ -135,35 +135,4 @@
#define GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE 0
#endif
/**
* There is a strange bug that occurs on Macs with NVIDIA GPUs. We don't
* fully understand it. When (element) array buffers are continually
* respecified using glBufferData performance can fall off of a cliff. The
* driver winds up performing many DMA mapping / unmappings and chews up ~50% of
* the core. However, it has been observed that occaisonally respecifiying the
* buffer using glBufferData and then writing data using glBufferSubData
* prevents the bad behavior.
*
* There is a lot of uncertainty around this issue. In Chrome backgrounding
* the tab somehow initiates this behavior and we don't know what the connection
* is. Another observation is that Chrome's cmd buffer server will actually
* create a buffer full of zeros when it sees a NULL data param (for security
* reasons). If this is disabled and NULL is actually passed all the way to the
* driver then the workaround doesn't help.
*
* The issue is tracked at:
* http://code.google.com/p/chromium/issues/detail?id=114865
*
* When the workaround is enabled we will use the glBufferData / glBufferSubData
* trick every 128 array buffer uploads.
*
* Hopefully we will understand this better and have a cleaner fix or get a
* OS/driver level fix.
*/
#if (defined(SK_BUILD_FOR_MAC) && !GR_GL_USE_BUFFER_DATA_NULL_HINT)
# define GR_GL_MAC_BUFFER_OBJECT_PERFOMANCE_WORKAROUND 1
#else
# define GR_GL_MAC_BUFFER_OBJECT_PERFOMANCE_WORKAROUND 0
#endif
#endif

22
src/gpu/gl/GrGLBufferImpl.cpp
View File

@ -195,26 +195,8 @@ bool GrGLBufferImpl::updateData(GrGLGpu* gpu, const void* src, size_t srcSizeInB
// Note that we're cheating on the size here. Currently no methods
// allow a partial update that preserves contents of non-updated
// portions of the buffer (map() does a glBufferData(..size, nullptr..))
bool doSubData = false;
#if GR_GL_MAC_BUFFER_OBJECT_PERFOMANCE_WORKAROUND
static int N = 0;
// 128 was chosen experimentally. At 256 a slight hitchiness was noticed
// when dragging a Chromium window around with a canvas tab backgrounded.
doSubData = 0 == (N % 128);
++N;
#endif
if (doSubData) {
// The workaround is to do a glBufferData followed by glBufferSubData.
// Chromium's command buffer may turn a glBufferSubData where the size
// exactly matches the buffer size into a glBufferData. So we tack 1
// extra byte onto the glBufferData.
fGLSizeInBytes = srcSizeInBytes + 1;
GL_CALL(gpu, BufferData(fBufferType, fGLSizeInBytes, nullptr, usage));
GL_CALL(gpu, BufferSubData(fBufferType, 0, srcSizeInBytes, src));
} else {
fGLSizeInBytes = srcSizeInBytes;
GL_CALL(gpu, BufferData(fBufferType, fGLSizeInBytes, src, usage));
}
fGLSizeInBytes = srcSizeInBytes;
GL_CALL(gpu, BufferData(fBufferType, fGLSizeInBytes, src, usage));
#endif
return true;
}