Skip to content

A
angle
Switch branch/tag
  1. 10 Nov, 2017 1 commit
  3. 09 Nov, 2017 9 commits
  5. 08 Nov, 2017 5 commits
  7. 07 Nov, 2017 9 commits
  9. 06 Nov, 2017 6 commits
  11. 05 Nov, 2017 1 commit
    • Fix dEQP test expectations. · ebb1ea2d
      Jamie Madill authored 
      These were broken in 1f4d68db because of a lack of test expectation.
Also narrow the expectations to the Quadro P400.
Also add a new GLES3 OpenGL expectation.

Note that putting in a certain configs breaks the GPU test
expectations logic on Android:

I   20.617s list_tests(01000be22172ac54)    Fail to identify GPU
I   20.617s list_tests(01000be22172ac54)    [ CRASHED      ]

BUG=angleproject:2222

Change-Id: I783c5e36414a201df64b21c6b7cf8410b2260534
Reviewed-on: https://chromium-review.googlesource.com/754591
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
  13. 04 Nov, 2017 1 commit
  15. 03 Nov, 2017 4 commits
    • Fix writing uniform block maps to HLSL output · 2ef23e2d
      Olli Etuaho authored 
      HLSL output maps structs in std140 uniform blocks to a different
layout in order to eliminate padding. The padding may have been
inserted to comply with std140 packing rules.

There used to be two issues in writing the maps: Sometimes the same
map could be written multiple times, and the maps were not being
written for uniform blocks with instance names.

Rewrite how the uniform buffer struct maps get generated so that
the code works correctly. Instead of flagging accesses, structs inside
uniform blocks are gathered from uniform block declarations. When
accesses to structs in uniform blocks are written out in OutputHLSL,
it's checked whether a mapped struct needs to be used instead of the
original one.

This code could still be optimized further by limiting mapped structs
generation to those ones that really need to be used. This is left to
be done later.

BUG=angleproject:2084
TEST=angle_end2end_tests

Change-Id: Iee24b3ef15847d2af64554ac74b8e4be5060d18c
Reviewed-on: https://chromium-review.googlesource.com/751506Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
    • Store shader interface variables as per query spec · d255123c
      Olli Etuaho authored 
      GLES 3.1 section 7.3.1.1 specifies how active variable entries should
be generated and how active variables are named. The specs for program
interface variable queries are built on top of this section.

ANGLE has already followed this spec for the most part for generating
variable lists in ProgramState, but now we also follow the naming spec
for arrays and include [0] at the end of the stored name.

This will make implementing arrays of arrays more straightforward.
Most logic for variable queries will just keep working as is when
arrays of arrays are added instead of needing more complex logic for
handling array indexing.

BUG=angleproject:2125
TEST=angle_end2end_tests

Change-Id: I3acd14253153e10bc312114b0303065da2efb506
Reviewed-on: https://chromium-review.googlesource.com/739826Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
    • Squash State dirty bits to below 64. · c67323a9
      Jamie Madill authored 
      This will dramatically speed up performance on 64-bit systems due to
the efficiency of angle::BitSet64. Improves performance of the GL
back-end on benchmarks quite a bit.

Squashes the Pack and Unpack states together. Also moves the current
value dirty bits to a single dirty bit, with a separate set for each
attribute. Also squashes a multisample dirty bit.

Also fixes an incorrect dirty bit in StateManagerGL.

We may want to implement a semi-fast version of BitSet64 for 32-bit
systems if we find performance is not satisfactory.

BUG=angleproject:2188

Change-Id: I4616782bf75413252ede3e3ac752b9ccdb9aab49
Reviewed-on: https://chromium-review.googlesource.com/722423Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Vulkan: Upgrade RGB8 textures to RGBA8. · 1d7be50a
      Jamie Madill authored 
      It's unlikely any real hardware supports this format. Hack in a fixed
fallback format for RGB8. We could consider implementing conditional
support by checking the VkPhysicalDevice properties.

This extends the Vulkan format support info in the RendererVk class
to distinguish between a Buffer and Texture format. This is closely
related to how Vulkan has separate format support bits for Linear
Textures, Optimal Textures, and Buffers. We probably won't need to
keep separate caps for Linear/Optimal, but it makes sense for Buffers
to eventually use the same format tables.

BUG=angleproject:2207

Change-Id: I8d427a99db15b314b13dd99f31aa1ac5055f0881
Reviewed-on: https://chromium-review.googlesource.com/742376
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Reviewed-by: 's avatarFrank Henigman <fjhenigman@chromium.org>
  17. 02 Nov, 2017 4 commits
    • Refactor TextureFormatMap to store an array. · 7b62cf97
      Jamie Madill authored 
      std::map lookups are already showing up as a hot spot during some
profile trace analysis. We can elimintate these by only doing a
single switch at the entry point level to convert the GL internal
format to an internal identifier or type info pointer.

This change doesn't completely fix the hot spot, since now we are
doing multiple switch statements, but it does remove the std::map
storage in TextureCapsMap. It replaces it with a flat std::array
indexed by angle::Format::ID, and gives us the option in the future
to eliminate all by one switch statement.

This should allow for a faster texture caps implementation in Vulkan.

This also fixes the missing ANGLE format entries for ETC1 compressed
formats.

BUG=angleproject:2207

Change-Id: I74ea2082e582a6790d5fde90e33246a618a2da0e
Reviewed-on: https://chromium-review.googlesource.com/742375
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
    • Add missing reset to GL multi-view dirty bits. · 0741c0f1
      Jamie Madill authored 
      This missing clear was costing quite a bit of performance on any
use case that called for a lot of state changes.

BUG=angleproject:2188

Change-Id: I98fa6c21728c1655fa9e1019ddc10ccfbdb594d8
Reviewed-on: https://chromium-review.googlesource.com/722422Reviewed-by: 's avatarFrank Henigman <fjhenigman@chromium.org>
Reviewed-by: 's avatarYuly Novikov <ynovikov@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Use active textures mask with robust init. · a59fc19f
      Jamie Madill authored 
      This should speed up clearUnclearedActiveTextures considerably.
It was showing up as a hotspot when running the aquarium demo with
the passthrough command decoder.

Also rename the complete textures mask in gl::State to an active
textures mask, since it includes incomplete textures.

BUG=angleproject:2188

Change-Id: Idf020fc49c1e74f17a8005c3b88516829767b84c
Reviewed-on: https://chromium-review.googlesource.com/722421Reviewed-by: 's avatarFrank Henigman <fjhenigman@chromium.org>
Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Vulkan: Refactor format table. · 6a89d227
      Jamie Madill authored 
      This moves the Vulkan format table to dynamically generated, but
keeps it easily indexed. Because Vulkan format support is not able
to be fully determined until runtime, we'll need a dynamic way to
build the table. The most straight-forward way seems to be to keep
a copy of the full table in the Renderer. Initializing it once at
startup makes it a bit slower to init, but saves us from any threading
shenanigans with lazy init when (and if) we ever support multi-
threaded Contexts.

BUG=angleproject:2207

Change-Id: Ib1ac879daa562c7ad1a965390be401fa2314e42c
Reviewed-on: https://chromium-review.googlesource.com/742374
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>