| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unprotected reads -> relaxed reads.
Unprotected write -> relaxed write.
The only unprotected write we had was in SkTraceEvent, which it looks like we nabbed from Chrome at some point and changed only to silence TSAN. Chrome's version uses AtomicWord / NoBarrier_Load / NoBarrier_Store, which boils down to the same as here, intptr_t / relaxed load / relaxed store.
This leaves one place where we're lying a bit to TSAN, in include/core/SkLazyPtr.h where we're doing a data-dependent consume load. We're telling TSAN it's consume, but telling any other compiler to compile it as relaxed, given how they all upgrade consume to acquire. This eliminates a barrier for us on ARM. How do you guys deal with this? Just use a consume memory order, take the hit, and hope compilers get smarter one day?
BUG=chromium:465721
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/996763002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrome's tracing framework appears to be intentionally racy on its
quick-reject checks, trading some data loss for better performance
when disabled. People will never notice the data loss, but TSAN does.
Let's assuage TSAN with some annotations.
The 'volatile' val in SK_ANNOTATE_UNPROTECTED_WRITE was making this
not compile, but that volatile doesn't really make sense there: the value we're
writing is not what we care about, it's the destination.
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
No API changes.
TBR=reed
BUG=skia:
Review URL: https://codereview.chromium.org/702883002
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On win64, long is 32-bit. Found by GCC (mingw-w64) build, where this causes an error.
This is the Skia version of https://codereview.chromium.org/374043002 .
R=bungeman@google.com, humper@google.com
Author: cjacek@gmail.com
Review URL: https://codereview.chromium.org/510923002
|
|
|
This patch includes a modified version of Chrome's trace_event.h, which provides
tracing macros that can easily integrate into the about://tracing framework.
Currently the macros link to a default implementation of the (narrow) tracing
class SkDefaultEventTracer which does nothing; next step will be to have Chrome
subclass the SkEventTracer with a shim that bolts Skia's trace events to its own,
allowing Skia's trace events to show up in about://tracing.
I've verified that this file builds properly, and when I added a simple scoped
TRACE_EVENT0 to SkCanvas::drawRect, along with some debug prints in the NOP
implementation of tracing, I saw what I expected printed to the screen.
BUG=skia:
R=nduca@chromium.org, reed@google.com, mtklein@google.com, bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/149563004
git-svn-id: http://skia.googlecode.com/svn/trunk@13256 2bbb7eff-a529-9590-31e7-b0007b416f81
|
mtklein
cjacek
commit-bot@chromium.org