At the time they were talking about integrated compute units between CPU and GPU, mapping GPU register space into CPU address space, linking/unlinking CPU and GPU pipelines, etc etc. And the CPU and GPU teams would be working on this while also having to produce top-shelf stand-alone CPUs and GPUs to fight on 2 separate fronts against entrenched and capable competitors. It didn't really seem possible or even desirable at the time.
I also don't understand why having a GPU would improve their chances with console vendors. Those vendors could have still selected AMD CPUs but cut separate deals for the GPU with other companies. This is a business AMD is already and was already in. They do this in all sorts of markets like network switches.
I don't know what the grand plans were to have CPU and GPU teams both in a multiple level deep tick tock pipeline (organizations are structured like CPUs or CPUs are structured like assembly lines ... pick your causal metaphor). That would require the right fabric, I don't know if they have that yet. There is a ton of research that shows that a mediocre GPU on the same memory bus as a CPU has a huge number advantages over a GPU on the PCIe bus, even at x16. With HBM, hell put the GPU in the HBM. All HSAIL the HBM!
CPU, GPU and FPGA will all merge into a computational goo. With AMD acquiring Xilinx and their past with APUs and HSA, I stand by my statement. AMD has been stalling on the G series Ryzen parts because I think they don't want to cannibalize their discrete GPU business, but CPUs have more than enough compute and memory bandwidth to support software geometry and rasterization.
https://moorinsightsstrategy.com/the-real-reasons-microsoft-...
The work they did around HSAIL and APUs shows that they have the creativity and the will.