Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

Thread: OpenGL 4.2 Specification Published With GLSL 4.20

  1. #21
    Join Date
    Jun 2010
    Posts
    227

    Default

    Quote Originally Posted by allquixotic View Post
    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?

  2. #22
    Join Date
    Sep 2010
    Posts
    453

    Default

    Quote Originally Posted by Yfrwlf View Post
    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!

  3. #23

    Unhappy

    Quote Originally Posted by elanthis View Post
    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)?

  4. #24
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by plonoma View Post
    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.

  5. #25
    Join Date
    Sep 2010
    Posts
    453

    Default

    Quote Originally Posted by snogglethorpe View Post
    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.

  6. #26
    Join Date
    Aug 2007
    Posts
    30

    Default

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

  7. #27

    Default

    Quote Originally Posted by snogglethorpe View Post
    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%!

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •