Skip to content

A
angle
Switch branch/tag
  1. 22 Mar, 2016 2 commits
  3. 21 Mar, 2016 1 commit
  5. 16 Mar, 2016 2 commits
    • Revert Dirty bits for VertexArray11 · 00f394ec
      Corentin Wallez authored 
      This is a combination of two reverts:
Revert "D3D11: Remove unused mRenderer from VertexArray11."
Revert "D3D11: Implement dirty bits for VertexArray11."
Reverting only the first commit would trigger warnings on the Windows
clang bot.

BUG=594509
BUG=angleproject:1327

This reverts commit fc4712b5.
This reverts commit 7d8585b8.

Change-Id: I612dbba0816d6144f71ce815701c13a798585bc7
Reviewed-on: https://chromium-review.googlesource.com/332989Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
    • Fix D3D11 DXGI format info tables · a0fc18d9
      Olli Etuaho authored 
      - Treat red/green views into depth/stencil formats as being red/green.

- Sort all AddDXGIFormat calls in a similar way and remove duplicate
  AddDXGIFormat calls.

- Add info on typeless formats.

These changes are needed to make it possible to change integer texture
DXGI formats. Native mipmap generation support will still be
determined by querying the DXGI format info table with the texture
storage format, so the TYPELESS formats will need entries there.

The changes to format info used for depth/stencil formats will not
affect existing uses of GetDXGIFormatInfo:

- In Clear11.cpp, info is queried for rtvFormat and dsvFormat. Info
  for possible values of rtvFormat and dsvFormat is not changed.

- In Renderer11::blitRenderbufferRect, info is queried for rtvFormat
  and dsvFormat.

- In Renderer11::packPixels, GetDXGIFormaInfo is used to get a
  fast-copy function. The function only exists for conversion from
  BGRA to RGBA, so the changes do not affect this.

- In Renderer11::getVertexComponentType, the component type is
  queried for vertex formats. The formats that might be queried here
  are SINT, SNORM, UINT, UNORM, or FLOAT formats with regular RGBA
  fields. Info is not changed for these.

- In TextureStorage11_Cube::createSRV, the SRV or blitSRV format is
  queried for whether it has integer on unsigned integer channels.
  This will not be affected by the changes done to the format table.

This change does not enable native mipmap generation for any new
formats to avoid any possible regressions.

BUG=angleproject:1244
TEST=angle_end2end_tests,
     dEQP-GLES3.functional.texture.mipmap.* (no regressions),
     dEQP-GLES3.functional.fbo.* (no regressions)

Change-Id: Ic5ed731ddf153ae97bce631b1634347f8d9ae75c
Reviewed-on: https://chromium-review.googlesource.com/329690Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
  7. 15 Mar, 2016 2 commits
  9. 14 Mar, 2016 2 commits
    • D3D11: Use blit SRV format for blits · 7b591905
      Olli Etuaho authored 
      blitSRVFormat stores the format that is used with ANGLE's internal
blit shaders. By default, it is the same as the normal SRV format.
For integer textures with a red channel, the RTV format is used
instead. This makes it possible to change the storage format and the
SRV format for the integer textures without affecting the blit format.

The blitSRVFormat is used when doing blits in Blit11::copyTexture().

An exception is made for depth/stencil renderbuffer blit - in these cases
it is okay to assume that the regular SRV format works for blitting.

In the future the regular SRV format for integer textures will be changed
to be different from their blit SRV format.

TEST=angle_end2end_tests
     dEQP-GLES3.functional.fbo.blit.* (no regression)
     dEQP-GLES3.functional.texture.swizzle.* (no regression)
BUG=angleproject:1244

Change-Id: Ie0e790e58ec054b64ef5983a09dbfc7754f269ca
Reviewed-on: https://chromium-review.googlesource.com/327104Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
    • Fix framebuffer attachment enum validation · 84c9f593
      Olli Etuaho authored 
      In GLES 3.0, GL_COLOR_ATTACHMENTi enums run all the way up to i=31,
and don't stop at i=15 which the validation was previously checking
against. It's acceptable to use this new enum range also for
EXT_draw_buffers, since an error will still be generated if an enum
is outside the range of maximum supported attachments.

Also, generate INVALID_ENUM when dEQP tests expect it to be generated
for color attachment number that's outside the supported range. This
is not in line with the published 3.0 spec, but that's just an
oversight in the spec document.

Also fix incorrect INVALID_VALUE error in the validation of
renderbufferStorageMultisample to INVALID_OPERATION.

BUG=angleproject:1101
TEST=dEQP-GLES3.functional.negative_api.buffer.* (all pass)

Change-Id: Ib8cf92651d29ef8fe8da0ce4bfa456cbc4d48850
Reviewed-on: https://chromium-review.googlesource.com/332140Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
  11. 12 Mar, 2016 1 commit
  13. 10 Mar, 2016 8 commits
  15. 09 Mar, 2016 2 commits
    • D3D11: Implement dirty bits for VertexArray11. · 7d8585b8
      Jamie Madill authored 
      Translated attributes are now stored in the VertexArray11 in a cache,
and only updated when dirty bits change. Currently dynamic attributes
must be re-translated every call, so these are stored in a list and
processed repeatedly.

This skips doing a lot of the VertexDataManager work for vertex
attributes that don't change between draw calls.

Current value attributes, which correspond to disabled attributes that
the program will pulls vertex data from, are owned by the Context, so
these need to be handled outside of the VertexArray11.

Further changes will be necessary to reduce the redundant work we do in
the InputLayoutCache. We shouldn't need to re-check the cache if
nothing relevant changed.

This give about a 23% performance improvement on the draw call
benchmark on my machine.

BUG=angleproject:1327

Change-Id: I7fb944d32ea7e6c78b9e478406bdb7e10a7fc05b
Reviewed-on: https://chromium-review.googlesource.com/330173Reviewed-by: 's avatarZhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Correct GLES depth 32 format. · aa57aa4c
      Frank Henigman authored 
      GL_OES_depth32 is required for DEPTH_COMPONENT32_OES render buffers.
This stops Mesa from complaining when using GLES in the back end.

BUG=angleproject:1301

Change-Id: I8c6ce6a5ce0cb5bf26157e3bb414f391a41d15c4
Reviewed-on: https://chromium-review.googlesource.com/331359Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Commit-Queue: Frank Henigman <fjhenigman@chromium.org>
  17. 08 Mar, 2016 8 commits
  19. 07 Mar, 2016 5 commits
  21. 05 Mar, 2016 3 commits
    • Return the correct count from getAttachedShaders · 586bc55c
      Olli Etuaho authored 
      The count should be the total amount of shader ids written. Before
this patch the code used to write the amount of attached shaders
to count regardless of the value of maxCount.

BUG=angleproject:1101
TEST=dEQP-GLES3.functional.state_query.shader.*

Change-Id: I5ae729748c7809f03fd496c927a76f60398d2b42
Reviewed-on: https://chromium-review.googlesource.com/329865Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
    • D3D: Refactor VertexDataManager attribute storage. · e18eb970
      Jamie Madill authored 
      Instead of splitting attributes into 'active enabled' and 'active
disabled', split them into static/dynamic/direct/current value, and
handle each group invidually. This also will allow the dirty bits
code to call in to the VertexDataManager separately for each type
of necessary vertex data translation, and skip it entirely for
direct buffer storage.

Should be a refactoring patch only.

BUG=angleproject:1327

Change-Id: I53cb5672054d99ae68e9aa2e5a3c046a002e360d
Reviewed-on: https://chromium-review.googlesource.com/330171Reviewed-by: 's avatarZhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • D3D: Use a single D3D buffer per static vertex attribute. · e36b92d4
      Jamie Madill authored 
      The current caching logic stores multiple static attributes in a single
buffer if the attributes share a D3D buffer - sometimes.
If a buffer is 'committed' (has been used in a draw) then we would
make a new D3D buffer for the next set of static attributes.

Instead use a simpler scheme of a single D3D buffer for each
static attribute. Also change rx::VertexBuffer to a reference
counted class. This simplifies the caching logic for static vertex
buffers (translated attributes) considerably. We only need to
release the buffers when the ref count is zero, and ensure we
track the ref count correctly when bound to D3D.

This leads the way towards using a simpler dirty bit scheme for
intelligent state updates, and less overhead doing work with
buffer state updates.

BUG=angleproject:1327

Change-Id: I99461d50b9663024eaa654cd56b42a63f1416d08
Reviewed-on: https://chromium-review.googlesource.com/330170Reviewed-by: 's avatarZhenyao Mo <zmo@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
  23. 04 Mar, 2016 4 commits