You seem to be missing a key point here: there's no such thing as a "Polaris 12 architecture". Polaris is the architecture, Polaris 12 is a specific chip found in the RX 550 and 560 with 16 CUs and a fixed feature set. There's no
architectural difference between Polaris 10, 11, or 12 beyond minor tweaks and optimizations that don't amount to anything near an architectural revision. While there are revisions of the Polaris architecture between chips, there are no
named revisions
. As such, there's no way of identifying revisions based on hardware ID numbers - those numbers identify specific chip designs. Any new chip with more or less CUs and other features changed would necessarily have a new hardware ID, as that would be necessary for drivers to utilize the correct paths and optimizations.
As for the "lego-like" nature of AMD GPUs, you're not telling anyone here anything we don't know - but you're not answering my questions either. See above. Given that GFX804 is
Polaris 12, how can it have 20-24 CUs as per the official spec sheets of KBL-G? That's impossible, as Polaris 12 has 16 CUs and a far smaller die size. In other words: this is not Polaris 12. Which, again, tells us that the GFX804 Hardware ID is erroneous in some way.
Now, the GFXBench link above is the only one actually saying anything linking GFX804 with 694C/694E, the rest are just benchmarks with varying degrees of misidientification of the CPU, GPU or both. Which is to be expected with pre-release hardware. If you see the others as evidence of any link between Vega M and the Polaris architecture, you'll have to spell that out for us, 'cause all the rest of the links are just saying "Vega M is 694C/694E" which tells us nothing at all.
As for the GFXBench thing, it's also interesting to note that only the OpenCL part identifies it as GFX804.
Now, I actually have a couple of hypotheses as to why we're seeing this weirdness, which are far friendlier with Ockham's razor than "'Vega M' is Polaris,
AMD is lying":
First, some base facts:
- KBL-G is a fully Intel product, with the entire driver stack provided by Intel (see launch information for confirmation of this from AMD)
- AMD then must provide Intel with base driver code to integrate into the Intel driver stack for KBL-G - Intel doesn't write drivers for AMD hardware, but probably optimizes it
- the KBL-G "pGPU" is a semi-custom chip, not entirely matching any existing amd GPU and thus requiring specific driver optimizations
- Support for new GPU designs rarely, if ever, appears in drivers until launch day or close to it
- Intel is selling this as a gaming chip, and has as of now not even hinted at pro-level aspirations for this design.
None of these things are new assumptions. Combining points 3 and 4 gives us two options for pre-release testing: either tweak existing drivers to misidentify the GPU to enable not-yet-finalized optimizations from another not-that-dissimilar chip (similar CU count/compute resources), or use not-yet-ready pre-release driver code lacking all these optimizations. They're probably doing both, but the first option would definitely be done as a step to seeing how the drivers would need to be tweaked compared to what's already released.
Then there's the fact that Intel is doing the testing, not AMD. They're on a tight schedule, requiring them to get this working quickly, while working with relatively unknown code and unknown hardware. Could this lead to the use of incorrect Hardware IDs as placeholders? I don't think that's unlikely - and certainly not as unlikely as AMD blurring the distinction between Polaris and Vega (which are separate architectures in very significant ways that don't relate to marketing whatsoever). Even though this project has been in the works for 2+ years, Intel hasn't had access to fully-functioning hardware or drivers until very recently.
Then there's the gaming-focused nature of the chip. If Intel has to pay AMD for every part of their hardware design AND software stack, and the OpenCL part is barely goint to be used at all (outside of professional applications, which isn't gaming, so not what this chip is marketed for). Why pay extra for a newer, more optimized version of the OpenCL driver stack if you don't need it, or could get an older one for cheaper? Or what if AMD is unwilling to part with it, to not cannibalize sales of Radeon Pro parts like in the MBP range and upcoming Vega Pro cards? Considering the compute-focused nature of the Vega architecture, it makes very much sense for AMD to not give Intel full access to the driver stack here, limiting the access to new, optimized code to the graphics/gaming parts.
In other words, this could be
- Placeholder IDs for early hardware testing, implemented to get drivers to work before significant rewriting can be done, or
- The result of AMD not giving Intel their newest OpenCL drivers, with Intel implementing the code "as-is" in pre-release testing
Neither of these hypotheses require any new assumptions - such as AMD calling a Polaris arch Vega for ... marketing purposes? - and as such fit well with Ockham's razor. Your hypothesis requires assuming that both AMD and Intel are lying or at best twisting the truth, which is a far bigger leap to make, and thus requires more evidence. What you've presented so far does not hold up to my standards, sadly. Heck, outside of the GFXBench listings, there's no link there
at all. If you have more, feel free to post it here, but for now I'll chalk it up to speculation with pretty shaky foundations.