Crurently, when preparing a texture for blitFramebuffer, we ignore the
kRectsMustMatchForMSAASrc_BlitFramebufferFlag, and may attempt to
copy from one src rect to a different dst rect.
This change updates initDescForDstCopy and setupDstTexture to allocate
larger textures if necessary and accomodate this flags requirements.
Bug: 658277
Change-Id: If4489ac3192dcf6f9996494c63821279721d0a12
Reviewed-on: https://skia-review.googlesource.com/11141
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit d58f040532.
Reason for revert: tests/BlendTest is failing on the Nexus Player:
https://chromium-swarm.appspot.com/task?id=353ffc638e202210https://chromium-swarm.appspot.com/task?id=353ff5e35819ab10
Original change's description:
> Respect kRectsMustMatchForMSAASrc_BlitFramebufferFlag in dst setup
>
> Crurently, when preparing a texture for blitFramebuffer, we ignore the
> kRectsMustMatchForMSAASrc_BlitFramebufferFlag, and may attempt to
> copy from one src rect to a different dst rect.
>
> This change updates initDescForDstCopy and setupDstTexture to allocate
> larger textures if necessary and accomodate this flags requirements.
>
> Bug: 658277
> Change-Id: I9f45a03d4055e0ad87c01e1d826287695096e609
> Reviewed-on: https://skia-review.googlesource.com/10941
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
>
TBR=bsalomon@google.com,ericrk@chromium.org,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I0fd6ca95bbc342f21978783b0103073179017795
Reviewed-on: https://skia-review.googlesource.com/11016
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Crurently, when preparing a texture for blitFramebuffer, we ignore the
kRectsMustMatchForMSAASrc_BlitFramebufferFlag, and may attempt to
copy from one src rect to a different dst rect.
This change updates initDescForDstCopy and setupDstTexture to allocate
larger textures if necessary and accomodate this flags requirements.
Bug: 658277
Change-Id: I9f45a03d4055e0ad87c01e1d826287695096e609
Reviewed-on: https://skia-review.googlesource.com/10941
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit e0ff6ab272.
Reason for revert: a bunch of bots failed.
Original change's description:
> Respect kRectsMustMatchForMSAASrc_BlitFramebufferFlag in dst setup
>
> Crurently, when preparing a texture for blitFramebuffer, we ignore the
> kRectsMustMatchForMSAASrc_BlitFramebufferFlag, and may attempt to
> copy from one src rect to a different dst rect.
>
> This change updates initDescForDstCopy and setupDstTexture to allocate
> larger textures if necessary and accomodate this flags requirements.
>
> Bug: 658277
> Change-Id: I500f10dba5700f5f7a7acad04bcdbc9ac9994835
> Reviewed-on: https://skia-review.googlesource.com/10247
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
>
TBR=bsalomon@google.com,ericrk@chromium.org,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I7fbd6c2652fe71c707d3120b035e0365fbc7fa66
Reviewed-on: https://skia-review.googlesource.com/10920
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Crurently, when preparing a texture for blitFramebuffer, we ignore the
kRectsMustMatchForMSAASrc_BlitFramebufferFlag, and may attempt to
copy from one src rect to a different dst rect.
This change updates initDescForDstCopy and setupDstTexture to allocate
larger textures if necessary and accomodate this flags requirements.
Bug: 658277
Change-Id: I500f10dba5700f5f7a7acad04bcdbc9ac9994835
Reviewed-on: https://skia-review.googlesource.com/10247
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This is currently done in GrOpList. However, it can trigger resource creation, which in turn can trigger a flush. In the future flushing may destroy the op list.
Change-Id: I21cb1e10060bf31c95431c0511fcfff637cd6498
Reviewed-on: https://skia-review.googlesource.com/9304
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
GrExternalTextureData is an API for exporting the backend-specific
information about a texture in a type-safe way, and without pointing
into the GrTexture. The new detachBackendTexture API lets us release
ownership of a texture to the client.
SkCrossContextImageData is the public API that lets clients upload
textures on one thread/GrContext, then safely transfer ownership to
another thread and GrContext for rendering.
Only GL is implemented/supported right now. Vulkan support requires
that we add thread-safe memory pools, or otherwise transfer the
actual memory block containing the texture to the new context.
Re-land of https://skia-review.googlesource.com/c/8529/
BUG=skia:
Change-Id: I48ebd57d1ea0cfd3a1db10c475f2903afb821966
Reviewed-on: https://skia-review.googlesource.com/8960
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This also makes the required changed to src, tests, and tools. The few
public APIs modified by this change appear to be unused outside of Skia.
Removing these from the public API makes it easier to ensure users are
no longer using them.
This also updates GrGpu::wrapBackendXXX and the
::onWrapBackendXXX methods to clarify ownership.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2448593002
Review-Url: https://codereview.chromium.org/2448593002
Adds the ability for GLInstancedRendering to use
glDrawElementsInstanced when glDrawElementsIndirect is not supported.
The only remaining 3.1 dependency now is EXT_texture_buffer.
Also moves the cap for glDraw*Instanced out of GrCaps and into
GrGLCaps.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2193303002
Review-Url: https://codereview.chromium.org/2193303002
On some platforms, a newly-created buffer was liable to be CPU backed.
This would break code that expected a VBO (aka instanced rendering).
This change adds an optional flag to GrResourceProvider that requires
a buffer to be created in GPU memory.
It also moves the CPU backing logic into Gr land in order to properly
cache real VBOs on platforms that prefer client-side buffers.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2143333002
Review-Url: https://codereview.chromium.org/2143333002
Reason for revert:
Lots of Android redness
Original issue's description:
> Consolidate GPU buffer implementations
>
> Consolidates all the different buffer implementations into a single
> GrBuffer class. This will allow us to add new buffer types, use DSA in
> OpenGL, track buffer bindings by unique ID, cache buffers without
> respect to the type of data they have been used for previously, etc.
> This change is strictly a refactor; it introduces no change in
> functionality.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1825393002
>
> Committed: https://skia.googlesource.com/skia/+/8b1bff29675afd25843439eade634a57f68fe16fTBR=bsalomon@google.com,egdaniel@google.com,jvanverth@google.com,cdalton@nvidia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1831133004
sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).
Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.
Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
Review URL: https://codereview.chromium.org/1789663002
Reason for revert:
We're getting sRGB non-8888 configs?
Original issue's description:
> sRGB support in Ganesh. Several pieces:
>
> sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
> us to disable sRGB -> Linear conversion when reading textures. This gives
> us an easy way to support "legacy" L32 mode. We disable decoding based on
> the pixel config of the render target. Textures can override that behavior
> (specifically for format-conversion draws where we want that behavior).
>
> Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
> internally, and the external format is BGR order, so TexImage calls will
> swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
> platforms.
>
> Devices without sRGB support behave like they always have: conversion from
> color type and profile type ignores sRGB and always returns linear pixel
> configs.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
>
> Committed: https://skia.googlesource.com/skia/+/9e3f1bf4e5cd8fc59554f986f36d6b034e99f9ebTBR=reed@google.com,bsalomon@google.com,robertphillips@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1814533003
sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).
Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.
Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1789663002
Review URL: https://codereview.chromium.org/1789663002
This CL may not really be necessary since it seems that the Android Ones we have fall back to mediump when highp isn't supported.
FYI, for bits-of-precision/precision we have:
Low Med High Precision-Used
A1 (Cherry One - Mali 400) 10 10 0 Med - conic looks bad
N5 (Adreno 330) 10 10 23 High - conic looks bad!!!
N6 (Adreno 420) 10 10 23 High - conic looks good
N7v2 (Adreno 320) 10 10 23 High - conic looks bad!!!
N9 (K1) 23 23 23 High - looks good
N10 (Mail-604) 10 10 23 High - looks good
I suspect derivative computation is broken on the Adreno 300s.
BUG=555779,skia:4668
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/1513573009
