So everyone is talking about something different here, and that's perfectly understandable, there are so many facets to the whole GP-GPU thing...
But this is why there will always be overhead with proprietary drivers: because those drivers, in order to write data to buffers without going through the CPU, or to buffers from other hardware parts, need a system function to do that. In GLX territory, the linux kernel provides that function. The instruction is called DMA-BUF. This instruction lets hardware parts directly access buffers from other hardware parts, which is pretty much the whole idea behind GP-GPU acceleration and CPU load minimization. Now here comes the problem: DMA-BUF is a GPL licensed linux kernel function, and that means that any derivative work of that function, should also be considered GPL. This means that if a graphics driver uses the DMA-BUF function, and guess what... they all do!... that driver should also be considered GPL licensed. The ONLY quasi-exception to this, is code that was written for another operating system, that means, code that uses a translation layer or state trackers or what have you to function with the operating system that provides the DMA-BUF function, in casu, linux. Now this is where the real problem is situated, because nVidia refuses to open source even the necessary hardware information to enable the community to make open source drivers, but their proprietary driver wants to use the DMA-BUF feature to enable GP-GPU functionality. The nVidia linux driver, just like the fglrx driver, are just Windows drivers, they are not written for linux, and they can't be, because then they would become derivative works and fall under a GPL license. nVidia is currently not respecting the GPL license of the linux kernel, because their kernel modules, which always should be considered GPL licensed because they clearly are specifically written to use linux kernel functionality, are not GPL licensed (nor are the AMD Catalyst kernel modules for that matter, but AMD does pay for open source driver development and the open source drivers are getting better faster, and are right now at least at the same level of the Intel drivers, which are only open source). nVidia has caved for the Tesla drivers, because the GP-GPU functionality is why anyone would be interested in such a card in the first place, and nVidia didn't have any other option, but in the consumer computing world, nVidia refuses to comply, and also refuses to go to court over this matter, because they know they will burn their arse on a court case. The linux foundation has no reason for getting mad at nVidia, because nVidia, by refusing to open source their drivers, is just excluding itself from the GP-GPU party that is being organized courtesy of AMD (HSA) and Intel (Beignet), because without open source drivers, they have to continue using Windows drivers in linux, which implies using a translation layer/state trackers/whatever to make the whole thing work. In Windows, the problem is not as deep as in linux, because in Windows, the kernel isn't GPL licensed, and they can merge functions into the Microsoft kernel against payment, and they can use proprietary drivers that access buffers directly, but the problem is, that the capabilities of Windows are very limited in this regard in comparison to linux, and that really shows.
Since nVidia was formally notified of this (as if they didn't know before...) (and Satya, here's your link to the discussion on this: http://lists.freedesktop.org/archives/dri-devel/2012-October/028846.html), they've stopped development on linux specific drivers almost completely (whereas before this date, they were very meticulous in making sure that their drivers worked really well in linux, which is why before that date, all linux users would buy nVidia GPU's), which is pretty much why every single kernel update leads to the failure of nVidia proprietary kernel modules to compile, which is something that is unfortunately the case again with the kernel update I did today on my machine, which is why I'm on nouveau again right now, and I'm starting to really hate nVidia, etc...
There simply is no solution for the nVidia driver problem. If they want to use the DMA-BUF and other functions of the linux kernel without driver overhead (and running a driver in a compatibility layer is just about as overheady as one can get), if they want to go really low level and join in the HSA party, they have to provide GPL licensed drivers. Since those drivers would necessitate both the ability to compile on GCC, and the open sourcing of the code, it would mean that they would have to open source all the code for their "extra functionality", which includes codec handling and PhysX, and it would mean that they would have to open source their machine language for their devices, which is called PTX. They don't want to do that, so they have to deal with the driver overhead. It's as simple as that.
Now Mantle is just a tool kit, it enables developers to relatively easily target particular instructions in their programming, these are the same instructions that are targeted by OpenGL, OpenCL, OpenMP and OpenAL, which are open source Khronos API's. Mantle is made for Windows, it is not made for linux, there are more development tools for GP-GPU optimization available for linux, Mantle specifically has the advantage of making it easier/cheaper for devs to develop for windows and linux at the same time, because Mantle as an API, targets the same instructions as the Khronos API's. Of course, AMD open sources hardware specifications and develops open source drivers and codec for all of the functionality in their cards. For instance, AMD has recently merged the audio functionality in the linux kernel, they have open sourced their VCE h.264 encoding codecs, etc... and in the end, what nVidia is still selling at a premium price as "Shadowplay", is de facto already in the linux kernel (and how more low level than that can one get?) because of AMD and Intel, and even nVidia itself, because nVidia for instance open sourced the VDPAU library, which allows for video acceleration in linux.
So is it true that Mantle allows for lower level instructions than Kronos API's... no... is Mantle necessary... no... is Mantle a good idea... absolutely yes, because it is something that allows developers of software console games to gradually migrate to a more powerful platform, so that they can get more out of the available hardware, which should benefit the evolution of the gaming experience, and buy some time for SteamOS and linux native gaming and applications to gain momentum. Is DirectX dead? No... a lot of newer ARM devices can natively run DirectX 11 instructions, which means that the overhead of DirectX is really low on those devices. On the x86 platform though, there are legal reasons why DirectX is dead, because it can't evolve any further on the linux x86 platform. Many linux games can be run in GLX or SDL, and the GLX versions often offer better fps with open source drivers than the SDL versions with proprietary drivers. Windows is not an objective platform, Microsoft can do whatever they want to prevent different API's than DirectX to perform well, and they probably will also do that with Mantle, nobody can even check that they're doing it, because their code is closed source, but the reality is that Microsoft is not following up on consumer requirements with their API's, and therefore, they left an opportunity for Mantle. AMD has grabbed this opportunity as soon as SteamOS was rolled out by Valve, and because Microsoft is always very slow to react, I think that the dice has pretty much been rolled on this matter. Will Microsoft update DirectX... yes they will... will it bring much improvement... no it won't, they might even screw it up entirely, or face software bans on multiple continents, before they even get the chance to react. Will Khronos Group do anything? Not at all, except maybe work with Intel and AMD (and Qualcomm, Samsung, Apple, etc...) to improve the existing API's, which is pretty much what they've been doing all along. Will Mantle come to linux... probably not, it's not made for that, but the existing toolkits for linux might be renamed into Mantle for linux for instance, to lower the developer threshold, but it would probably be unwise for AMD to do that right now, because Mantle on Windows isn't even embedded into application development yet.
Does nVidia have a technical alternative that would prevent them from GPL licensing their drivers... no!... they've tried, they actually paid RedHat to find a different solution, based on IOMMU for instance, but they ran into the same GPL problems, and they chose not to release the fruit of that research, but continue as they are doing now, because they mainly still have business from software console gamers, and the next generation of gaming platforms is not there yet, so they're sitting this thing out and continue milking the cash cow until they can't any more, and maybe hope for Microsoft to come up with a new platform that could rival linux in performance, who knows. In the future, they will however have to give in, and GPL license their drivers or make open source linux native drivers, because the x86 desktop platform is not the only platform that is important for game devs, and all other platforms, of which the ARM platform is already outselling the desktop x86 platform completely, are all absolutely dominated by linux, and as things are now, linux is also the only platform that allows for the lowest possible level of hardware targeted programming and the lowest possible driver overhead.