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

Thread: After OpenGL 4.5, The Mesa OpenGL 4 Support Matrix

  1. #21
    Join Date
    May 2008
    Posts
    100

    Default

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

  2. #22
    Join Date
    Nov 2012
    Location
    France
    Posts
    618

    Default

    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?

  3. #23
    Join Date
    Jul 2013
    Posts
    341

    Default

    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.

  4. #24
    Join Date
    Jan 2013
    Location
    Poland
    Posts
    36

    Default

    Quote 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?
    http://cgit.freedesktop.org/mesa/mes...d58083e6917fd6
    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.

  5. #25
    Join Date
    Mar 2013
    Location
    Porto
    Posts
    268

    Default hm

    Quote 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

  6. #26
    Join Date
    Jul 2013
    Posts
    433

    Default

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

  7. #27
    Join Date
    Aug 2014
    Posts
    3

    Default

    Quote 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.
    http://mesa3d.org/faq.html#part1

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

  8. #28
    Join Date
    Aug 2014
    Posts
    12

    Default

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

Posting Permissions

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