Skip to content

A
angle
Switch branch/tag
  1. 10 Sep, 2018 3 commits
    • Vulkan: Fix FragCoord scaling when a viewport is applied. · 8e9d2340
      Jamie Madill authored 
      We were using the pivot based on the viewport dimensions which is
only valid if the viewport is the size of the framebuffer. The more
correct pivot size is actually based on the Framebuffer height.

Also updates the driver uniforms block to be a bit simpler.

Bug: angleproject:2598
Change-Id: I1cb500cded7141d10e8db6862b6ed29758cc7fb4
Reviewed-on: https://chromium-review.googlesource.com/1214205
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: 's avatarFrank Henigman <fjhenigman@chromium.org>
    • Clean up TextureStorage11_2DMultisample · 480edb8c
      Olli Etuaho authored 
      This de-duplicates functionality from TextureStorage11_EGLImage and
TextureStorage11_2DMultisample. Neither of those supports changing the
associated images or image access in shaders.

Multisampled textures also cannot be compressed, so the size doesn't
need to be adjusted according to block size.

BUG=angleproject:2275
TEST=angle_end2end_tests

Change-Id: I45bc573584065bf4f528f883435fadfbd7281077
Reviewed-on: https://chromium-review.googlesource.com/1216002Reviewed-by: 's avatarCorentin Wallez <cwallez@chromium.org>
Reviewed-by: 's avatarJamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
    • 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>
  3. 09 Sep, 2018 1 commit
  5. 07 Sep, 2018 5 commits
  7. 06 Sep, 2018 4 commits
  9. 05 Sep, 2018 6 commits
  11. 04 Sep, 2018 3 commits
  13. 03 Sep, 2018 12 commits
  15. 02 Sep, 2018 2 commits
  17. 31 Aug, 2018 4 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>