3 ms·
A decent chunk of it also comprises definitions of names/addresses/values that are (presumably) automatically translated from some authoritative description. Th
by 0xcde4c3db 6y ago
A decent chunk of it also comprises definitions of names/addresses/values that are (presumably) automatically translated from some authoritative description. This seems to be optimized for portability and consistent mapping to the input, not optimized for size, so there's a lot of stuff like [1]:
typedef enum CRC_SRC_SEL {
CRC_SRC_0 = 0x00000000,
CRC_SRC_1 = 0x00000001,
CRC_SRC_2 = 0x00000002,
CRC_SRC_3 = 0x00000003,
} CRC_SRC_SEL;
This might seem silly and redundant, and there are arguably better ways to express it, but the explicit approach makes a lot more sense if you skim the other definitions and see that some are 1-indexed, some have discontinuities, some have non-obvious reserved or otherwise special values, some have a totally distinct meaning for each value, etc.. Some of the definitions do look questionable, but on the whole I don't think any amount of macro magic could actually make these definitions small; the feature set of a modern GPU really is massively complex.
[1] https://github.com/torvalds/linux/blob/c84e1efae022071a4fcf9f1899bf71777c49943a/drivers/gpu/drm/amd/include/navi10_enum.h#L1092 https://github.com/torvalds/linux/blob/c84e1efae022071a4fcf9...
- derefr 6y agoThat makes me wonder: is there some tool for C that does dead-code elimination of source code rather than of the target binary? Something that'd strip out all these un-referenced constants? It certainly wouldn't be useful for most projects, because most code that's un-referenced is only temporarily so. But in this codebase, it's a more permanent thing, with the driver for any given model being guaranteed to never need e.g. hardware register addresses for hardware doesn't have.