skia2/tests/FloatingPointTextureTest.cpp

101 lines
4.1 KiB
C++
Raw Normal View History

/*
* Copyright 2014 Google Inc.
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
/*
* This is a straightforward test of floating point textures, which are
* supported on some platforms. As of right now, this test only supports
* 32 bit floating point textures, and indeed floating point test values
* have been selected to require 32 bits of precision and full IEEE conformance
*/
#include "tests/Test.h"
#include "include/gpu/GrContext.h"
#include "include/private/GrTextureProxy.h"
#include "include/private/SkHalf.h"
#include "src/gpu/GrContextPriv.h"
#include "src/gpu/GrProxyProvider.h"
#include "tools/gpu/ProxyUtils.h"
#include <float.h>
static const int DEV_W = 100, DEV_H = 100;
template <typename T>
void runFPTest(skiatest::Reporter* reporter, GrContext* context, T min, T max, T epsilon, T maxInt,
int arraySize, GrColorType colorType) {
if (0 != arraySize % 4) {
REPORT_FAILURE(reporter, "(0 != arraySize % 4)",
SkString("arraySize must be divisible by 4."));
return;
}
SkTDArray<T> controlPixelData, readBuffer;
controlPixelData.setCount(arraySize);
readBuffer.setCount(arraySize);
for (int i = 0; i < arraySize; i += 4) {
controlPixelData[i + 0] = min;
controlPixelData[i + 1] = max;
controlPixelData[i + 2] = epsilon;
controlPixelData[i + 3] = maxInt;
}
for (auto origin : {kTopLeft_GrSurfaceOrigin, kBottomLeft_GrSurfaceOrigin}) {
auto fpProxy = sk_gpu_test::MakeTextureProxyFromData(context, true, DEV_W, DEV_H, colorType,
origin, controlPixelData.begin(), 0);
// Floating point textures are NOT supported everywhere
if (!fpProxy) {
continue;
}
sk_sp<GrSurfaceContext> sContext = context->priv().makeWrappedSurfaceContext(
std::move(fpProxy));
REPORTER_ASSERT(reporter, sContext);
bool result = context->priv().readSurfacePixels(
sContext.get(), 0, 0, DEV_W, DEV_H, colorType, nullptr, readBuffer.begin(), 0);
REPORTER_ASSERT(reporter, result);
REPORTER_ASSERT(reporter,
0 == memcmp(readBuffer.begin(), controlPixelData.begin(), readBuffer.bytes()));
}
}
static const int RGBA32F_CONTROL_ARRAY_SIZE = DEV_W * DEV_H * 4;
static const float kMaxIntegerRepresentableInSPFloatingPoint = 16777216; // 2 ^ 24
DEF_GPUTEST_FOR_RENDERING_CONTEXTS(FloatingPointTextureTest, reporter, ctxInfo) {
runFPTest<float>(reporter, ctxInfo.grContext(), FLT_MIN, FLT_MAX, FLT_EPSILON,
kMaxIntegerRepresentableInSPFloatingPoint, RGBA32F_CONTROL_ARRAY_SIZE,
GrColorType::kRGBA_F32);
}
static const int RG32F_CONTROL_ARRAY_SIZE = DEV_W * DEV_H * 2;
DEF_GPUTEST_FOR_RENDERING_CONTEXTS(FloatingPointTextureTest_RG, reporter, ctxInfo) {
runFPTest<float>(reporter, ctxInfo.grContext(), FLT_MIN, FLT_MAX, FLT_EPSILON,
kMaxIntegerRepresentableInSPFloatingPoint, RG32F_CONTROL_ARRAY_SIZE,
GrColorType::kRG_F32);
}
static const int HALF_ALPHA_CONTROL_ARRAY_SIZE = DEV_W * DEV_H * 1 /*alpha-only*/;
static const SkHalf kMaxIntegerRepresentableInHalfFloatingPoint = 0x6800; // 2 ^ 11
Always use GL_HALF_FLOAT_OES on ANGLE, even with ES3. 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>
2016-11-17 18:27:31 +00:00
DEF_GPUTEST_FOR_RENDERING_CONTEXTS(HalfFloatAlphaTextureTest, reporter, ctxInfo) {
runFPTest<SkHalf>(reporter, ctxInfo.grContext(), SK_HalfMin, SK_HalfMax, SK_HalfEpsilon,
kMaxIntegerRepresentableInHalfFloatingPoint, HALF_ALPHA_CONTROL_ARRAY_SIZE,
GrColorType::kAlpha_F16);
}
static const int HALF_RGBA_CONTROL_ARRAY_SIZE = DEV_W * DEV_H * 4 /*RGBA*/;
Always use GL_HALF_FLOAT_OES on ANGLE, even with ES3. 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>
2016-11-17 18:27:31 +00:00
DEF_GPUTEST_FOR_RENDERING_CONTEXTS(HalfFloatRGBATextureTest, reporter, ctxInfo) {
runFPTest<SkHalf>(reporter, ctxInfo.grContext(), SK_HalfMin, SK_HalfMax, SK_HalfEpsilon,
kMaxIntegerRepresentableInHalfFloatingPoint, HALF_RGBA_CONTROL_ARRAY_SIZE,
GrColorType::kRGBA_F16);
}