|
7d53c60b
|
2019-02-15T21:06:42
|
|
ParallelCompile: use the native extensions
This enhances to use the native parallel compile extensions if
available.
Bug: 873724
Change-Id: I0aaed314accd75e1bfa596b322225b56d729d3a6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1475234
Commit-Queue: Jie A Chen <jie.a.chen@intel.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
c09ae15c
|
2019-02-01T14:16:32
|
|
Enable -Wextra-semi and -Wextra-semi-stmt.
This will prevent users from accidentally making semicolon errors in
the future.
Bug: chromium:926235
Change-Id: I79a6fa376fb1ad8f0fcf1b65b1f572a035d1f4e9
Reviewed-on: https://chromium-review.googlesource.com/c/1446493
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a100d8f4
|
2018-12-29T16:39:55
|
|
ParallelCompile: add GL backend support
For GL backend, at first each worker thread must have a naitve context
for its own to work in. These worker contexts have to be shared from
the main context, so that all shader and program objects are seen in
any context. This extends backend displays to create and destroy the
worker contexts. RendererGL manages and allocates them to the worker
threads. ShaderImpl has a new compile method added to do the actual
glCompile work in worker thread. The ProgramGL's link method is broken
down by introducing the LinkEventGL class.
Bug: chromium:849576
Change-Id: Idc2c51b4b6c978781ae77810e62c480acc67ebb5
Reviewed-on: https://chromium-review.googlesource.com/c/1373015
Commit-Queue: Jie A Chen <jie.a.chen@intel.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
ab2bfa81
|
2019-01-15T19:06:47
|
|
Enable Chromium clang style plugin for libANGLE.
This fixes a few style warnings:
* auto should not deduce to raw pointer type
* inlined virtual methods are not allowed
* non-trivial constructors and destructors should be explicit
* inlined non-trivial constructors should not be in-class
* missing override keywords
Bug: angleproject:3069
Change-Id: I3b3e55683691da3ebf6da06a5d3c729c71b6ee53
Reviewed-on: https://chromium-review.googlesource.com/c/1407640
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
|
|
|
b980c563
|
2018-11-27T11:34:27
|
|
Reformat all cpp and h files.
This applies git cl format --full to all ANGLE sources.
Bug: angleproject:2986
Change-Id: Ib504e618c1589332a37e97696cdc3515d739308f
Reviewed-on: https://chromium-review.googlesource.com/c/1351367
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7ae70d8f
|
2018-07-06T13:47:01
|
|
ParallelCompile: Parallelize D3D linking
This adds a new linking state to Program. If a Program is in linking
state, on the one hand the foreground thread may continue issuing more
GL calls, and on the other hand the background linking threads may be
accessing Program internally too. Without a proper constraint there
must be conflicts between them. For this purpose, we block any further
GL calls to Program until it's actually linked. In addition, we
prohibit parallel linking an active program, so that ProgramD3D does
not have to worry about such similar conflicts.
Also changes the WorkerThread to support limiting the number of
concurrently running worker threads.
BUG=chromium:849576
Change-Id: I52618647539323f8bf27201320bdf7301c4982e6
Reviewed-on: https://chromium-review.googlesource.com/1127495
Commit-Queue: Jie A Chen <jie.a.chen@intel.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
01074255
|
2016-11-28T15:55:51
|
|
D3D: Implement multi-thread shader compilation.
Choose to use std::async for now to implement multi-threaded compiles.
This should work across platforms and also be usable for other
threading tasks. Note that std::async does not have a good way to
wait for multiple std::futures. Also the Linux compile of std::async
is broken due to a bug in an old STL version, so disable it on this
platform.
The implementation uses a static polymorphism approach, which should
have very good performance (no virtual calls).
This design leaves the door open for other future implementations,
such as a Win32 thread pool, or one based on angle::Platform.
BUG=angleproject:422
Change-Id: Ia2f13c3af0339efaca1d19b40b3e08ecca61b8e8
Reviewed-on: https://chromium-review.googlesource.com/413712
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|