OpenGL 4.2 Specification Published With GLSL 4.20

Quote:

---

Originally Posted by allquixotic

This is such a great idea. We should be able to use the low-level hardware access provided by Gallium3d to build a reference implementation of this nebulous new API as a G3D state tracker! Ideally the state tracker should be written with as little hardware-specific binding as possible, and version 1.0 should have the ability to reliably report on hardware capabilities, software emulated capabilities, and completely unsupported capabilities, with a well-defined interface that doesn't involve any guesswork or string parsing, and uses an easy-to-understand object model with predictable semantics, common computing terminology used as much as possible (avoiding graphics domain-specific technical terms unless they are completely unavoidable), and with a design goal of minimizing the amount of work that would be required of an engine author. Almost to the point that actually "writing" a 3d engine on top of this API would be a mimicry of the API itself. Basically, you'd get a low-level 3d engine as a Gallium3d state tracker, but still with enough flexibility to do crazy things like portal effects and non-3d geometries.

The gallium3d infrastructure may not be the end-all of APIs, but it is the best hardware-independent 3d graphics API we have in the free world right now. And it's only on version 0.4; I am sure it will improve. But what's the use of improving it if the end-user API on top of it is the culprit of most of the semantic mismatch you see?

---

If this was done, wouldn't that mean that application developers would have to target the code for it and that the OpenGL apps not work with such drivers? Also, apps that use such graphics wouldn't work with OpenGL drivers, right?

Quote:

---

Originally Posted by Yfrwlf

It's called hosting the information in a country that isn't retarded.

---

When you allow people to download it, from countries where the patent is valid, on a non 'try it out to see if it works'-way.
They can still sue you!

Quote:

---

Originally Posted by elanthis

All of which are thing that Khronos can fix (and in fact, have put money into achieving for OpenGL ES already, which they clearly care far more about than regular OpenGL, likely due to the mobile market not already being dominated by a superior API).

---

From what I hear, the better handling of OGL ES is also due in part to the lack of stodgy legacy vendors that seem to have a lot of influence on the normal OpenGL process.

Weren't many of the ideas in OGL ES originally slated (in some form) for OpenGL 3.0, but then that plan shot down by vendor complaints (thus the semi-scandal when OGL 3.0 was released)?

Quote:

---

Originally Posted by plonoma

When you allow people to download it, from countries where the patent is valid, on a non 'try it out to see if it works'-way.
They can still sue you!

---

The country they were in would have to be the one to carry out the suing, so the goal is to live in (or at least host information in) countries which don't allow, at the very least, stupid math/art/programming patents.

Quote:

---

Originally Posted by snogglethorpe

From what I hear, the better handling of OGL ES is also due in part to the lack of stodgy legacy vendors that seem to have a lot of influence on the normal OpenGL process.

Weren't many of the ideas in OGL ES originally slated (in some form) for OpenGL 3.0, but then that plan shot down by vendor complaints (thus the semi-scandal when OGL 3.0 was released)?

---

There was one vendor in particular that shot about everything down.
That vendor has left Khronos and it's name is Microsoft (no kidding !!!).

This is why Khronos had such a crappy history.
And after the release of OpenGL 3.0 Microsoft left the group.
An from then khronos could release some decent versions.

But they should really find a system where they can drop old stuff.
e.g. using context creation calls with major version number in so you can change stuff without breaking old stuff and the drivers can support both.

Microsoft left in 2003 ( http://en.wikipedia.org/wiki/OpenGL_...e_Review_Board ), that was even before OpenGL 2.0...

Quote:

---

Originally Posted by snogglethorpe

From what I hear, the better handling of OGL ES is also due in part to the lack of stodgy legacy vendors that seem to have a lot of influence on the normal OpenGL process.

Weren't many of the ideas in OGL ES originally slated (in some form) for OpenGL 3.0, but then that plan shot down by vendor complaints (thus the semi-scandal when OGL 3.0 was released)?

---

agree 100%！
http://www.amovos.info/1.jpg http://www.amovos.info/2.jpg http://www.amovos.info/3.jpg