This change makes the translator files more organized by:
- Grouping files that are specific to a certain output under their own
directory,
- Moving transformations under tree_ops
- Removing Direct from metal translation now that that SPIR-V Cross path
is removed
Bug: angleproject:6394
Change-Id: Iaf5bb8d5604b84748dece029821b1f77b2813967
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4678780
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Removes scripts/code_generation_hashes/Test_spec_JSON.json
Instead, run codegen in --verify-only mode and compare content.
This run during presubmits and is fast (~0.2s in my tests)
Similar to https://crrev.com/c/4604579
With this, should be able to auto-resolve conflicts in
infra/specs/angle.json
Also testing/buildbot/mixins.pyl
seems to have had hashes routinely updated by autorolls.
Bug: angleproject:8193
Change-Id: Ic1a657dbf464e6f4a8066ea8c5e18297e27a3b4c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4605467
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Auto-Submit: Roman Lavrov <romanl@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Only changes the way we get auto_script inputs/outputs.
Before this CL, some of the scripts (depending on the shebang)
are run via vpython3 - which can take a few seconds. But the
inputs/outputs code generally doesn't require any unusual imports, so we
can just add little hacks to suppress those imports where needed when
an argument is given to the script.
Bug: angleproject:8184
Change-Id: Ib09a35b839318253fe7e913e24a756d2cb46dad1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4585820
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Get rid of chdir which breaks parallel execution due to global state.
Makes dirty verification faster. auto_script runs scripts with args
which can be slow (as scripts have imports)
On my machine, this speeds up verification from ~6s to ~1.3s
Bug: None
Change-Id: I78227cc80be54b0901029a286b0f017d36348a71
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4499820
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Features are now specified in a json file and autogenerated. This is in
preparation for more autogeneration to support feature override in
tests.
This change doesn't yet fix the issues in anglebug.com/6435 and should
be a no-op.
Bug: angleproject:6435
Change-Id: Icdb63a94dc37b5fef0a356e0fc0b49937e083c8a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3579941
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Some border color tests used to fail due to either unclamped color
values or not accounting for depth, stencil or luma formats. We now
adjust the border color value according to the sampler's format.
Test: dEQP-GLES31.functional.texture.border_clamp.*
Bug: angleproject:3577
Bug: angleproject:6213
Change-Id: Ib38ce2374622bfafde69fe3fa2d7227d60043954
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551895
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Uses the data from registry.xml combined with gl.xml to produce the
necessary header and source file with the strings map. Also updates
the list of supported extensions. Several extensions were missing
from the supported extensions map.
ARB_sync and NV_robustness_video_memory_purge require some specific
tweaks to get the generator to accept them as gles extensions.
Also includes a generate markdown file that lists supported exts.
Bug: angleproject:6379
Change-Id: I95bd589aa31a62b4a008de24408c7823a49023ed
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3157418
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
ANGLE implementes some formats as other formats,such as ALPHA8 to R8,
this caused some tests failed due to missing border color's channel
translation,this change add a new textureBorderLoadFunction to
translate channels of border color by image view format.
Bug: angleproject:6046
Change-Id: I94ce719b4db3724ffd3dc862b51a412b5d9f3cce
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2972328
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
If any JSON files get out of whack this will print which file is
malformed. Also will show any temporary files (e.g. .rej or .orig)
as untracked in the code generation hashes dir.
Bug: angleproject:3691
Change-Id: I534e87bd2ea692182aa558bb80e09fb526e441b0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2564000
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The trace tests aren't strictly for performance. Since we'll be using
them for correctenss testing as well it makes sense to move them out
of the perf_tests/ folder.
Also renames RestrictedTraceTests.md to README.md so it'll load
automatically in gitiles.
Bug: angleproject:4090
Bug: b/168049670
Change-Id: I8be9f1d831489a9abf534d049a93441687850142
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2416913
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
For some reason this line of code confused git cl format
in that it would generate different results depending on when
it was called:
"PFNEGLSTREAMCONSUMERGLTEXTUREEXTERNALATTRIBSNVPROC
ANGLE_EGL_StreamConsumerGLTextureExternalAttribsNV;"
I wasn't able to root cause the bug. Instead I worked around
it by changing the signatures for this file.
Bug: angleproject:4596
Change-Id: I4f18e03d27d378480b19831de51c4e85d815ca66
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2176157
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
ANGLE translator's parser code generation is changed to use the binaries
of flex/bison stored in the cloud. scripts/run_code_generation.py now
automatically runs these files if the input files change.
Bug: angleproject:3419
Change-Id: Icce4247f93b27baf8ee12dbb16112fa2cc98c111
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1940572
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
dEQP has data files that live in several directories within dEQP's
source tree. For example, GLES3 has data files that live within:
data/gles3/data/
external/graphicsfuzz/data/gles3/
However, we can only tell dEQP about a single data directory during
initialization of dEQP. To get around this, we are manually copying all
of the necessary data files to the output generated files directory and
pointing dEQP to this single directory. This also helps us solve a
second problem related to the paths that dEQP uses when accessing
graphicsfuzz data files.
For the graphicsfuzz tests, dEQP will attempt to open the necessary
shaders by accessing them with the path:
data/gles3/graphicsfuzz/
However, those files would normally live at the path that matches their
location within the source tree:
external/graphicsfuzz/data/gles3/graphicsfuzz/
As part of the manual copy of these data files, we are also able to
strip the extra 'external/graphicsfuzz/' portion of the path.
Bug: angleproject:2322
Test: dEQP
Change-Id: Ibc96442c221485e2f246890fa8fe51f090c5e222
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1881759
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
This is a reland of e54d0f90d1
This was reverted due to a build failure as a result of a missing
virtual destructor in the widget base class.
Original change's description:
> Vulkan: Debug overlay
>
> A debug overlay system for the Vulkan backend designed with efficiency
> and runtime configurability in mind. Overlay widgets are of two
> fundamental types:
>
> - Text widgets: A single line of text with small, medium or large font.
> - Graph widgets: A bar graph of data.
>
> Built on these, various overlay widget types are defined that gather
> statistics. Five such types are defined with one widget per type as
> example:
>
> - Count: A widget that counts something. VulkanValidationMessageCount
> is an overlay widget of this type that shows the number of validation
> messages received from the validation layers.
> - Text: A generic text. VulkanLastValidationMessage is an overlay
> widget of this type that shows the last validation message.
> - PerSecond: A value that gets reset every second automatically. FPS is
> an overlay widget of this type that simply gets incremented on every
> swap().
> - RunningGraph: A graph of last N values. VulkanCommandGraphSize is an
> overlay of this type. On every vkQueueSubmit, the number of nodes in
> the command graph is accumulated. On every present(), the value is
> taken as the number of nodes for the whole duration of the frame.
> - RunningHistogram: A histogram of last N values. Input values are in
> the [0, 1] range and they are ranked to N buckets for histogram
> calculation. VulkanSecondaryCommandBufferPoolWaste is an overlay
> widget of this type. On vkQueueSubmit, the memory waste from command
> buffer pool allocations is recorded in the histogram.
>
> Overlay font is placed in libANGLE/overlay/ which gen_overlay_fonts.py
> processes to create an array of bits, which is processed at runtime to
> create the actual font image (an image with 3 layers).
>
> The overlay widget layout is defined in overlay_widgets.json which
> gen_overlay_widgets.py processes to generate an array of widgetss, each
> of its respective type, and sets their properties, such as color and
> bounding box. The json file allows widgets to align against other
> widgets as well as against the framebuffer edges.
>
> Two compute shaders are implemented to efficiently render the UI:
>
> - OverlayCull: This shader creates a bitset of Text and Graph widgets
> whose bounding boxes intersect a corresponding subgroup processed by
> OverlayDraw. This is done only when the enabled overlay widgets are
> changed (a feature that is not yet implemented) or the surface is
> resized.
> - OverlayDraw: Using the bitsets generated by OverlayCull, values that
> are uniform for each workgroup (set to be equal to hardware subgroup
> size), this shader loops over enabled widgets that can possibly
> intersect the pixel being processed and renders and blends in texts
> and graphs. This is done once per frame on present().
>
> Currently, to enable overlay widgets an environment variable is used.
> For example:
>
> $ export ANGLE_OVERLAY=FPS:VulkanSecondaryCommandBufferPoolWaste
> $ ./hello_triangle --use-angle=vulkan
>
> Possible future work:
>
> - On Android, add settings in developer options and enable widgets based
> on those.
> - Spawn a small server in ANGLE and write an application that sends
> enable/disable commands remotely.
> - Implement overlay for other backends.
>
> Bug: angleproject:3757
> Change-Id: If9c6974d1935c18f460ec569e79b41188bd7afcc
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1729440
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Bug: angleproject:3757
Change-Id: I47915d88b37b6f882c686c2de13fca309a10b572
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1780897
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
This reverts commit e54d0f90d1.
Reason for revert: causes compile failure on Linux CFI bot.
Sample build: https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/14810
Sample log: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8903575125463586160/+/steps/compile/0/stdout?format=raw
Original change's description:
> Vulkan: Debug overlay
>
> A debug overlay system for the Vulkan backend designed with efficiency
> and runtime configurability in mind. Overlay widgets are of two
> fundamental types:
>
> - Text widgets: A single line of text with small, medium or large font.
> - Graph widgets: A bar graph of data.
>
> Built on these, various overlay widget types are defined that gather
> statistics. Five such types are defined with one widget per type as
> example:
>
> - Count: A widget that counts something. VulkanValidationMessageCount
> is an overlay widget of this type that shows the number of validation
> messages received from the validation layers.
> - Text: A generic text. VulkanLastValidationMessage is an overlay
> widget of this type that shows the last validation message.
> - PerSecond: A value that gets reset every second automatically. FPS is
> an overlay widget of this type that simply gets incremented on every
> swap().
> - RunningGraph: A graph of last N values. VulkanCommandGraphSize is an
> overlay of this type. On every vkQueueSubmit, the number of nodes in
> the command graph is accumulated. On every present(), the value is
> taken as the number of nodes for the whole duration of the frame.
> - RunningHistogram: A histogram of last N values. Input values are in
> the [0, 1] range and they are ranked to N buckets for histogram
> calculation. VulkanSecondaryCommandBufferPoolWaste is an overlay
> widget of this type. On vkQueueSubmit, the memory waste from command
> buffer pool allocations is recorded in the histogram.
>
> Overlay font is placed in libANGLE/overlay/ which gen_overlay_fonts.py
> processes to create an array of bits, which is processed at runtime to
> create the actual font image (an image with 3 layers).
>
> The overlay widget layout is defined in overlay_widgets.json which
> gen_overlay_widgets.py processes to generate an array of widgetss, each
> of its respective type, and sets their properties, such as color and
> bounding box. The json file allows widgets to align against other
> widgets as well as against the framebuffer edges.
>
> Two compute shaders are implemented to efficiently render the UI:
>
> - OverlayCull: This shader creates a bitset of Text and Graph widgets
> whose bounding boxes intersect a corresponding subgroup processed by
> OverlayDraw. This is done only when the enabled overlay widgets are
> changed (a feature that is not yet implemented) or the surface is
> resized.
> - OverlayDraw: Using the bitsets generated by OverlayCull, values that
> are uniform for each workgroup (set to be equal to hardware subgroup
> size), this shader loops over enabled widgets that can possibly
> intersect the pixel being processed and renders and blends in texts
> and graphs. This is done once per frame on present().
>
> Currently, to enable overlay widgets an environment variable is used.
> For example:
>
> $ export ANGLE_OVERLAY=FPS:VulkanSecondaryCommandBufferPoolWaste
> $ ./hello_triangle --use-angle=vulkan
>
> Possible future work:
>
> - On Android, add settings in developer options and enable widgets based
> on those.
> - Spawn a small server in ANGLE and write an application that sends
> enable/disable commands remotely.
> - Implement overlay for other backends.
>
> Bug: angleproject:3757
> Change-Id: If9c6974d1935c18f460ec569e79b41188bd7afcc
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1729440
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
TBR=geofflang@chromium.org,syoussefi@chromium.org,jmadill@chromium.org
Bug: angleproject:3757
Change-Id: Ib08e2e7b1a9449ca097673acb11655df5d2bbf31
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1778862
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
A debug overlay system for the Vulkan backend designed with efficiency
and runtime configurability in mind. Overlay widgets are of two
fundamental types:
- Text widgets: A single line of text with small, medium or large font.
- Graph widgets: A bar graph of data.
Built on these, various overlay widget types are defined that gather
statistics. Five such types are defined with one widget per type as
example:
- Count: A widget that counts something. VulkanValidationMessageCount
is an overlay widget of this type that shows the number of validation
messages received from the validation layers.
- Text: A generic text. VulkanLastValidationMessage is an overlay
widget of this type that shows the last validation message.
- PerSecond: A value that gets reset every second automatically. FPS is
an overlay widget of this type that simply gets incremented on every
swap().
- RunningGraph: A graph of last N values. VulkanCommandGraphSize is an
overlay of this type. On every vkQueueSubmit, the number of nodes in
the command graph is accumulated. On every present(), the value is
taken as the number of nodes for the whole duration of the frame.
- RunningHistogram: A histogram of last N values. Input values are in
the [0, 1] range and they are ranked to N buckets for histogram
calculation. VulkanSecondaryCommandBufferPoolWaste is an overlay
widget of this type. On vkQueueSubmit, the memory waste from command
buffer pool allocations is recorded in the histogram.
Overlay font is placed in libANGLE/overlay/ which gen_overlay_fonts.py
processes to create an array of bits, which is processed at runtime to
create the actual font image (an image with 3 layers).
The overlay widget layout is defined in overlay_widgets.json which
gen_overlay_widgets.py processes to generate an array of widgetss, each
of its respective type, and sets their properties, such as color and
bounding box. The json file allows widgets to align against other
widgets as well as against the framebuffer edges.
Two compute shaders are implemented to efficiently render the UI:
- OverlayCull: This shader creates a bitset of Text and Graph widgets
whose bounding boxes intersect a corresponding subgroup processed by
OverlayDraw. This is done only when the enabled overlay widgets are
changed (a feature that is not yet implemented) or the surface is
resized.
- OverlayDraw: Using the bitsets generated by OverlayCull, values that
are uniform for each workgroup (set to be equal to hardware subgroup
size), this shader loops over enabled widgets that can possibly
intersect the pixel being processed and renders and blends in texts
and graphs. This is done once per frame on present().
Currently, to enable overlay widgets an environment variable is used.
For example:
$ export ANGLE_OVERLAY=FPS:VulkanSecondaryCommandBufferPoolWaste
$ ./hello_triangle --use-angle=vulkan
Possible future work:
- On Android, add settings in developer options and enable widgets based
on those.
- Spawn a small server in ANGLE and write an application that sends
enable/disable commands remotely.
- Implement overlay for other backends.
Bug: angleproject:3757
Change-Id: If9c6974d1935c18f460ec569e79b41188bd7afcc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1729440
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
With the relaxed C++14 constexpr rules allowed in Chromium, we can
use a constexpr sorted array to store our table data. This can lead
to very fast lookups while being more maintanable than using auto-
generator scripts for every lookup table.
Note that to be sure this syntax is permitted, we should land this
through the bots and let it sit for a little while.
Bug: angleproject:1389
Change-Id: I9395c40276470108ce3e5786d8f1b8d85462c517
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/777544
Commit-Queue: Jamie Madill <jmadill@google.com>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Re-land fixes build to ensure commit_id is built before libEGL.
libEGL was implicitly loading libGLESv2 on startup. This is bad
because on platforms like Linux and Mac we could sometimes use the
incorrect rpath. This in turn meant we needed workarounds like using
"_angle" extensions to our shared objects to get the correct loading
behaviour.
Fix this by loading libGLESv2 dynamically in libEGL. We build the
loader automatically from egl.xml. The loader itself is lazily
initialized on every EGL entry point call. This is necessary because
on Linux, etc, there is no equivalent to Windows' DLLMain.
We also use an EGL.h with different generation options so we have the
proper function pointer types. A README is included for instructions
on how to regenerate EGL.h.
The entry point generation script is refactored into a helper class
that is used in the loader generator. Also adds the libGLESv2 versions
of the EGL entry points in the DEF file on Windows. This allows them to
be imported properly in 32-bit configurations.
Also fixes up some errors in ANGLE's entry point definitions. Also
includes a clang-format disable rule for the Khronos headers.
This CL will help us to run ANGLE tests against native drivers.
Bug: angleproject:2871
Bug: chromium:915731
Change-Id: I4192a938d1f4117cea1bf1399c98bda7ac25ddab
Reviewed-on: https://chromium-review.googlesource.com/c/1380511
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
This reverts commit dd815b623e.
Reason for revert: Broke https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.ci/win-rel/8006
Original change's description:
> Load correct libGLESv2 on Linux and Mac.
>
> libEGL was implicitly loading libGLESv2 on startup. This is bad
> because on platforms like Linux and Mac we could sometimes use the
> incorrect rpath. This in turn meant we needed workarounds like using
> "_angle" extensions to our shared objects to get the correct loading
> behaviour.
>
> Fix this by loading libGLESv2 dynamically in libEGL. We build the
> loader automatically from egl.xml. The loader itself is lazily
> initialized on every EGL entry point call. This is necessary because
> on Linux, etc, there is no equivalent to Windows' DLLMain.
>
> We also use an EGL.h with different generation options so we have the
> proper function pointer types. A README is included for instructions
> on how to regenerate EGL.h.
>
> The entry point generation script is refactored into a helper class
> that is used in the loader generator. Also adds the libGLESv2 versions
> of the EGL entry points in the DEF file on Windows. This allows them to
> be imported properly in 32-bit configurations.
>
> Also fixes up some errors in ANGLE's entry point definitions. Also
> includes a clang-format disable rule for the Khronos headers.
>
> This CL will help us to run ANGLE tests against native drivers.
>
> Bug: angleproject:2871
> Change-Id: Id6ecf969308f17b1be4083538428c9c1a1836572
> Reviewed-on: https://chromium-review.googlesource.com/c/1370725
> Commit-Queue: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
TBR=ynovikov@chromium.org,geofflang@chromium.org,jmadill@chromium.org
Change-Id: I921b3c45435ab4f05cbc2d1c1172b4185d6257b0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: angleproject:2871
Reviewed-on: https://chromium-review.googlesource.com/c/1378887
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
libEGL was implicitly loading libGLESv2 on startup. This is bad
because on platforms like Linux and Mac we could sometimes use the
incorrect rpath. This in turn meant we needed workarounds like using
"_angle" extensions to our shared objects to get the correct loading
behaviour.
Fix this by loading libGLESv2 dynamically in libEGL. We build the
loader automatically from egl.xml. The loader itself is lazily
initialized on every EGL entry point call. This is necessary because
on Linux, etc, there is no equivalent to Windows' DLLMain.
We also use an EGL.h with different generation options so we have the
proper function pointer types. A README is included for instructions
on how to regenerate EGL.h.
The entry point generation script is refactored into a helper class
that is used in the loader generator. Also adds the libGLESv2 versions
of the EGL entry points in the DEF file on Windows. This allows them to
be imported properly in 32-bit configurations.
Also fixes up some errors in ANGLE's entry point definitions. Also
includes a clang-format disable rule for the Khronos headers.
This CL will help us to run ANGLE tests against native drivers.
Bug: angleproject:2871
Change-Id: Id6ecf969308f17b1be4083538428c9c1a1836572
Reviewed-on: https://chromium-review.googlesource.com/c/1370725
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
The packing and unpacking take a few extra instructions. But it
completely obviates the need for any switches in the validation code.
Speed is slightly faster or the similar depending on the back-end.
Also add gl_angle_ext.xml to GL entry point generator inputs. This was
missing and would cause the code generation to miss certain changes.
Bug: angleproject:2985
Change-Id: I1ea41a71db71135000166ead8305ec42d22ff7b3
Reviewed-on: https://chromium-review.googlesource.com/c/1351729
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Open files with mode 'r' instead of 'rb' so the hash calculation
produces the same results on Linux and Windows.
Recalculate the hashes and proc_table_autogen.cpp which was out of date.
BUG=angleproject:2711
Change-Id: I31562c96ce36e6df009c44c565fe9a3f1b5ba6c4
Reviewed-on: https://chromium-review.googlesource.com/1128549
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Frank Henigman <fjhenigman@chromium.org>
any_input_dirty would return early when finding a dirty input and not finish
filling the new_hashes map. This would require multiple runs of the code
generation script to fully generate all the outputs.
BUG=angleproject:2695
Change-Id: Ie62190efe2765df432b0a535fb8d33ed2ffa66a7
Reviewed-on: https://chromium-review.googlesource.com/1127439
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
