1. 10 Sep, 2018 1 commit
    • ES31: Support shader storage block in D3D11 compiler - Part1 · a735ee2f
      Qin Jiajia authored
      This patch is the first step to implement a basic skeleton to translate
      shader storage block to HLSL RWByteAddressBuffer.
      
      In GLSL each shader storage block is just one structured block and in API side
      it corresponds to a buffer range where stores the whole structure.
      RWStructuredBuffer is an array-like object and can have many structured
      elements. The structured element doesn't support unsized array and also have
      a small limitation on the element size. So we choose RWByteAddressBuffer as
      the counterpart of shader storage block in HLSL.
      
      Due to RWByteAddressBuffer does not support using an index to reference a
      specific location, we must use Load and Store to process the read/write
      operation of a buffer variable. Moreover, in the compiler tree, since we
      can't use variable name to get the resource value in RWByteAddressBuffer,
      we have to calculate the offset of buffer variable in a shader storage block,
      then call the corresponding wrapper function to get the right value.
      
      In this patch, we only process below situations:
          assign_to_ssbo := ssbo_access_chain = expr_no_ssbo;
          assign_from_ssbo := lvalue_no_ssbo = ssbo_access_chain;
      
      The translation is like below:
          // GLSL
          #version 310 es
          layout(local_size_x=8) in;
          layout(std140, binding = 0) buffer blockA {
              float f[8];
          } instanceA;
          layout(std140, binding = 1) buffer blockB {
              float f[8];
          };
          void main()
          {
              float data = instanceA.f[gl_LocalInvocationIndex];
              f[gl_LocalInvocationIndex] = data;
          }
      
          // HLSL
          RWByteAddressBuffer _instanceA: register(u0);
          RWByteAddressBuffer _blockB: register(u1);
          float float_Load(RWByteAddressBuffer buffer, uint loc)
          {
              float result = asfloat(buffer.Load(loc));
              return result;
          }
      
          void float_Store(RWByteAddressBuffer buffer, uint loc, float value)
          {
              buffer.Store(loc, asuint(value));
          }
      
          void gl_main()
          {
          float _data = float_Load(_instanceA, 0 + 16 * gl_LocalInvocationIndex);
          float_Store(_blockB, 0 + 16 * gl_LocalInvocationIndex, _data);
          }
      
      We will do below things in the following patches:
      1. Modify the intermediate tree to flatten all ssbo usages to:
          assign_to_ssbo := ssbo_access_chain = expr_no_ssbo;
          assign_from_ssbo := lvalue_no_ssbo = ssbo_access_chain;
      e.g.
          intanceA.a +=1;
        ->tmp = intanceA.a;
          intanceA.a = tmp + 1;
      
          while(++instanceA.a < 16) {
          }
        ->
          int PreIncrement(out int a)
          {
              a += 1;
              return a;
          }
          tmp = instanceA.a;
          while(PreIncrement(tmp) < 16) {
              instanceA.a = tmp
          }
      
      2. Add offset calculation for structure and array of arrays.
      TODOs have been marked in the corresponding places in this patch.
      
      3. Improve helper functions so that they can process all possible types.
      TODOs have been marked in the corresponding places in this patch.
      
      4. Process the swizzle situation.
      TODOs have been marked in the corresponding places in this patch.
      A possible method is to extend current helper functions like below:
          *_Load(RWByteAddressBuffer buffer, uint loc, bool isSwizzle, uint4 swizzleOffset)
      
      Bug: angleproject:1951
      Test: angle_end2end_tests
      
      Change-Id: I68ae68d5bb77d0d5627c8272627a7f689b8dc38b
      Reviewed-on: https://chromium-review.googlesource.com/848215Reviewed-by: 's avatarOlli Etuaho <oetuaho@nvidia.com>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Commit-Queue: Jiajia Qin <jiajia.qin@intel.com>
  2. 09 Sep, 2018 1 commit
  3. 07 Sep, 2018 5 commits
  4. 06 Sep, 2018 4 commits
  5. 05 Sep, 2018 6 commits
  6. 04 Sep, 2018 3 commits
  7. 03 Sep, 2018 12 commits
  8. 02 Sep, 2018 2 commits
  9. 31 Aug, 2018 6 commits
    • Vulkan: Mega-refactor to VertexArrayVk. · 88fc6da3
      Jamie Madill authored
      This moves a lot of the code in VertexArrayVk into ContextVk. Having
      the code in a centralized place makes the code a bit more organized
      since the Context is reponsible for binding state to the command
      buffers. It also makes it easier to use dirty bits to track the command
      buffer state.
      
      Bug: angleproject:2786
      Change-Id: I5cefbb14028e8f3fe651f26e997ca88f8f1c7628
      Reviewed-on: https://chromium-review.googlesource.com/1188953
      Commit-Queue: Jamie Madill <jmadill@chromium.org>
      Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
    • Vulkan: Refactor VertexArrayVk::streamIndexData. · 253038d8
      Jamie Madill authored
      This enables us to use the same code for streaming client side index
      arrays and for translating buffers.
      
      Also includes a few more code cleanups.
      
      Bug: angleproject:2786
      Change-Id: Ic615d87cb50fd0acd8ab6b63ed334da4b1c40eff
      Reviewed-on: https://chromium-review.googlesource.com/1188952
      Commit-Queue: Jamie Madill <jmadill@chromium.org>
      Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
      Reviewed-by: 's avatarFrank Henigman <fjhenigman@chromium.org>
    • Fix EGLImage pixel format validation · 2eb54074
      Yuly Novikov authored
      This fixes the scenario when EGLImage source and target have different types.
      For example, a texture is created with unsigned format using glTexImage2D,
      it is used as a source of EGLImage with eglCreateImageKHR,
      and then the EGLImage is used to create a renderbuffer target with
      glEGLImageTargetRenderbufferStorageOES.
      
      OES_EGL_image doesn't specify what should happen in this case,
      but GL implementations (Nexus 5X) seem to allow using this renderbuffer in
      glFramebufferRenderbuffer and the resulting framebuffer is complete.
      Thus, in this case, instead of checking whether the renderbuffer format
      can be used in glFramebufferRenderbuffer, we need to check whether the
      original texture can be used in glFramebufferTexture2D.
      Similarly in reverse direction.
      
      Also, for the case of source renderbuffer and target texture,
      presume that glEGLImageTargetTexture2DOES will succeed regardless of
      renderbuffer format.
      
      1. Add isRenderable and isTexturable checks to egl::Image class,
         and perform different checks depending on source type.
      2. Add isRenderable check to FramebufferAttachment and delegate EGLImage
         attachments check to egl::Image.
      3. Use these checks in validation of EGLImageTargetTexture2D,
         EGLImageTargetRenderbufferStorage and when checking attachment completeness
      
      Bug: angleproject:2567
      
      Change-Id: I8e9f4a2930a4075a4d8464f62582c6825270187e
      Reviewed-on: https://chromium-review.googlesource.com/1192585
      Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
      Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
    • Add stubs for A4A opt-in library. · abcb2b3b
      Ian Elliott authored
      Bug: angleproject:2794
      Change-Id: I9ba8abf5fdac4a1bae24bc78ece62337d24e903b
      Reviewed-on: https://chromium-review.googlesource.com/1196043
      Commit-Queue: Ian Elliott <ianelliott@google.com>
      Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
    • Add specification for ANGLE_texture_multisample. · 97dbf436
      Yunchao He authored
      The patch adds the specification for the ANGLE_texture_multisample
      extension, which enables the functionality of multisample texture.
      
      This extension is also the basis to expose multisample texture to
      web via a webgl extension.
      
      BUG=angleproject:2275
      BUG=angleproject:2775
      
      Change-Id: I21771ac1d7d3e2fad8bf5d5e0a5c5e082c8fe7a2
      Reviewed-on: https://chromium-review.googlesource.com/859917
      Commit-Queue: Yunchao He <yunchao.he@intel.com>
      Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
    • Roll VK deps forward as of 8/31/2018 · 3a181e3e
      Tobin Ehlis authored
      Roll Vulkan ANGLE dependencies forward as of 8/31/2018. This grabs some
      new validation checks including point-related checks that may be
      interesting for bug 2727.
      
      One of these checks, related to PointSize, is firing so I've added some
      code in the VK debug callback to suppress those error messages for now
      and filed a separate bug (2796) to fix that issue in the renderer.
      
      Had to overhaul the json gen script as validation changed how these are
      generated. They now use a base template with some strings replaced to
      account for platform and Vulkan header version. Offloaded all of that
      work to our existing json generate script which was previously more of
      an intelligent copy but now had some further intelligence for
      transforming from input template into final json files.
      
      Had to also roll glslang forward to meet shader validation dependency.
      
      Bug: angleproject:2727
      Change-Id: I929619cd258cddd6bc9c6743600e072c46736f5c
      Reviewed-on: https://chromium-review.googlesource.com/1194617Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
      Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org>
      Commit-Queue: Tobin Ehlis <tobine@google.com>