> So it's not like they had to start absolutely from scratch here No, and actually in some respects that's not a good thing either. Their existing iGPU driver

> So it's not like they had to start absolutely from scratch here No, and actually in some respects that's not a good thing either. Their existing iGPU driver was designed with the assumption of GPU and CPU memory being pretty much fungible, and with the CPU being pretty "close" in terms of latency, just across the ringbus. It wasn't even PCIe attached, like how AMD does it, it was directly on the ringbus like another core. Now you need to take that legacy codebase and refactor it to have a conception of where data lives and how computation needs to proceed in order to feed the GPU with the minimum number of trips across the bus. Is that easier than writing a clean driver from scratch, and pulling in specific bits that you need? .... One of their recent bugs in raytracing was literally due to one line of code in an allocator that was missing a flag to allocate the space in GPU memory instead of CPU, a one-line change produced a 100x speedup in the raytracing performance. https://www.phoronix.com/news/Intel-Vulkan-RT-100x-Improve https://www.phoronix.com/news/Intel-Vulkan-RT-100x-Improve It is most likely much easier to do what AMD did and go from discrete to integrated than the other way around... again, they don't have a tightly-coupled design like Intel did, their iGPU is literally just a pcie client that happens to be on the same die. (also, AMD paid the penalty like 15 years ago... there were terascale based APUs, and the GCN driver was developed as a dGPU/iGPU hybrid architecture from day 1, they never had to backport GCN itself from dGPU, that was all done in the terascale days.)