Hash :
4334125b
Author :
Date :
2025-03-14T16:12:32
Metal: Make StateCache descriptors hash consistent Various descriptors would compare equality and do hashing based on the underlying storage. The storage contains alignment padding and bitfields. The contents of these are not defined, even when the constructors tried to memset and memcpy. The various hash and compare functions also seemed to be missing some elements, like rasterSampleCount. Missing == on fields and hashing unused memory may lead to inconsistency where a==b is true but hash(a) != hash(b). Fix by: Remove the memset/memcpy and write out the operator== and hash() consistently. Initialize the members to their default values. Use uint32_t : 1 instead of bool if the struct tries to optimize for size, since mixing types stops the packing. Use uint32_t to get the alignment to uint32_t, which is mostly what is expected. Use uint32 someVar : N where N is payload bits + padding bits for the last member. This way the assignment clears the padding bits. The goal os to get the operator== to compare the padding bits, which lets the compiler elide the memberwise compares and use word-wise compares where it makes sense. This is an attempt to fix rare crashes related to map inserts and lookups. std::unordered_map will crash if operator== is not consistent with hash. Bug: angleproject:403372465 Change-Id: I0a3a2ff327ac9f65e7d41bc9585cda54ce93ab86 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6355828 Commit-Queue: Kimmo Kinnunen <kkinnunen@apple.com> Auto-Submit: Kimmo Kinnunen <kkinnunen@apple.com> Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com> Reviewed-by: Geoff Lang <geofflang@chromium.org>
This folder contains shared back-end-specific implementation files. The classes
and types in renderer are not specified by GLES. They instead are common to
all the various ANGLE implementations.
See renderer_utils.h for various cross back-end utilties.
The ANGLE format class, angle::Format, works as a union
between GLES and all the various back-end formats. It can represent any type
of format in ANGLE. e.g. Formats in Vulkan that don’t exist in GLES, or DXGI
formats that don’t exist in GLES, or Windows/Android surface configs that
don’t exist anywhere else.
The glInternalFormat member of angle::Format represents the “closest” GL
format for an ANGLE format. For formats that don’t exist in GLES this will
not be exactly what the format represents.
The back-ends also define their own format tables. See the Vulkan Format table docs and the [D3D11 format table docs][D23D11FormatDocs].
DXGI formats are used in both the GL and D3D11 back-end. Therefore the generated info table lives in this common shared location.
The DXGI info table is generated by gen_dxgi_format_table.py
and sources data from dxgi_format_data.json. The
main purpose of the table is to convert from a DXGI format to an ANGLE
format, where the ANGLE format should have all the necessary information.