In order to address some of the sources of CPU overhead and provide developers with more explicit control over rendering, w’ve been working to bring a new 3D rendering API, Vulkan, to Android. Like OpenGL ES, Vulkan is an open standard for 3D graphics and rendering maintained by Khronos. Vulkan is being designed from the ground up to minimize CPU overhead in the driver, and allow your application to control GPU operation more directly. Vulkan also enables better parallelization by allowing multiple threads to perform work such as command buffer construction at once.
OpenGL updates to Android are delivered via Google Play Services, right?
I take it that this will be the case?
I guess openGL updates are part of the Android core and therefor it is up to each manufacturer to deliver an updated version of Android?
But i might be completely wrong here.
Would be nice if the updates (for such functionality) were delivered via Google Play.
Dunno how similar it is to Linux on desktops, but there i think you have to keep the GPU driver and the main OpenGL lib (Mesa) somewhat in sync.
Sadly Google don’t seem interested in segmenting Android much beyond firmware (AOSP et all) and APKs.
Since AMD/ATI have made something similar, would Vulkan be close enough to maintain a kind of compatibility ?
Vulkan is descending from Mantle. If you didn’t follow, AMD gave Mantle spec to Khronos group (for free) to kickstart the Vulkan project. Otherwise it would have taken a much longer time to create. That’s a really great thing they did.
I.e. Mantle is gone, it’s Vulkan now.
Edited 2015-08-10 19:24 UTC
Nope, I not really followed that path. Good to know. BTW my main laptop is a A8-3500M
AMD seems to be doing everything right these days, yet Intel is what gets all the Open Source love…
I do love AMD/ATI’s spirit and products. I’m into low energy, parallel processing, nice architecture. They do it right, sure. But not really efficiently. Raw power and power consumption always lags behind. Perhaps because Intel have their own foundries, AMD had their at one point in time too, but hardly managed to shrink their etching scale enough to compete with Intel’s. It’s kind of sad AMD mostly disappeared from the high end hardware.
Still have AMD in my heart and be reminded everybody: x64/x86-64 is actually AMD64. For a short time, AMD was far ahead in the game.
AMD made a stalled intel get their act together. It shows how important competition really is.
Edited 2015-08-11 11:17 UTC
AMD was far ahead of Intel with the Athlon series (the Alpha RISC cpu architect constructed Athlon) but not many PC vendors bought Athlon. Why? Because Intel threatened and bribed PC vendors.
For this, Intel had to pay AMD a great fee of $1.4 billion several years later. But the damage was done. Intel kept AMD at low sales and AMD could never gain market share so AMD never got momentum enough to continue research to beat Intel
So, it was a very good move for Intel: threaten and bribe PC vendors to not buy AMD, and years later, pay a fee of $1.4 billion – but meanwhile Intel earned much more than the fee during all these years. It payed off. And now AMD is tiny.
http://www.theverge.com/2014/6/12/5803442/intel-nearly-1-and-a-half…
Even today, if AMD Zen cpu which looks to be a monster (4 teraflop, 100 GB/sec which is seven times faster than PCIe, etc etc), was much better than Intel’s cpus – what would happen? No one would buy Zen, because Intel would threaten and bribe and years later Intel will happily pay $1 billion or so, strangling AMD and Zen during the years until the law suite is settled.
http://www.fudzilla.com/news/processors/38402-amd-s-coherent-data-f…
The new AMD Zen monster cpu:
http://www.fudzilla.com/news/processors/38402-amd-s-coherent-data-f…
And mean while, Intel SGX functionality in Skylake allows encrypted code to be run in a secret area that the OS can not even see. This is probably the work of NSA, so NSA can monitor all Skylake cpus. Google Skylake SGX for more information.
You also had the shenanigans where Intels compiler produced x86 binaries that violated the very standard they had hammered out with AMD and VIA to allow a binary to make full use of the extensions a CPU offered independently of brand.
If said resulting binary didn’t find a “Intel” string in what was supposed to be a purely descriptive location, it would run a branch that basically assumed the CPU was a 386.
Intel open-source GPU drivers are still far ahead AMD open-source GPU drivers. In fact, AMD still maintains a proprietary GPU driver that is leaps ahead the open-source driver in terms of 3D performance.
If you want to refrain from the proprietary AMD driver because of principles, security concerns or just because it causes many troubles, your dedicated AMD GPU may become worthless compared to intel integrated graphics solutions.
So as you can see, in terms of earning open-source love, AMD still has some homework to do.
Once upon a time, at 2007, i did felt that AMD was really going full throttle to support the open source effort. I even bought a Radeon card back then. Currently, i just advice all my friends to go either with NVidia or Intel on Linux.
Now, i do believe that AMD open-source linux strategy was just a clever way to severely reduce Linux support without the marketing backslash from doing so. Now AMD can claim that it did provided some GPU docs to open source community, and if they cannot fend for themselves is their problem, while keeping just a skeleton crew to keep fglrx minimally afloat (just in case), and occasionally help the open source effort.
Fglrx is still a shame, and the open source ones are virtually useless with mid to high-end gpus (the low end ones do make a really nice GPU for HTPC although, they are really stable and boost support for all features that you need for this). Using Steam on Linux with a AMD card for anything but simple or really old games is just a waste of money and a headache.
Intel has the benefit of starting from scratch, and so having full control of the IP etc.
AMD bought ATI back in the day, and who knows how many bugbears are hiding in the wings regarding some sub-contracted functionality or other.
Most prominent message across the board: AMD Ends Mantle API 1.0 – Raja Koduri Advises Devs To Focus on Latest DirectX and Vulkan (OpenGL)
Some articles for you to get up to date with the matter:
http://wccftech.com/amd-ends-revolutionary-mantle-api-10-asks-devs-…
http://www.redgamingtech.com/amd-halts-development-on-mantle-focuse…
http://www.pcworld.com/article/2894036/mantle-is-a-vulkan-amds-dead…
http://www.extremetech.com/extreme/200286-not-dead-yet-amds-mantle-…
Do you know if Vulcan can be a base for more open source drivers? They say it will slimm down the driver blob.
Vulcan could be also paired with a GPU metrics spec for a real Open Source experience (e.g. GPU temperature etc)