Intel Supports OpenGL ES 3.0 On Linux Before Windows 113
An anonymous reader writes "The Khronos Group has published the first products that are officially conformant to OpenGL ES 3.0. On that list is the Intel Ivy Bridge processors with integrated graphics, which support OpenGL ES 3.0 on open-source Linux Mesa. This is the best timing yet for Intel's open-source team to support a new OpenGL standard — the standard is just six months old whereas it took years for them to support OpenGL ES 2.0. There's also no OpenGL ES 3.0 Intel Windows driver yet that's conformant. Intel also had a faster turn-around time than NVIDIA and AMD with the only other hardware on the list being Qualcomm and PowerVR hardware. OpenGL ES 3.0 works with Intel Ivy Bridge when using the Linux 3.6 kernel and the soon-to-be-out Mesa 9.1."
Phoronix ran a rundown of what OpenGL ES 3.0 brings back in August.
Re:Why? (Score:3, Informative)
The only things that OpenGL provides that ES doesn't are the big, ugly, slow things which are useful for certain kinds of graphic design and industrial apps, but are completely useless for high-performance games. You're really not missing much, and in general if you're using things which are not provided by OpenGL ES to write apps where the real-time user experience counts, you are doing it wrong.
Very very poor article (Score:5, Informative)
On Windows, the GPU is driven by either DirectX or OpenGL. Native OpenGL ES drivers for Windows are ONLY needed for cross-platform development where applications destined for mobile devices are built and tested on Windows first.
Now, this being so, the usual way to offer ES on the desktop is via EMULATION LAYERS that take ES calls and pass them on to the full blown OpenGL driver. So long as full OpenGL is a superset of ES (which is mostly the case), this method works fine.
The situation is different on Linux. Why? Because traditionally, Linux has terrible graphics drivers from AMD, Nvidia AND Intel. Full blown OpenGL contains tons of utterly useless garbage, and supporting this is more than Linux is worth. OpenGL ES is a chance to start over. OpenGL ES 2.0 already is good enough for ports of most AAA games (with a few rendering options turned off). OpenGL ES 3.0 will be an almost perfect alternative to DirectX and full blown OpenGL.
OpenGL ES 2.0/3.0 is getting first class driver support on Linux class systems because of Android and iOS. OpenGL ES 3.0 will be the future standard GPU API for the vast majority of computers manufactured. However, on Windows, there is no reason to expect DirectX and full blown OpenGL to be displaced. As I've said, OpenGL ES apps can easily be ported to systems with decent OpenGL drivers.
Intel is focusing on ES because, frankly, its drivers and GPU hardware have been terrible. It is their ONLY chance to start over and attempt to gain traction in the marketplace. On the Windows desktop, Intel is about to be wiped out by the new class of AMD fusion (CPU and GPU) parts that will power the new consoles. AMD is light-years ahead of Intel with integrated graphics, GPU driver support on Windows, and high speed memory buses with uniform memory addressing for fused CPU+GPU devices.
Inside Intel, senior management have convinced themselves (falsely) that they can compete with ARM in low power mobile devices. This is despite the fact that 'Ivybridge' (their first FinFET device) was a disaster as an ultra low power architecture, and their coming design, Haswell, needs a die size 5-10 times its ARM equivalent. The Intel tax alone ensures that Intel could never win in this market. Worse again is the fact that Intel needs massive margins per CPU to simply keep the company going.
PS Intel's products are so stinky, Apple is about to drop Intel altogether, and Microsoft's new tablet, Surface Pro 2, is going to use an AMD fusion part.
Re:Why? (Score:4, Informative)
I went from OpenGL 1.x over to OpenGL ES, so I don't know most of what modern OpenGL can do. But one glaring weakness is that OpenGL ES doesn't support drawing quads, only triangles. Yeah, the GPU processes a quad as two triangles internally, but if it supports quads, there's less vertex data to generate and pass to the GPU. You can somewhat make up for it by using glDrawArrays, which uses array indexing into the vertex list, but in a lot of cases (especially for 2D scenes), it's still less efficient than if you had quads.
Comment removed (Score:2, Informative)
Re:Why? (Score:4, Informative)
In my experience that will show an artifact. Like an odd line between triangles where there shouldn't be. It's been a while since i've worked in straight gl but you should reuse the vert to prevent that. Even if the verts are in the exact same position, it won't matter.
Re:Why? (Score:2, Informative)
Depends on the rendering method.
In one comment you manage to demonstrate that you've never worked on an SGI machine, before.