|
9d737966
|
2019-08-14T12:25:12
|
|
Standardize copyright notices to project style
For all "ANGLE Project" copyrights, standardize to the format specified
by the style guide. Changes:
- "Copyright (c)" and "Copyright(c)" changed to just "Copyright".
- Removed the second half of date ranges ("Y1Y1-Y2Y2"->"Y1Y1").
- Fixed a small number of files that had no copyright date using the
initial commit year from the version control history.
- Fixed one instance of copyright being "The ANGLE Project" rather than
"The ANGLE Project Authors"
These changes are applied both to the copyright of source file, and
where applicable to copyright statements that are generated by
templates.
BUG=angleproject:3811
Change-Id: I973dd65e4ef9deeba232d5be74c768256a0eb2e5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1754397
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@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>
|
|
|
888081d5
|
2018-02-27T00:24:46
|
|
D3D11: Refactor dependent Framebuffer state changes.
Previously, when a state change would cause a Texture to
recreate its storage specific to D3D11, we would use a
dependent notification from RenderTarget11 to Framebuffer11
to re-check internal dirty bits. In this new method, we
instead set dirty bits on the gl::Frambuffer directly. This
also means we use fewer internal objects for these
notifications, because we share the same structures between
the D3D11 back-end notifications and the top-level notifications
we use for Robust init and Framebuffer completeness.
This also allows us to get rid of one "if" that we check on
every draw call in D3D11.
This also introduces a dirty bits guard concept - a shadow
set of dirty bits that is checked in dependent state changes
to ensure that extra bits aren't set inside syncState.
This also implements Framebuffer dirty bits for the D3D9
back-end. This has the side effect of cleaning up the
"null colorbuffer" D3D9 workaround.
Bug: angleproject:2372
Change-Id: Ie346d39030f4f6df583d735685b0babea4e745a8
Reviewed-on: https://chromium-review.googlesource.com/936691
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
acf2f3ad
|
2017-11-21T19:22:44
|
|
Apply Chromium style fixes.
This addresses several minor code quality issues that are validated
in Chromium, but not yet applied to ANGLE:
* constructors and destructors must be defined out-of-line
* auto is not allowed for simple pointer types
* use override everywhere instead of virtual
* virtual functions must also be defined out-of-line
Slightly reduces binary size for me (~2k on Win, 150k on Linux).
Bug: angleproject:1569
Change-Id: I073ca3365188caf5f29fb28d9eb207903c1843e6
Reviewed-on: https://chromium-review.googlesource.com/779959
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
ea84f6ff
|
2017-09-20T13:20:30
|
|
Pass Context to Framebuffer11 dirty callback.
This allows us to call StateManager11::invalidateRenderTarget from the
Framebuffer11::signal function, which will then trigger state refresh
on the next draw call.
This requires passing Context through a few more Renderbuffer methods,
and reorganizing the RenderTarget signalling so that it doesn't signal
dirty in the destructor. Instead they are signaled as they are
destroyed in the containing classes.
BUG=angleproject:2151
Change-Id: I4cf575e4a01b48275ff78d75bc55b2d1fced591d
Reviewed-on: https://chromium-review.googlesource.com/673139
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
|
|
6938285b
|
2017-07-21T16:38:44
|
|
Fix BlitFramebuffer validation for BGRA sources and targets.
It is legal to blit between GL_RGBA8 and GL_BGRA8 sources and
destinations when resolving multisampled renderbuffers. Expand
BlitFramebuffer's validation to handle this case.
Query GL_MAX_VERTEX_OUTPUT_COMPONENTS on the Core Profile to work
around an error generated on macOS when querying
GL_MAX_VARYING_COMPONENTS.
Expand the BlitFramebuffer tests to cover these cases and start
running them on the OpenGL backend.
Fix detectition of multisampled D3D11 rendertargets when the sample count
is 1.
BUG=angleproject:891
Change-Id: Ief5531756651caa66f612e647d3d5c05c8c51ff5
Reviewed-on: https://chromium-review.googlesource.com/587459
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
1fbc59fe
|
2016-02-24T15:25:51
|
|
D3D11: Enable dirty bits for Framebuffer11.
This patch works using a notification scheme - whenever a Texture or
Renderbuffer changes in such a way as to recreate its RenderTarget, we
pass a signal to the Framebuffer to invalidate some internal state.
Everything is entirely tracked in the Renderer11 layer, and the GL
layer is left untouched.
A RenderTarget11 now tracks points to which it is bound, and the
Framebuffer11 is mostly responsible for managing those links.
The three locations where we notify a Framebuffer when its bound
RenderTargets might be dirty are:
1) RenderTarget11::~RenderTarget
2) EGLImageD3D::copyToLocalRendertarget
3) TextureStorage11_2D::useLevelZeroWorkaroundTexture
This patch gives about a 10% score increase in the D3D11 draw call
benchmark on my system.
BUG=angleproject:1260
Change-Id: Ide38aeadff4a2681bf5bd685e8ca3c9e2612a380
Reviewed-on: https://chromium-review.googlesource.com/327255
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
8cf813c7
|
2015-05-04T12:55:18
|
|
Query attachment render targets from Impl class.
*re-land with fix for D3D9*
This allows us to eradicate the GetAttachmentRenderTarget methods.
This improves potential performance, at the cost of exposing a
Renderer-specific function at the API object level.
BUG=angleproject:963
Change-Id: Iee9f985ddaed668df0c622228004b348eb4d2ea8
Reviewed-on: https://chromium-review.googlesource.com/269006
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
e737b06c
|
2015-05-04T16:53:56
|
|
Revert "Query attachment render targets from Impl class."
D3D9 bug is causing failures in the WebGL depth texture test.
BUG=angleproject:963
This reverts commit 804e8436f91733e1d0f769ec10082e4741f2e549.
Change-Id: I660f05033360e97258794138cb50b604f5ac16b6
Reviewed-on: https://chromium-review.googlesource.com/269005
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
804e8436
|
2015-04-30T09:42:23
|
|
Query attachment render targets from Impl class.
This allows us to eradicate the GetAttachmentRenderTarget methods.
This improves potential performance, at the cost of exposing a
Renderer-specific function at the API object level.
BUG=angleproject:963
Change-Id: Ifc227b5f42e87bd4deb451d685618cf61fea39f1
Reviewed-on: https://chromium-review.googlesource.com/263491
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Jamie Madill <jmadill@chromium.org>
|
|
|
f0d10f89
|
2015-03-31T12:56:52
|
|
Replace non-copyable macro with a helper class.
This class provides a simpler scheme for blocking default copy
and assignment operators. It also reduces the amount of code
needed since it's inherited to child classes. This also fixes
the conflict between our macro and the same-named macro in
Chromium code.
BUG=angleproject:956
Change-Id: If0dc72aa3f63fbc7b8fa34907418821c64c39e2f
Reviewed-on: https://chromium-review.googlesource.com/263257
Tested-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
|
|
c2e75afa
|
2015-01-05T14:26:24
|
|
Rename RenderTarget to RenderTargetD3D and move it into the d3d folder.
BUG=angle:681
Change-Id: I1946e01ce09d99405c318723c254fe300cc5ac53
Reviewed-on: https://chromium-review.googlesource.com/238471
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Tested-by: Geoff Lang <geofflang@chromium.org>
|