Slashdot Mirror
Intel Supports OpenGL ES 3.0 On Linux Before Windows
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.
OpenGL ES is a cut-down version of OpenGL aimed at mobile and embedded. Windows has never supported any version of it, and probably won't anytime soon.
So to see Linux get it "first" is completely unsurprising.
It's like saying Linux supported the EXT3 filesystem before Windows. So?
Beating out nVidia and AMD is marginally surprising, but OpenGL ES support in Windows I'd figure to be the lowest priority 3D interface to implement for Windows, behind Direct3D and OpenGL. MS' attempt at targeting the lower end market is still emphasizing Direct3D, with OpenGL on Windows mostly only mattering for the occasional game engine and engineering application. OpenGL ES on Windows I'm thinking is a very very small slice of potentially interested parties.
XML is like violence. If it doesn't solve the problem, use more.
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.
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.
No this is about OpenGL ES which is basically irrelevant on desktop Windows.
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.
You use OpenGL ES on desktop Windows for what exactly?
On the other hand, if you're not the one writing the apps, it can be infuriating to use a system that supports only OpenGL ES. Last time I tried to use Ubuntu on a system with only OpenGL ES support, I discovered that OpenGL ES basically meant "no graphics acceleration", because nothing in the repository supported it; everything wanted OpenGL.
That's probably changed since then (it was a few years ago), but it was pretty frustrating at the time, especially since the GPU itself was rated for full OpenGL, it was only that PowerVR charged extra for that driver and TI didn't want to license it.
OpenGL, unlike DirectX pre 11, doesn't lock your structures to a thread. Any thread from the same process can access OpenGL data and therefore supports multithreading.
DX forbid multithreading until 11. OpenGL never did.
Execpt that OpenGL ES has zero relevance on desktop Windows. No one uses it. Kinda blows your whole theory out of the water.
Not true. Full blown OpenGL supports geometry and tesselation shaders for example and loosens up various restrictions or limitations of ES. e.g. draw quads instead of screwing around triangulating everything. And while the fixed function pipeline is deprecated, it's still useful to just knock out something and far simpler rather than screwing around trying to compile, link and use a shader which does a matrix transformation and little else.
Just curious, how would quads be more efficient than say, triangle strips for drawing quads?
I use it on the desktop for Android development because it's a pain in the arse to develop OpenGL ES at the best of times. Development turnaround is a lot faster than uploading to a device and discovering the shader is broken because of a syntax error.
Portability. You could write a game engine that would run pretty much everywhere.
You use a wrapper not ES directly.
I was asking for what they specifically used it for. Not what someone could theoretically do. Also, ES is only supported through translation wrappers or emulators on Windows anyway.
Or one could just use the EGL or WGL wrappers for AMD or NVIDIA GPUs respectively. Wouldn't make this submission's title any less stupid.
He explained it in the comment: "there's less vertex data to generate and pass to the GPU"
Unlike porn, which yada yada rimshot hey-ooh!
There will be a windows driver soon, I assume. I also assume NVIDIA and AMD will provide drivers for windows. Asking what specifically you would use OpenGL ES 3.0 on windows for is like asking specifically what you would use OpenGL on windows for. It's for portable 3D graphics. OpenGL ES 3.0 looks like it will be the most portable version yet.
Triangle strips require everything in one draw call to be connected. If you want to draw N quads, you have to make N draw calls, passing 4 vertices each time. There's a significant amount of overhead involved in a draw calls, so this is slow. With quad support, to draw N quads you can just make a big array of 4N vertices and process it all in one draw call.
He explained it in the comment: "there's less vertex data to generate and pass to the GPU"
This is false. If you're drawing a quad, you pass 4 vertices. If you draw 2 triangles forming a quad, you also pass 4 vertices (using a triangle strip and index buffer). The index buffer is not updated every frame, just once.
I'm calling ES directly through JOGL bindings and the GLES2 profile. I don't care if the driver is doing it over OpenGL, DirectX or directly. As far as I'm concerned it's ES and that's the primary thing for me. Makes it vastly easier to develop code, sparing any actual android work until things are beginning to take shape.
no you draw 6 vertices. the triangles are independently rendered.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Here's a trick you can do to draw all your 2-triangle-quads in one draw call; pass 4 identical vertices for each quad, and 4 other attributes representing each corner of the quad. (-1, -1), (1, -1), etc. Then displace the vertex according to the corner attribute in the vertex shader. There's more data to pass, but I assume you're not passing the data every frame. If that's the case, don't. If you're moving the quads, just pass the position.
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.
Yet despite their allegedly superior technology, last year was an unmitigated disaster, a steady decline from Q1 to Q4 losing over 30% in revenue and where in Q4 2011 they had a gross margin of 46%, in Q4 2012 it was down to 15%. They're cutting in R&D, in 2011 they spent 1453 million, in 2012 1354 million and if they spend the whole of 2013 at Q4 2012 levels then 1252 million. Yes, hopefully the PS4/Xbox 720 will give AMD a much needed cash infusion but their technology is not at all selling so maybe they should stop bleeding market share first before "wiping out" anything. Also, AMD just recently posted a new graphics roadmap for 2013, I'll give you the summary: No new desktop graphics cards until Q4 at the earliest.
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.
While Intel may have a tough time battling ARM on the low power front, AMD is totally lost. All their x86 CPUs burn more power than an equivalent Intel and they're dividing their resources between ARM and x86, try pitting a 18W Brazos 2.0 against a 17W i7 ULV. They're totally not in the same price class, but they are in the same wattage range. Intel will milk the market of high end desktop/workstation/server chips that AMD has pretty much abandoned and use that as its war chest against ARM, if they'll win is another matter but they got billions and billions to spend on that, right now based on market cap Intel could buy AMD for about 2% of their stock. Not that Intel would want to since they'd become a true monopolist in x86 space, but in the all-out battle with ARM they might end up a casualty caught in the crossfire.
Live today, because you never know what tomorrow brings
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.
http://soylentnews.org/~tibman
no you draw 6 vertices.
You don't draw vertices at all, and if you're using triangle strips you only need 4 vertices to create a quad out of 2 triangles.
The index buffer is not updated every frame, just once.
That's not always true. Sometimes it's more efficient to just stick the vertex data directly into the vertex buffer as your frame is generated, then do your draw order sorting at the end by rewriting the index buffer.
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.
Like geometry shaders?
And it's basically irrelevent on x86/x64 linux too. Afaict when software supports ES it generally has a compile time switch between regular opengl and opengl ES. Pretty much all GPUs seen in x86 systems support regular opengl while only a subset of them support ES so the sane thing for a distro to do is to use regular opengl for the x86/x64 builds of their software and only build for ES on architectures where ES only GPUs are common.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You can do things like augmented reality on a smartphone. Use the built-in camera to take a live video stream of a particular location, the MEMS gyroscope and tilt sensors to determine the orientation of the system and GPS to determine the latitude and longitude. Combine this information together and render 3D information on top of this view. Maybe it's a terrain map, geological layers, the direction to the nearest public bar, train station, police station or A&E.
http://www.youtube.com/watch?v=gWrDaYP5w58
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Uhhh...isn't that running in a VM anyway? by that logic one could say windows supports EXT since a VM of Linux runs EXT.
ACs don't waste your time replying, your posts are never seen by me.
The Android SDK VM is slow enough at the best of times and the OpenGL software emulation is abysmally slow. It's real devices or the test harness, not the VM.
Depends on the rendering method.
In one comment you manage to demonstrate that you've never worked on an SGI machine, before.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
On modern embedded systems the Linux kernel is the same. In the old days, or in cases where Linux is used on processors without VMM support, the kernel might be substantially different. Today most embedded systems use an x86 or ARM architecture. They don't use a "stripped down" kernel. They use the same kernel, and configure at build time to use the features they want. The same is true on the desktop. The only difference that you may be mistakenly referring to as "stripped down" is that for an embedded system you only build and include the drivers for the hardware you will run on, since you know that in advance. On a Desktop distributions kernel they build and include many more modules since they will be loaded and used on some hardware and not on other hardware. Thye details go on from there, but suffice it to say that you don't grasp any of them, and to be certain an embedded system using an NVIDIA, AMD, or Intel chipset will use the same driver as a desktop system.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
What SGI machine supports modern OpenGL with vertex shaders but no vertex caching? If you don't need vertex shaders, then you don't need to do things the newer way with later versions of OpenGL anyway. The drivers will just translate everything you do.
And SGI machines have split quads up into triangles for a long time now. It is faster than trying to check for coplanarity or better than dealing with artifacts that some pure quad rendering methods produce if the points are not coplanar (or even some depth related problems that can come up). So even they bailed on doing things that way some time ago, before shaders and OpenGL 2.0 was even reached.
There are reasons that went from being part of how the renderer worked, to a convenience for the application writer, to ultimately a method that should be avoided. I do remember IrisGL, and while innovative for the time in some ways, things have moved on a lot since then.