We need a Campaign for OpenGL Patent Exemptions for OSS, namely Mesa, and Linux

[mirv]

Why can't the Khronos people be replaced with people willing to break ABI and really improve the spec to make it meet or beat DirectX? Shareholders do it to executives all the time in the business world. Why not here? Even if that did happen, it still wouldn't change the fact that software patents are there to block open source implementations.

Because Khronos is comprised of people (companies/groups) who make the hardware and implement the spec.

[Prescience500]

Why can't the Khronos people be replaced with people willing to break ABI and really improve the spec to make it meet or beat DirectX? Shareholders do it to executives all the time in the business world. Why not here? Even if that did happen, it still wouldn't change the fact that software patents are there to block open source implementations.

[crazycheese]

The whole mess with OpenGL 2 and 3 has to do with one company in Khronos (at the time) who tried to keep everything as it was. Turned down every suggestion.
That company was Microsoft. In 2006 or something around that year Microsoft left Khronos. Then work begun on OpenGL 3.1 and so on. Which went much quicker without Microsoft interference.

Somehow Im not surprised.

When I quit using microsoft software, my productivity boosted as well.

[plonoma]

[QUOTE]

Again, OSX, Linux, mobile devices (apart from Microsofts offerings) rely on OpenGL, if it was so bad as you describe it we would have seen a cross platform replacement by now.
[/QUOTE=XorEaxEax;194830]

No we wouldn't.
Ten years ago we also didn't have a function for saying we don't want our application using the graphic card. Only Last year they introduced a decent function that doesn't lock the whole card! And that's in windows.

As for Mesa's test suite. Don't forget that mesa is actually a third party in OpenGL. There should be an official test suite. Making one is quite a problem because C and C++. Most widely used languages with OpenGL? Don't have a standardized way for doing tests. The language D would be better for this. If it had enough tools to work with just as much as C and C++ ide's exist.

[plonoma]

The whole mess with OpenGL 2 and 3 has to do with one company in Khronos (at the time) who tried to keep everything as it was. Turned down every suggestion.
That company was Microsoft. In 2006 or something around that year Microsoft left Khronos. Then work begun on OpenGL 3.1 and so on. Which went much quicker without Microsoft interference.

[mirv]

I'll throw in some more comments here:
The core OpenGL functionality of the big players (nvidia and ati/amd) is stable. It has to be. Most of the bugs that occur with desktop use are with handling outside the core (typically some X integration). By core of course, I mean defined spec. Both companies have had outlying issues on occasion, but they're about as rare as D3D issues now.

From an API perspective, workstation graphics care a bit more about the geometry processing than shaders, if I recall correctly, and there are a few tweaks aimed at that.

Driver quality aside, opengl and d3d are supposedly quite similar in terms of functionality these days (I'll repeat my disclaimer: I have no intention of doing anything that can't run on windows/linux/mac, so it's OpenGL or software rendering for me).

I'm also going to note something else: neither one has hardware accelerated multi-threaded rendering. D3D does not have it - it's done in software. OpenGL doesn't define it, which is perhaps not good for gaming, but power users (programmers) do have greater control if they want to create their own. Always a tradeoff.

I can't comment on OpenGL ES btw, as I've nothing to play around on with that (not properly anyway).

All this is pointless banter anyway - OpenGL is the only viable option on Linux, unless you want software rendering. D3D is not going to happen, and unless you can start doing wonderful things with Fusion systems (quite the possibility, but again I haven't looked into programming with that architecture, though I'd like to one day) software rendering can't compete with hardware accelerated performance just yet.

[artivision]

First of all developers don't like API's like dx11 or ogl4. They want to get rid of them. They want direct access to hardware with a C-like language. If they do that, then their games will have much batter graphics. For example an 1teraflop vga with direct access will give performance like an 4teraflop vga with API!!! If that language is the famous openCL then they will gain universal access to all hardware, as this hardware has an openCL driver!!! OpenCL programming does not need compile for a specific cpu. Second, openGL now has openRL library (open ray-tracing library). http://www.caustic.com/products.php | http://3dradar.techradar.com/3d-tech...les-15-12-2010 So openGL is now better than directX. A ray-traced 3d image may be 5-10 times better than an only raster 3d image, at the same flops, or equal at only 1/5 of flops for example. See NPG with the next powerVR gpu and ray-tracing.

[XorEaxEax]

And movies are not rendered using OpenGL.

No, but their content is generated in apps powered by OpenGL, apps that require a great deal of performance since at the stage of conception the meshes are MASSES of raw polygons in order to allow for as flexible a workflow as possible.

So why are you throwing a royal hissy fit because someone dares to claim (along with thousands of other developers) that OpenGL doesn't work just peachy-keen for a use case other than your own pet one?

LOL, 'doesn't work just peachy-keen'? You are claiming that it's unuseable crap.

Write some code, Khronos! Write samples! Write tools! Write a test suite!

Khronos is as far as I know nothing but a consortium of industry players (including NVidia and ATI) who submits api suggestions for consideration/voting, as for an 'official' test suite that would be Mesa afaik.

I get that you don't understand software engineering, but get this: there is absolutely no damn excuse for Khronos' incompetence and negligence with how it's handling OpenGL, or the ARB's incompetence and negligence before it.

Oh, I've worked as a software engineer (or programmer, as it is usually called) for 8+ years, mainly c, c++ but also x86 assembly, scripting languages and some java (uurk!), although I must admit that I haven't worked in games or 3d for that matter (unless some patches to the Allegro game library ages ago count ) I'd say I'm pretty well versed in software development.

And you speak of Khronos again as if they were a single 'entity', they are not. It's a group of separate members agreeing on an api specification, which is then implemented separately in drivers.

OpenGL has been mishandled and left to rot by its caretakers over and over again throughout its history. This is why it's in such an awful state today, and why so many developers absolutely freaking hate using the API.

Again, OSX, Linux, mobile devices (apart from Microsofts offerings) rely on OpenGL, if it was so bad as you describe it we would have seen a cross platform replacement by now.

NVIDIA's drivers are the best. By a long shot. Everybody knows that. And they still have a ton of bugs that their Direct3D drivers don't have.

All these sweeping statements with nothing to back them up, please point me to some objective comparisons regarding bugs in NVidia OpenGL vs Direct3D drivers. Again I can only compare NVidia OpenGL drivers since the programs I use are for OpenGL (although I test many of them on both Linux and Windows and I've seen no difference in stability or general performance).

But your modeler app works, so screw everyone else, right?

Oh please, the ONLY thing working in OpenGL are the 3d applications that I've used... man I must be lucky, everything else running OpenGL out there must be using software rendering or some fairy dust or something, because it's just no f****** way OpenGL could be working, I mean all drivers except NVidia's (again lucky me) are just big piles of bugs, and the api is so terrible that no programmers could actually create anything in it anyway, I mean it's just so f****** bad.

[crazycheese]

You're attempting to ignore every other point in a (very weak) attempt to knock down my argument on a single facet.

elanthis, no one is ignoring you. You published lots of valuable info, thanks!

I don't think that knocking everything from the table and starting third API as OpenGL replacement is sane.

Nor is current situation any good. Support it means supporting something broken by design, and with bad owner. It is true that result is as good, as the inventor/owner is.

Developers seem to be FORCED to use DirectAPI. I wonder IF any microsoft people are involved in Khronos or who has brought it down by carrying out ill decisions leading to:
1) Evolution/Invention momentum loose
2) All patent crap
3) Absence of actually hearing what GPU/3D programmers have to SAY (which is actually how things are assembled in Linux!) instead of pushing decision from the top
4) Having or focusing on features that are currently required and demanded
5) Absence of quality control and certification
6) Absence of solid, discrete versioned API
7) Being unpredictable, badly documented and non-oversee-able

The API should also have broad recognition from start at same time maintaining open standards and cross-platform interoperability due to money charged for actual work instead of "implementation and ongoing milking"-model.

Some big entity should fork OpenGL and take the leadership, someone whos leadership is based on amount of positive drive.

[elanthis]

What so you say that the drivers are stable/efficient and featureful for 3d applications but somehow not for games?

What is so hard to believe about that statement?

You do realize that the way a 3D modeler's renderer is implemented and the way a video game's renderer is implemented are _totally freaking different_, right? Night and day.

And movies are not rendered using OpenGL. I've seen some recent-ish work on getting things like RasterMan/REYES running on the GPU, but that was actually using Direct3D 11 + DirectCompute, not OpenGL.

I have no loyalty for OpenGL, it works great for the software I use so yes I have no problems with it, but if something better came along which I could use instead then certainly I would use that. But there isn't anything better.

So why are you throwing a royal hissy fit because someone dares to claim (along with thousands of other developers) that OpenGL doesn't work just peachy-keen for a use case other than your own pet one?

Khronos can't affect the driver quality

YES THEY CAN!!

A specification that's nothing but text describing what the API should be is completely worthless. No major, successful industry specification is developed like that. It simply is not a successful model, period.

Write some code, Khronos! Write samples! Write tools! Write a test suite!

I get that you don't understand software engineering, but get this: there is absolutely no damn excuse for Khronos' incompetence and negligence with how it's handling OpenGL, or the ARB's incompetence and negligence before it.

This is old hat. Developers have been pissed off with the ARB since they swept 3D Labs' redesign of OpenGL under the rug, and then pissed off twice as much when Khronos reneged on the Long Peaks' OpenGL 3 redesign.

OpenGL has been mishandled and left to rot by its caretakers over and over again throughout its history. This is why it's in such an awful state today, and why so many developers absolutely freaking hate using the API.

and no I can't vouch for the quality of OpenGL drivers for cards I do not own, but for NVidia they are excellent from my quite extensive experience with 3d applications.

NVIDIA's drivers are the best. By a long shot. Everybody knows that. And they still have a ton of bugs that their Direct3D drivers don't have.

When you code against OpenGL, and your app misbehaves, you have to question every single time whether it's some crazy ass illogical driver bug or not. You're buiding a house on quicksand. It's a nightmare.

When you code against Direct3D, and your app misbehaves, you just debug your code to figure out what your likely obvious and simple mistake was, and then carry on. Regular application development stuff.

If your OS had hard-drive controllers that randomly corrupted data or stopped responding because you wrote a particular pattern of characters to a file, you'd call the entire system broken. If your OS had network drivers that randomly stopped accepting packets after you sent 37 AIM packets over the wire, you'd call the entire system broken. If your input drivers randomly returned nonsense keystrokes or button click events whenever your processor's FPU was instructed to add 7e23 and 2.34e2, you'd call the entire system broken.

If your OS has video drivers that randomly cause loops in shaders to execute only the first iteration of a constant eight-iteration loop containing more than three if statements and only if you happen to have more than 2 functions defined before the main function, you'd call the entire OS broken.

The first paragraph is silly hyperbole. The second paragraph is just one of many actual illogical sanity-breaking bugs that developers have to work around in actual up-to-date OpenGL drivers from one of the the big two GPU providers... but only on OpenGL.

So no, your generalistic 'OpenGL sucks' doesn't hold water. Buggy drivers are buggy drivers, doesn't matter if they are for OpenGL or DirectX.

You're attempting to ignore every other point in a (very weak) attempt to knock down my argument on a single facet.

OpenGL is a hard to use crufty state-machine C API originally designed for 1980's SGI hardware. OpenGL lags hardware capabilities, by years sometimes, and the extension system is most often used just to play catchup with D3D rather than being used for innovation like it used to be. OpenGL is poorly documented, and there simply are not any good tutorial or documents available on how to write a modern high-performance OpenGL renderer, because even NVIDIA's engineers use the API wrong in their sample code (because the API sucks and is hard to learn and hard to use). OpenGL has no test suite to help driver developers implement stable drivers, which would handily solve the excessively buggy driver problem. OpenGL literally cannot do several important things that Direct3D can do... at least one of which D3D has been able to do since freaking D3D 8 and is fundamental to using shaders efficiently and easily!

But your modeler app works, so screw everyone else, right?