Adds kRG_float_GrPixelConfig.
Also removes default labels from switches on GrPixelConfig, in order
to help guide future enumerals to handle them properly.
BUG=skia:
Change-Id: Ie80b9413b4002b666df3ef1a7a8ea4c9c29ce43b
Reviewed-on: https://skia-review.googlesource.com/8226
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Change-Id: I04bcaf91aa7a43e0563e332c1fe2836d762a04d4
Reviewed-on: https://skia-review.googlesource.com/7520
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
In the past, ANGLE always used GL_HALF_FLOAT. I filed a bug about that,
and they switched to HALF_FLOAT_OES. However, ES3 has direct support for
HALF_FLOAT, so we expect that as the format for read pixels.
The better solution would be to remember and return the value we get
back from IMPLEMENTATION_COLOR_READ_TYPE, but there are subtleties that
create additional bugs when we do that. In particular:
If trying to read Alpha8 from RGBA, the current sequence is:
1. readPixelsSupported asks for the format to use. getExternalFormat
switches out the format (assuming we're using GL_RED). This creates
a format/type pair that fails the ES3.2 rules (16.1.2), so we ask
the driver for the secondary format, which matches the one that we
expect (from our config table).
2. Then we *actually* do the readPixels, and here we just call
getReadPixelsFormat, which does the remapping, but skips the follow
up checks in readPixelsSupported. So we end up passing a format/type
pair that our code in readPixelsSupported thinks is illegal (and
which is neither the pair that our config table stores, *nor* the
pair returned by the implementation).
A straightforward solution of the original problem is to notice that
we had to ask the implementation (because the values are filled in),
so we should trust those and not the ones in the config table. But then
we miss out on the chance to overwrite the values for the alpha only
from RGBA case. Sigh.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4963
Change-Id: Icb0c151c9f07ffc178ed3a597fa8ab0ed3c6cb94
Reviewed-on: https://skia-review.googlesource.com/4963
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Update the ANGLE test GL context, GrContextFactory, and config parsing to allow explicit control of ANGLE front/backend.
This will allow us to explicitly test ES2 vs ES3 interfaces to ANGLE as well as D3D9, D3D11, and OpenGL backends.
Also makes the angle api types valid in all builds (but will just fail when SK_ANGLE=1 or not on windows for the d3d backends).
BUG=skia:5804
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2381033002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Win-MSVC-ShuttleC-GPU-GTX960-x86_64-Debug-ANGLE-Trybot
Review-Url: https://codereview.chromium.org/2381033002
Use DEF_GPUTEST_FOR_*_CONTEXT macros to obtain the
test GPU context.
Makes changing the context -related classes easier,
since not all tests need to be changed.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1448873002
I have been hacking at this test trying to understand why the N5 is
still sometimes crashy (it seems, less but not zero now). No luck so far.
But, while I've been reading and hacking at it, I think I've made a
few small improvements, mostly to readability.
BUG=skia:
Review URL: https://codereview.chromium.org/870803002
This is a speculative fix for the crashing N5 bots. It looks like the bots are
always failing in or around FloatingPointTextureTest.
It looks like sometimes they're hitting a SIGBUS, which I suspect is stack
overflow. FloatingPointTextureTest allocates ~320K on the stack, which may
be too much. This CL moves those buffers to the heap. For consistency I did
the same with the half-float tests, though they're only using ~1/8th the stack.
It looks like sometimes the bots are failing to malloc. I don't understand that,
and this CL doesn't address that directly. But it's possible this is still a stack
overflow, just trashing RAM and causing arbitrary mayhem instead of a SIGBUS.
I have no idea why this is a problem only on the N5. I have been unable to
reproduce this locally, neither with a K N5 nor an L N5, but the bots are pretty
reliable.
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/871623002
Added in check for sized internal format.
Made choice between RED and ALPHA orthogonal to HALF_FLOAT and
HALF_FLOAT_OES.
Enabled rendertarget support on ES 2.0.
Review URL: https://codereview.chromium.org/805033002
It's unclear what params should be used for half float alpha
rendertargets, so they are disabled for the moment.
Review URL: https://codereview.chromium.org/799593002
This allows us to create distance field textures with better precision,
which may help text quality.
BUG=skia:3103
Review URL: https://codereview.chromium.org/762923003
Consolidate read/write funcs in context.
Remove support for reading pixels from a surface that's not a target. It's currently broken and neither used nor tested.
Review URL: https://codereview.chromium.org/648863002
