Announcement

Collapse
No announcement yet.

We're Now Up To OpenGL 4.1; Brings New Features

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

  • #21
    Actually the biggest responsibility here is on the game and application developers. If they decide that the applications don't run without each and every one of the new extensions, then people do have to buy new hardware to run it. If they design the games to be scalable and to work without the new and fancy stuff, no problem for the people who want to upgrade systems slower either. Then again, this implies more work for application developers.
    But I wouldn't really blame standardization bodies for making new hardware necessary. If it wasn't for them, application developers would just use vendor-specific extensions always and you'd have to have a graphics accelerator chip from a specific vendor in your computer for things to run.

    Comment


    • #22
      Tutorials for new driver hackers

      Originally posted by agd5f View Post
      Also, keep in mind that mesa and the open source drivers are open source so anyone that's interested in adding support for newer functionality is free to contribute. The the hardware and software specs are available, the only thing missing is more manpower.
      I agree with this very much. but I also see a problem that is probably a reason why there is lack of manpower. There is no good documentation for those who would like to start hacking on drivers. Some kind of a tutorial to orient newcomers so open source driver developer which would help them orient. Like how the card works, where does one start if she wants to add support for one openGL extension. i have this feeling that the whole graphics stack in Linux is very complex and confusing and there is nothing to gently introduce a new contributor to all this.

      Comment


      • #23
        Well... Modern systems and stacks just *are* complex, and it's impossible to overcome this. But I agree with you in terms of documentation. There are some bits of it here and there, but some of them is outdated, etc.

        I have one month of holiday left, and I wanted to contribute a FOSS project during this time. But I don't know how to start... It was simple to add one feature to KHTML, but that whole stack (linux kernel + drm + libdrm + ddx + mesa, including g3d, drivers, state trackers...) is a bit complicated, and doing anything *major* in terms of OpenGL 3.x support (like UBO/TBO) will require contributions to almost whole stack (that is my assumption).

        Maybe I should spend a day or two (or ten) reading source

        Comment


        • #24
          I just skipped this entire thread (mostly) and like to say:
          1. Awesome. Let OpenGL slaughter DirectX because it was about to die and I am not kidding.
          2. Don't hate on OpenGL simply because Mesa is heavily understaffed. Don't hate Mesa either for trying to keep up, no matter what.
          3. Gallium, in a working state, can handle everything. The 90's called and took fixed function cards away already.
          4. Almost no-one implemented Direct3D 10 and 11, let alone without d3d 9 fallback anyway, so OpenGL won't either. Plenty of time to catch up.
          5. The OpenGL revision train won't be running at full speed for long anymore.

          Now grab a beer/smoke/icecream and chill a little.

          Comment


          • #25
            Originally posted by Wielkie G View Post
            (linux kernel + drm + libdrm + ddx + mesa, including g3d, drivers, state trackers...) is a bit complicated, and doing anything *major* in terms of OpenGL 3.x support (like UBO/TBO) will require contributions to almost whole stack (that is my assumption)
            I suspect just focusing on the userspace implementation inside Gallium3D would already go a long way.

            Comment


            • #26
              Originally posted by jrch2k8 View Post
              i agree that apps have to keep a moderated adoption rate at least until mesa do some catch up but khronos cant just slow down cuz that will efectively kill OpenGL.
              Yes. That is very true.

              It is also called the "Red Queen Hypothesis" - you must run in order to stand still.

              With DX10 and DX11 here since long, the programs (games etc) which have been in development for three or four years are finally coming out in force.

              So, for OpenGL to be relevant, they must keep the pace of MS, at least. "Unfortunately", as the gaming industry has grown to be gigantic, it really does matter. All graphic cards are designed together with MS (quite possibly with Xbox in mind 1st), which has given MS a head start for a decade or so.

              Sad but true.

              Comment


              • #27
                I'm happy to see OpenGL moving along at a brisk pace. It sucks to see the open source stack fall further and further behind but Khronos can't sit on their hands and wait for the open source stack to catch up to the standard. Microsoft ain't going to stop and wait so Open GL needs to keep up with feature parity (in a perfect world maybe even come out with features first like it was years ago), otherwise OpenGL will fall further and further behind and even developers super friendly to OpenGL like id may have to turn to DX exclusively and shun OpenGL.

                Comment


                • #28
                  For the record, I don't think the open source stack is falling further and further behind unless you interpret the OpenGL version numbers as being directly proportional to the complexity of the implementation. GL 4.0 is not twice as hard as GL 2.0. As others have said, the jump from GL 4.0 to GL 4.1 is a tweak, not a wrenching change.

                  The entire graphics stack had to be revamped in order to get to GL 2.0 (rebuilding around a kernel memory manager, along with the associated KMS work, and making Gallium3D production-ready) but AFAIK that effort ("two years gone from everyone's life" ) should not have to be done again in the next few years.
                  Test signature

                  Comment


                  • #29
                    Originally posted by Tsiolkovsky View Post
                    I agree with this very much. but I also see a problem that is probably a reason why there is lack of manpower. There is no good documentation for those who would like to start hacking on drivers. Some kind of a tutorial to orient newcomers so open source driver developer which would help them orient. Like how the card works, where does one start if she wants to add support for one openGL extension. i have this feeling that the whole graphics stack in Linux is very complex and confusing and there is nothing to gently introduce a new contributor to all this.
                    Programming a GPU is no different from programming in OpenGL. Instead of calling e.g. glBlendFunc, you set the corresponding register (such a register usually contains the blend enable bit, the blend func, and the blend equation). Shaders are not a big deal either, you just use something like ARB_fragment_program in a binary representation. Of course, before joining any project, you need to know something about its code, so just read the code you are interested in, and ask questions. That's all.

                    I do not think the Linux graphics stack is complex, it is just another project a skilled programmer may come across and jump in (or not...).

                    Originally posted by Wielkie G View Post
                    I have one month of holiday left, and I wanted to contribute a FOSS project during this time. But I don't know how to start... It was simple to add one feature to KHTML, but that whole stack (linux kernel + drm + libdrm + ddx + mesa, including g3d, drivers, state trackers...) is a bit complicated, and doing anything *major* in terms of OpenGL 3.x support (like UBO/TBO) will require contributions to almost whole stack (that is my assumption).
                    Did you have to know whole KDE before contributing to KHTML? No you didn't. You don't need to know kernel DRM to be able to contribute to a driver (you don't even need to know whole Mesa, not even a fifth). Sometimes you just know the few source files you work with, ignoring everything else. Code reviews ensure that you commit good stuff, especially when touching someone else's code. Complexity is not an excuse, lack of time or motivation is.

                    BTW Mesa supports a lot of GL 3.x extensions including geometry shaders, just not all of them to be able to bump the GL version.

                    Comment


                    • #30
                      Originally posted by marek View Post
                      Did you have to know whole KDE before contributing to KHTML? No you didn't. You don't need to know kernel DRM to be able to contribute to a driver (you don't even need to know whole Mesa, not even a fifth). Sometimes you just know the few source files you work with, ignoring everything else. Code reviews ensure that you commit good stuff, especially when touching someone else's code. Complexity is not an excuse, lack of time or motivation is.
                      But it was probably a lot easier for him to figure out where and how to implement his feature. I agree that lack of time and motivation is most of it. A lack of time is certainly the main thing holding me back, but if I had an idea of how all the different parts of the graphical stack fit together, then perhaps I could make some small contributions here and there.

                      Comment

                      Working...
                      X