Judging by config files, these seem to be added in May/June for Arden. Oberon A0 regression tests date from March 28 for first blocks to June.
That broad a range leaves some uncertainty on how it aligns with the apparent mention of bvh64 in AMD's LLVM commit. The upper date limit for the last-saved information puts them after the LLVM changes, which doesn't reinforce the usefulness of those lines as much as if it were certain they were around longer and were sourced from an undeniably private source.
Also, nothing there is older then June 2018 (I think Navi 10 is oldest), thus I doubt Ariel is 2017 design. Perhaps it was used as early "bench" as it seems to have originated from Navi 10, and Oberon is iGPU with RT, I dunno, but Oberon is clearly PS5 chip (as per aquariusZi, as per Flute benchmark from July). We have no other codename from AMD of another "hidden" SOC chip...
Some of the data points we are connecting do step on the usual practice in other parts of the discipline.
For example, the tying of PCI ID values to specific chips or steppings doesn't fully make sense and might mean some of the inferences are spurious. The choice of PCI ID values on their own doesn't quite compute, since it seems to strand the supposed Ariel ID in the middle of the the SOC range, and the narrative tacks on two separate IGP IDs that normally could have just taken its slot.
The way they just increment the last ID from the SOC range seems sloppy, and more like someone looked at the public PCI ID range and incremented rather than the more planned-out ID allocation actual products have.
That could be an indication that these values can be messier during internal development, but it could also mean some of these points are misleading.
Not sure about splitting up the CCX sections for the PS5, for one thing. The CCX uses the shared L3 and shadow tags in that space for internal coherence, and there's pretty broad data paths between each group of 4 that might not play well with that arrangement.
The 3 SE scenario for the Xbox does run into a question about how AMD would handle non-symmetric rasterizer and RBE coverage.
AMD's distribution methods and some code mentions for primitive shaders in Vega point to using some straightforward methods for determining what SEs may be involved based on the coordinates of a triangle. AMD uses some form of checkerboard, and its implementations have worked with the 1/2/4 setup in the past. Navi10 at least seems like it follows the same tiling method. There are now 2 rasterizers and primitive units per SE, but that hasn't taken that GPU out of the range of prior GPUs.
