Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Mesa Support For OpenGL 3.1 Core Contexts

  1. #1
    Join Date
    Jan 2007
    Posts
    14,357

    Default 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...

    http://www.phoronix.com/vr.php?view=MTE1NjQ

  2. #2
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    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. :/

  3. #3
    Join Date
    Dec 2011
    Posts
    2,006

    Default Thanks!

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

  4. #4
    Join Date
    Jan 2009
    Posts
    1,591

    Default

    Who owns this patent now??

  5. #5
    Join Date
    Jul 2012
    Posts
    13

    Default Such a Big news

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

  6. #6
    Join Date
    Jul 2012
    Posts
    5

    Default

    Quote 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.

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,993

    Default

    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.

  8. #8
    Join Date
    Jan 2007
    Posts
    418

    Default

    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.

  9. #9
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote 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.

  10. #10
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote 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).

Posting Permissions

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