Announcement

Collapse
No announcement yet.

Mesa Support For OpenGL 3.1 Core Contexts

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

  • Mesa Support For OpenGL 3.1 Core Contexts

    Phoronix: Mesa Support For OpenGL 3.1 Core Contexts

    Ian Romanick has published a set of 14 new patches today as he prepares support within Mesa for creating OpenGL 3.1 core contexts, as open-source OpenGL 3.1 support finally inches further...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Unless the patent issue is resolved, this is basically 100% worthless until late 2026.

    I really hope the patent issue gets resolved. I really hope _all_ software patents get resolved, permanently. I suspect there's almost zero chance either of those will happen, unfortunately. :/

    Comment


    • #3
      Thanks!

      Great job Ian Romanick! Thanks!
      Hope to see OpenGL 3.2 support soon!

      Comment


      • #4
        Who owns this patent now??

        Comment


        • #5
          Such a Big news

          Such a big news yet nobody comments on this.
          Great work man.

          Comment


          • #6
            Originally posted by elanthis View Post
            Unless the patent issue is resolved, this is basically 100% worthless until late 2026.

            I really hope the patent issue gets resolved. I really hope _all_ software patents get resolved, permanently. I suspect there's almost zero chance either of those will happen, unfortunately. :/
            What patent filed in 2006 is problematic? SGI's fp texture patent (6650327) should go away in 2020 and the S3TC one (5956431) in 2017.

            OG.

            Comment


            • #7
              Meh. The "superior new way" of the core contexts is way more cumbersome to dev for.

              kthxbye, I'll stay on 2.1 and use the new stuff via extensions when it makes sense. Not always because forced to, because the more convenient interfaces get removed in core profiles.


              Forcing everyone to re-write passthrough shaders, really? More and more cumbersome loading code for various things? Even the GLSL syntax got worse in the recent releases, more verbose without any gain.

              Comment


              • #8
                Apalling that an 'open standard' depends on patented stuff. How is that an open standard? ClosedGL would have been a better name

                Then again, there's more tings thatuse 'open' when it reality they lie and just abuse the term really.

                Comment


                • #9
                  Originally posted by oliver View Post
                  Apalling that an 'open standard' depends on patented stuff. How is that an open standard?
                  Without those patented features, the API would be useless for a large subset of modern graphics techniques. The job of a hardware API is to (gasp!) interface to the hardware. If the hardware can't be interfaced with without a patent license then any and all attempts to build an API for it will be fucked without acquiring said license. Hardly the fault of the people in charge of any such API.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    Even the GLSL syntax got worse in the recent releases, more verbose without any gain.
                    Wow. You might be the first person I've ever heard actually think that fixing 3D Labs' screwed up GLSL linkage model (which is the only part that significantly changed with the syntax) is actually a step backward.

                    Of course there is _huge_ gain to the changes. Try writing an engine that can easily support 200 different materials (a.k.a., shaders) in a single scene with a unified deferred shading system, a complete particle system with artist-friendly editor, material editing GUI, artist-friendly effects system, multi-pass shader support, and the other usual stuff like GPU skinning and post-processing chains all while using GLSL's original linkage model. Hint: it don't work all too well. The only way you can make it work is by basically writing a replacement for GLSL and then source-retargetting that to GLSL. Which is what actual engines do, usually via Cg (a.k.a. HLSL) and a higher level preprocessor.

                    Granted, yes, the new syntax GLSL imposes for the new linkage model is absolutely completely awful, and whoever designed it should be stabbed with a rusty screwdriver. You're confusing the features themselves with Khronos' incompetence at API and language design, though. HLSL has worked in the same way as the newer GLSL releases for years (because that's how the hardware works, and that's why 3D Labs' model was so wrong), but it does so with a _significantly_ more readable and pleasant syntax. Of course, you can get all that nice syntax by just using Cg... which again, is what the industry generally does (outside of people on iOS/Android, barely anybody actually uses GLSL directly; and mobile is only an exception because Cg still doesn't freaking support GLSL ES).

                    Comment

                    Working...
                    X