|
9bda9a79
|
2022-10-22T22:05:11
|
|
Add Store Ops to pixel local storage
Browsers will need the ability to pre-empt pixel local storage, which
means every plane will need a backing store to dump to. Store Ops allow
the app to still avoid memory transactions at the end of PLS even if
their plane has a backing texture.
Bug: angleproject:7279
Change-Id: I3a3efa21773f87c03cd346a996e3c638028c68ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3974652
Commit-Queue: Chris Dalton <chris@rive.app>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
3605b399
|
2022-10-20T17:00:02
|
|
Move PLS clear values back into context state
The API that required packing raw data into a buffer was un-ergonomic
for developers and difficult to implement for WebGL vendors.
Bug: angleproject:7279
Change-Id: If7c98908c285462c5775e8e2d8811883be139f64
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3972376
Commit-Queue: Chris Dalton <chris@rive.app>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9f693aa3
|
2022-10-22T14:45:59
|
|
Implement an allow list for PLS
In order to guarantee no data is lost while using the
EXT_shader_pixel_local_storage extension, we need to restrict
applications to a small subset of commands while pixel local storage is
active. This CL implements the allow list for GL entrypoints using
wildcard matching inside the code generator, and adds custom validation
for the more specific restrictions that go into effect when PLS is
active.
Bug: angleproject:7279
Change-Id: I5dd48bd93c10e8775f32be32a4fcf17855eb2f0e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3932552
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
a7dc51f2
|
2022-10-01T08:49:11
|
|
Add a framebuffer fetch implementation of PLS
The framebuffer fetch implementation works by attaching PLS backing
textures to the framebuffer, and then rewriting PLS uniforms as "inout"
fragment variables. The compiler's existing machinery takes it from
there and makes it work on GL and Vulkan, and soon Metal.
EXT_shader_framebuffer_fetch is now the preferred backend for pixel
local storage, but we also use EXT_shader_framebuffer_fetch_non_coherent
if shader images can't be coherent. This is especially interesting for
Vulkan, since noncoherent framebuffer fetch is possible without any
extensions.
Bug: angleproject:7279
Bug: angleproject:7683
Bug: angleproject:7684
Bug: angleproject:7724
Change-Id: I33f3b2c6df9a5709969d9165c448ea71b096c9e1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3900142
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
8b2aff28
|
2022-09-12T10:27:28
|
|
Implement the ANGLE_shader_pixel_local_storage API
Implements the OpenGL ES API for ANGLE_shader_pixel_local_storage and
adds thorough validation and testing as outlined in the spec. This
feature is still implemented entirely in the frontend, but the extension
now works end-to-end with a passing test suite, and can be used
externally. Over time we can start gradually moving the implementation
into backends as appropriate.
Bug: angleproject:7279
Bug: angleproject:7647
Change-Id: I1c861a0fca96423be02e17bbe1fb7f57b99ea63f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3886462
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
7822c9df
|
2022-09-10T14:17:21
|
|
Delete FramebufferPixelLocalClearValue{f,i,ui}vANGLE
Instead, BeginPixelLocalStorageANGLE just accepts a buffer containing
clear values. In WebGL, the clear data can be an array of Numbers. This
makes the API smaller, simpler, and less stateful and bug-prone.
Bug: angleproject:7279
Change-Id: I8b3fa4ae7f20ba3ad72beb01f275acf50eee803c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3888960
Commit-Queue: Chris Dalton <chris@rive.app>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6fde3568
|
2022-08-09T16:42:17
|
|
Spec out the PLS client API
Drafts the additions to the OpenGL ES 3.0 spec for pixel local storage.
Bug: angleproject:7279
Change-Id: Ibc0d227142ac51f5d3820f27c9114779d846ffc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3824171
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
4a636cdd
|
2022-07-20T22:44:30
|
|
Require all PLS formats to consume exactly 4 bytes of storage
D3D 11.0 UAVs only support R32_FLOAT, R32_UINT, R32_SINT formats.
EXT_shader_pixel_local_storage explicitly states that all PLS variables
consume exactly 4 bytes.
ESSL images can only have both read and write access if their format is
r32f, r32i, r32ui. (We were able to circumvent this via aliasing, but it
was a huge source of bugs.)
There is a large precedent for only supporting 4 bytes of storage in the
capabilities we use for PLS, so this CL removes support for all PLS
storage formats that are not 4 bytes. It also implements an "R32" mode
for PLS, that does manual packing and unpacking of r32* image formats.
If the application wants larger formats, it can always define multiple
PLS planes and piece them together.
Next up we ought to be able to support rg16* types with more
packing/unpacking.
With aliasing gone, and with a bit of tweaking, the PLS tests now pass
on the Pixel 4 GLES bot.
Bug: angleproject:7279
Bug: angleproject:7388
Bug: angleproject:7524
Bug: angleproject:7527
Change-Id: I6b8f62c2428ade6cb5413e33360d734e55dda0eb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3782579
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
aa7e6751
|
2022-07-15T23:33:30
|
|
Automatically enable early_fragment_tests when PLS is declared
When PLS is polyfilled by shader images, we need early_fragment_tests in
order to match the same depth/stencil behavior as when it is implemented
as framebuffer fetch.
Bug: angleproject:7279
Change-Id: I37f5a8682cc96a14ef247d53ed243e4aceb15f39
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3767535
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
c460c299
|
2022-06-21T11:20:45
|
|
Implement GLSL additions for ANGLE_shader_pixel_local_storage
Specs out, implements, and thoroughly tests the GLSL additions for
ANGLE_shader_pixel_local_storage. Adds a simple transformation that
rewrites PLS directly into shader images. Updates the existing PLS tests
to use the newly built-in PLS features and ensures they continue
passing.
For now, applications call glBindImageTexture to configure their pixel
local storage. The OpenGL ES API side of this extension will follow
shortly.
Bug: angleproject:7279
Change-Id: I141183069b5cbfcca01cbb77b5b36d3e5f834bf5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3761876
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
15cc0013
|
2022-07-14T23:32:05
|
|
Add a GL_ANGLE_shader_pixel_local_storage extension
Plumbs through "GL_ANGLE_shader_pixel_local_storage" and
"GL_ANGLE_shader_pixel_local_storage_coherent" extension strings
advertised by ANGLE and stubs out an initial spec document. This change
doesn't add any new procedures or shader constructs, but it does allow
the PLS tests to start checking for the real extension strings and
requiring the GL_ANGLE_shader_pixel_local_storage extension.
Bug: angleproject:7279
Change-Id: I36877fe4117185a2121f803288123cd69a447cf3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3739590
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|