Reply With QuoteAlso add the complex licensing behind video processing. DRM requires some component never to be allowed to be openly revealed. And saddly, on some engines (AMD's UVD) they are too much interlinked and indissociable with the parts useful for the community (the video codec hardware decompression). At least AMD has promised to address this in the future and make future UVD more open-source friendly.Originally Posted by AJSB
The problem is that software patents aren't the only obstacle. you also have problems regarding DRM (not only DMCA, but the consortium controlling a given scheme can decide to revoke the key present in AMD hardware if they are un happy), and plain simple copyright (Nvidia could decide to opensource code that they own - basically: that they wrote themselves. They have no control over code that they don't own - basically: code that they bought from 3rd parties).
You'll need to abolish not only software patents, but also DCMA, copyright on software, and outlaw the activities of organisation like those handing the keys for HDCP encryption.
I'm all for it, but its a much more difficult task than what even you suggested before.
AMD *do* document their hardware. It's only slow, because any release (documentation or code) has to trickle through their legal department to make sure none of the opponent i cited before feels violated. But their are doing it. And promising (and actually showing signs or) stream-lining the whole process, and integrating the taking of account of FOSS in their hardware development life cycle. Just remember that H/W is a very long process. As we are talking right now, somewhere in their R&D department, the first steps of hardware 2 generations away from now are already beginning. That means, we still have to wait a few generation between an announcement (we're going to play nicely with open-source) and actual hardware designed under this policy hitting the shelves.
I think the current generation of Radeon is the first whose entire design dates after the beginning of AMD's opensource policy right after their acquisition of ATI. Now factor in that they have to get used to the process, fix the problems, iron-out the bump... it's getting to take quite a lot of time before they are a fully open-source supporting house like Intel. (As an indication, look at all the time it took google to transition to an FOSS model of development with Android and integrate their mods into main-line kernel, *even* if they've been pro open-source from the begining, and *even* if it's software only with way much more shorter cycles than hardware).
Nvidia indeed *does not* document their desktop hardware. But regarding to Tegra and their mobile hardware, they are warming up to the idea of opening and documenting their stuff (probably because Linux *is* a very strong player in the embed world). But then again (specially taking into account the transition of AMD mentioned above) it's going to take quite some time until their opensource offering rivals what AMD (or even Intel) are doing.
OpenGL ES 2.x = subset of OpenGL 3.x
Current OpenGL ES 3.x = subset of the current OpenGL 4.x
(That's why Mesa can claim Open GL ES 3.x support sooner than OpenGL 4.x. : less things to support).
Now you have to look closely:
- what OpenGL ES and OpenGL have in common is all basic graphic functionality needed to draw things on a screen. (Triangles, shaders, etc.)
- what OpenGL has in addition is a lot of complex arcane stuff which currently is only used on high end workstation running CAD software. Things that don't actually make sense for any everyday use of graphic hardware (desktop compositing, gaming, etc) but only make sense for this specific hardware.
- also OpenGL ES keeps a lot of old almost 'deprecated' functionality because of backward compatibility to please the CAD-on-workstation crowd. For example you'll find a lot of API for fixed pippeline handling, even if most of the modern hardware use programmable shaders. OpenGL ES tries to throw away some of this (almost unused) legacy cruft.
So:
- Open GL = every single API call dating all the way back from when it was a library running on expensive SGI workstations.
- Open GL ES = only what modern hardware does and what modern applications needs.
Believe it or not, under the hood, there's a lot more in common between what latest generation embed hardware is doing and your desktop, than there is between an old dusty Silicon Graphics machine and your desktop.
So the hype is that it is a thiner and lighter layer that does exactly what Open GL is currently used for on desktops, making it easier to develop for and making it easier to add support into FOSS drivers.
The functionnality we're throwing away between OpenGL ES 3.x and OpenGL 4.x mostly isn't that much relevant to us.
*BUT* this functionnality is relevant to a very specific crowd, which happens to be the most profitable market segment for hardware makres (the CAD-on-workstation crowd) so you can expect that vendors will continue to cater to them and produce OpenGL in addition to OpenGL ES support.
Just don't expect regular dekstop application to use much of OpenGL beyond what's available in OpenGL ES. Maybe expect for a few specific stuff. Which never the less can be incorporated into OpenGL ES as specific official extension. (Which aren't supported on some mobile devices).
