1. 10 Nov, 2017 6 commits
    • Align float access in InterleavedAttributeData perf test · e3bfefb4
      Yuly Novikov authored
      Used to crash on arm because of unaligned float access in positionColorData
      
      BUG=chromium:675997
      
      Change-Id: Iadc705986700248ce3cff9bb33fcd72c94ad1c59
      Reviewed-on: https://chromium-review.googlesource.com/764688Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
    • Vulkan: Implement Buffer updates. · 9776035d
      Jamie Madill authored
      This allows the app to update Buffer data while the data is in use
      by the GPU. For instance, uploading new vertex attribute data after
      a draw call.
      
      It introduces a StagingBuffer helper class, similar to StagingImage.
      These classes are somewhat temporary and could be redesigned.
      
      BUG=angleproject:2200
      
      Change-Id: If8634b1411779b16c2bd22cce18a5f37ed958d1c
      Reviewed-on: https://chromium-review.googlesource.com/756959Reviewed-by: 's avatarFrank Henigman <fjhenigman@chromium.org>
      Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
      Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Workaround Intel driver bug on D3D when renderering with no render target · 38d92b59
      JiangYizhou authored
      When rendering with no render target on D3D, two bugs lead to
      incorrect behavior on Intel drivers < 4815. The rendering samples
      always pass neglecting discard statement in pixel shader.
      
      Two bugs are listed bellow,
      1. When a framebuffer has no attachments, the pixel shader will be
      recompiled to drop 'SV_TARGET'. On Intel drivers, when using a pixel
      shader with no 'SV_TARGET' in a draw, pixels are always generated even
      if they should be discard by 'discard' statements.
      
      2. When a framebuffer has no attachments, ID3D11BlendState.RenderTarget
      [].RenderTargetWriteMask were set to 0 in angle. If RenderTargetWriteMask
      is 0 and rendertarget is not set, then rendering samples also pass
      neglecting discard statement in pixel shader on Intel.
      
      So we add a dummy texture as render target to workaround this issue.
      
      BUG=angleproject:2152
      
      TEST=FramebufferTest_ES31.RenderingLimitToDefaultFBOSizeWithNoAttachments/ES3_1_D3D11
      TEST=dEQP-GLES31.functional.fbo.no_attachments.*
      TEST=dEQP-GLES31.functional.state_query.integer.max_framebuffer*
      TEST=dEQP-GLES31.functional.state_query.integer.max_color_texture_samples_*
      TEST=dEQP-GLES31.functional.state_query.integer.max_depth_texture_samples_*
      TEST=dEQP-GLES31.functional.state_query.integer.max_integer_samples_*
      
      Change-Id: I1cb974703b6c05c39b731d147f7c8c4fb7b5fe68
      Reviewed-on: https://chromium-review.googlesource.com/741544Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • ES31: Add BUFFER_VARIABLE and SHADER_STORAGE_BLOCK program interfaces · 3a9090fa
      Jiajia Qin authored
      This patch collects the shader storage block members information.
      It implements getShaderStorageBlockMemberInfo and getShaderStorageBlockSize
      for OpenGL backend. Meanwhile, it implements BUFFER_VARIABLE and SHADER_STORAGE_BLOCK
      interfaces for program query.
      
      BUG=angleproject:1920
      TEST=angle_end2end_tests:ProgramInterfaceTest*
           dEQP-GLES31.functional.layout_binding.ssbo*
           dEQP-GLES31.functional.compute.basic.empty
           dEQP-GLES31.functional.compute.basic.ssbo_rw*
           dEQP-GLES31.functional.compute.basic.ssbo_local_barrier*
           dEQP-GLES31.functional.compute.basic.copy_image_to_ssbo_small
           dEQP-GLES31.functional.compute.basic.copy_ssbo_multiple_groups
           dEQP-GLES31.functional.compute.basic.copy_ssbo_multiple_invocations
           dEQP-GLES31.functional.compute.basic.copy_ssbo_single_invocation
           dEQP-GLES31.functional.compute.basic.copy_ssbo_to_image_small
           dEQP-GLES31.functional.compute.basic.shared_var*
           dEQP-GLES31.functional.compute.basic.ubo_to_ssbo*
           dEQP-GLES31.functional.compute.basic.write_multiple_arr*
           dEQP-GLES31.functional.compute.shared_var.basic_type.*
           dEQP-GLES31.functional.compute.shared_var.work_group_size.*
           dEQP-GLES31.functional.atomic_counter.*
      
      Change-Id: Ie8b81fde5a2e919aab77adb3d137c9ff2f193409
      Reviewed-on: https://chromium-review.googlesource.com/712235Reviewed-by: 's avatarOlli Etuaho <oetuaho@nvidia.com>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Commit-Queue: Jamie Madill <jmadill@chromium.org>
    • Always update HALF_FLOAT_OES type to HALF_FLOAT on Desktop GL. · 225bfa95
      Geoff Lang authored
      TEST=webgl_conformance_gl_passthrough_tests on Linux/Windows
      
      BUG=angleproject:2231
      
      Change-Id: I17c7d693e2b75726e2478925e0f22963de6ab819
      Reviewed-on: https://chromium-review.googlesource.com/763987Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
      Commit-Queue: Geoff Lang <geofflang@chromium.org>
    • Generate generic error messages for Error objects without messages. · ee6884e7
      Geoff Lang authored
      Makes sure that the debug output is fired for all generated errors.
      
      BUG=783054
      
      Change-Id: Ia30870cd950c53da892554e0862276d4be5360ac
      Reviewed-on: https://chromium-review.googlesource.com/761760
      Commit-Queue: Geoff Lang <geofflang@chromium.org>
      Reviewed-by: 's avatarAntoine Labour <piman@chromium.org>
  2. 09 Nov, 2017 9 commits
  3. 08 Nov, 2017 5 commits
  4. 07 Nov, 2017 9 commits
  5. 06 Nov, 2017 6 commits
  6. 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>
  7. 04 Nov, 2017 1 commit
  8. 03 Nov, 2017 3 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>