Announcement

Collapse
No announcement yet.

OpenGL 4.2 Specification Published With GLSL 4.20

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I hear a lot of moaning and whining about open source opengl support from non developers. But has anyone considered this: The open source drivers have a single standardised codebase. Once they are finished, OpenGL will work on every single alternative OS platform out there. Linux, AROS, FreeBSD, NetBSD, OpenBSD, even the HURD. All the platforms that are currently obscure/crap to do 3D on will have ATi/NVIDIA/Intel 3d graphics support. The Open Source drivers are moving in the right direction, and have the correct architecture under way. Criticism at this point is stupid and useless. It's like criticising someone for being unemployed when they have already filled out job applications and have done everything they can to get work. It's not like they can make a company get back to them sooner or hire them any quicker. By the same token it's not like Nouveau or the open Radeon projects can make their drivers fall out of the sky magically faster. The criticisms are silly. You want to complain about something? complain about desktop coherency, about the gnome3/unity debacle. Or about Linux not using cocoa like Apple does. Complaining about a real project with real developers busting their asses off to get the results people need is a silly pointless exercise.

    Comment


    • #17
      If you look at GL3.txt then you'll see most of 3.x has been completed, even some of 4.x has been started

      Comment


      • #18
        Originally posted by plonoma View Post
        The problem is that being sued is kinda hard to ignore.

        If you have a solution for that, it would really help if you would tell everyone your solution.

        Most patents aren't confined to the U.S.
        Many countries in Asia and Europe recognize U.S. patents.
        It's called hosting the information in a country that isn't retarded.

        Comment


        • #19
          Originally posted by DMJC View Post
          I hear a lot of moaning and whining about open source opengl support from non developers. But has anyone considered this: The open source drivers have a single standardised codebase. Once they are finished, OpenGL will work on every single alternative OS platform out there. Linux, AROS, FreeBSD, NetBSD, OpenBSD, even the HURD.
          Not really.

          First the DRM/KMS/GEM/TTM bits of the Linux kernel need to be ported over to each one of those kernels. That provides the functionality that Gallium3d (and every classic Mesa driver which can do OpenGL > 1.5) needs to function.

          The OpenGL implementation itself (Mesa) is shared, however.

          And that's quite a bit of work.

          Comment


          • #20
            Originally posted by smitty3268 View Post
            Where we might have better luck is with OpenGL ES. People actually care about that API and are using it heavily on the new "hot" market, and backwards compatibility isn't nearly as important in the phone market. Maybe we can get a GL ES 3 that changes the API into a more modern alternative, and then the desktop can follow along and start using that instead of the old GL.
            OpenGL ES Halti?

            Comment


            • #21
              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?

              Comment


              • #22
                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!

                Comment


                • #23
                  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)?

                  Comment


                  • #24
                    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.

                    Comment


                    • #25
                      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.

                      Comment


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

                        Comment


                        • #27
                          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%!

                          Comment

                          Working...
                          X