|
d27a1fd0
|
2025-04-03T19:59:20
|
|
Compiler: Allow denorm float values in the lexer
This adds an option to preserve denorm values in the lexer,
skipping the explicit zero conversions for below range floats.
There are applications in the wild that expect to be able to
use denorm float values. They are typically immediately converted
to integer values, not used in floating point operations.
The option is only enabled for Vulkan backends.
Test: FloatLexTest, DenormFloatsToIntValues, app traces
Bug: b/406827038
Change-Id: Iab5a1a69a540b78ccbce8ea90b532d2d4976e29e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6432237
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
3892ac14
|
2023-10-12T13:35:33
|
|
Do not flush normal float constants to zero.
It's ok to flush denormalized constants to zero.
It's not ok to flush perfectly valid normal float constants >= FLT_MIN
to zero.
Two problems:
1) Values when parsed as doubles with a value less than FLT_MIN are
being flushed to zero. This is incorrect when the comparison is done
in double, since some values below FLT_MIN in double are equal to
FLT_MIN when cast to float. The fix is to perform the comparison in
float.
2) Values with a decimal exponent less than FLT_MIN_10_EXP are being
flushed to zero. FLT_MIN_10_EXP is -37 but FLT_MIN is 1.1754943E-38.
10^-37 may be the "minimum negative integer such that 10 raised to
that power is a normalized float", but being constrained to powers of
ten it's above FLT_MIN (which is 2^-126). Since this comparison is
done before #1 above, it's only present (AFAIK) to ensure that the
exponent will not make the pow() function overflow. Comparing against
-38 (FLT_MIN_10_EXP - 1) instead will do the trick.
Bug: angleproject:8373, dawn:2077
Change-Id: I1ddf410c2caa9f0d1ba3529ace693dcd326a2cb3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4936714
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
9d737966
|
2019-08-14T12:25:12
|
|
Standardize copyright notices to project style
For all "ANGLE Project" copyrights, standardize to the format specified
by the style guide. Changes:
- "Copyright (c)" and "Copyright(c)" changed to just "Copyright".
- Removed the second half of date ranges ("Y1Y1-Y2Y2"->"Y1Y1").
- Fixed a small number of files that had no copyright date using the
initial commit year from the version control history.
- Fixed one instance of copyright being "The ANGLE Project" rather than
"The ANGLE Project Authors"
These changes are applied both to the copyright of source file, and
where applicable to copyright statements that are generated by
templates.
BUG=angleproject:3811
Change-Id: I973dd65e4ef9deeba232d5be74c768256a0eb2e5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1754397
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
ffd39978
|
2019-02-20T10:45:24
|
|
test: Replace _TEST_CASE_ with _TEST_SUITE_.
Googletest is (at last) converging with industry-standard terminology
[1]. We previously called test suites "test cases", which was rather
confusing for folks coming from any other testing framework.
Chrome now has a googletest version that supports _TEST_SUITE_ macros
instead of _TEST_CASE_, so this CL cleans up some of the outdated usage.
[1] https://github.com/google/googletest/blob/master/googletest/docs/primer.md#beware-of-the-nomenclature
Bug: chromium:925652
Change-Id: Ia0deec0bc4216ef1adabc33985a7cbda89682608
Reviewed-on: https://chromium-review.googlesource.com/c/1477418
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
|
|
c3907efa
|
2018-06-08T13:03:15
|
|
Always use custom float parsing in GLSL
We now always use custom parsing code for parsing floats in GLSL
shaders. Previously this code was only used in corner cases that
stringstream parsing did not handle according to the GLSL spec.
This is slightly faster in compiler perftests, and results in a
smaller binary as well.
Some new test cases are added to make sure that the custom float
parsing behaves correctly.
BUG=chromium:849245
TEST=angle_unittests, angle_perftests
Change-Id: I2a88ec6a8b427016e34519d72bc98216947a4c64
Reviewed-on: https://chromium-review.googlesource.com/1092697
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
99bd5f40
|
2016-11-07T12:44:29
|
|
Fix GLSL float parsing corner cases
This fixes parsing floats that are out-of-range, and floats that have
more digits than the standard library float parsing functions can
handle. In these cases, we now fall back to a custom implementation of
float parsing. The custom parsing path can correctly process floats
with up to hundreds of millions of digits in their mantissa part.
Rounding behavior of the custom float parser may not be entirely
consistent with the standard parser, but the error should be at most
a few ULP. This can be considered acceptable since floating point
operations are not expected to be exact in GLSL in general. Settling
for lower accuracy also enables the parser to run in constant memory,
instead of having to store all the significant digits of the decimal
mantissa being parsed.
BUG=angleproject:1613
TEST=angle_unittests
Change-Id: I04a5d9ae5aaca48ef14b79cca5b997078614eb1c
Reviewed-on: https://chromium-review.googlesource.com/412082
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|