OpenGL Spec Now Controlled by Khronos Group
99BottlesOfBeerInMyF writes "According to a recent press release, the OpenGL Architecture Review Board has voted to transfer control of the OpenGL API standard to the Khronos Group, an industry working group that seems mostly known for its focus on mobile applications. Apple Computer has also just joined the group, presumably because of their interest in OpenGL for the OS X platform. I wonder what affect, if any, this will have upon the future development of the OpenGL standard."
Well, I'm sure it will benefit Apple a lot and hardly anyone else at all. (See KHMTL and Safari and Konqueror)
*Fortitudo, aequitas, fidelitas.*
Jesus fucking GOD how hard is it?
Affect == verb. "I am affecting you with my fist in your fat fucking face".
Effect == noun "Blood and broken bones were amongst the effects of my fist in your fat fucking face."
EXCEPT WHERE
Affect == Noun meaning EMOTION.
I can't believe I saw this and thought we were talking about Klingons until my brain caught up.
I can't make up my mind what affect it will have ...
Anything that helps OpenGL and provides drivers for it will be welcome. May it prod developers to write more OpenGL games (mainly) and thus make porting easier.
The cesspool just got a check and balance.
I wonder what affect, if any, this will have upon the future development of the OpenGL standard.
Well reading TFA and not finding Microsoft on either their promoters page or their contributors page I'm cautiously optimistic.
** affect? effect? I can never keep this one straight either.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
If you look at the list of Members you will also spot Panasonic, Toshiba, Softimage, NCSoft and alot of other heavy hitters.
The fact that Google and Apple are involved gives me hope that people will start making applications for Linux and Macs soon. Also, since DirectX 10 is only available for Vista, this may be the prime time for OpenGL to start stealing some market share.
This is my sig. There are many like it but this one is mine.
If this doesn't come out favorably, don't blame me!
I voted for Kodos.
Small potatoes make the steak look bigger.
Part of the reason Direct3D took off (aside from Microsoft's market influence) is that the ARB worked too damn slow and caused OpenGL to lag behind in terms of capability. If Khronos can make decisions faster such that OpenGL can keep feature parity with (or even get ahead of) Direct3D, it'll be great!
It would also probably help if they form close ties with the people making OpenAL, SDL, etc. so that there can be a big, open, complete solution to compete with the whole of DirectX.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Sony is also a member of the consortium, and is providing the API suite as part of the PS3 development kit.
Whether Apple contributes back to Free Software isn't really relevant here, and it's been beaten to death in other threads already. Could we please save it for the next KHTML article, at least?!
Besides, the more relevant thing regarding Apple is their behavior regarding other standards (as opposed to software implementations), such as USB, WebDAV, ZeroConf (aka Rendesvous, Bonjour), etc.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Khronos *already* handled most OpenGL related specs, like OpenGL ES.
On the negative side, this probably means that yes, SGI is going to be asset-stripped and wound up in short order. One must remember that the writing was on the wall a long time ago. Like CBM before them, Microsoft placed a "mole" in an executive position to wreak havoc, and SGI never really recovered from that period of moronic rebranding and windows NT workstations.
I did a little more looking after submitting this article and while I was not familiar with the Khronos group's work aside from mobile applications, it seems they are also responsible for the COLLADA standard Sony is promoting for open exchange of graphics/models primarily for video games. Perhaps with OpenGL, COLLADA, and some multimedia standards all under the same roof, we'll see development directed to be a better alternative to OpenGL aimed at multiple platforms (Windows, PS3, Mac, and Nintendo?) to offset the threat of MS's DirectX development aimed at Windows and Xbox simultaneously.
That's another powerful force with DirectX is that MS goes and talks with people like nVidia and ATi and finds out what they want out of an API. So not only is DX updated frequently, but it gets the updates that the companies want generally.
... Because this is a direct competitor to DirectX.
Although Microsoft has not been openly hostile. They distribute OpenGL with Windows. And although there are concerns that they are "crippling" the implementation they are shipping with Vista (of which I, personally, am skeptical), hardware vendors ATI and nVidia will be shipping the latest versions with their cards.
can also mean to bring into existence.
Please, for the good of Humanity, vote Obama.
Hopefully this will mean there will be continued improvements to OpenGL, especially to keep up with competing microsoft products. OpenGL should provide cross platform compatability so these apps can run with few modifications on many platforms. Microsoft unfortunately, just cant have this and has been pushing its own technologies and neglecting OpenGL, which is a move designed to lock software onto the windows platform. Microsoft of course cannot tolerate competitition and cohabitating in the marketplace with others, it has to have it all for itself and will use anti-competitive tactics to prevent compatability between different OSs.
OpenGL has been stagnate for quite some time. Most of the newer features of 3D cards have only been accessible with their horrible extensions interface. Well, it's not horrible, but it's not ideal either. At a minimum, better support for pixel shaders (nearly a decade old feature) is much desired. Better support for NURBS & subdivision surfaces (without using evaluators) would rock. I doubt that things like this are on the agenda.
OpenGL, IMHO, has no place on mobile phones... not yet anyway. Poor Java stacks, pathetic amounts of RAM, and CPU's slower than my TI-82 calculator make phones a questionable 3D platform. How on earth can OpenGL grow if it always has to support the lowest common denominator.
I'd hate to see the focus change toward embedded systems and not have enough energy dedicated toward advancing desktop development, where OpenGL has a very important role. Outside of DirectX, it's the only game in town... especially on the Mac & Linux.
I write all of my 3D apps on top of OpenGL, so this decision is very important to me. I like that OpenGL will finally get some much needed attention, I just hope it's the kind that benefits me... not just teenagers and their cell phones.
Now you wil have to be a member to even see the standard. Even more $ to be certified.
---- Booth was a patriot ----
I saw a story recently that seemed like SGI was considering OpenGL to be one of it's few remaining pieces of IP that it could sell off. I'm not sure how true that was (centainly they own various patents which are licensed to OpenGL implementors), but I expect this is a move to try to get it out of the car wreck that is going to be SGI soon.
A shame it has to be done, but probably a good thing.
My money is on nVidia buying up the IP once SGI is gone (ala 3Dfx)
OpenGL was traditionally aimed at enterprises and workstations. There you need a stable platform. So new features tend to get added slowly. On the other hand, DirectX is aimed towards the gaming market. Here the pace of development is hectic. The pace of development of DirectX also supports that. New features get added very fast. Microsoft being a single entity can also introduce changes much faster than a board controlled OpenGL can. The problem with OpenGL is that it is now trying to do what DirectX does. But it was never intended to be an API for games, or to be changed frequently. It is becoming something in the middle, neither here nor there,evolving too slowly for games and too fast for workstations. Maybe the two just need to diverge, with OpenGL returning to what it was intended for - enterprise apps, while leaving DirectX to cater to the games market.
http://www.vcnet.com/bms/features/3d.html
I haven't read it, but it looks basically the same as the stuff I've read before on how Microsoft crushed OpenGL, even though DirectX was much worse at the time.
!. Direct3D vs OpenGL:
Doesn't realy matter, for a couple reasons:
Only games are written using Direct3D/DirectX. It is very rarely used for anything beyond that. If given a choice no developer would ever use Direct3d for anything.. but if your making games for technically challenged people and your target platform is Windows then writing it to use Direct3D/directX makes more sense since it's more likely to work well in Windows.
All the major gaming engines already run on Linux. They already run using either OpenGL or Direct3D.. All except HL2/Steam stuff.
The reason Linux doesn't have more games isn't because of DirectX. It's because of lack of ease of use for OpenGL acceleration and market share.
Also DirectX/Direct3d is tied directly to the hardware. If your card doesn't support DirectX 9 your not going to be able to run DirectX 9 application.
For OpenGL it doesn't work that way. It's a programming API that can be accelerated. If you have a card that was designed to accelerate OpenGL 1.x you can still run OpenGL 2.x. It just won't all be hardware accelerated.
If your programming a 3d application and it's not a game and your not Microsoft.. Then your using OpenGL or OpenGL-based system. Period, end of story.
2. OpenGL ARB is 'Advanced Review Board'. They create a set of extensions to the current OpenGL standard to create proven/established OpenGL-related stuff that they can then wrap up together and place into the next generation OpenGL standard.
This is were all that extra stuff goes that people say that OpenGL lacks and DirectX has. OpenGL has a much more formal review system then DirectX/3D has. It needs to be carefull as any standard they create will need to be replicated by multiple people on multiple platforms and be sustainable into the forseeable future.
Microsoft and Direct3D/DirectX doesn't have to deal with that. They can abtrarially make decisions becasue they only have to worry about one platform.
3. Kronos group is partially responsable for the OpenGL-EGL extensions which allow for easier OpenGL based displays for embedded devices.
This is required for a stand-alone XGL-based X Windows server. Current AIGLX (Redhat) and XGLX (Novel) require you to either run a OpenGL-based X server on top of a normal X server (XGLX) or run OpenGL extensions to a normal X server (AIGLX).
This approach has numerious issues. Instead of making a clean break and going with pure OpenGL system your dealing with multiple legacy drivers that can only do a fraction of what OpenGL can do in addition to OpenGL acceleration drivers.
To put it another way.. The current driver model for X is broken. Right now we have 2-3 drivers acting on the same video card at the same time and they need to share resources. These drivers come from different vendors. This is technically difficult and doesn't lead to good acceleration or performance.
Another point:
Legacy 2D X drivers (EXA, XAA) can only provide 2D acceleration.
OpenGL 3d drivers can provide 2D AND 3D acceleration.
OpenGL 3d drivers can provide faster 2D acceleration then what the legacy 2D drivers can do. (due to the nature of the hardware GPU, not so much the drivers)
Having 2D and 3D drivers at the same time makes things much more complecated then just having 3D that can do everything.
3D acceleration is a hard requirement for a modern desktop.
So obviously having OpenGL-based X server is the way to go. And stuff like GLITZ (Xrender replacement) and other things means we can move to a pure OpenGL X server and still keep binary compatability. It's quite a acheivement.
Now the reason we cna't have a pure OpenGL-based display yet is because OpenGL lacks the API hooks to allow you to control the display and other items like that. There is nothing in OpenGL that says "Set the monitor at this resolution". That has to be handled by other stuff.
Kronos had to solve this same exact problem for it's embedded OpenGL display stuff. So they created the OpenGL-EG
I wonder how the growing pressures of the mobile market will be on the OpenGL framework, especially with Khronos at the reins. Perhaps there will be more emphasis on procedural methods (to deal with the small VRAM sizes of mobile chips), or better resource usage for power conservation?
...they've at least promoted programmable shaders to core features:
o n/
http://www.opengl.org/documentation/current_versi
I voted for Kang
insert inflammatory anti-microsoft comment here
Jesus fucking GOD how hard is it?
It amazes me that you have such a grasp of the use of "affect" and "effect" but don't seem to grasp that the word "fucking" should only be used as a verb or adverb and not an adjective. Unless your really meant to express that Jesus is copulating with God, which to answer your question, would seem to be pretty hard to do.
I agree -- four days is a long time! Luckily, my girlfriend will be back from out-of-town thursday...
/posted without karma or subscriber bonus
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
fucking Pronunciation Key (fkng) Vulgar Slang
adv. & adj.
Used as an intensive.
>> but if your making games
>> your not going to be able to run DirectX 9
>> If your programming a 3d
Dude, your is actually spelt you're.
I hear Zanshin is getting ready to release his Glide Wrapper for GlQuake
Change is certain; progress is not obligatory.
Jesus fucking GOD how hard is it?
Depends on Jesus' relationship with His Father, I'd say.
Defining Statistics and Social Research
Besides the spelling gaffe (your is the possessive of you, you're is a contraction of "you are"), this statement is not 100% correct. DirectX/Direct3D developers can mandate that certain API features are handled in hardware in order for the application to run, but they can just as easily allow DirectX to emulate in software what is not implemented in hardware. It's just that, for performance and usability reasons, most game developers don't want to allow DirectX to let the CPU handle certain things. So really, the practical difference between DirectX and OpenGL here is nil.
Since OpenGL is used for much more than just games, and since it's not as tightly tied to hardware specifications, it is more likely that OpenGL applications will tolerate missing hardware acceleration for some features. Having said that, I know there's a mechanism for programmatically determining which extensions an OpenGL implementation supports; what I don't know is whether you can easily detect if a particular feature is hardware accelerated or not. (I suspect the answer is yes, since there are still game developers out there who write to OpenGL.)
Actually, ARB stands for "Architecture Review Board." But the rest of what you said about the ARB is pretty accurate.
(1)Ironically, you yourself appear to "not know a whole lot." There are several reasons that developers use D3D over OpenGL. Personally, if I need cross platform, for example Sense8's WorldToolKit back when I used to work there, I used OpenGL. If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32. There are other reasons to prefer D3D over OpenGL but they are somewhat subjective (i.e. some people absolutely detest the extensions mechanism in OpenGL for example while others don't really care.) Some people like to write simpler code to support multiple rendering paths, et cetera. There are subjective reasons to use OpenGL as well, but this is unimportant, what is important is pointing out that "If given a choice no developer would ever use Direct3d for anything" is a ridiculous and biased statement. Also, if your hardware doesn't support OpenGL 2.0, and your application uses OpenGL 2.0, your application isn't going to run either, so the statements:
"Also DirectX/Direct3d is tied directly to the hardware. If your card doesn't support DirectX 9 your not going to be able to run DirectX 9 application. For OpenGL it doesn't work that way. It's a programming API that can be accelerated. If you have a card that was designed to accelerate OpenGL 1.x you can still run OpenGL 2.x. It just won't all be hardware accelerated."
This is VERY misleading. Presuming scenario 1 where the developer (for either D3D or OpenGL) has coded a support for only a particular version of the API, neither API will run partially in software if the driver does not support that level of the API. D3D9 will not run in software unless you're going to use a debugging rasterizer (highly unlikely), and OpenGL 2.0 WILL NOT RUN on a card with a 1.0, 1.1, 1.2, 1.4 driver. Now, there are some 1.4 drivers which were written so that people like myself could write 2.0 code and execute before the hardware was available, in which case the 2.0 distinctions were supported via software emulation, but this was for developers. You're confusing the ability of a specific OpenGL implementation supporting a specification to the maximum of its ability. For example, if a I have an OpenGL 1.4 driver but the card I'm running on doesn't have Hardware T&L, OpenGL's pipeline is quite capable of transparently deciding whether or not it should offload the lighting to the card or doing it in software. This is not the same as some future version of OpenGL running on my old OpenGL card with an old driver.
"If your programming a 3d application and it's not a game and your not Microsoft.. Then your using OpenGL or OpenGL-based system. Period, end of story" - I certainly hope you're not in a decision making capacity at your job (or that your job is doing something other than writing rendering code) because you're screwing your company over. Right tool for the right job, every time. It's a toolbox not a religious jihad.
(2)"OpenGL has a much more formal review system then DirectX/3D has" - No it doesn't. Crimony. Do you know what the specification process for DirectX is? You can say they're different, but it certainly isn't less "formal." You could say it is less open, but that's because it isn't an open API.
Loading...
Ok, then a better way to word it would be: HL2/Steam stuff only runs on Win32 (Wine is a Win32/etc layer for linux).
Microsoft's DirectX/Direct3d implementation (the official one) is tied directly to the hardware. He never said it would be impossible to make an implementation that wasn't.
Because affect and effect are a long standing and obvious problem in the english language, I propose the word "uhfect"(yes, only one f is needed), to be used in any situation where either affect or effect were previously used, and the meaning to be derived from the use and context in the sentence.
FAQ
Q-Why?
A-Stasis sucks!
Q-Is this necessary?
A-Damn Straight!
Q-well, aren't you just mr. smarty pants joe helpful!
A-why thankyou! yes, yes I am! No probs! Always pleased to help my fellow nerds!
next up! there, their and they're to be universally replaced with THARE, becase that is by far the correct way to spell that letter combination by sound and normal english language rules
FAQ
Q-what is it with you and capital letters?
A-my typing sucks, the shift key is activated by your little finger, the weakest on your hand, and keyboard manufacturers haven't figured this out yet because they are RETARDS
Q-How would you fix that, Mr. Pants?
A-make the shift key be twice as high as the other keys and angled inward to the keyboard, and making that particular microswitch be more sensitive so the least little touch would activate it easily.
Q-man, that's simply amazing! Are you going to patent that and get rich?
A-No, I think patents are medieval, feel free to build one like that, I'll buy one from you
Q-do you have any more good ideas?
A-yes!
Q-well, uhh, what are they?
A-where's my plate of free chocolate chip cookies first? You think synapses fire on prana or something? So share, and share alike!
I work in a decision making capacity at my job, and I choose free software and open standards for purely pragmatic reasons, not 'religious jihad', as you so self-righteously put it. The real jihadists are those who obfuscate their code and otherwise keep their customers in the dark, leaving them little recourse but to serve the dweeb behind the curtain. So keep your mumbly self-interested pseudo politics to yourself, fanbois.
Typically, if an ARB or other extension is offered by the driver (VBO support, for example...), it's hardware accelerated- typically, the driver suppliers don't bother advertising things that don't have at least a little hardware boost backing them as it makes them look bad. Now, having said this, it doesn't mean that the boost is as much as it ought to be for the OS (i.e. the ATI drivers for their chipsets don't perform anywhere near as well as they ought to on Linux...) so it's still a mixed bag- but then, it was that way with DirectX too.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
If anything, Apple has more of a reason to seek out the destruction of Linux than Microsoft does, and Apple is already on record as backing the european software patent effort as a way to "compete against open source". Apple is no friend of Linux, so I would view their involvement the same as I would Microsoft's or Sun's.
I just saw The Incredibles again, and I suddenly get the weird feeling the new plans for OpenGL involve rocket-borne, city-ravaging Omnidroids...
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
You mix facts with opinion.
For example, your argument about the difference of piecemeal acceleartion in OpenGL versus presence or absence of capabilities in Direct X. This is known as the caps bits (or caps flags) argument. You present the factual part, then you skip over some of the intermediate steps and go straight to the (incorrect) conclusion that you can't run Direct X 9 games if you don't have a Direct X 9 card.
First of all, you can run Direct X 9 games on Direct X 8 cards as long as the games check to see if the card has the new Direct X 9 capabilities (using caps bits) before using them. If the card (or more accurately the driver) doesn't have them, it had better not try to use them or it will fail. The short version is that you can use Direct X 9 games on Direct X cards, they just won't look like Direct X 9 games because they won't have true displacement mapping or some stuff that the card doesn't offer.
This seems vastly different then OpenGL where OpenGL can do the new operations in software and thus you can use the new capabilities even if your card doesn't have them. The problem however is that the moment you use a capability that is emulated in software, the chances are it will be very slow. Draw any frame that uses the capability in over half the frame (like water using displacement mapping) and the frame rate will drop 10X. To a developer, this is death. Gamers will tolerate variable frame rates, but they won't tolerate their frame rate dropping from 60 to 6. The developer will have to avoid using the technique when it isn't present in hardware.
And that, in a nutshell, is the reason that it doesn't make any difference whether you use the OpenGL piecemeal acceleration model or the DirectX caps bits model. The developer still cannot use new techniques that aren't implemented in software. In either case they'll instead use some other technique that doesn't look as good but maintains their frame rate.
OpenGL's system is more academic. That means if you are making less frame-intensive programs (non games), you can render a still life with all the newest techniques regardless of how old your video card is, it'll just take a while. In that way, OpenGL is probably a little better for learners.
You also mix in a lot of opinion. Like that no developer would use Direct3D by choice. That's just ridiculous. Many developers would prefer OpenGL, but by no means all. Like all kinds of other things in life, some people like one option and some like another.
Other things like:
>OpenGL 3d drivers can provide 2D AND 3D acceleration.
Yes, that's true from an academic point of view. Many 2D operations can be represented in 3D. Not quite all though. Some operations require access to the current contents of the framebuffer during rasterization that are not possible with 3D acceleration. These things are done in 3D by compositing portions of the image into offscreen buffers and then recompositing them back to the screen. This isn't as fast as the equivalent 2D operations. Other things require information about the pixel registration of the patch compared to the display so they can do things like ClearType does. Finally, I don't know (I could be wrong on this) that it is currently possible to do prepress-type color matching (like Apple's ColorSync) in any current 3D system.
>OpenGL 3d drivers can provide faster 2D acceleration then what the legacy 2D drivers can do. (due to the nature of the hardware GPU, not so much the drivers)
That's patently untrue. If a 2D operation could be done in a faster way using the installed video hardware, the driver for the 2D card would use it. This includes by making use of 3D hardware.
>3D acceleration is a hard requirement for a modern desktop.
Not that I can tell. Anyone who only runs Excel may do no 3D at all, and any 3D they could do could even be done on the main processor instead of a GPU. Many Linux machines have no 3D acceleration at all and they seem to be considered modern desktops.
I don't see why OpenGL should take over the screen completely like DirectX does. Sure, make a standardized API to do it, but why add it to OpenGL?
http://lkml.org/lkml/2005/8/20/95
>If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32.
:0.0 and :0.1) and it works well, running OpenGL on both monitors, simultaneously. I suspect I can do it with a single xinerama-style X screen too, but have not tried. Is this insufficient? Why?
Why can't you use nvidia on linux with OpenGL? I do dual monitor (seperate X screens,
fnord.
Also except as in:
Effect == verb "Effect a change in your face"
verb [ trans. ] (often be effected) cause (something) to happen; bring about : nature always effected a cure | budget cuts that were quietly effected over four years.
Wow this is OT. Parent got modded Informative?
> Also, since DirectX 10 is only available for Vista, this may be the prime time
> for OpenGL to start stealing some market share.
Vista? You mean I have to wait until 2012? How ridiculous.
But GL? From the same corner whose greed and pretty squabbling let Unix die. "Let us become the operating system of the masses who will pay $20K per site."
Khronos group. Wasn't that a Kevin Sorbo movie?
BTW Why is it called OpenGL(R). Open(R)? C'mon!
If I need multi-monitor and/or multi-device hardware acceleration on anything other than an upper end SGI, like what I currently work on, I HAVE to use DirectX9/10 and Win32
Why is this? Does WGL not allow two device contexts (as well as multiple render contexts, one active at a time, with multiple threads per render context)?
BBH
Legacy 2D X drivers (EXA, XAA) can only provide 2D acceleration.
OpenGL 3d drivers can provide 2D AND 3D acceleration.
OpenGL 3d drivers can provide faster 2D acceleration then what the legacy 2D drivers can do. (due to the nature of the hardware GPU, not so much the drivers)
What about those cards for which there is no open source hw accelerated OpenGL driver? How fast is 2d rendered via the Mesa software renderer?
You can do some forms of multi-monitor on OpenGL, I didn't say you could not. I do it on my Ubuntu and SUSE systems. What you cannot do is multi-device with hardware accleration. Something necessary for many professional 3D products. As an example, I recently re-wrote an OpenGL client application that renders geographic locations in 3D in order to monitor real-time events from the 'engine side' of things.
It was re-written for two reasons, first because you couldn't currently have more than one geographic location behing shown at a particular time or even two views on the same location. This I could have kept using OpenGL for (which would have been nice.) The second reason was because our customers spend six figures or more (rarely 7 figures) on our enterprise system and as a result they end up with these hideously expensive client machines with ridiculous monitor configurations. I.e., 4 monitors connected to two PCIe cards not running in SLI/Crossfire mode. They want to be able to drag the client anywhere and not worry about whether or not the display freezes, or becomes unusable. My biggest gripe about OpenGL is that I cannot do multi-device HW Acceleration. I have written the ARB about it for the past 4 years. Ever since it was introduced in, iirc, DX7, I have wanted to see it in OpenGL. There are lots of reasons why it hasn't happened, and none of them have to do with Microsoft, but that's another story. Basically, "Applications which need features like that tend to be run on SGI which already has a mechanism for this" was what I got back early on. So, here I am needing to use DX9. Not a big deal because I know both APIs well, and don't really care subjectively about one over the other. OpenGL is more nostalgic for me, but DX9 is easy to use (unlike DX3, how I don't miss execute buffers) as well.
Now, for a short while, there was a driver hack for nVidia cards where you could have two nVidia cards of the EXACT same type in your machine and set this little driver level switch and the two cards could share the OpenGL context (thereby getting you multi-device acceleration) but this went away, iirc, a few years ago. I looked for it before re-writing our display client hoping that I could do less work, but to no avail.
I probably came off in the earlier article as anti-OpenGL but I'm not. I'm anti-FUD whether that's some idiot bashing *nix/nux, or some idiot bashing D3D or OpenGL.
Loading...
On Windows 2000 drivers it was because you could not have more than one hardware accelerated OpenGL context although you could have more than one context. It was sort of like "Yeah, you can have two ferraris, but one of them doesn't have an engine in it..."
There was an nVidia driver hack that existed for a while where you could have two identical cards in a system and they could 'share' an OpenGL context intelligently (I use that term very loosely here) and thereby give you hardware acceleration. This was when the ARB was supposedly reviewing a multi-device/head acceleration addition. Sadly they left it to the card vendors who, of course, spend 99% of their time on worrying about games and single monitor applications.
Loading...
I have no idea why this information isn't more readily understood by this crowd. I guess because it's more "slashdot-y" to complain MS is boning the OpenGL spec instead of the truth of the matter where they've said "we support DirectX, you want anything else, do it your own damn selves."
My goodness, a company not doing the heavy lifting for someone elses specification? How un-American! Look at it this way, with MS out of the way, maybe some real progress will be made in OpenGL implementations.
Nice theory, except that Microsoft is doing everything possible to make sure OpenGL runs very badly on Vista. On Vista you'll get two choices:
a) You can install an ICD for full OpenGL support but then the Aeroglass desktop disables itself.
b) You can keep Aeroglass but then OpenGL runs through an emulation layer and they've taken out all anything which might make it useful or go fast (shaders, VBOs, pbuffers, etc., etc.)
No sig today...
If porting OpenGL games to OS/X is easier because they have moved to x86 then OS/X x86 will take the home PC OS market from Vista. So, yes Apple should be very interested in OpenGL. Shifting the focus of OpenGL to include portable devices would only help spread adoption of the API. This, like Apples move to x86, is more good news.
Having to work for a living is the root of all evil.
What about cards with more advanced Ogl drivers like the Matrox P10 (the called it the Perelia or something) or Permedia2. Or, rather more to the point... Is this a WGL limitation or a driver limitation? I recall having a number of dual moniter Intergraph boxes (glint based I believe) that seemed to do accelerated OGL on both monitors. It is possible that they were using the SGI windows OGL implementation though.
BBH
Retail XP comes with OpenGL drivers. If for some reason your copy does not *cough* you have an illegitimate version *cough* get it here or through Windows Update.
Yes, and it is the responsibility of the Independant Hardware Vendor (IHV), not the Operating System Manufactuer to provide drivers. Microsoft is providing a basic level of functionality by providing an OpenGL interface via DirectX. IHV's ( nVidia, ATI ) will be supplying their own, lower level, most likely faster implementations with the hardware. This is very well explained on a number of websites, if you really cared... but no, just a microsoft basher. Microsoft is actually supplying a baseline API they really don't have to, since any decent IHV will supply an OpenGL implementation with their cards (as they already do).
I had RealiZm and Wildcat boards that did this but it was multi-head not multi-device and only two monitors. It was one 'pseudo desktop' and one context.
This and the ridiculous nature of the extension mechanism are the only two things I have against OGL. I prefer its C-like usage because I like to introduce my own OO based abstractions without having to contend with the inherent structural rigidities of the D3D approach (this is purely subjective though.)
The ARB was just sooooooo damn slow...
Loading...
Like I said, they have to make the checks in any case. Because they need to reduce the detail in order to maintain frame rates on older hardware.
Yes, there are very few or perhaps even no games that absolutely cannot be played on a DX8 card (really driver). Developers don't want to restrict their potential customer base to only people with the newest cards.
http://lkml.org/lkml/2005/8/20/95