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
Reason for revert:
Co-centered sample locations are not needed to do stencil clip with mixed samples
Original issue's description:
> Implement stencil clipping in mixed sampled render targets
>
> This change enables multisampled clipping for mixed sampled
> render targets. Previously clipping in mixed samples config
> behaved the same as in the gpu config.
>
> In order to retrofit non-MSAA draw methods, programmable sample
> locations are used in order to colocate all samples at (0.5, 0.5).
> Requires support for NV_sample_locations.
>
> BUG=skia:4399
>
> Committed:
> https://skia.googlesource.com/skia/+/3e77ba96d56d15db30ac6d8ccb900e30aafcbb16
BUG=skia:
Review URL: https://codereview.chromium.org/1415873011
Reason for revert:
Co-centered sample locations are not needed to do stencil clip with mixed samples.
Original issue's description:
> Fix mixed samples stencil clip
>
> Fixes rendering bugs and nondeterminism in gm.
>
> Before, mixed samples stencil clip would try to infer whether the draw
> wanted co-centered sample locations from within GrGLGpu, which caused
> various errors. This change reworks it so the draw itself can request
> the co-centered sample locations when it knows it will need them.
>
> Also reduces framebuffer binds by moving the code that enables
> GL_FRAMEBUFFER_PROGRAMMABLE_SAMPLE_LOCATIONS into flushRenderTarget.
>
> Committed: https://skia.googlesource.com/skia/+/14184d5567b58085b6d8a6375796d405056f7f73TBR=bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1407063011
Fixes rendering bugs and nondeterminism in gm.
Before, mixed samples stencil clip would try to infer whether the draw
wanted co-centered sample locations from within GrGLGpu, which caused
various errors. This change reworks it so the draw itself can request
the co-centered sample locations when it knows it will need them.
Also reduces framebuffer binds by moving the code that enables
GL_FRAMEBUFFER_PROGRAMMABLE_SAMPLE_LOCATIONS into flushRenderTarget.
Review URL: https://codereview.chromium.org/1431593006
Quits requiring EXT_raster_multisample and
NV_sample_mask_override_coverage for mixed samples support. This will
allow platforms without those latter extensions (i.e. Chrome) to still
use mixed samples for path rendering. Also moves the mixed samples cap
out of shader caps, since it no longer denotes shader functionality.
BUG=skia:
Review URL: https://codereview.chromium.org/1410383011
This allows internal Gr texture creation code to succeed for extraneous textures while running the bleed GM. This means we can turn on the shader variants.
Review URL: https://codereview.chromium.org/1418473004
This change enables multisampled clipping for mixed sampled
render targets. Previously clipping in mixed samples config
behaved the same as in the gpu config.
In order to retrofit non-MSAA draw methods, programmable sample
locations are used in order to colocate all samples at (0.5, 0.5).
Requires support for NV_sample_locations.
BUG=skia:4399
Review URL: https://codereview.chromium.org/1232103002
