Talk:OpenGL/Archive 1

Archive 1

Proposed example removal

Does the example subsection really make sense? It's much more complicated than this (where's the context acquired?), spreads bad habits (clearing color buffer ??? No way! ) and it's redundant with most tutorial sites. Last but not least, I'm not sure it would fit in an encyclopedia.
Personally, I propose to remove it. Ah, last note: I'll do it if no one opposes in the next few days ;)
MaxDZ8 talk 15:39, 22 March 2007 (UTC)

I think that the example help to give the readers an idea of the "appearance" of OpenGL, recognize it in the future and, maybe, compare its use with others alternatives. I would keep it but let's see more opinions :) Bedwyr 23:03, 22 March 2007 (UTC)

I really don't see how OpenGL output could look much different to Direct3D, PHIGS, or QuickDraw 3D. I think the appearance of any 3D app is more dependant on the models, textures, shaders and other content that goes into producing it. Even the hardware has been fairly common for a while. So just what is the "appearance" of OpenGL? --Imroy 06:58, 23 March 2007 (UTC)

Of course, you're right :) but I think that it helps people to associate the gl___ calls with OpenGL. A bit simplistic, I know, but informative for the people who don't know anything of OpenGL. Bedwyr 10:43, 23 March 2007 (UTC)

I think it would be better to have a colored sourcecode snapshot (raster) for this. The problem is that "idea" isn't right. An issue which regoularly pokes on support forum is people who just write gl___ calls in their code and expect it to work. It obviously doesn't.

MaxDZ8 talk 06:11, 23 March 2007 (UTC)

Well, we can advise about that in the article Bedwyr 10:43, 23 March 2007 (UTC)

Ok, keep it. At least I know someone is aware of the issue.
MaxDZ8 talk 13:03, 23 March 2007 (UTC)

Some contributions

Hi, I am a spanish wikipedist and after being working on the spanish version I have some contributions to this one. Please, be understanding with my poor English and help me to do it correctly. Thank you. Bedwyr 18:09, 16 February 2007 (UTC)

Versions

Hmm, needs some explaination of the different versions. -- Lightkey 17:19, 3 Apr 2005 (UTC)

Not a library

OpenGL isn't a library. It's a language - the Open Graphics Language. It started out as a set of tokens that could be passed from graphics clients to graphics servers, a token stream. The library that everyone's used to using, conceptually, just generates those tokens in the stream for you. OpenGL is /certainly/ not a specification - the "OpenGL Specification" is a specification, but OpenGL is a language (or if you're not convinced of that, a 'technology'). The really irritating thing about this is that it used to be on the SGI web site, but I can't find the page anymore :(

Above poster is misinformed: The spec defines 'OpenGL' as 'Open Graphics Library'.

The token-stream referred to is the GLX protocol. This is an important component - and should probably be mentioned in the article - but is not in itself 'OpenGL' by any stretch of the imagination. Many conformant implementations exist that completely omit GLX support. Further, there are OpenGL entry-points that do not generate GLX tokens, affecting only client-side state. Neither is OpenGL a 'technology'; the API is carefully specified such that implementations are free to choose how they implement features. Thus, two implementations can use completely different technologies to implement the same feature. OpenGL is best described as an API, but given that it's most completely embodied in it's spec it's not unreasonable to call it a specification.

OpenGL is a library (at least in all modern incarnations) - but the 'L' in 'GL' stands for 'Language'...yeah - it's silly - but that's what it is. SteveBaker

Its obviouly a libarary. Although it has its own syntax and is a language in it own right - its still a library. One can use it in conjunction with many different languages, by linking to the openGL library. Fresheneesz 00:49, 31 January 2007 (UTC)

Vista

Wouldn't this page be better off with some of the anti-MS FUD tempered a little? In Windows XP and below, there are the following options for OpenGL:

1) built-in software-only OpenGL 1.2 provided through opengl32.dll. Slow, basic, but ubiquitous. All but unused because it's so slow. 2) video card vendor-supplied ICD (e.g. nvoglnt.dll from NVidia). Offering whatever the video card vendor wants (e.g. NVidia presently support OpenGL 2.0), with whatever acceleration they can manage.

In Windows Vista, that first option will be replaced with: 3) built-in hardware (D3D) accelerated OpenGL 1.4. Not as quick as an ICD. But not as slow as XP's opengl32.dll.

ICDs will remain. They'll lose none of their ability to accelerate. They'll be no slower than they are right now. They'll still be the most widely used OpenGL implementation. MS aren't crippling OpenGL; they're not making it slower; they're improving the baseline OpenGL provider (so that it can achieve at least some acceleration, as opposed to none, which is what it achieves at present).

There is a secondary issue of desktop compositing. This is only an issue for windowed applications (as compositing is turned off for full-screen applications (e.g. games) anyway). And it's not an issue for Windows XP because it barely composites the desktop anyway (only layered windows get double buffered and blended). Loading an ICD will disable compositing (because it'll disable the Direct3D time slicing/context switching that Vista needs for compositing). Is this bad? Well, the user experience will degrade to that of Windows XP. The experience of using an ICD with Vista in a windowed OpenGL application will be no worse than it is today. Though the OpenGL fanbois seem to regard this as the end of the world, it isn't. The practical difference it'll make is negligible.

Whether it would be practical to develop an ICD that can coexist with compositing is speculation on the part of 3DLabs. What isn't speculation is that OS X's OpenGL implementation (which *does* support timeslicing/context switching in much the same way as Vista will, for much the same reasons--desktop composition) suffers decidedly lacklustre performance as a consequence. Design decisions were taken that compromise its performance relative to other operating systems.

No, it isn't speculation; it's a basic fact about graphics hardware. If you can run multiple D3D contexts then you can run a mixture of D3D and GL contexts (which is, of course, possible right now with XP). The hardware doesn't know or care which API is being used. In the case of compositing, applications must render to an offscreen buffer, which is then composited onto the screen under DX control. Where the contents of that buffer come from is irrelevant to the compositing process itself. The only issue is how GL and the DWM interact to organise this. At the time of the 3DLabs statement, the Microsoft plan was to have nothing in place to allow this, thus forcing the DWM to be switched off. Stuarta 01:35, 23 February 2006 (UTC)

Though it isn't inevitable that such an issue would arise on Vista, it does seem quite likely; Vista has the added complication of having to switch not simply between different users of OpenGL, but rather between OpenGL and Direct3D. It seems feasible that the performance of such an ICD in Vista would be undesirable in any case. Even if it could be done, it's not clear that you'd want to do it. It might also compromise the Direct3D performance, and since that's far more important (because it'll be used all the time on Vista) it's not worth doing.

This is flat out wrong. See above. Stuarta 01:35, 23 February 2006 (UTC)

The whole issue is a mountain out of a molehill.

DrPizza 16:53, 17 October 2005 (UTC)

Should the Vista bit have its own article "OpenGL in Windows Vista" Racklever 06:54, 22 December 2005 (UTC)

I believe it should not. This whole thing is based on certain (but possibly badly outdated) facts. Unoffical contacts with some vendors shows that this issue is being addressed. The point is that according to wikipedia policy those "hints" cannot be used to proof articles. I believe it's better to not spread the flames. Anyway, even if you want to write an article, you'll end up in using outdated statements from a reliable source (months have passed since then). As a second point against this, it would be just a stub. If something needs to be discussed, I believe it should be done here. MaxDZ8 17:54, 23 December 2005 (UTC)

OpenGL category?

I'm not sure of it but I cannot find a category for OpenGL users. You know, those things you put in babel boxes and such. I believe I may want to create it. If it's already there, could someone point it out? By the way, {{gl-X}} is already reserved by a language. I like {{opengl-X}}. Any suggestions?

Removal of 'Future in Microsoft Windows' section

This entire section as it stood was, I believe, grossly misleading, and I don't have the time to fix it right now, so as a temporary fix I have removed it altogether. From more recent postings than those on opengl.org, the facts appear to be:

• The default implementation of OpenGL on Windows Vista will provide version 1.4 of the API, implemented as a wrapper to DirectX (an improvement on the existing software-only implementation of OpenGL 1.2 that is provided with Windows XP). Only the core 1.4 API will be provided; no extensions.
• Vendors will be able to provide their own OpenGL drivers as they have before, which can implement any version of the API and any extensions as desired.
• However, as a consequence of using such a third-party driver, the Aeroglass compositor will be disabled for applications that use OpenGL. All other applications remain unaffected. The worst possible consequence of this is that window borders that use alpha-blending will not display correctly; although this is bad, it is not IMO a show-stopper. For games, this should be a non-issue, since games are normally run fullscreen.
• There is some debate as to whether it would be technically possible to remove that last issue. It appears that Microsoft refuse to release specs that would allow driver vendors to easily do so.

Lastly:

• Installing Windows XP or Windows 2000 graphics drivers on Windows Vista, as some with access to the beta have already done, results in the graphics subsystem operating in an XP-compatibility mode. Consequently, in this case, Aeroglass compositing is disabled for the entire desktop (since XP drivers do not support the compositor). Native Windows Vista drivers will not have this issue. This is possibly the source of much of the confusion.

Since this is a developing story with rumours flying in all directions, it seems to me that the only responsible approach is to either keep silent on the issue until the facts are more clear, or carefully describe all conflicting speculation with a neutral stance, clearly labelling it as such.

Please see: http://www.gamedev.net/community/forums/topic.asp?topic_id=338694

--Lezek 09:59, 8 January 2006 (UTC)

---

See also: [1], a more direct and reliable source of information.

[2] lists these quotes as 'from' the above presentation. I couldn't find them within the powerpoint file, so I assume that they are quotes from accompanying narration (or inaccurate :)):

...Currently, the implication of using the IHV-supplied OpenGL driver is that the Aeroglass desktop compositor will be switched off for the OpenGL application going through an OpenGL ICD. This means that the borders of the application window will be opaque instead of (potentially) transparently composited with underlying windows...

...Other running apps are unaffected.

--Lezek 11:30, 8 January 2006 (UTC)

A little note on how this gamedev message seems to have surfaced to let readers take this with some salt. Since the announcement from www.opengl.org about the VISTA dangers, many people actually emailed vendors asking for more informations. Looks like some of them actually succeeded (there's another one I know of on www.opengl.org forum thread). The good thing is that this information is actually newer than the powerpoint presentations by MS. The bad thing is that while the presentations are official, those mail contacts are not. This means that if they're true they possibly mean the problem has been fixed but this is not sure. By sure, there's been a problem and we know maybe it's fixed. Maybe. The original powerpoint presentations can be found on www.opengl.org, just go to the VISTA thread (you really cannot miss it!). MaxDZ8 17:56, 9 January 2006 (UTC)

I don't really agree that the section as it stood was "grossly misleading", or that the characterisation of the situation given above is correct. Some coverage of the Vista situation would be worthwhile in the article.

A few points:

There are fundamental reasons why Direct3D cannot be used to produce a compliant Gl implementation (e.g. fill conventions). While the XP software implementation is very poor, and non-compliant in some cases, the D3D wrapper is not much of a step up. It will never be compliant, and is already, before release, out of date. The jump from 1.2 to 1.4 is negligible from a modern application POV, given that no programmability is exposed. They are about as useless as each other.

There is no debate regarding whether it is technically possible to avoid the compositor switch-off. It is. It is a matter of Microsoft allowing the ICD to interact with the compositing system in such a way as to allow it. Moves have been made in this direction.

It is false to suggest "the worst possible consequence" of compositing switch-off is poorly rendered window borders. Compositing is used throughout the Vista user interface for a variety of effects.

The comment from the 3DLabs employee was accurate when it was made, and is still worth citing from a historical perspective, along with the WinHEC slides. The discussion that you deleted had some valuable information, and with some updates/rewording should be reinstated, in my view. There's no question that compositor switch-off was Microsoft's plan, and it is illuminating regarding the long term future of GL on Windows regardless of what ultimately happens with Vista.

Stuarta 01:23, 23 February 2006 (UTC)

LinkSpam

66.168.219.120 said:

  "Add way useful link back; wikipedia is one big link farm; read the policy Honk-On"

I did - and you should. Please read: "Wikipedia is not a repository of links",,and (more concisely):

  http://en.wikipedia.org/wiki/Wikipedia:External_links

I'm going to re-revert your change - please note that if you re-re-revert it, you (and your assumed sock-puppet) will be in violation of the 3 revert rule (WP:3RR) - which will get you banned from Wikipedia for a cooling off period.

65.193.87.52 said:

 "Steve is not an OPENGL god like me"

Untrue - I am in fact a minor deity in the OpenGL pantheon with divine knowledge of the problem of MIPmap level selection and the mystic power to debug shaders without a safety net.

Thanks. SteveBaker 16:54, 24 March 2006 (UTC)

I support the removal of the link. An encyclopedia should be a really high-quality content, not a whole load of links. People wanting to get in touch with the issue often have better things to do than wandering thuru a load of links grinding the few little information. Quantity does not mean content. I also think this link didn't qualify as trustable in the first place. Last but not least: if this is something which deserves to be noted, what are all the libraries and engines floating around the net? MaxDZ8 _talk 17:09, 24 March 2006 (UTC)

There is a case for making a page called "List of Published OpenGL Support Libraries" or "List of OpenSourced OpenGL Libraries" - which would be justified in having links to all of the hundreds and hundreds of OpenGL support libraries. But to undertake to create and maintain that list on the OpenGL page itself is wrong. We should restrict ourselves to linking the 'official' OpenGL libraries (GLUT, GLU, GLX, etc) - and only referring to web sites that describe OpenGL - or include important tutorials or something. To do otherwise opens the floodgates and before you know it we'd be advertising every OpenGL-based product on the planet. SteveBaker 21:55, 24 March 2006 (UTC)

Don't worry about removing the linkspam. I did some investigation last night and found out it's really User:0waldo (contribs), a known sock-puppeteer and all-round jerk. He's been banned because of his behaviour and now seems to be resorting to open proxies or something to continue his campaign of linking to his web site and abusing people. Just ignore his comments and revert his edits on sight. I certainly won't be losing any sleep over removing the juevenile and largely-useless contributions of someone who doesn't want to work with the Wikipedia community. Imroy 02:56, 25 March 2006 (UTC)

Mmmm'K - but can I still be an OpenGL God because I already bought the costume and everything? SteveBaker 12:51, 25 March 2006 (UTC)

I added back the 'linkspam' because I have a right to add it for waldo, just as you have a right to label it such and subsequently remove it. BTW, I went to your page and I'm not impressed, could you go back to school or something Steve? More GOD classes maybe?

Hello All this is 0Waldo and I'm SO FREEKING happy to be back, unfettered and or/no shackles AND UNBLOCKED TOTALLY. I added the link back because it has been there forever and is useful. Please DO NOT REMOVE THE LINK unless I tell you. Thanks!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 0waldo 15:32, 25 March 2006 (UTC)

So, let's get this straight. You get banned for link-spamming - and the very first thing you do when you get back is linkspam again? Hmmm - I think you have a problem. SteveBaker 15:59, 25 March 2006 (UTC)

Other people would have gotten the message by now, but not 0waldo! About banning him, I seem to remember reading somewhere that special "filters" can be constructed to catch automated spam being added to any Wikipedia site (maybe all of the WikiMedia sites too). Since 0waldo's been using a few sock-puppets (open proxies?) this might be a better solution. Imroy 16:10, 25 March 2006 (UTC)

WTF EVER - from waldo, you guys are SO junior and lacking!

Attn IMROY: if I want your stinky opinion I would have flushed three times pal! 0waldo 16:14, 25 March 2006 (UTC)

---

removed image

It has nothing to do with content. I has to do with lickbutt. That's all. If you want to play lickbutt with all the people here then you can edit whatever you like. Otherwise you wind up right here painting a special picture for all the slurpies that hang around here and harass me for the fun of it. —Preceding unsigned comment added by 0waldo (talk • contribs) 23:01, 25 March 2006 (UTC)

---

What the hell is lickbutt?--Hellogoodsir 20:10, 23 July 2006 (UTC)

Some strange accusation made by an unstable user who was trying to get his website linked on Wikipedia, and adding his strange 'paintings'. User 0waldo (talk · contribs) has since left Wikipedia and removed much of his work. It's sad to see someone run into the wall that is Wikipedia's rules and guidelines and instead of accepting them, grow frustrated and angry at what appears to be personal attacks by an 'inner circle'. People should learn to lurk more and learn the local customs before launching themselves onto a public forum. Imroy 03:09, 24 July 2006 (UTC)

Well it's good that he's gone then. I use to frequently monitor the Battlefield 2 article, and users would attempt to advertise so many websites. Wikipedia isn't a billboard, and it shouldn't be! I honestly have no knowledge of OpenGL, so I'll just take in the info people have presented. Good article!--Hellogoodsir 05:16, 8 August 2006 (UTC)

OpenGL 2.1

Somebody should add information about how the ARB has stepped down and the Khronos group is now in control of OpenGL. I'd do so myself, but I'm not exactly a great writer. Amnesiasoft 01:35, 24 June 2006 (UTC)

Agreed. If the OpenGL ARB is defunct, the Specificaiton section of this article should be revised. User:knicholson

See Also

There a few OpenGL Binding references in the "See Also" section: JOGL, LWJGL, Tao.

Shouldn't these be moved to the "Bindings" section? If there are no objections, I'll do so. —The preceding unsigned comment was added by Grafman (talk • contribs) 05:11, 15 May 2007 (UTC).

External links

I took them out of the article becase the are just not needed! why did you put them back anyway? Alf. OK, I think I agree with you about the official external links. So I left those two. Others can just be googled if more information is required. —Preceding unsigned comment added by 24.236.76.231 (talk • contribs)

I can understand the removal of links to free code on our company site because it is relatively obscure but removing the NeHe tutorials is insane, IMO. Jon Harrop

Client and Server

Would someone add to the article the concept of an OpenGL client and OpenGL server? One particular detail I can't find is, what is the server? Is it an executable that runs on the CPU, or does it refer to the GPU? —Preceding unsigned comment added by 134.197.40.199 (talk • contribs)

OpenGL is an API and is entirely transparent about where/what the display hardware is (if there even is any acceleration). If there is a 'client' and 'server', it would have to be platform-specific. The only one I know of is GLX, for use with the X Window System. It functions as an X extension, meaning the OpenGL calls/commands are transported over the same connection with all the other X commands. The display could be on the local machine (often with special optimisations) or over the network. Apart from that, I know of no other OpenGL client and OpenGL server. --Imroy 18:22, 15 June 2007 (UTC)

Is this issue resolved?
I cannot believe I'm reading this. The GL specs have a specific information about the server and client state. There is explicit notion of a OpenGL server (usually HW+driver) in the GL spec. The OpenGL client is the accelerated application. Also, if there would be no "client" then why is there a call named "EnableClientState"?
MaxDZ8 talk 05:49, 9 October 2007 (UTC)

Fair use rationale for Image:OpenGL Logo.jpg

Image:OpenGL Logo.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 23:38, 1 July 2007 (UTC)

Language Bindings

Both Java and Visual Basic bullets referred to OpenGL.org's Language Binding page - which is out-of-date (broken links) and Java-centric (see URL). I've consolidated and replaced with OpenGL.org's more current Language Bindings Wiki. Grafman 15:45, 6 July 2007 (UTC)

Open GL

I know it sounds stupid, but for the longest time I thought OpenGL was actually "open", as in "open source". A quick look at their website shows it isn't, but I wonder how widespread this belief is. (If it is, it should be added to the article.)

-- trlkly 05:39, 17 August 2007 (UTC)

The sample implementation is open source (under a BSD license), but other than that, OpenGL is just a specification which is freely available to implementors of open-source software (proprietary software does require a license, though). – Mipadi 07:29, 17 August 2007 (UTC)

Technically speaking even commercial implementations of the API do not need license, however they need license to use the OpenGL name or logo, or call their implementation OpenGL conforming. - JohnyDog 19:21, 3 September 2007 (UTC)

Games needs more attention

Use in Consoles

all PS2/Gamecube/PS3 games use OpenGL, i think that part needs a revision. allot of people think OpenGL isn't used allot in games, but the majority of console games are indeed OpenGL "from elder scrolls, to PGA Golf" Markthemac 20:11, 31 August 2007 (UTC)

No, they don't. The PS2 and GC both had graphics APIs that were similar to OpenGL, but were definitely not actual OpenGL. I wouldn't know about the PS3 though. —Preceding unsigned comment added by 195.72.176.232 (talk) 14:13, 20 September 2007 (UTC)

I didn't think Half-Life and Counter-Strike used Open GL; their Direct3D dependancies was often mentioned as the primary reason why we never saw a Linux port... 80.203.44.70 (talk) 14:21, 20 January 2008 (UTC)

Weird enough (irony intended). CS is based on HL (so it doesn't make sense to consider them differently since they're the same technology) but HL was based on Quake tech in the first place, which didn't need a video card. It's hard to believe that something which allowed SW rendering does not allowed to switch API, especially after a PS2 port hit the shelves... Note this is covered in the relevant articles. Do you have some evidence?
MaxDZ8 talk 14:39, 20 January 2008 (UTC)

Please, please, PLEASE stop perpetuating this misconception! As the unsigned commenter above said the consoles you mentioned do have OpenGL or OpenGL-like API's (a very important distinction!) but it is not their only, or even most commonly used, method of rendering! I know that on the Playstation platforms the most common method is using a very low-level API to submit triangles directly to the hardware, which is considerably faster. This is feasible because the hardware is static and can be coded to explicitly, which eliminates the need for the abstraction layer that PC developers are so used to. The OpenGL interfaces are only provided for convenience but are rarely used because of the overhead they introduce. If you know of a specific title that uses OpenGL on a platform feel free to list it, but don't claim that all Console "X" games use it since it's simply not true.

I think the list should be converted to a sortable table which includes the year of release. -- Gordon Ecker (talk) 07:58, 10 November 2008 (UTC)

Omit it entirely?

I think having a list of all games that rely on OpenGL isn't really the role of an encyclopedia, and is getting a bit cumbersome. I would favor either entirely removing the section, or splitting it off into a separate page. It's not really relevant to people looking for information about OpenGL itself. If there's any especially notable uses of OpenGL that's a different story, but that doesn't appear to be what that list entails. --Sam (talk) 18:19, 20 December 2008 (UTC)

Use of OpenGL in safety-critical software

This may need special treatment, related info:

• http://www.khronos.org/opengles/sc/
• http://www.khronos.org/opengles/sc/documentation/es_sc_philosophy.pdf
• http://www.khronos.org/files/opengles_sc_spec_1_0.pdf —Preceding unsigned comment added by Parallelized (talk • contribs) 06:57, 29 March 2008 (UTC)

Mesa3D has hardware support

"Notably, the free software/open source library Mesa 3D is a fully software-based graphics API which is code-compatible with OpenGL"

According to the discuession page of the Mesa 3D article, Messa isn't "fully software-based," and it supports hardware rendering as well... —Preceding unsigned comment added by 168.28.136.13 (talk) 23:30, 12 April 2008 (UTC)

OpenGL 3.0 - an update

we have some sort of news http://scriptionary.com/blog/2008/05/13/opengl-30-an-update/ --Andri12 (talk) 14:21, 16 May 2008 (UTC)

Also, BoF has passed - it's been officially announced. Google it —Preceding unsigned comment added by 210.49.37.84 (talk) 09:39, 3 June 2008 (UTC)

OpenGL 3 was only "announced" at the last BoF, and they claimed it was on track to be finalized by the end of last August. That hasn't happened. The text in the OpenGL 3 section is talking about the next BoF. --Skrapion (talk) 02:52, 4 June 2008 (UTC)

NVIDIA to Release OpenGL 3.0 Drivers September

it seems that NVIDIA will Release OpenGL 3.0 Drivers in September

http://scriptionary.com/blog/2008/07/25/nvidia-to-release-opengl-3-0-drivers-september/ —Preceding unsigned comment added by Andri12 (talk • contribs) 19:15, 1 August 2008 (UTC)

No. According to the link, looks more like they are speculating they could release from a stolen pic. From what we know, they could just be putting some money in writing/finalizing the spec. It doesn't really matter what they do at this stage, but if they really release in Sept it will be another nail in the coffin as there's no public spec around...
MaxDZ8 talk 08:27, 4 August 2008 (UTC)

i have to say it match the time line OpenGL 3.0 Specification will be release in at Siggraph 2008 http://www.opengl.org/events/details/siggraph_2008_los_angeles_california/

1. OpenGL 3.0 Specification Overview
2. OpenGL hardware and driver plans - AMD, Intel, NVIDIA
3. Developer's perspective on OpenGL 3.0

and as NVIDIA is a member of the Khronos Group they have early Access to the OpenGL 3.0 Specification so it donset surprise me that they will release the drivers for it in september --Andri12 (talk) 15:34, 5 August 2008 (UTC)

Seems like alot of sources have arisen yesterday so now this seems definetly more real. I've also been told the spec will be released as well (but I'm not sure if it'll be at siggraph). Looks like I was too pessimistic. Let's see how it turns out to be.
MaxDZ8 talk 17:40, 6 August 2008 (UTC)

OpenGL 3.0 spec released

http://opengl.org/registry/doc/glspec30.20080811.pdf

Needs to be integrated into the page. I'd do it myself but... well, I don't want to. Ubermammal (talk) 15:16, 11 August 2008 (UTC)

OpenGL 3.0 is crap. This is basicly OpenGL 2.1 with some addtions and some old stuff declared as deprecated. No object model and not much of the promised stuff. —Preceding unsigned comment added by 89.246.106.34 (talk) 15:40, 11 August 2008 (UTC)

I've updated the OpenGL 3.0 section to hopefully represent it a bit better, breaking the discarded features from Long Peaks into their own section. Thanks to whoever made the spelling fixes, BTW. —Preceding unsigned comment added by 63.226.104.225 (talk) 19:35, 20 August 2008 (UTC)

Full use of OpenGL 3.0 on DirectX 10 hardware only ?

But OpenGL is cross-platform, and DirectX is only for Windows. I removed the sentence. Hervegirod (talk) 22:08, 19 October 2008 (UTC)

while I agree that opengl is not only available on windows, i don't know any 3D accelerator maker that does not support windows also. as all workstation maker stopped making non windows compatible stations, lat only left legacy system which certainly won't have hardware accelerated opengl3, and windows compatible hardware. as such what GPU in the near future will support opengl3 and not be a direct X 10 comp. card ? --Dwarfpower (talk) 04:50, 20 October 2008 (UTC)

Removing the statement is, in my opinion, a big mistake. I'm pretty sure you noticed basically everybody, even GL developers have now dropped the ball and rating GPUs in terms of their D3D capabilities, unless going in the top-notch multi-million-dollar visualization systems where D3D has less than zero importance.
I am not well aware if you read the GL3 discussions but it's just plain out obvious GL3 actually needs D3D10 features to be supported, and this caused quite a bit of discomfort since it left in the dust basically everyone.
I suggest to put the statement back in.
MaxDZ8 talk 07:00, 20 October 2008 (UTC)

it's just plain out obvious GL3 actually needs D3D10 features to be supported : such a statement is IMHO not correct. You could says both D3D10 and opengl3 need the same underlying hardware capability and that the driving force for the inclusion of the feature in the hardware was D3D10, but actually saying opengl need d3d would mean that d3d emulated opengl which is clearly wrong. --Dwarfpower (talk) 08:50, 20 October 2008 (UTC)

D3D10 and OGL3 are competing standards. It's just as inappropriate to say that OGL3 needs D3D10 hardware as it is to say in the DirectX page that it requires OpenGL 3 hardware. It's also not very helpful, as support for D3D10 in hardware and software is no guarantee of support of OpenGL3 in drivers. So given that it's factually incorrect, unhelpful, and possibly misleading, I support omitting the phrase. --Sam (talk) 20:37, 20 October 2008 (UTC)

I think I know where this is heading. Let's recap the issue (some emphasis added):
"Full use of OpenGL 3.0 is only available on DirectX 10 level hardware"
"it's just plain out obvious GL3 actually needs D3D10 features to be supported"
Nobody is saying that a D3D implementation is needed but that the underlying machinery is.

I believe there's some sort of language misunderstanding here.
MaxDZ8 talk 13:26, 20 October 2008 (UTC)

the terminology "DirectX 10 level hardware" in itslef his not appropriate. it is a marketing termonology developped by graphic accelerators manufacturers to sell/differentiate theyr new hardware. While its clearly clear, it is and will be more and more biased over time, so hould IMHO discarded. --Dwarfpower (talk) 13:33, 20 October 2008 (UTC)

I'm personally for putting it back in (kind of a given, since I'm the one that put it there in the first place.) Consider this: I think that we can all agree that the hardware requirements are significant enough that they should be mentioned. As such, we need an easy to understand way of indicating what that hardware level is. Since it's redundant to say "OpenGL 3.0 required OpenGL 3.0 level hardware", we must look at outside sources, of which we have two reasonable alternatives: Indicating that it requires the same level of hardware as DirectX 10 (hence, DirectX10 Level Hardware) or by indicating the card models of the individual manufacturers that have enough functionality to support the API (NVidia 8000 series or above, ATI... etc). This introduces some confusion though, in that people that aren't intimately familiar with the hardware naming conventions aren't going to be aware that an Nvidia 200 series is actually a couple of generations above the 8000 series.

The fact is that saying "DirectX 10 Level Hardware" has become the de-facto standard for identifying hardware that meets a certain shader/feature requirement. It does not indicate that DirectX 10 is required in any way, only draws the comparison that hardware that can run DirectX 10 can also run OpenGL 3.0, and it presents this information in a manner that is likely to be well understood by a large number of people. Yes, it's Microsoft marketing at it's best(worst?), but it's what people recognize and the goal of Wikipedia is to distribute knowledge, not push anti-Microsoft agendas.

Category created & list pulled

In the interest of clarity and Integration, I created a new article for the applications list, and a new category for the relevant articles. Cwolfsheep (talk) 03:53, 9 January 2009 (UTC)

merge

per discussion at Talk:Silicon Graphics I'm moving the proposed merge here. Unless there is more than just trivial coverage on IRIS GL, it should be merged into the larger article.じんない 22:07, 11 February 2009 (UTC)

That illustration

For the love of God, why you put that irrelevant scheme with a penguin there? Is OGL somehow linux specific? Nooo. So why the hell that crappy irrelevant illustration has been put there? linux guts are NOT of interest for the OGL article. their depictions in no way depict OGL. Jeez, it's way too moronic. crappux zealotry is overflowing. this is just disgusting and totally antiencyclopAEdic. — Preceding unsigned comment added by 188.190.1.60 (talk) 20:16, 6 May 2017 (UTC)

That image shows an overview of how OpenGL works on Linux systems. I'm not completely sure of the reason, but I think that Linux may have been chosen because a) it's open, so the process by which OpenGL works upon it is completely transparent (as opposed to some other systems), and 2.) it's a fairly well-known system, so people will be able to recognize it. 2600:1700:E4C0:9EA0:D1E1:35BF:9040:9E5B (talk) 22:01, 25 March 2022 (UTC)

developed by

how is ogl being developed by SGI? i believe info in info box should read 'khronos', and SGI, ARB or whatever historical involvnemt should be mentioned somewhere in text, no? 83.25.69.155 (talk) 20:36, 13 May 2009 (UTC)

Does not OpenGL stand for Open Graphics Language? (compare IrisGL). /Mikael —Preceding unsigned comment added by 212.117.81.29 (talk) 08:26, 26 October 2009 (UTC)

OpenGL was originally developed by SGI, but they then formed the OpenGL group to manage the standard, which then became Khronos. As a note, IrisGL is a 2D standard, not a 3D one. --65.29.104.121 (talk) 07:16, 3 January 2015 (UTC)

Does OpenGL stand for Open Graphics Library?

I cannot find a reference that OpenGL actually stands for Open Graphics Library. Is it possible that OpenGL is simply a name by itself, and does not stand for anything? --Jephir (talk) 02:31, 8 May 2010 (UTC)

Ah, found it, it's in the OpenGL specification. --Jephir (talk) 02:36, 8 May 2010 (UTC)

Example needs info on how to run

The Examples section would benefit by explaining how one might actually try out the example code. Is there an OpenGL interpreter or compiler to execute the code? Or how would one submit that code to their graphics card? I suspect there are many answers to these questions, but a simple explanation of where to look would be apropos. 76.197.0.39 (talk) 21:21, 1 January 2012 (UTC)

Add section on noteworthy implementations

I think a section on noteworthy implementations should be added -- preferably in a tabular format which includes entries with project name, developers, platforms it works on, GL compliancy level etc. For example

Project	Developers	Platforms	OpenGL APIs	Status
Mesa3d	Mesa3d developers	X11, Windows, Mac OS X, OS independent, others	2.1	Active
nVidia drivers	nVidia	Windows, Linux/X11, Mac OS X	4	Active
ATI drivers	ATI/AMD	Windows, Linux/X11, Mac OS X	4	Active

Please note that the above information is not likely to be completly accurate. FrederikHertzum (talk) 20:40, 12 December 2010 (UTC)

Well, Mesa3D now supports up to 3.3 with partial 4.x extensions. This goes for both the software LLVMPipe driver and the various hardware drivers, limited by hardware capability. Additionally, Mesa now supports KMS/GLE FrameBuffer video instances as well as X11 on Linux, BSD and similar platforms. They have an active roadmap for the 4.x transition, and are currently the only driver that removes the depricated GLSL functions outside of compatibility contexts. This is a major noteworthy point, as nVidia has stated that they have no interest in doing the same, and even plan to continue optimizing the depricated functions. As of version support, both nVidia and AMD drivers support 4.4 in stable and 4.5 in unstable. They can be generalized as being 4.x implementations for the sake of simplicity and reducing the frequency of updates. As a note, AMD and nVidia have separate OpenGL implementations for mobile. These focus on OpenGL ES2/ES3 API performance even though they also support the OpenGL 4.x API as well. The primary difference is that the Linux and Android Mobile implementations don't require X11 or GLX. --65.29.104.121 (talk) 07:12, 3 January 2015 (UTC)

An updated chart as well

Project	Developers	Platforms	Supported Hardware	OpenGL API Version	Status
Mesa3d	Mesa3d developers	X11-GLX, KMS/GLE-Framebuffer, Win32, Win64, Other Windows, Mac OS X, OS independent, others	AMD/ATI, nVidia, Intel GMA, Software Rendering.	3.x w/4.x extensions (Hardware dependent)	Active (Legacy drivers for other hardware unmaintained)
nVidia drivers	nVidia	Win32, Win64, Linux/X11-GLX, Mac OS X	nVidia graphics chips	4.x (Legacy drivers 3.x/2.x)	Active
AMD "Catalyst" drivers	AMD	Win32, Win64, Linux/X11-GLX, Mac OS X	AMD/ATI Graphics Chips	4.x (Legacy drivers 3.x/2.x)	Active

Example

Could someone more knowledgeable of OpenGL devise a better, non-deprecated, helloworld-style example? I quickly looked at some of the more popular tutorials and their first examples are 200 lines of code, which kinda doesn't fit here imho. Anyways imho immediate mode code is not representative of modern OpenGL and it should either be revised or removed 88.193.60.243 (talk) 06:41, 28 March 2012 (UTC)

I've removed the example altogether. Deprecated code seems a bit too misleading, and it's not possible to write a concise-but-complete example using only the non-deprecated API. An example of the API could be pretty informative, but I can't come up with any code fragments which wouldn't be completely opaque to a casual reader (eg, binding and modifying a texture object).

One alternative could be a section which describes the API in general terms - language-agnosticism, the difference between glColor3f and glColor4ub, the object-generation-and-binding system, the fact that state changes tend to carry a high performance cost and strategies used to avoid this, etc. 95.144.193.189 (talk) 15:01, 22 September 2012 (UTC)

"Written in" section of the sidebar

I deleted the "written in" note a couple of weeks ago, but it's been restored with a reference. I'm deleting it again, and thought I'd better explain why.

OpenGL is explicitly not written against any single language (the specs don't even use function signatures and tokens which match the C binding). The version 4.3 spec only mentions C a few times, and only ever in the context of a "language binding". On page 10: "Languages such as C++ and Javascript ... permit language bindings with simpler declarations". Seems pretty clear-cut that C doesn't have any special status, from the spec's perspective.

The source cited seems pretty dubious. No references are given, and "OpenGL" could refer to Mesa3D, the OpenGL binding for Windows, the most commonly-used bindings, most OpenGL drivers, etc.

The entry could be replaced with something like "Written in: Multiple languages", but that seems sort of misleading. I think OpenGL's language-agnosticism is best represented by removing the entry altogether.

77.101.163.231 (talk) 08:08, 20 October 2012 (UTC)

APPLE_flush_buffer_range in GL3?

I'm pretty sure what made it into OpenGL 3.0 was GL_ARB_map_buffer_range. The ARB extension borrows a little from Apple's earlier flush_buffer_range extension, but the final GL3 spec matches the newer ARB extension more closely (notably: it offers glMapBufferRange() like the ARB extension and not glBufferParameteri() like the Apple extension).

https://www.opengl.org/registry/specs/ARB/map_buffer_range.txt

https://www.opengl.org/registry/specs/APPLE/flush_buffer_range.txt

(EDIT: er, specifically, the ARB extension says it's a subset of the 3.0 functionality, made available for pre-3.0 implementations...so maybe the reference to APPLE_flush_buffer_range is correct as-is.)

Ryancgordon (talk) 03:23, 14 March 2014 (UTC)

DSA same as D3D12/Mantle

I removed the following text from the GL 4.5 section on DSA:

effectively the equivalent of the same capability from DirectX 12 and AMD's Mantle

The referenced article makes no such claim about DSA. The ArsTech article states that DSA is a feature D3D has had for years, but nowhere does it call it the equivalent of D3D12 or Mantle.

Korval (talk) 20:48, 17 January 2015 (UTC)

DSA is only mentioned as an example of AZDO in OpenGL (Approaching zero driver overhead). With AZDO being the equivalent to the goals of D3D12 and Mantle. Besides DSA other features used by AZDO are the indirect and batched rendering calls that have been in OpenGL much longer.Carewolf (talk) 13:06, 19 January 2015 (UTC)

Relationship to Apple's Metal API?

Should there be a mention somewhere about the relationship of OpenGL to Apple's Metal API? Is Metal a complete replacement of OpenGL (meaning "competitor" like DirectX)? Or something that can "work along side OpenGL" - I would presume allowing the main program to directly alter things that OpenGL doesn't allow the main program to do (I don't really know..), or perhaps allowing Apple's much-touted "motion coprocessor" to interact directly with the GPU?

I can't imagine Apple completely dropping OpenGL, because there have to be an large number of scientific visualization and modeling applications out there that aren't just going to drop OpenGL just because Apple has a new API - and are going to continue using new OpenGL features as they are added in the future. (Then again, this is Apple)

Or is Metal being advertised right now as "Apple's Game Rendering Engine". I guess this would create a situation like when (or if) Apple had it's Quickdraw3D and (if) there were also OpenGL extensions available for the classic MacOS? Jimw338 (talk) 17:31, 17 June 2015 (UTC)

The relationship between OpenGL and Metal as APIs is essentially that they do the same thing: 3D graphics rendering via dedicated GPU hardware. I'm sure that there are news articles out there that mention which features of OpenGL don't exist in Metal or otherwise talk about the differences between the APIs. Writing such a comparison would require finding said articles.

However, note that there is no similar section on Direct3D, despite it being a much longer-time competitor to OpenGL. So you would also need some kind of justification for adding a comparative analysis to Metal here. Unless you want to do comparisons for both.

As for Apple's continued support for OpenGL, I don't believe there are any references for that, so there's nothing you can talk about until there are. Korval (talk) 16:14, 18 June 2015 (UTC)

Sort of related - the few bits of Apple demo code for Metal that I've looked at look quite complicated compared to OpenGL code I've seen. This suggests that Metal is optimized for getting absolute performance, at the cost of not having OpenGL doing "housekeeping"? Is this a correct assessment? Jimw338 (talk) 15:48, 7 September 2017 (UTC)

Article too long and technical?

I feel like this article does not require a long list of added extensions. This information is freely available in more sensible places, such the Khronos website. In addition, the article's layout is unconventional and seems hard to follow. Any opinions on this please? -- Pingumeister^(talk) 13:02, 3 January 2017 (UTC)

Version history seems to be overly detailed. I'll try to put it all in one table and get rid of all extension tables. – K4rolB (talk) 15:25, 30 September 2019 (UTC)

Nvidia ARBs with OpenGL 2015 and 2016

See

. — Preceding unsigned comment added by 95.90.229.210 (talk) 14:26, 25 January 2017 (UTC)

References

Important Conformant products table ?

The Khronos Group maintains an extended list of OpenGL-conformant products

See https://www.khronos.org/conformance/adopters/conformant-products#opengl

Also in OpenCL — Preceding unsigned comment added by 95.90.229.251 (talk) 14:59, 28 January 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on OpenGL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://archive.is/20120530/http://www.lextrait.com/Vincent/implementations.html to http://www.lextrait.com/Vincent/implementations.html
• Added {{dead link}} tag to http://www.findarticles.com/p/articles/mi_m0CGN/is_n3341/ai_20211297

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 04:26, 24 May 2017 (UTC)

FWIW checked=true, a long page with a huge table, where one row claims that OpenGL can be done in C, or similar. –84.46.53.102 (talk) 21:51, 22 June 2019 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on OpenGL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20150402105758/https://downloadcenter.intel.com/download/24785 to https://downloadcenter.intel.com/download/24785

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:30, 26 July 2017 (UTC)

Checked=true, but I doubt that the links on the archived Intel page still work. –84.46.53.102 (talk) 21:45, 22 June 2019 (UTC)

Second reference/citation now redirects to an unrelated page.

For one, the page now leads to something irrelevant, and secondly, SGI went bankrupt so any archive of said page is probably outdated now. Should we link to this page instead? Lvivtotoro (talk) 12:00, 22 September 2019 (UTC)

OpenGL Language Version 4.6.7 in july 2019, actual 4.6 API in october 2019

See https://www.khronos.org/registry/OpenGL/index_gl.php — Preceding unsigned comment added by 2A02:6D40:3485:2101:388D:CF6A:5BC5:17CB (talk) 19:53, 8 December 2019 (UTC)

Is OpenGL really inactive?

I noticed that the template for the Khronos Group standards listed OpenGL as being "inactive". I was aware that development on it had generally stagnated since the creation of Vulkan, but I didn't think that it was inactive—there are, after all, plenty of applications still using it. So is it truly inactive, or just dormant for a bit? 2600:1700:E4C0:9EA0:D1E1:35BF:9040:9E5B (talk) 22:03, 25 March 2022 (UTC)

MoltenVK is no longer "proprietary"

MoltenVK is now open-source (and has been for some time) at [3]KhronosGroup/MoltenVK

it is now maintained by the Khronos Group Eteled286 (talk) 21:39, 21 September 2022 (UTC)

Ok, but the statement in the article is about MoltenGL which is proprietary. MrOllie (talk) 22:41, 21 September 2022 (UTC)

Oh, I just re-read the sentence and it makes sense, but IMO "authors of MoltenVK" should be changed to "original authors of MoltenVK" - or maybe not, idk Eteled286 (talk) 20:14, 29 September 2022 (UTC)