Reading this article got me thinking - specifically about the HSA part, and what this means under Linux. It seems to me that supporting such a GPU, with the same address space and MMU as the CPU, would require pretty invasive changes to the mm subsystem - a core part of the kernel. Furthermore, I'm assuming this means that the GPU driver would need some kind of interface to the memory manager to coordinate the CPU and GPU. This is no problem for the open-source driver - albeit it would require tons and tons of work as it's basically ripping out GEM/TTM or extending it so that it can handle the new way of managing memory. However, for Catalyst to work this would require exporting these interface as not GPLed (i.e. EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL), similar to what nvidia is trying to do with dma-buf. Of course we all know the uproar that's caused - now take that, and crank it to 11 to imagine what would happen if AMD tried to do that with the mm subsystem. So, the question is, is it even possible to support HSA with a closed blob? Of course, this is all purely hypothetical - we won't really know what will happen until AMD discloses more information about how HSA works. Regardless, I think its an interesting question, one will certainly come up when Kaveri and Kabini launch in 2013 and has broad implications for Linux GPU driver development in the future.