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.

Comments

ES is the key word.

[Anonymous Coward]

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?

Re:ES is the key word.

[Zero__Kelvin]

I was unaware that there is no Windows for portable or embedded devices. Microsoft would start working on a mobile phone OS!

Re:ES is the key word.

[Desler]

It uses Direct3d. Also the story was referring to desktop Windows.

Re:ES is the key word.

[hairyfeet]

That would be like asking why the software that runs on an airplane doesn't run on your cellphone. Windows Embedded, just like Linux embedded, runs a stripped down kernel and a MUCH thinner OS because when you are dealing with an embedded system you just aren't gonna be doing as much as a full OS, as they are designed for specific functions.

Re:ES is the key word.

[Anonymous Coward]

Depends on what you're defining as "cut down"...

ES 1.1 is intrinsically the fixed function pipeline from OpenGL 1.4 and before, sans the immediate mode calls (something that's been deprecated FOREVER...).
ES 2.X is intrinsically the shader driven pipeline from OpenGL 2.x and after, sans the fixed function path and the immediate mode calls.

If you're doing OpenGL like you're really supposed to be using it, it's amazingly easy to get your code to work properly on an ES implementation- and there's fixed-function wrappers for ES 2.X so you can mix and match pretty easily.

Re:ES is the key word.

[Anonymous Coward]

Except that ES 2.0 (2.X? 2.0 was directly followed by 3.0) supports very few features, even compared to various desktop GL 2.x implementations. Want to render to a depth buffer (for shadow mapping)? That's not supported by the core spec, you need an extension. Want multiple render targets in your FBO? Same thing. Even the GLSL is limited - officially, the fragment shader only supports loops with a compile-time fixed iteration count (some implementations relax this slightly, though). Not to mention that the GLSL in ES 2.0 is pretty much an ancient dialect, not really comparable to modern GLSL.

(All of this is not really surprising, considering that ES 2.0 itself is pretty old at this point.)

And if you're doing OpenGL 4.x style, you'll notice that 4.x has deprecated rendering from VBOs without going through a VAO.

So, yeah, ES 3.0 is starting to resemble a modern desktop OpenGL. Just too bad it's not supported by any device you'd want to run it on. Hint: the Intel HD 4000 that's mentioned here *already* supports desktop OpenGL 4.0 (windows), 3.2 (mac os) and 3.1 (linux). So, technically you can already get a "better" GL from the same hardware.

Re:ES is the key word.

[Anonymous Coward]

Direct3D has feature levels that cover embedded: One API, expanding function base that can be queried in real-time. Embedded GPUs sit around DX level 9.4, with some on the newest ones achieving DX 11.

Re:ES is the key word.

[ikaruga]

Also windows mobile and RT only use ARM(AFAIK), while there are a few Intel Android phones and it's expected to see Ubuntu phones using both architectures as well. Linux actually has a need for new OpenGL ES version support.

Re:ES is the key word.

[Anonymous Coward]

Deja vu?

Re:ES is the key word.

[drinkypoo]

Windows Embedded, just like Linux Embedded, permits you to select how much of the operating system you want to include.

Before Windows Embedded, there was Windows CE, the less said about which the better.

Why?

[Anonymous Coward]

What's the point of having OpenGL ES when you can run full OpenGL on the desktop?

Re:Why?

[Anonymous Coward]

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.

Re:Why?

[edwdig]

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.

Re:Why?

[Anonymous Coward]

You mean such things like pixel buffers without which it's impossible to have fast texture upload?
Of course you can do it the "GL ES way", by not using GL ES features by some vendor specific, crappy EGL hacks to do it.

Re:Why?

[Guspaz]

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.

Re:Why?

[DrXym]

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.

Re:Why?

[foijord]

Just curious, how would quads be more efficient than say, triangle strips for drawing quads?

Re:Why?

[k3vlar]

He explained it in the comment: "there's less vertex data to generate and pass to the GPU"

Re:Why?

[edwdig]

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.

Re:Why?

[foijord]

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.

Re:Why?

[Khyber]

no you draw 6 vertices. the triangles are independently rendered.

Re:Why?

[foijord]

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.

Re:Why?

[tibman]

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?

[exomondo]

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.

Re:Why?

[edwdig]

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.

Re:Why?

[exomondo]

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?

Re:Why?

[Anonymous Coward]

In such a short comment you essentially show you neither know how quads or triangle strips are rendered.

Re:Why?

[mikael]

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

Re:Why?

[Anonymous Coward]

You can use triangle strips to make one call too via degenerate triangles which get thrown out by the video card anyway, so don't represent more work. So the triangle strips can be used for disjoint quads, with the same 4N vertex data. The only added thing needed would be the index array. Depending on what you are doing, and if you are using a vertex shader well, you could come out using a lot less data for the same quads. In the not too distant future for OpenGL ES, or on full OpenGL now, you can do better than all of that with just a geometry shader anyways.

Re:Why?

[Anonymous Coward]

Uh... If it's internally processing the things, the GPU pipeline actually takes more of a hit than your having to decompose the quads into two tri's and push the two tri's instead- there's a REASON that they quit supporting that construct. You're bitching because you want to be lazy and not think through your polygon specifications to the pipeline. Not to mention that you can still specify quads if you're specifying a tesselation shader...

Re:Why?

[Anonymous Coward]

Or render-to-depth-texture for shadow mapping in ES 2.0. Fortunately that was added in ES3.0.

Re:Why?

[Anonymous Coward]

OpenGL 4 manual pages (297 functions):
http://www.opengl.org/sdk/docs/man4/
OpenGL ES 2 manual pages (109 functions):
http://www.khronos.org/opengles/sdk/docs/man/

Apart from the number of functions:
* Many OpenGL ES functions support fewer options than the equivalent OpenGL functions (e.g. the ES version of glTexImage2D supports 5 formats, the real version supports 81 formats)
* There are another 124 OpenGL 1.x functions which are deprecated but still available in the compatibility profile; those aren't listed in the OpenGL 4 manual pages.
* The ES version of the shading language is similarly "cut down" down compared to that in desktop OpenGL.
* ES has much lower minimum implementation limits (OpenGL 3 and later require support for 1024x1024 textures; OpenGL ES only requires 64x64).

Re:Why?

[Anonymous Coward]

What does any of that have to do with the DESKTOP?

Re:Why?

[Khyber]

Depends on the rendering method.

In one comment you manage to demonstrate that you've never worked on an SGI machine, before.

Re:Why?

[Anonymous Coward]

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.

Re:Why?

[Anonymous Coward]

OpenGL ES 3 has 180 functions, and glTexImage2D supports 13 formats and 16 types. OpenGL 4's glTexImage2D supports only 5 formats and 19 types.

And while there is a difference of just over a hundred functions, many of them are not there because of cleaned up interfaces. Instead of having both a function to do something once and one to act on a list, they just keep the one that acts on the list, not limiting what you can do (unless you have a phobia of adding a second parameter value of one to reproduce what the singular function would have done). The shader program interface is a lot cleaned up. Seven of the missing functions are just to deal with 1D textures, similar effects can be done with shaders anyway, and the functions are essentially redundant.

Oh, and OpenGL ES 3.0 has a minimum required supported texture size of 2048x2048.

Yes, there are things that OpenGL 4.x does that OpenGL ES doesn't do. But that gap gets a lot smaller when you look at ES 3.0, and the gap includes a lot of cruft besides the couple of useful things that are dropped.

Not too suprising...

[Junta]

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.

Re:Not too suprising...

[UnknowingFool]

Well depends on what the average consumer needs from their PC. If it is not gaming (which a consumer would buy a discrete card anyway), most consumers need some graphics for web surfing and the like. With the built-in graphics of Ivy Bridge, there is enough GPU power for the average consumer. Why would this average consumer need Direct3D for YouTube?

Re:Not too suprising...

[fuzzyfuzzyfungus]

Well depends on what the average consumer needs from their PC. If it is not gaming (which a consumer would buy a discrete card anyway), most consumers need some graphics for web surfing and the like. With the built-in graphics of Ivy Bridge, there is enough GPU power for the average consumer. Why would this average consumer need Direct3D for YouTube?

To say that they 'need' it would be a gross overstatement; but if they are doing their casual youtubing on a relatively recent wintel, they'll be using it anyway...

Re:Not too suprising...

[Desler]

They wouldn't be using OpenGL ES. This submission is nothing but fanboy wankery.

Re:Not too suprising...

[Hal_Porter]

Why would this average consumer need Direct3D for YouTube?

Most consumers need DXVA - i.e. DirectX Video Acceleration. On a netbook DXVA would mean that you could play Youtube videos with low CPU usage. That's particularly important on a netbook.

On my 1015PX - which is the second netbook I've bought so Intel have had two chances to get it right - it still doesn't work.

http://www.notebookcheck.net/Intel-Graphics-Media-Accelerator-3150.23264.0.html

According to Intel, the GMA 3150 can help the CPU decode MPEG2 videos. The DXVAChecker shows hooks for MPEG2 (VLD, MoComp, A, and C) up to 1920x1080. Therefore, the performance of the N450 and N470 with GMA 3150 is currently not sufficient to watch H.264 encoded HD videos with a higher resolution than 720p. HD flash videos (e.g. from youtube) are also not running fluently on the Atom CPUs.

It supports MPEG2. I don't think I've ever played an MPEG2 video on this machine and it could probably decode them fine in software anyway. It doesn't support H.264, which is absolutely ubiquitous and used by Youtube. An Atom N570 can decode H.264 in software but only with some effort (high CPU usage,fans at high speed, high power usage) at high resolutions.

On my i5 based notebook which is powerful enough to decode HD H.264 in software without breaking sweat H.264 is decoded by the GPU.

I think the problem is that Intel already has most of the netbook chipset market already. So getting HD youtube videos to work would just cannibalize the market for higher end i5/i7 machines. Still it seems odd that they revved the chipset and didn't fix the most obvious limitation.

Snore

[Anonymous Coward]

And zero people beyond Linux fanbois actually care.

Who cares?

[Desler]

And zero fucks were actually given.

Re:Who cares?

[Anonymous Coward]

Those of us who actually use OpenGL ES care. This is because with each advancement we can implement more and more cool stuff into the hardware you want it in. Of course if you don't like playing games, using smart phones, or using modern GUI's then advances in graphics technology specifications don't really matter. You can go hide in your cave and pretend like anything not on the x-box doesn't matter now.

Re:Who cares?

[Desler]

You use OpenGL ES on desktop Windows for what exactly?

Re:Who cares?

[DrXym]

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.

Re:Who cares?

[foijord]

Portability. You could write a game engine that would run pretty much everywhere.

Re: Who cares?

[Anonymous Coward]

Who cares? who cares??!!? Now I can masturbate to an OpenGL ES rendered rotating teapot smug with the knowledge that Winblows users are watching inferior direct3d rendered porn!

Re:Who cares?

[Desler]

You use a wrapper not ES directly.

Re:Who cares?

[Desler]

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.

Re: Who cares?

[Desler]

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.

Re:Who cares?

[foijord]

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.

Re:Who cares?

[DrXym]

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.

Re:Who cares?

[hairyfeet]

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.

Re:Who cares?

[DrXym]

I'm not using the Android SDK VM for OpenGL ES 2.0 work. I'm using Java and JOGL on the desktop to develop the rendering code in a test harness. The JOGL and the Android bindings are close enough together that I can write two backends and an abstraction layer and have 99% of the rendering code common to either. I can turnaround stuff probably 5x faster too without the uploading to a device.

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.

Very very poor article

[Anonymous Coward]

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:Very very poor article

[Anonymous Coward]

Just waiting for multi-threading support for OpenGL. It currently only supports one context per app, but threads behind the scenes. Optimally it allows multiple contexts per app and does no threading behind the scenes.

Re:Very very poor article

[Zero__Kelvin]

" Linux has terrible graphics drivers from AMD, Nvidia AND Intel."

Since youdon't use Linux, or don't know how to configure it properly, you should refrain from speaking as though you have. NVIDIA and Intel have great Linux drivers. I cannot speak for AMD, since I haven't used them in years, but you seem to confuse the Open Source NVIDIA driver (nouveau) with the proprietary drivers, which work awesome and allow full use of the GPU through CUDA. Intel's Open Source driver is also quite good.

Re:Very very poor article

[Anonymous Coward]

Why? I don't really get this fascination with multi-threading when you have to wait for a lock on a common device (screen) anyway.

Re:Very very poor article

[Guspaz]

Microsoft going AMD Fusion would be surprising, since the AMD Fusion chips that can compete with Haswell on a power usage standpoint make the Atom look high performance by comparison.

Re:Very very poor article

[Anonymous Coward]

Modern GPUs can be feed both asynchronously and concurrently, so threading can help a lot. Civ5 is one of the few games to support threading and non-threaded drivers showed 6 out of 12 cores under load and around 20fps and enabling threading in the drivers allowed 12 out of 12 cores to be used and the fps almost doubled to 40fps.

When there are lots of objects to be rendered, the single biggest bottleneck is how many commands you can issue to the GPU, and that is almost entirely dictated by the number of cores you have. If you want lots of objects, you need to thread, and Civ5 is a great example of lots of objects, so is EvE Online and blob warfare, but that engine does not support threading.

Re:Very very poor article

[foijord]

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.

That's a really good reason to have native OpenGL ES drivers IMHO. But why would you create an app on windows, and release it on any platform except windows?

Re:Very very poor article

[Anonymous Coward]

Intel about to be blown out of the water by AMD? Not in this reality. This statement is so full of shit, it's safe to assume the rest of your post is too.

AMD's integrated cpu/gpu combos have been nothing more than a massive disappointment at every turn and there is nothing to suggest the next gen will be anything different. Furthermore, Intel surpasses whatever AMD has been putting out whenever they release a new generation, and Intel doe not even seem to be putting much effort in to their integrated GPU development.

Furthermore, do you know what other console was originally supposed to ship with an AMD cpu? The orginal xbox. Yeah. Intel scooped that deal handily. What makes you think they won't attempt it again? And probably succeed? What do you bet that MS and Sony aren't just baiting Intel in an effort to leverage a better deal?

Re:Very very poor article

[tibman]

Your wait is over! (and has been for a long time)
https://www.opengl.org/wiki/OpenGL_and_multithreading

Re:Very very poor article

[hairyfeet]

You are forgetting how much people want their mobile devices to do everything their PCs will do and AMD does have a pretty big advantage when it comes to GPUs. it was a big enough advantage that not one, not two, but three of the next gen consoles are using their GPUs and two are using their APUs so having lots of multimedia power is a big plus and Intel is still behind in that area. i'm frankly shocked Intel hasn't bought Nvidia by now, it would give them the graphics expertise they could really use.

Re:Very very poor article

[fat_mike]

Try running X-Plane on the same system using a Windows 7 and any Linux distribution and tell me how awesome the open source drivers are compared to Windows.

Re:Very very poor article

[Guspaz]

The PS4's use of an APU is an unsubstantiated rumour at this point, the Wii U definitely doesn't use an AMD CPU at all (it's a PowerPC for Pete's sake), and the XBox 720's rumoured to have a GPU that's more than double the size of the biggest one they're shipping today (as far as I can tell), indicating a more traditional CPU/GPU architecture...

Re:Very very poor article

[Marxdot]

Since there is only one interface to the GPU (and thus only one command pipeline being used to the best of its ability for each context), multi-threaded access to OpenGL contexts only serves to slow rendering down.

Re:Very very poor article

[Guspaz]

Sorry, I should clarify, the GPU is more than double the size of the GPU in any APU.

Re:Very very poor article

[Randle_Revar]

I wouldn't use Nvidia anyway, but if I did, I sure wouldn't use the binary pile of shit.

Quality goes kinda like this:
fglrx < Nvidia < Nouveau < r300g/r600g < i965

Re:Very very poor article

[drinkypoo]

I wouldn't use Nvidia anyway, but if I did, I sure wouldn't use the binary pile of shit.

Unless you wanted 3d acceleration that worked. Or XVBA that works. Or, basically, anything else that works beyond framebuffer and basic OpenGL.

Re:Very very poor article

[Anonymous Coward]

Apparently you cannot read, since the post you replied to clearly says "you seem to confuse the Open Source NVIDIA driver (nouveau) with the proprietary drivers, which work awesome and allow full use of the GPU through CUDA."

You are obviously confused.

Re:Very very poor article

[Zero__Kelvin]

First of all, X-Plane is designed for OS X, but can be made to run on Windows and Linux. Second of all, there is no problem with doing it if, as I clearly stated, you use the proprietary driver.

Re:Very very poor article

[Zero__Kelvin]

Well, as a guy who never has used it, and never will use it, you are certainly in a position to counter my claim as a guy who does in fact use it even as I type this post.

Re:Very very poor article

[Anonymous Coward]

Except it doesn't allow for multiple threads to do so at the same time. Each thread must request control, which means it's serialized.

Re:Very very poor article

[Randle_Revar]

ABI breakage is all you need to know about the blobs.

And I never said I hadn't used it in the past. Because I did, though it didn't take me long to go buy a Radeon to replace it (this was pre-Nouveau)

Re:Very very poor article

[Randle_Revar]

My Intel 3D acceleration has recently been working great at playing some Steam games, actually. And so did my old Intel chip (well, Wine and ID, not Steam at that time), and so did my r300.

>XVBA
Eh, that would be nice, but even my old system played 1080p h.264 mkv files just fine, so I am not worried.

>framebuffer
the framebuffer is not a function of the Mesa driver...

Re:Very very poor article

[Anonymous Coward]

ABI breakage is all you need to know about the blobs.

And if the Linux kernel had a stable ABI we wouldn't have this problem.

Re:Very very poor article

[tibman]

Sorry, but you didn't get very far into that:
wglShareLists causes a few things to be shared such as textures, display lists, VBO/IBO, shaders. You should call wglShareLists as soon as possible, meaning before you create any resources. You can then make GL rendering context 1 current in thread1 and make GL rendering context 2 current in thread2 at the same time. If you upload a texture from thread2, then it will be available in thread1.

Are you wanting to perform draw calls at the same time? That should never be possible. You should be rendering the frame to the back buffer and then swapping it forward to be displayed. You certainly could have different threads doing that part but i feel like it would be slower. All opengl is executed in the order it was issued in. Drawing out of order would be very bad.

Re:Very very poor article

[Randle_Revar]

Having a stable ABI would BE the the problem.

Re:Very very poor article

[Anonymous Coward]

DX11 handles deferred rendering just fine. Actually, the Wine devels had a blog many years back talking about how well DX11 is engineered and what a blessing it is to work with compared to any prior DX or even OpenGL.

I +1'd you for your useful info that I did not notice.

Re:Very very poor article

[hairyfeet]

The PS4 is NOT a rumor as dev kits have already been sent, its using an "octo-core" (I put quotes because in the AMD arch the new modules work more like HT than full cores so IRL its a quad with HT) Jaguar based APU at 1.7GHz, the specs are already out there and they all say the same thing.

As for the 720 if the rumors are true then it IS using a similar jaguar octo-core, its simply also using an AMD graphics chip (but no discrete graphics memory other than a little bit of SRAM which makes it even more likely its an onboard IGP and an APU in hybrid crossfire) on top of the jaguar APU. Again look up Xbox Next Dev kits" to see all the nitty gritty details but the APUs in both systems are essentially identical, AMD jaguar.

And I SAID that 3 used the GPU and 2 the APU, The wii U uses an AMD GPU and a PPC CPU, which is exactly the approach they did for the Wii. Several devs at Sony have already admitted Cell was a dead end, too hard to code for and too niche to get lower prices thanks to lousy economies of scale so going AMD APU cuts their costs significantly which considering how many billions they lost on PS3 is totally understandable. with MSFT it also makes sense as MSFT has been wanting better integration with the PC for awhile now and an AMD APU will likewise cut costs while making it easy for devs to port to/from the PC.

Re:Very very poor article

[Guspaz]

I find it highly questionable that a console manufacturer, who are normally incredibly sensitive to die size and unnecessary complexity, would ship consoles with both an iGPU and a dGPU requiring questionable multi-GPU techniques (which tend to add latency and microstutter) when they could simply ship a pure CPU with a more powerful GPU. Considering Intel's edge in manufacturing and IPC, there seems to be little advantage to using an AMD APU if you're going to rely mainly on an external GPU anyhow.

Re:Very very poor article

[hairyfeet]

Then you haven't kept up on current events and how the new GCN cores work. you see when you are in "multimedia mode" like say watching netflix or streaming video or even playing your "cut the rope" style games? it shuts down the powerful GPU and switches to the weaker APU to save a LOT of power. Then when you are playing your CoD or Crysis what it does is hand all the GPU work to the bigger chip and the APU does physics and other tasks that can be handled by a GP-GPU.

You should really look up some of the in depth articles on the GCN design, its really smart and gives AMD some serious advantages. Basically the OS decides what work to send where and the chip adapts while having a much more streamed pipeline than the previous VLIW based chips, its really interesting.

but you are basing the stutter and lag on the older VLIW design which had a tendency to stall if the code wasn't optimized just right, the new vector cores are like having truly independent GPUs that can just do other work while say thread C which needs the output of thread B is handled by itself, no longer can one thread choke the pipe like that. again its a really good read, Anandtech and Tom's hardware IIRC both have good articles on the subject. i bet when you read them it'll be a lightbulb going off over your head because when you see how the new design really works it makes a LOT of sense to split the load between a full bore GPU and an APU as the APU can handle multimedia, AI, pathfinding, physics, while the full bore GPU does the heavy lifting. Its just a really smart design.

And????

[who_stole_my_kidneys]

So your saying support for OpenGL came out faster on an Open Source Operating system (Linux) then it did on Windows? Shocking!

Re:And????

[Desler]

No this is about OpenGL ES which is basically irrelevant on desktop Windows.

Re:And????

[petermgreen]

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.

Re:And????

[Anonymous Coward]

Precisely.

Add to the fact that the Linux drivers for the Intel HD 4000 mentioned here already have had support for desktop OpenGL 3.1 for some time, this is pretty much irrelevant. (What's more annoying is that the HD 4000 apparently supports OpenGL 4.0 on Windows.)

Windows and opengl ES

[Anonymous Coward]

In other words the sky is blue, they don't support any version on windows natively. It's wrapped and passed if you're designing programs on windows. Which makes sense.

Assuming you're old enough

[Anonymous Coward]

Assuming you're old enough to have sex legally, that is.

ABSOLUTELY FALSE.

[Anonymous Coward]

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.

Re:ABSOLUTELY FALSE.

[Anonymous Coward]

OpenGL only supports one thread sending commands to the GPU at a time, DX11 supports deferred contexts which allows threads to write to their own command queues and lets the GPU drivers to read concurrently and about removes context switching.

Currently, the one of the biggest bottlenecks is the ability of the CPU to send commands to the GPU. A modern 3ghz CPU has an effective cap on how many instructions it can send, but threading it allows an almost linear increase in the number of commands that can be sent.

In nearly every game, my GPU is around 10% load and my CPU is around 10% load and my FPS tanks when lots of objects enter the screen. If my system is effectively "idle", then why is my performance so bad? Ohh, plenty of research says we need to thread this stuff.

Re:ABSOLUTELY FALSE.

[Marxdot]

lets the GPU drivers to read concurrently

There is currently no such thing.

and about removes context switching

Again, there is no such thing. The command buffer of the GPU is a shared resource that can only serve one logical core at a time.

Ohh, plenty of research says we need to thread this stuff.

What should we be "threading"? Obviously not context access, which is a gimmick. It would make sense for software rendering, but not for shared access to a single resource.

Please show us this research.

Intel is playing both sides of the street.

[Anonymous Coward]

On one hand they gave Microsoft a carrot by not releasing c compile specs giving Windows a one time exclusive on a specialized release of the Atom. Now they are giving Microsoft the stick by making sure that the future of gaming and advanced entertainment devices using the Linux kernel with their processors is not effected.

Further to the point they are simply making sure that there is a door open for them in future to get some of the high end entertainment device business back from arm and AMD.

They realize the fact that an open software approach to device firmware is much more manufacturer friendly than anything Microsoft has come up with the locked down Windows embedded firmware kernels.

This is a fairly reasonable approach when dealing with the juggernaut from Redmond.

Re:Intel is playing both sides of the street.

[Desler]

Execpt that OpenGL ES has zero relevance on desktop Windows. No one uses it. Kinda blows your whole theory out of the water.

Re:Intel is playing both sides of the street.

[Anonymous Coward]

Well WebGL is OpenGL ES. I am sure you heard of this web craze that started lately...

By the only interpretation that could be true

[Anonymous Coward]

By the only interpretation that could be true, DX doesn't allow sending multiple commands to the GPU at a time either.

OpenGL was used and designed for UNIX and similar Big Workstations (SGI et al). Lots of CPUs. Intended to produce graphics alone.

Why the HELL are you thinking they would not have allowed more than one CPU thread update to their graphics system???

Your apocryphal is bullshit. Hell, it's not even true for single threaded DX9 or 10. Some games CPU bound some games GPU bound.

Re:By the only interpretation that could be true

[Anonymous Coward]

OpenGL was meant for Professional rendering systems where the GPU/CPU was the bottle-neck, not the rate at which commands could be issued.

Most games are neither CPU nor GPU bound, they are thread-bound because they cannot make use of current resources.

In OpenGL, there is only one shared context, which is a critical path. This means only one thread at a time. DX11 has one primary context, but then each worker thread can request a deferred context. These deferred contexts can be read in concurrently, which is handled by the drivers. Each context is still critical in DX11, but you can have as many as you want.

Dream on

[Kjella]

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.

Re:Dream on

[dbIII]

Yet despite their allegedly superior technology, last year was an unmitigated disaster

Sales of personal computers are not doing well due to economic conditions and Intel has a tight grip on Dell etc, as well as closing the price gap that made AMD look like vastly better value for money in earlier years. It doesn't mean they are doomed.

the market of high end desktop/workstation/server chips that AMD has pretty much abandoned

Excuse me? Where did you get that from? There's a 32 core opteron coming out that can go on 4 socket boards, while meanwhile Intel is on ten cores with no better clock speed for the multi-way CPUs and a vast price difference. You are confusing the middle to low end with the high end.

Re:Dream on

[drinkypoo]

While Intel may have a tough time battling ARM on the low power front, AMD is totally lost.

Intel has already proven they can't battle ARM on the low power front. Even when they made ARM processors themselves they were higher-power than everyone else's. Literally. But your point about AMD power consumption is well-taken. Not since Geode have they managed to be impressive in that department.

Well it's about effing time

[Anonymous Coward]

WTF took so long, anyway?

AMD are buggered by Windows & Games single thr

[Anonymous Coward]

Because there hasn't been any games using more than a couple of threads to any extent that makes a damn difference (DX9,10 and 11 initial release), the scalability of the multi-core AMD system compared to that of Intel has been of no use.

But the simpler (and stupid) Intel multicore system wasn't the bottleneck and, along with fewer cores being pumped faster, resulted in Intel on games being better bang per buck.

Just barely now are DX games going to *start* be multi-cpu dependent, which would normally allow AMD's better technology to make a difference. Problem is, though, MS's marketing killbot strategy demanding that 11b which finally allows DX to be multi-threaded is ONLY allowed on Win8 will ensure that for the next three years or more. And that will likely see AMD screwed whilst Intel work out how the hell to make a sensible multi-core system that isn't a bloody silly bottleneck.

You can do it on the DESKTOP too.

[Anonymous Coward]

Didn't you know that?

OpenGL ES can be used to do the same things on the desktop.

WebGL uses OpenGL ES. It's on the desktop too.

Look, just because Microsoft aren't "world leaders" doesn't mean you have to diss OpenGL ES.

So multithreading DX11 will slow things down?

[Anonymous Coward]

Your claim doesn't pass the sniff test, old boy.

Not to mention that updating the scene doesn't have to be single threaded: you can have one thread for each discrete object and each thread updates the location of its object in the scene.

And when Windows gets it, Desler will like it.

[Anonymous Coward]

Because the only reason why this troll is going "so what?" is because it isn't on Windows.

No other reason at all.

Your lack of Linux understanding is astounding

[Zero__Kelvin]

",just like Linux embedded, runs a stripped down kernel "

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.

Re:Your lack of Linux understanding is astounding

[hairyfeet]

Uhhh...yeah, kinda what I was talking about, you just don't include anything that isn't gonna be specifically need ed for the limited functions you are gonna support, hence a lower memory and space footprint. Just as you wouldn't build Windows Embedded with support for calc and WiFi and Windows sharing if its running in a Kiosk so too would you not include anything in embedded linux except the kernel and what module you need to support the specific hardware and perform the specific task you had in mind.

Kinda fucking sad I apparently have to spell every damned little thing out now as otherwise people get so God damned anal retentive when it comes to phrasing its insane. At least you didn't do the whole "Linux is a kernel" horseshit like most do, I'll at least give you credit for that but since we were talking about embedded OSes and not just the kernel i figured most could follow the conversation, i guess not, my bad.

Re:Your lack of Linux understanding is astounding

[Zero__Kelvin]

" Windows Embedded, just like Linux embedded, runs a stripped down kernel "

Again. You are simply wrong. Linux doesn't run a "stripped down" kernel. Just as with a desktop version the modules are either compiled at runtime into the kernel or loaded as needed. There is no difference. In an embedded system you know which modules are needed and which aren't so you build them into the kernel. There is no wasted storage space, since there is no need to have modules lying around on disk (including FLASH) just in case they are needed for a different hardware configuration. Just be a man and admit you misspoke, rather than trying to save face and claim you were correct the whole time. It's not the hard to man up. Seriously.