DirectX & OpenGL are going to follow the Mantle example

You read that right: Microsoft, AMD, Intel, NVIDIA are going to work on opening low-level access to hardware through OpenGL and DirectX, something that was lacking from these APIs and that AMD's Mantle sought to fix, albeit with a terribad launch (I'm looking at you, Battlefield 4).

Here's the article from Guru3D.

What kind of "low level" access would be possible with Mantle that is not already possible with OpenGL?

These are just API's, tool kits to integrate GPU instructions into programs.

IF developers would start to use Khronos spec tools instead of DirectX again, as they did before DirectX came about, and as they always did in linux, that would not solve the driver bottleneck, because the drivers would still be in userspace, and often need a state tracker to translate the native instructions to the graphics hardware. For AMD and Intel, that will be less of a problem in the near future because they've decided to open source their hardware code (the assembler code that drives the hardware) just enough to allow for the development of KMS drivers, but for nVidia, that categorically refuses to open source their PTX assembler code, it would still mean that there would be crucial compiler overhead, because obviously they wouldn't be able to compile their proprietary PTX instructions into the linux kernel with the GCC, which would only be a solution on OSX, as it is compiled with LLVM/Clang, which allows for proprietary plugins. The Windows kernel isn't even capable of native KMS drivers, all drivers are always in userspace, and DirectX is not equipped to work with kernel drivers, so the driver overhead will just stick, and there is no real low level capability.

So great that they want to do something, but what could Intel, AMD and nVidia really do, they don't have control over GCC, which is owned by Richard Stallmann's FSF, and GCC is still the prevalent compiler for everything that really works as it should, and OpenGL is owned by the Khronos Foundation. Unless they go open source, there is no way they're going to have real low level integration of their GPU hardware. That's exactly why AMD and Intel are developing open source drivers like crazy, that's exactly why nVidia has open sourced their Tesla drivers last week, because nobody was buying their crap in the enterprise marked any more, because having no open source drivers these days, is the same as having no drivers at all, it's the same as bringing a Windows-only hardware product to market, which is pretty stupid for an enterprise product.

Mantle is nothing but an API that uses the Khronos spec instructions directly, it's nothing but window dressing OpenGL, OpenCL and OpenMP in such a way that it's easier for game devs to work with. It adds nothing to OpenGL, OpenCL or OpenMP, and it's still plagued by the fact that the KMS-drivers are not good enough yet to kill the userspace driver overhead, which is why Mantle only has a limited effect. Once the AMD open source drivers are at the same development level as the fglrx drivers, programs that are developed using the Mantle API, will be able to squeeze much more performance out of linux-based machines that use the most modern kernels that have all the trimmings. In reality, as SteamOS is based on Debian Stable, which is about 2 years behind on kernel evolution, that means that if it takes another 6 months to get the open source AMD and Intel drivers sorted (and nVidia hasn't even started developing open source drivers, they're still fighting against open source drivers), the first benefit of Mantle in games would be visible for bleeding edge linux users at the end of this year, and for SteamOS/Ubuntu/Debian/Mint/etc... users at the end of 2016, while there will never be any real benefit on Windows because the driver overhead can never be fully eliminated, and the only platform that would benefit immediately would be Apple OSX, which is the platform that is most despised by gamers.... so that picture is not that appealing for game devs at all in my opinion...

There is only one solution for the driver overhead: open source everything, merge it, use Khronos spec tools with or without window dressing with Mantle or similar tool kits, and drop proprietary assembler crap. To unlock the complete performance, it's not just limited to OpenGL, it's also a matter of integrating OpenCL and OpenMP, which is what AMD's linux version of the development tools do, of which a small part has been ported into the Windows-specific Mantle tool. nVidia cards aren't even natively compatible with OpenCL and OpenMP, they do have the proprietary CUDA and OpenACC (which is not open at all, the name is just a lie and it's not an official Khronos spec API), which have less instructions, and only compile without overhead on Apple OSX or custom tainted linux kernels that are compiled with LLVM/Clang with proprietary plug-ins, but the performance of that compiler is not at the same level of GCC, so there is compiler overhead that will limit system performance.

They can say whatever they want, everybody knows that there is only one solution to unlock all of the performance of the hardware that is sold, and that is to kill the concept of proprietary drivers and assemblers, put all energy into optimizing open source drivers, and merge it into the linux kernel, then use that linux kernel for a GNU/Linux distro that would run the games. Everybody also knows that hell will freeze over before that will happen in nVidia's case, unless people actually stop buying their products, like what happened in the enterprise world. With all the pro-nVidia marketing towards consumers and gamers, chances of the same thing happening in the consumer market, are really slim, especially since nVidia - by refusing to evolve - supports the proprietary system ideas of Microsoft's software console solutions for consumers and ignorant businesses, and if there is one single benefit to DirectX, it's that it costs less for game developers to use it, because they don't have to worry about low level instructions and Khronos specifications, they can just let the DirectX API do all the work, so they want to continue to develop games for Windows and not for anything else, because that's just cheaper and they don't need to even hire people that really know what they're doing.

this, my friends, is the definition of bullshit

I'm sorry but there is soooo much difference between mantle and the rest of API, google is plenty of articles of this. 

I'm sorry, but the only thing that's right with Zoltan's post is that Mantle is indeed not needed at all.

If you didn't use OpenGL just shut up. I'm sick of, muuh gamurs, talking about this without ever having touched graphics code.

You can't just come on, say someone else's post is bullshit, tell them to shut up, and then not explain why, or give your own reasoning or discussion. 

You're being rude. If you have a problem with what zoltan is saying, then prove him wrong.

You can't just come on, say someone else's post is bullshit

I can and I did. If someone writes so much bullshit that it would take you so much time to show that everything IS bullshit that you could actually do something useful why should you do?

If you have a problem with what zoltan is saying, then prove him wrong.

Prove that it's true. That's how everything works.

Oh, right, you can't because it's bullshit.

Well so far you have contributed nothing to the post, so we can all see what kind of poster you are going to be in the future.

Look at his name, it's probably just some Microsoft dude that gets payed just to go to tech forums and call BS on things that favor Linux and not MS Windows.

Saying something wrong and proclaiming that it's the truth is way worse than doing nothing.

Did you notice that he never backs up ANYTHING that he says? His justification is that others should do the research. That's completely insane. If you say something you are responsible for backing it up, for proofing it, otherwise it's worthless junk.

I didn't even know that this thread is about operating systems! I must have missed something!!11

Satya, you need to relax first after a frustrating day at work before you post comments, really.

Feel free to comment on the abstractions and imprecisions that you can explain better.

Months ago, I've posted the entire Mantle and other AMD API arsenal with links on the forum already, you could have at least looked through the forum.

Now chew on this for a second: you are being abrasive in almost every one of your posts, not against companies that do devious stuff to make a point, but against forum members directly. You really need to change your attitude, because your interventions make threads derail, they make them veer off the subject.

As I said, share your superior knowledge with the forum, do something useful, you undoubtedly can say things better than me, I'm not a computer specialist, and I'm not a gamer, just talk about the subject, for instance, with your deep and all encompassing knowledge of graphics drivers and graphics tool kits in all operating systems, explain what nVidia for instance will do to provide low level graphics access to game developers without any driver overhead. Now that would be useful!

I made a reply, but deleted it, because this.

 

(Also, Zoltan, I sent you an email. I don't know if you used a throw away email for your account or anything, so I thought I would notify you of it.)

Months ago, I've posted the entire Mantle and other AMD API arsenal with links on the forum already, you could have at least looked through the forum.

That's exactly what I'm talking about! You simply say that everything has already been said and that everyone should just search for the proofs for themselves. That's so stupid that I don't know what else to say.

If you say something, proof it. It doesn't matter if you already proofed it for you granny or some random dude on the street, it matter for those who read this damn thread.

explain what nVidia for instance will do to provide low level graphics access to game developers without any driver overhead. Now that would be useful!

Exactly the same as AMD and Intel: they simply allow it. Why do you even assume that there will be driver overhead by granting more generalized access on buffers? You even reduce it because you transfer more data in one app-driver interaction instead of doing multiple smaller, specific transfers.

http://www.g-truc.net/doc/OpenGL%204.4%20review.pdf

http://de.slideshare.net/CassEveritt/beyond-porting

Yup, I saw it, I'm still working for another 3/4 of an hour or so, I'll respond to it with full focus afterwards. I didn't have that when I did the install, even before I reflashed coreboot, but I'll take a C720 and quickly throw Arch on it to see what it does.

erm.... we're not talking driver overhead per se... we're talking about the overhead from DirectX and openGL. mantle is not only for the GPU, but it also allows easier multithreading.

Hu? That's exactly what I'm talking about. You simply avoid the client side driver part from stalling and have (virtually) no overhead. To avoid stalling, you allow more general access on buffers and let the user handle the details and therefor don't need any state from the "server thread" which means no synchronization and no stalling.

How exactly can you multithread any graphics API? Everything has to be synced and serialized before sending it over to the GPU anyway.

Mantle allows more CPU utilization, up to (and beyond) 8 cores. It isnt JUST a GPU implementation. 

If you have virtually no overhead from an API call, it doesn't matter how many threads you have.

And I didn't talk about the GPU AT ALL.

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.