Adds a module that performs instanced rendering and starts using it
for a select subset of draws on Mac GL platforms. The instance
processor can currently handle rects, ovals, round rects, and double
round rects. It can generalize shapes as round rects in order to
improve batching. The instance processor also employs new drawing
algorithms, irrespective of instanced rendering, that improve GPU-side
performance (e.g. sample mask, different triangle layouts, etc.).
This change only scratches the surface of instanced rendering. The
majority of draws still only have one instance. Future work may
include:
* Passing coord transforms through the texel buffer.
* Sending FP uniforms through instanced vertex attribs.
* Using instanced rendering for more draws (stencil writes,
drawAtlas, etc.).
* Adding more shapes to the instance processor’s repertoire.
* Batching draws that have mismatched scissors (analyzing draw
bounds, inserting clip planes, etc.).
* Bindless textures.
* Uber shaders.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2066993003
Review-Url: https://codereview.chromium.org/2066993003
Reason for revert:
GMs are crashing on Windows Test trybots
Original issue's description:
> SkLightingShader normal vector CPU computation refactor.
>
> The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
>
> This CL's base was the CL for GPU handling: https://codereview.chromium.org/2043393002/
>
> What this CL includes:
>
> - A refactor of the SkLightingShader context's code that deals with reading normals off of a normal map. This is now abstracted out into a NormalSource::Provider class that the context uses.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2050773002
>
> Committed: https://skia.googlesource.com/skia/+/790a70118327a129cb6b48fabe80f4e184c1e67cTBR=egdaniel@google.com,reed@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/2101653002
The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
This CL's base was the CL for GPU handling: https://codereview.chromium.org/2043393002/
What this CL includes:
- A refactor of the SkLightingShader context's code that deals with reading normals off of a normal map. This is now abstracted out into a NormalSource::Provider class that the context uses.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2050773002
Review-Url: https://codereview.chromium.org/2050773002
__mulodi4() is roughly,
int64_t __mulodi4(int64_t a, int64_t b, int* overflow) {
int64_t result = a*b;
*overflow = did_overflow(result);
return result;
}
It's used by Clang's __builtin_smulll_overflow(), which is basically the same
except it swaps the positions of the return value and the out parameter.
DNG SDK in turn uses __builtin_smulll_overflow().
When building ARMv7 binaries with Clang, __mulodi4() turns up as a missing symbol.
That's because it's defined in a separate compiler-rt library. I have not been
able to link that. Instead, I've provided our own trivial __builtin_smulll_overflow().
Before this patch both nanobench and DM failed dynamically linking __mulodi4(). After this patch nanobench runs for a while, eventually segfaulting. DM immediately segfaults.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2011073002
Review-Url: https://codereview.chromium.org/2011073002
Reason for revert:
break deps roll
Original issue's description:
> Refactoring of GPU NormalMap handling out into its own class.
>
> The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
>
> What this CL includes:
>
> - Created a new 'NormalMapFP', out of the existing normal map reading behavior in LightingFP.
>
> - Encapsulates this new fragment processor on a new class NormalMapSource.
>
> - Created a NormalSource abstraction that will interface with SkLightingShader.
>
> - Adapted SkLightingShader to use the normals from its NormalSource field ON THE GPU SIDE. No changes done to the CPU side yet.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2043393002
>
> Committed: https://skia.googlesource.com/skia/+/87b0dd00cf9409c5fc990f5d0bb7c0df837f08da
> Committed: https://skia.googlesource.com/skia/+/a7d1e2a57aef2aa4913d4380646d60bbab761318TBR=reed@google.com,dvonbeck@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/2068983005
The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
What this CL includes:
- Created a new 'NormalMapFP', out of the existing normal map reading behavior in LightingFP.
- Encapsulates this new fragment processor on a new class NormalMapSource.
- Created a NormalSource abstraction that will interface with SkLightingShader.
- Adapted SkLightingShader to use the normals from its NormalSource field ON THE GPU SIDE. No changes done to the CPU side yet.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2043393002
Committed: https://skia.googlesource.com/skia/+/87b0dd00cf9409c5fc990f5d0bb7c0df837f08da
Review-Url: https://codereview.chromium.org/2043393002
- When the stroke width gets too big the raster algorithm produces
incorrect output
- This also causes the GPU path to produce incorrect output if the width
is larger than an arbitrary limit in GrAALinearizingConvexPathRenderer
(which is the renderer used for this specific geometry)
- Other non-convex geometries probably also produce strange results
BUG=skia:5405,skia:5406
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2060903002
Review-Url: https://codereview.chromium.org/2060903002
Reason for revert:
Breaking build and deps roll. Need to move include of SkBitmapProcShader in SkLightingShader.cpp from gpu include list to general list.
Original issue's description:
> Refactoring of GPU NormalMap handling out into its own class.
>
> The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
>
> What this CL includes:
>
> - Created a new 'NormalMapFP', out of the existing normal map reading behavior in LightingFP.
>
> - Encapsulates this new fragment processor on a new class NormalMapSource.
>
> - Created a NormalSource abstraction that will interface with SkLightingShader.
>
> - Adapted SkLightingShader to use the normals from its NormalSource field ON THE GPU SIDE. No changes done to the CPU side yet.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2043393002
>
> Committed: https://skia.googlesource.com/skia/+/87b0dd00cf9409c5fc990f5d0bb7c0df837f08daTBR=reed@google.com,dvonbeck@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/2062133004
The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
What this CL includes:
- Created a new 'NormalMapFP', out of the existing normal map reading behavior in LightingFP.
- Encapsulates this new fragment processor on a new class NormalMapSource.
- Created a NormalSource abstraction that will interface with SkLightingShader.
- Adapted SkLightingShader to use the normals from its NormalSource field ON THE GPU SIDE. No changes done to the CPU side yet.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2043393002
Review-Url: https://codereview.chromium.org/2043393002
To build shaderc, gyp used to punt to cmake, which did not work well on the bots and I couldn't find any way to pipe the variables into cmake which would have made it happy.
So, I wrote a gyp file for shaderc and its dependencies. Nothing super complicated (thank goodness), except for the files that spirv-tools needed generated.
BUG=skia:5186
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2047833003
Review-Url: https://codereview.chromium.org/2047833003
Currently this is not actually hooked into the system.
To give some context, in a follow up CL I'll add this to GrDrawTarget.
For this I will move the gpu onDraw command to the GpuCommandBuffer as well.
For GL this will end up just being a pass through to a non virtual draw(...)
on GrGLGpu, and for vulkan it will mostly do what it currently does but
adding commands to the secondary command buffer instead.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2038583002
Review-Url: https://codereview.chromium.org/2038583002
Crash is caused by ldxc1 instruction, which traps when double values are
not aligned on 8-byte boundaries. Problem was tracked to SkChunkAlloc which
produces pointers aligned on 4-byte boundaries leading to misalignment.
This change makes sure that SkChunkAlloc will produce pointers that are
aligned to 8 bytes.
Appropriate tests are added to tests/MemsetTest.cpp
TEST=Build Chromium with Clang and run on MIPS32r2 platform
TEST=./out/Debug/dm --match Memset
BUG=130022
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1849183004
Review-Url: https://codereview.chromium.org/1849183004
With this change, the CMake build, which does not use DEPS to sync
external projects, is able to build and use the same version of libpng
that is used in other builds.
This will allow all platforms (including Google3 CMake build) to test on
the same version of libpng, so we do not need to make SkPngCodec support
all versions of libpng.
- Update CMakeLists.txt to use the checked in libpng.
- Check in libpng version 1.6.22rc01
- Update README.google
- Replace our old LICENSE file with the latest one from libpng
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2033063003
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2033063003
When targetting iOS and using gyp to generate the build files, it is not
possible to select files to build depending on the architecture. Due to
that, the skia code was disabling all optimisation when SK_BUILD_FOR_IOS
was defined.
Since it is possible to select the correct optimised version when using
gn, this pessimisation is hurting the build. Introduce a new define to
disable the optimisation SK_BUILD_NO_OPTS. It will be used by Chromium
when building skia for iOS with gyp but not gn.
Define SK_BUILD_NO_OPTS along-side SK_BUILD_FOR_IOS for all files that
look like build configuration (Xcode projects, gyp configuration files,
public.bzl) in order to avoid introducing breakage on those builds.
BUG=607933
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2002423002
Review-Url: https://codereview.chromium.org/2002423002
