Fixed-function NVPR codepaths were removed a while ago. Only NVPR API
version 1.3 (PathFragmentInputGen) was left working. Remove
backwards-compatibility code that was left behind.
Remove some NVPR API function typedefs that were left from initial
commits.
Remove PathCoords function pointer from GrGLInterface, it has
never been called and causes problems in the future, since it will
not be implemented in the Chromium pseudo extension.
Avoid failing interface creation even if nvprmsaaXX config is
requested but the driver is not recent enough. The SAN bots have
old driver, but try to run nvprmsaa16 configs. Instead, print
out a warning.
Committed: https://skia.googlesource.com/skia/+/fb8d6884e0e01d0c2f8596adf5af1efb0d08de7e
Committed: https://skia.googlesource.com/skia/+/e35b5d99d8dfcc6b2be844df28cba47436380809
Review URL: https://codereview.chromium.org/1177243004
This patch ensures that when inverting a SkMatrix44, we handle small
floats properly. When inverted these can cause infinite values, but
still evaluate to true in an if condition.
BUG=chromium:498516
Review URL: https://codereview.chromium.org/1209763002
All of the CodecSubset benches fail when the color type is
kIndex8. We need to pass a color table to allocPixels()
when we want to decode to kIndex8 or it will throw a failure.
BUG=skia:
Review URL: https://codereview.chromium.org/1213983003
The ~ means "don't run this". This keeps all the other bots running the code, skipping it only on the whiny TSAN bot.
BUG=skia:3997
Review URL: https://codereview.chromium.org/1213033003
This has the effect of using delay_copy() on every argument,
obviating the need for delay_copy() and, crucially, having
to remember to call delay_copy().
All these constructors are fully inlined, so we'll never pay
a penalty for passing small things by reference... the compiler
can see that and just pass by value.
BUG=skia:
Review URL: https://codereview.chromium.org/1215523004
Reason for revert:
Breaks the Ubuntu *SAN bots.
Original issue's description:
> Cleanup legacy NVPR-related definitions
>
> Fixed-function NVPR codepaths were removed a while ago. Only NVPR API
> version 1.3 (PathFragmentInputGen) was left working. Remove
> backwards-compatibility code that was left behind.
>
> Remove some NVPR API function typedefs that were left from initial
> commits.
>
> Remove PathCoords function pointer from GrGLInterface, it has
> never been called and causes problems in the future, since it will
> not be implemented in the Chromium pseudo extension.
>
> Committed: https://skia.googlesource.com/skia/+/fb8d6884e0e01d0c2f8596adf5af1efb0d08de7e
>
> Committed: https://skia.googlesource.com/skia/+/e35b5d99d8dfcc6b2be844df28cba47436380809TBR=joshualitt@google.com,cdalton@nvidia.com,bsalomon@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1219663005
Fixed-function NVPR codepaths were removed a while ago. Only NVPR API
version 1.3 (PathFragmentInputGen) was left working. Remove
backwards-compatibility code that was left behind.
Remove some NVPR API function typedefs that were left from initial
commits.
Remove PathCoords function pointer from GrGLInterface, it has
never been called and causes problems in the future, since it will
not be implemented in the Chromium pseudo extension.
Committed: https://skia.googlesource.com/skia/+/fb8d6884e0e01d0c2f8596adf5af1efb0d08de7e
Review URL: https://codereview.chromium.org/1177243004
Refactor separable varying location info to be stored in GrGLProgram
subclass GrGLProgram instead of storing it in GrGLPathProcessor.
Separable varyings are exactly analoguous to uniforms: they are inputs
to the shader program. Shader compile-time information about uniforms is gathered to
GrGLProgramBuilder. This information is the converted to link-time
information, uniform locations, when constructing the program. Separable
varyings need to have same lifetime model.
This is needed in the future to support path rendering in Chromium. The
Chromium pseudo-extension will expose program fragment input binding
function similar to uniform binding function. Thus the separable varying
locations need to be decided and bound before link, e.g. before
GrGLProgram is created. This will be achieved in further patches by
overloading GrGLProgramBuilder::bindProgramResourceLocations() in
GrGLNvprProgramBuilder.
BUG=chromium:344330
Review URL: https://codereview.chromium.org/1186113007
A path can be non-empty but become empty when it is simplified.
For instance, a path with the same rectangle, twice, with opposite
windings.
No contours are created for empty paths, so don't try to
fix their winding direction.
Additionally, check for a NULL coincidence since the
OpBuilder assumes that no concidence edges can be present
after the paths are simplified. This code should not get
called, but it's worth the future-proofing to check.
R=fmalita@chromium.org
BUG=502792
Review URL: https://codereview.chromium.org/1218863005
Reason for revert:
xfermodes and xfermodes2 show major diffs on Nexus 5 and Daisy (both ARMv7 w/NEON). Nexus 9 and SSE all look fine...
Original issue's description:
> SoftLight with SkPMFloat
>
> SSE speeds up about 4.5x over existing integer SSE,
> NEON speeds up about 3x over serial integer code.
>
> We expect 1-2 bit component diffs in the usual GMs.
>
> Still guarded by SK_SUPPORT_LEGACY_XFERMODES,
> which I'll now try to lift in Chrome.
>
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/3e47d49b46b3ab62071218ef3dd44642c9713e04TBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1221683002
SSE speeds up about 4.5x over existing integer SSE,
NEON speeds up about 3x over serial integer code.
We expect 1-2 bit component diffs in the usual GMs.
Still guarded by SK_SUPPORT_LEGACY_XFERMODES,
which I'll now try to lift in Chrome.
BUG=skia:
Review URL: https://codereview.chromium.org/1221493002
Changes verbose mode to print both the table and the individual sample
values. No need to hold back information in verbose mode.
BUG=skia:
Review URL: https://codereview.chromium.org/1208763003
These structs are always implemented as
struct uintNNxMx4_t {
uintNNxM val[4];
};
So, the first set of braces is for the struct, the second for val.
BUG=skia:
Review URL: https://codereview.chromium.org/1221453002
