|
935cb7c5
|
2017-11-08T15:53:41
|
|
Support B8G8R8A8_UNORM_SRGB as D3D11 texture format
Support B8G8R8A8_UNORM_SRGB as D3D11 texture format.
BUG=angleproject:2172
Change-Id: I2f15a55123601735d7fc6caa40bb056243a91b44
Reviewed-on: https://chromium-review.googlesource.com/758600
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
1d7be50a
|
2017-10-29T18:06:50
|
|
Vulkan: Upgrade RGB8 textures to RGBA8.
It's unlikely any real hardware supports this format. Hack in a fixed
fallback format for RGB8. We could consider implementing conditional
support by checking the VkPhysicalDevice properties.
This extends the Vulkan format support info in the RendererVk class
to distinguish between a Buffer and Texture format. This is closely
related to how Vulkan has separate format support bits for Linear
Textures, Optimal Textures, and Buffers. We probably won't need to
keep separate caps for Linear/Optimal, but it makes sense for Buffers
to eventually use the same format tables.
BUG=angleproject:2207
Change-Id: I8d427a99db15b314b13dd99f31aa1ac5055f0881
Reviewed-on: https://chromium-review.googlesource.com/742376
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
|
|
7b62cf97
|
2017-11-02T15:20:49
|
|
Refactor TextureFormatMap to store an array.
std::map lookups are already showing up as a hot spot during some
profile trace analysis. We can elimintate these by only doing a
single switch at the entry point level to convert the GL internal
format to an internal identifier or type info pointer.
This change doesn't completely fix the hot spot, since now we are
doing multiple switch statements, but it does remove the std::map
storage in TextureCapsMap. It replaces it with a flat std::array
indexed by angle::Format::ID, and gives us the option in the future
to eliminate all by one switch statement.
This should allow for a faster texture caps implementation in Vulkan.
This also fixes the missing ANGLE format entries for ETC1 compressed
formats.
BUG=angleproject:2207
Change-Id: I74ea2082e582a6790d5fde90e33246a618a2da0e
Reviewed-on: https://chromium-review.googlesource.com/742375
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|
|
6a89d227
|
2017-11-02T11:59:51
|
|
Vulkan: Refactor format table.
This moves the Vulkan format table to dynamically generated, but
keeps it easily indexed. Because Vulkan format support is not able
to be fully determined until runtime, we'll need a dynamic way to
build the table. The most straight-forward way seems to be to keep
a copy of the full table in the Renderer. Initializing it once at
startup makes it a bit slower to init, but saves us from any threading
shenanigans with lazy init when (and if) we ever support multi-
threaded Contexts.
BUG=angleproject:2207
Change-Id: Ib1ac879daa562c7ad1a965390be401fa2314e42c
Reviewed-on: https://chromium-review.googlesource.com/742374
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|
|
a8b73ed0
|
2017-11-02T09:22:29
|
|
Add a meta-script to run code generators.
This script calls all the various GL and back-end python scripts to
generate our internal format tables and entry points, etc. It uses
a GYP-like scheme of inputs/outputs to check modified time before
running the generators. It also will automatically call 'git cl
format' if any generator was called.
Also updates the copyright in a couple of touched files.
BUG=angleproject:2207
Change-Id: I4187a7622accc1c97a8d779b8f87fe00b74855ea
Reviewed-on: https://chromium-review.googlesource.com/742372
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
abaab233
|
2017-01-10T12:37:37
|
|
Vulkan: Introduce vk::Format.
BUG=angleproject:1319
Change-Id: I88bcc6caa5d29565728848bada1563e47e383b29
Reviewed-on: https://chromium-review.googlesource.com/367753
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|