Skip to content

A
angle
Switch branch/tag
  1. 27 Sep, 2018 1 commit
  3. 26 Sep, 2018 7 commits
  5. 25 Sep, 2018 12 commits
  7. 24 Sep, 2018 3 commits
  9. 22 Sep, 2018 1 commit
  11. 21 Sep, 2018 8 commits
  13. 20 Sep, 2018 2 commits
  15. 19 Sep, 2018 6 commits
    • Use FastVector in angle::Subject. · d511948b
      Jamie Madill authored 
      This improves object binding performance. We no longer need to check
two containers when manipulating the bound subjects/observers.

Bug: angleproject:2763
Change-Id: I0ccb2e76be47bd8a28fba5a0c3eff857aa166bb7
Reviewed-on: https://chromium-review.googlesource.com/1227795
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarYuly Novikov <ynovikov@chromium.org>
Reviewed-by: 's avatarShahbaz Youssefi <syoussefi@chromium.org>
    • Fix FastVector::resize when count < size. · 20c01390
      Jamie Madill authored 
      Also update a test to trigger the bug.

Bug: angleproject:2763
Change-Id: I8e6735320a34dcc4cc8beee1b7a22b768912f24f
Reviewed-on: https://chromium-review.googlesource.com/1234338Reviewed-by: 's avatarShahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Fix trying to clear nonexistent FBO attachments · dbce1f89
      Olli Etuaho authored 
      The D3D11 backend used to crash to a null pointer dereference if a
glClearBuffer call was done on a nonexistent depth or stencil
attachment. Validate for these conditions so that the backend can't
crash in this case.

BUG=angleproject:2827
TEST=angle_end2end_tests

Change-Id: Iecee78d213d11d492d52f246b4b068e8b6f34244
Reviewed-on: https://chromium-review.googlesource.com/1233675Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
    • Re-land "Add FastVector for simple dynamic vector cases." · bf7cfbea
      Jamie Madill authored 
      Re-land fixes memory leak and adds inline to a few more methods.

This optimized vector keeps an initial fixed size storage but has
unbounded growth like a normal std::vector. It operates like a
FixedVector initially but then switches the storage to an allocated
pool when the element count exceeds the array limit.

This gives fast performance in the small case since no dynamic
allocation is needed. It also handles the "slow" big case.

Bug: angleproject:2763
Change-Id: Ib3cc7b652a14ed346528bf15820023ab0b5317ce
Reviewed-on: https://chromium-review.googlesource.com/1233453
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarYuly Novikov <ynovikov@chromium.org>
    • Remove writeResource down readPixels path · 2ec817bb
      Tobin Ehlis authored 
      This is not needed and results in creating an empty command buffer.

Bug: angleproject:2818
Change-Id: I06e5542cb3cd819c18758c909b8fcb624b074874
Reviewed-on: https://chromium-review.googlesource.com/1232981Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Tobin Ehlis <tobine@google.com>
    • Add ANGLE_multiview_multisample · 2c8f0845
      Olli Etuaho authored 
      We add a novel multiview multisampling extension that includes the
requirement to explicitly resolve the multisampled framebuffer. The
explicit resolve is much more straightforward to implement on top of
OpenGL and D3D11 than implicit resolve found in the native extension
OVR_multiview_multisampled_render_to_texture. It also has predictable
performance characteristics.

The extension allows multiview drawing to 2D multisample texture
arrays and is now enabled on both the GL backend and the D3D11
backend. The implementation is fairly simple, as it involves just
small changes in validation to allow multisampled framebuffer
attachments. The multiview rendering logic is exactly the same
regardless of whether multisampling is enabled.

For the most part the same tests are used to test both multisampled
and non-multisampled rendering. The tests will use a different
framebuffer setup depending on the test param. They resolve the
multisampled framebuffer to a non-multisampled framebuffer prior to
any readbacks from the framebuffer.

Some of the tests are adjusted so that they have the correct sub-pixel
positioning of multisampled quads, so there won't be any pixels that
would be just partially covered.

The tests don't have any tolerance for partially covered pixels - if
we find any platforms where the tests run into a sub-pixel positioning
corner case, tolerance may need to be added later.

BUG=angleproject:2775
TEST=angle_end2end_tests

Change-Id: I590d7f300a92ea5439f2720d9db14a7976db2e1d
Reviewed-on: https://chromium-review.googlesource.com/1221214
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>