|
8f6d1af9
|
2020-03-19T14:35:48
|
|
Vulkan: Implement EXT_texture_format_sRGB_override
Implemented support for EXT_texture_format_sRGB_override
This is done by creating new imageviews for textures with sRGB
overridden that reinterpret the format to its sRGB counterpart.
As preparation for this, textures that use this feature are
reallocated with VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT. This will
have a performance cost for textures that use this feature, but
should have no performance cost for regular textures, since they
will not have this bit set.
Bug: angleproject:4561
Test: angle_end2end_tests --gtest_filter=SRGBTextureTest.*Vulkan*
Change-Id: Iba25f1f2b0a7227959c1cb4ba6e3ca8311c20d06
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2152145
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
3ff24d6f
|
2020-05-10T18:16:55
|
|
Vulkan: Add dedicated allocation support to MemoryObjectVk
Add a VkMemoryDedicatedAllocateInfo to the vkAllocateMemory pNext chain
if the client specifies the memory object was a dedicated allocation.
We don't yet support suballocation of external memory objects, so all
allocations are already effectively dedicated allocations regardless
of whether vulkan requires it.
The spec requires that memory passed to vkBindImageMemory be created with
a VkMemoryDedicatedAllocateInfo if the driver requires dedicated
allocations for that VkImage. If the driver does not require a dedicated
allocation, there actually seems to be no explicit requirement to use
this structure even if it was passed in at allocation time.
Bug: angleproject:4627
Change-Id: I8a660e871bdf72815815f0c0b3000f3b0570bd2d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2192501
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
|
|
|
dae210e6
|
2020-05-04T00:44:16
|
|
Fix validation errors & re-enable VulkanExternalImageTest clear tests
These tests previously encountered errors attempting to transfer images
from VK_QUEUE_FAMILY_EXTERNAL back to itself (this is not valid because
one of the queues families in a memory barrier must be the family of the
queue that executes the barrier). These invalid transfers were made
because our ownership tracking started all resources in the "externally
owned" state, with the expectation that the first operation on the
resource would be a call to glWaitSemaphoreEXT to acquire ownership.
It is far from clear that a call to glWaitSemaphoreEXT is always
required to gain ownership of a resource. The EXT_external_objects
extension inherits Vulkan's semantics, and what the Vulkan spec says is
that the first entity to access a resource implicitly assumes ownership
(see 11.7.1 "External Resource Sharing"). Binding a resource to memory
does not constitute an access to that resource, or affect its ownership.
Allocations should not be accesses, either; they happen at a lower level
and the entire discussion about determining initial ownership from first
access would serve no purpose if the mere allocation of the underlying
memory was sufficient to assume ownership.
This patch therefore adjusts the initial queue family ownership of
resources created in memory objects to be the ANGLE renderer's queue
family, just like a locally allocated image would be. Since this
ownership state may not be correct (an external API may have already
accessed the image, and assumed ownership) we must relax our assertions
to allow a call to glWaitSemaphoreEXT while in this state. For images,
this is only permitted while the layout is undefined.
An alternative would be to set the initial queue family to a sentinel
value that indicates that we don't know, but that would require checking
for this value before making any accesses, and only then asserting local
ownership. There's no real upside to this; the net effect of the first
access rule is that we must effectively assume ownership until proven
otherwise.
Besides appearing to be the spec's intent, this change simplifies some
usage scenarios because a queue submission is not required in the source
Vulkan instance in order to allocate resources that will be initially
accessed from GL. This seems especially important since there's no
mechanism to allocate an external memory object from inside GL.
The only downside is that the initial ambiguity in ownership prevents us
from diagnosing certain errors, but this limitation is temporary;
ownership becomes clear as soon as there is at least one access or at
least one synchronization operation affecting the resource.
Bug: angleproject:4229
Change-Id: Ibca2bfe373810c55352b1d849d07733d5fcfe5f4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2178946
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
3cb9c4be
|
2020-03-13T13:56:47
|
|
Statically link vulkan-loader on Mac
Disable angle_shared_libvulkan on Mac since we are the only client.
Re-add codepaths to support this.
Bug: angleproject:4477
Change-Id: Ie128c83adaae741636541bbfd6105d160d874a8d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2102954
Commit-Queue: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Tobin Ehlis <tobine@google.com>
|
|
13ea5b7f
|
2020-03-19T12:43:12
|
|
Implement gl[Get]MemoryObjectParameterivEXT
These functions are required to tell the driver that the memory object
is dedicated memory. This is required for AMD drivers on Linux.
Bug: chromium:1049218
Change-Id: I17d69cde5e6308791dc90784f4d6e348503a6ed6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2110051
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
c4197713
|
2019-06-03T19:23:02
|
|
Implement glImportMemoryZirconHandle & glImportSemaphoreZirconHandle
Implement import of fuchsia external objects passed by zircon handle. This
works exactly the same as with file descriptors.
Bug: angleproject:3492
Change-Id: I4d46917dfc5902f00c94550158a9f8073097f0a4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1642334
Commit-Queue: Michael Spang <spang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
e4ba2d87
|
2020-02-20T16:05:02
|
|
Pass ContextVk instead of gl::Context to internal methods
Minor cleanup to change funciton signatures of vulkan specific methods in
MemoryObjectVk & SemaphoreVk.
Bug: angleproject:2475
Change-Id: I230664548004ebc48b559e0f25264ea948ce5a1f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2067500
Commit-Queue: Michael Spang <spang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
5fd73782
|
2019-08-09T11:46:46
|
|
Vulkan: Use volk to load vk* func ptrs
Thanks to Jamie Madill for some fixes to get all CI test passing w/ volk.
This change updates all ANGLE targets that use Vulkan to dyanmically
link all of the VK entrypoints using the volk OSS library from
https://github.com/zeux/volk.
It's only two source files so baking them directly into ANGLE repo.
Also it's used in both the tests and libANGLE trees so added to
src/common/third_party/volk dir.
Updated volk and the renderer to track latest instance and device
that were loaded and renderer will refresh vk* function pointers if
the current and previous device and/or instance don't match. This
prevents errors in the test framework as we transition between
backends, especially between VK HW & SwiftShader ICDs.
This change rolls the Vulkan Loader forward to use the latest loader
version which no longer allows static linking but requires dynamic
linking.
Bug: angleproject:3740
Bug: angleproject:4092
Bug: angleproject:4162
Bug: angleproject:4210
Bug: angleproject:4225
Change-Id: I8a0b7d24c9545bbfdfaa4b9357a9bfe6793e0140
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1965640
Commit-Queue: Tobin Ehlis <tobine@google.com>
Reviewed-by: Tobin Ehlis <tobine@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
cb16fb5f
|
2019-08-29T16:53:55
|
|
Vulkan: Support texture base and max levels
The Vulkan backend uses a vkImage that matches the number
of effective levels in the GL texture. This is due to the fact
that GL textures can have really strange layouts that only make
sense when base level and max level are applied.
For instance, take the following layout with disjoint mip levels:
Level 0: 4x4 RGBA
Level 1: 2x2 RGBA
Level 2: 10x10 RGB
If base level is set to zero and max level is set to 1, the image is
still considered mip-complete:
Level 0: 4x4 RGBA ==> Base Level 0 ==> Level 0: 4x4 RGBA
Level 1: 2x2 RGBA ==> Max Level 1 ==> Level 1: 2x2 RGBA
Level 2: 10x10 RGB
If base and max level are then both set to 2, the texture is still
considered complete, but of a different size and format:
Level 0: 4x4 RGBA
Level 1: 2x2 RGBA
Level 2: 10x10 RGB ==> Base/Max Level 2 ==> Level 2: 10x10 RGB
When the base or max level is changed, we must recreate the vkImage to
match the new level count.
To support that, we:
- Stage updates from the current image to the new image
- Only stage updates if there aren't already staged updates for a level
- Free the current image and so it can be recreated at the next draw
This CL does the following:
- Refactors TextureVk::copyImageDataToBuffer to support staging updates
without flush
- Adds TextureVk::copyImageDataToBufferAndGetData to support previous
use model
- Adds TextureVk::changeLevels, triggered during syncState, which stages
updates and releases the current image.
- Updates ImageHelper::flushStagedUpdates to understand base/max levels
- Updates TextureVk::ensureImageInitialized and TextureVk::generateMipmap
to account for base/max level
- Tracks base and max levels in ImageHelper
- Adds ImageHelper::stageSubresourceUpdateFromBuffer to support
this use case
- Adds ImageHelper::isUpdateStaged to determine if changeLevels
should propagate data
- Makes gl::TextureTypeToTarget available for use outside of ImageIndex
- Enables several deqp and end2end tests
Bug: angleproject:3148
Test: dEQP-GLES3.functional.texture.mipmap.*base_level*
Test: dEQP-GLES3.functional.texture.mipmap.*max_level*
Change-Id: I14ca071c9c62eb310dfed7ef9290dc65fc3ff696
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1776933
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
7e48c9eb
|
2019-08-06T17:17:19
|
|
Add explicit integer casts
WebKit uses the -Wshorten-64-to-32 flag which warns on these cases.
Bug: 3439
Change-Id: I8c1de60da0f173ca2036e2120e79b857f5f2775f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1740866
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
a2129356
|
2019-07-23T12:54:13
|
|
Vulkan: Add support for 2D array textures
Includes changes from jmadill to align with Vulkan backend design.
Correctly setting layer count and depth when the texture type is
2Darray. Vulkan requires depth of 1 for 2Darray textures.
Bug: angleproject:3189
Change-Id: I0d58c33fcd75b1d768ea0308ac6e54230d8cfcc5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1721169
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
c327370e
|
2019-07-23T12:54:12
|
|
Vulkan: Pass VkExtent3D to TextureHelper::init.
Bug: angleproject:3189
Change-Id: I4b95240bb32fbc2b3d0c8f097e0552d0fe23417d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1713094
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
c467f7b5
|
2019-04-17T20:20:30
|
|
Compute usage from format properties cache in glTexStorageMem2DEXT
Per issue 13 in the EXT_external_objects spec, we should request all of
the usage flags that are supported for the format.
Bug: angleproject:3289, angleproject:3389
Change-Id: I5ef9906061af0fd619f580a9f603dd43be162932
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1573218
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
|
|
|
f02a767d
|
2019-04-09T18:45:23
|
|
Vulkan: Implement glTexStorageMem2DEXT
This implements support for creating textures that alias vulkan images
allocated inside external memory.
Bug: angleproject:3289
Change-Id: Iad071f353a217793102ae737647c7cd572f7b0ad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1552029
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
|
|
|
3b2c6bfd
|
2019-04-16T17:19:50
|
|
Vulkan: Implement glImportMemoryFdEXT
Allow importing opaque file descriptors into memory objects on linux.
Currently this just holds onto the file descriptor rather than calling
vkAllocateMemory immediately. The latter will be easier once we have
support for suballocation (anglebug.com/2162).
Bug: angleproject:3289
Change-Id: Ia80ce07b2a9ec95b9063feb9bfeb24ffe77fa40e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1552028
Commit-Queue: Michael Spang <spang@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
a0b00e97
|
2019-04-09T18:45:22
|
|
Vulkan: Expose GL_EXT_memory_object_fd & GL_EXT_semaphore_fd
If the vulkan driver has support for VK_KHR_external_memory_fd or
VK_KHR_external_semaphore_fd, add the GL versions of these to the vulkan
renderer's extensions.
Bug: angleproject:3289
Change-Id: I7f04b5cf883f93f6ccd579c2b75d6831b854bfd0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1552027
Commit-Queue: Michael Spang <spang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|