Announcement

Collapse
No announcement yet.

After OpenGL 4.5, The Mesa OpenGL 4 Support Matrix

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

  • #21
    Originally posted by Luke_Wolf View Post
    You did not just report the state of affairs, you put a negative spin on it by focusing on the fact that it's not at the latest standard, and using statements like it being years behind, and you've done this each time you've done one of these articles as of late. Putting a positive spin on it would be showing how much progress has been made and putting a predictive outcome on when Mesa is likely to reach OpenGL 4.5 support. Simply reporting the facts would be to simply highlight the changes since the latest stable Mesa, with no predictive statements, and any commentary being on what are the big ticket items and which are the small jobs for what needs to be completed.
    I totally agree with you Luke_Wolf, Mesa/Intel/Gallium/Radeon/Nouveau have done a tremendous job and I don't think it's fair to keep their head under the water like that.
    What I feel, Michael, is that you simply copy/pasted the GL3.txt file without really reading it. Because when I look at it, I see that:
    • we're 3 functions behind to be GL 4.0 compliant.
    • we're 5 functions behind to be GL 4.1 compliant.
    • we're 6 functions behind to be GL 4.2 compliant.


    I expect to be 4.2 compliant pretty soon actually.
    For 4.3, 4.4 and 4.5 it's going to take a bit more, but work is already on its way for these versions.

    Comment


    • #22
      Until a few days ago, GL3.txt talked about support of various GLSL versions. But that particular text is gone now. Does it mean it's done, or are they hiding it?

      Comment


      • #23
        I am guessing once the new API is released a lot of the open source developers will just switch over, making the progress much slower at the open source OGL.

        Comment


        • #24
          Originally posted by Calinou View Post
          Until a few days ago, GL3.txt talked about support of various GLSL versions. But that particular text is gone now. Does it mean it's done, or are they hiding it?

          Listing the GLSL version as an individual component of a GL version,
          separate from the extensions isn't really right. The GLSL changes are
          (almost?) entirely comprised of changes listed in the extensions.

          Comment


          • #25
            hm

            Originally posted by Daktyl198 View Post
            Okay, could somebody PLEASE point me to an explanation of Mesa's part in modern Linux graphics?
            For example, how the fuck does Gallium interact with Mesa? It uses "State Trackers" for literally everything EXCEPT OpenGL? That, it passes over to MESA for translation? Wouldn't it be like, 100 times easier to just write an OpenGL state tracker for Gallium3D and leave Intel to deal with their own OpenGL shit? (Since they refuse to use Gallium apparently). The only drivers I really see benefiting from the MESA driver structure are older drivers that really can't change over (or are long dead) and some ARM or other out-of-the-way GPUs

            "Duplicating work is bad!" Yeah, but if it made it easier to catch up to OpenGL compliance (For AMD&NVidia&other Gallium users) AND ended up in faster OpenGL on Gallium drivers, why don't we do it?

            Again, I'm ignorant on this subject, so could somebody point me to a blog post about this or something?
            don't forget something, intel does almost all the work with new extensions, the other drivers use their work, without the help of Intel'd be still in opengl 2.1

            Comment


            • #26
              Originally posted by LoneVVolf View Post
              Look at http://mesa3d.org/sourcetree.html

              It makes clear gallium-3D is an integral PART of mesa, not a separate project.

              Afaik a typical linux graphical stack consists of these 3 parts :
              kernel
              mesa
              X

              X can be replaced by wayland and/or mir, but i don't know any alternative for mesa .
              Actually, the way that tree is laid out suggests Gallium is definitely separate from Mesa (given that Gallium isn't under the "Mesa" tree, but rather on the same level).
              If I am right, then for Intel it goes like this:
              Program (OpenGL) > Driver > Mesa > Driver > Kernel > Display Server
              And for AMD/NVidia/etc:
              Program (OpenGL) > Driver > Mesa > Gallium3D > Driver > Kernel > Display Server
              When it could go:
              Program (OpenGL) > Driver > Gallium3D > Driver > Kernel > Display Server
              If we just wrote an OpenGL State Tracker for G3D. But this is all assuming that writing (or converting the current Mesa code into) a state tracker is easier than continuing adding to the giant massive bulk that is "MESA"

              (and if I'm right, maybe we could also remove that second "Driver" step, and write a single "Gallium3D" kernel module that all G3D drivers use? or am I just being an idiot now?)

              Comment


              • #27
                Originally posted by Daktyl198 View Post
                Actually, the way that tree is laid out suggests Gallium is definitely separate from Mesa (given that Gallium isn't under the "Mesa" tree, but rather on the same level).
                I agree that tree is a bit confusing.

                My post should have been like this :

                Gallium is build from the Mesa 3D graphics library sourcecode, and afaict there is no way to build gallium separately.
                This indicates gallium is a part of mesa 3D, not a separate project.

                The mesa faq part 1, 1. High-level Questions and Answers has some useful info, including open alternatives for mesa.


                The rest of your post is out of my league, although i do get the impression the flow is more complicated then that.

                Comment


                • #28
                  Originally posted by LoneVVolf View Post

                  Afaik a typical linux graphical stack consists of these 3 parts :
                  kernel
                  mesa
                  X

                  X can be replaced by wayland and/or mir, but i don't know any alternative for mesa .

                  Maybe you could use DirectFB instead of Mesa I think it's suppsoed to be more light weight - for embedded stuff like TV's etc.

                  I really should pay more attention to graphics last time I tried playing games in Linux (Dota 2) my laptop was really buggy (textures missing etc) this is despite using an intel graphics card, which is supposed to have good support - Eventually I tracked the issue down - I was using softpipe instead of i965 for some reason - I think it was a SE Linux permission issue if I ran steam with elevated permissions it would correctly use i965 but running under standard user permissions it kept using softpipe. I found a fix online to chmod some of the entries in /dev but seems like a bit of a hack and you have to do it every time the computer rebooted.

                  I think the above issue is also why websites that use flash etc caused the cpu fan to spin like crazy because it was falling back to software rendering.

                  Using Fedora's package manager it was really difficult to work out what version of mesa I was using - what configuration options were setup etc. There were no warnings or anything emitted to tell me I was using software rendering I only found out by chance because I launched steam through a terminal window once and saw softpipe in the debug messages it emitted.

                  Comment

                  Working...
                  X