This code was running on our bots but never in Chrome.
That's a bad state to be in.
My plan here use to be to redesign how our 8888 blits worked in SSE 4.1, mainly
for perfect correctness but also for speed, then to spread what I learned there
to SSE2, AVX+, and NEON.
I have since lost interest in changing any aspect of how our legacy 8888 blits
work. There's not much point in making them a bit or two more correct when the
math is fundamentally wrong.
This will cause many diffs in Gold, none perceptible.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2062853002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Committed: https://skia.googlesource.com/skia/+/6e472093009bf2fc4a8e53010b51040efcb71213
Review-Url: https://codereview.chromium.org/2062853002
201295.jpg on HP z620
(300x280, most common form of sRGB profile)
QCMS Xform 0.495 ms
Skia Old Xform 0.235 ms
Skia NEW Xform 0.423 ms
Vs Old Code 0.56x
Vs QCMS 1.17x
So to summarize, we are now much slower than before,
but still a bit faster than QCMS. And now we are also
far more accurate than QCMS :).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2060823003
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2060823003
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
These provide an easy way to create assets to be used by bots,
eg. Android SDK.
To create an asset:
$ infra/bots/assets/assets.py add android_sdk
(adds scripts in infra/bots/assets/android_sdk)
To upload a new version of an asset:
$ infra/bots/assets/android_sdk/upload.py -t $ANDROID_SDK_ROOT
(uploads Android SDK to GS, writes a version file)
$ git commit
$ git cl upload
To download the current version of the asset:
$ infra/bots/assets/android_sdk/download.py -t ../tmp
BUG=skia:5427
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2069543002
Review-Url: https://codereview.chromium.org/2069543002
- 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
SkPicture::cullRect() is not guaranteed to be the same as the
bounds passed to SkPictureRecorder::beginRecording().
Review-Url: https://codereview.chromium.org/2067473003
Reason for revert:
Breaks a couple Google3 goldens. I need to rebaseline google3 with -DSK_SUPPORT_LEGACY_X86_BLITS first, then reland this.
Original issue's description:
> Clean up two unlaunched SSE 4.1 8888 blits.
>
> This code was running on our bots but never in Chrome.
> That's a bad state to be in.
>
> My plan here use to be to redesign how our 8888 blits worked in SSE 4.1, mainly
> for perfect correctness but also for speed, then to spread what I learned there
> to SSE2, AVX+, and NEON.
>
> I have since lost interest in changing any aspect of how our legacy 8888 blits
> work. There's not much point in making them a bit or two more correct when the
> math is fundamentally wrong.
>
> This will cause many diffs in Gold, none perceptible.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2062853002
> CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/6e472093009bf2fc4a8e53010b51040efcb71213TBR=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/2066453003
Currently, Skia always uploads GPU textures at full resolution. This
change allows us to pass a pre-scale mip level to the
deferred texture image logic, which causes us to pre-scale the image
to the given mip level, and upload that mip level instead of the full
image.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2007113008
Review-Url: https://codereview.chromium.org/2007113008
This code was running on our bots but never in Chrome.
That's a bad state to be in.
My plan here use to be to redesign how our 8888 blits worked in SSE 4.1, mainly
for perfect correctness but also for speed, then to spread what I learned there
to SSE2, AVX+, and NEON.
I have since lost interest in changing any aspect of how our legacy 8888 blits
work. There's not much point in making them a bit or two more correct when the
math is fundamentally wrong.
This will cause many diffs in Gold, none perceptible.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2062853002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2062853002
