If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Yeah seriously, I have no idea what these Zealots are screaming about. Ubuntu brought Nvidia to EGL (Mir & Wayland) single handedly. They are acticly working with Nvidia to go this. NO ONE in wayland seems to have even got Nvidia to entertain the idea. Seems like a success story to me.

Nvidia said they were working on EGL support at XDC2012 in Spetember, six months ago, so I would think Wayland is more likely than Mir to have been a factor in that decision.

I think as long as they can be backwards-compatible with the xservers then this change would be relatively trivial for them, it's probably the regression testing which will be the hard part. They already support EGL on Tegra so just use that I guess. Also will GLX still work via xwayland or xmir? Surely this wouldn't be too hard, I'd really like Maya/Nuke/Mudbox/etc. to still work on my workstation with these new display managers, but not using a software fallback or indirection driver like XGL did.

OpenGL ES 3.0 is more like OpenGL 3.0 but with a few things cut like the GLSL syntax doesn't use in/out and there's no geometry shaders. I think adding OpenGL support to EGL would be trivial, you'd just specify the right enum in context-creation of your app, no big deal? The window manager might be better off using a subset of what ES supplies just for compatibility but the apps themselves shouldn't have a problem...

Yes it does, according to the spec. See page 36. I'm happy about that, I like the new in/out syntax better. It doesn't affect speed, since it compiles to the same code, but it's nice that it will be compatible with OpenGL 3.3+ syntax.

Yes it does, according to the spec. See page 36. I'm happy about that, I like the new in/out syntax better. It doesn't affect speed, since it compiles to the same code, but it's nice that it will be compatible with OpenGL 3.3+ syntax.

Oh awesome I didn't know, thanks for the link. Now I'm trying to remember where I read that they weren't in it, I think it was page 2 that tricked me under "Changes from OpenGL GLSL 3.3: Removed: in and out blocks."

;)

Nvidia has had GLES & EGL support for a couple of years now it's in the Tegra driver, nothing new there. Linux, Wayland, Mir, ... had nothing to do with this. AMD/Ati doesn't have GLES/EGL support what they have is an emulator. I predict, in the future GL and GLES will be one in the same call it OpenGL 5 maybe?

We really need to dump legacy support at this point it's only holding us back.

Regardless once GLES/EGL support on the desktop for all common chipsets is here, Display Servers will be developed like Window Managers "Everyone is going to have there own flavor" things
like Wayland and Mir are not going to be all that important.

We will also see an explosion of Application/GUI development toolkits. You think things are fragmented now just wait. GLES, EGL and OpenVG make these things trivial to develop.

Nvidia has had GLES & EGL support for a couple of years now it's in the Tegra driver, nothing new there. Linux, Wayland, Mir, ... had nothing to do with this. AMD/Ati doesn't have GLES/EGL support what they have is an emulator. I predict, in the future GL and GLES will be one in the same call it OpenGL 5 maybe?

We really need to dump legacy support at this point it's only holding us back.

Regardless once GLES/EGL support on the desktop for all common chipsets is here, Display Servers will be developed like Window Managers "Everyone is going to have there own flavor" things
like Wayland and Mir are not going to be all that important.

We will also see an explosion of Application/GUI development toolkits. You think things are fragmented now just wait. GLES, EGL and OpenVG make these things trivial to develop.

If you read up the politics behind the conception of glES, one of the driving reasons for its creation and adoption was that openGL 1 - 2 built up a lot of completely useless in modern usage API calls, such that glES only uses vertex arrays, for example. The reason openGL still exists and is extended at all is for backwards compatibility reasons, and a few niche cutting edge features not in glES 3. Most anything you want to implement can be done in the shader language anyway.

A lot of CAD programs depend on non-vertex GL commands from the early days of ogl, so they are one of the greatest interest groups keeping it supported. I think the Linux desktop is at an interesting point in its development where it could in theory depreciate the original ogl entirely and focus on ES, since it has few / no legacy apps that require the old API calls, and anyone that needs those could still in theory run an XWayland server (in context) and expect full openGL to be present.

Targeting gles means you can hit every mobile and desktop platform, plus webgl (which is implemented as a dialect of gles 2, and only requires command translation rather than total engine refactoring due to different API syntax) in one swoop.