Announcement

Collapse
No announcement yet.

Intel Starts Landing Another OpenGL 4.3 Extension

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

  • Intel Starts Landing Another OpenGL 4.3 Extension

    Phoronix: Intel Starts Landing Another OpenGL 4.3 Extension

    Finally receiving some mainline treatment within Mesa this Sunday is the start of Chris Forbes' long work-in-progress patches concerning ARB_fragment_layer_viewport...

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

  • #2
    Sorry for my lack of knowlegde and understanding, but, will this benefit other drivers in any way? If so, how?

    Comment


    • #3
      Originally posted by CrvenaZvezda View Post
      Sorry for my lack of knowlegde and understanding, but, will this benefit other drivers in any way? If so, how?
      Although Intel's drivers are based on DRI instead of Gallium, their work can benefit core Mesa, adding the necessary infrastructure. The patches seem to only add code to advertise the extension -as Michael reported, Chris Forbes' work is only being introduced-, but they could benefit other drivers, specially if the GLSL compiler is shared between them.

      Comment


      • #4
        Originally posted by kalrish View Post
        Although Intel's drivers are based on DRI instead of Gallium, their work can benefit core Mesa, adding the necessary infrastructure. The patches seem to only add code to advertise the extension -as Michael reported, Chris Forbes' work is only being introduced-, but they could benefit other drivers, specially if the GLSL compiler is shared between them.
        I've always wondered, what exactly is Gallium? And how does it differ from Mesa?

        Comment


        • #5
          Originally posted by xeekei View Post
          I've always wondered, what exactly is Gallium? And how does it differ from Mesa?
          Mesa is an implementation of the OpenGL API against DRI and Gallium. Here is the path a GL call takes depending on your device:

          Intel: GL Call -> Mesa libGL -> DRI -> intel-dri -> i915
          AMD: GL Call -> Mesa libGL -> Gallium / DRI (depending on call) -> winsys on gallium -> ati-dri -> radeon

          You can read the wiki article here: https://en.wikipedia.org/wiki/Mesa_%...er_graphics%29

          If you want more clarification just ask.

          Comment


          • #6
            Originally posted by kalrish View Post
            Although Intel's drivers are based on DRI instead of Gallium, their work can benefit core Mesa, adding the necessary infrastructure. The patches seem to only add code to advertise the extension -as Michael reported, Chris Forbes' work is only being introduced-, but they could benefit other drivers, specially if the GLSL compiler is shared between them.
            Thanks!

            Comment


            • #7
              Originally posted by zanny View Post
              Mesa is an implementation of the OpenGL API against DRI and Gallium. Here is the path a GL call takes depending on your device:

              Intel: GL Call -> Mesa libGL -> DRI -> intel-dri -> i915
              AMD: GL Call -> Mesa libGL -> Gallium / DRI (depending on call) -> winsys on gallium -> ati-dri -> radeon

              You can read the wiki article here: https://en.wikipedia.org/wiki/Mesa_%...er_graphics%29

              If you want more clarification just ask.
              Then I guess I wonder what the difference between Gallium and DRI is. Are they competing? Or do they need each other?

              Comment


              • #8
                Where is GLSL 4.0 at?

                Originally posted by phoronix View Post
                These changes will end up in the Mesa 10.3 release later this summer, which could be known as Mesa 11.0 if there's OpenGL 4.0 compliance in time.
                Is there any word on the state of progress for GLSL 4.0?

                Comment


                • #9
                  Originally posted by zanny View Post
                  Mesa is an implementation of the OpenGL API against DRI and Gallium. Here is the path a GL call takes depending on your device:

                  Intel: GL Call -> Mesa libGL -> DRI -> intel-dri -> i915
                  AMD: GL Call -> Mesa libGL -> Gallium / DRI (depending on call) -> winsys on gallium -> ati-dri -> radeon

                  You can read the wiki article here: https://en.wikipedia.org/wiki/Mesa_%...er_graphics%29

                  If you want more clarification just ask.
                  Calling the non-Gallium path "DRI" is probably obsolete at best. I think the intent of the Wikipedia diagram was to say "this is the interface that was used back in the DRI 1 days", but that ("classic Mesa") interface is still used today even with DRI 3. DRI is a separate interface used with both Gallium and non-Gallium paths.

                  I think the usual terminology is along the lines of :

                  - the Mesa stack has two major sections -- HW independent common code and HW-dependent "hardware layer" code
                  - there are two hardware layer interfaces -- "classic Mesa" and "Gallium3D", each with a set of functions and an IR for shaders
                  - Intel uses an enhanced "classic Mesa", passing GLSL IR rather than Mesa IR to the HW layer
                  - radeon and nouveau use Gallium3D, passing TGSI to the HW layer (except OpenCL which passes LLVM IR instead of TGSI)
                  - older drivers use classic Mesa and Mesa IR
                  - all the drivers use various versions of DRI
                  - each of the hardware layer interfaces includes software renderers - <I forget name> for classic Mesa and softpipe / llvmpipe for Gallium3D

                  The above may not be 100% correct either (I imagine Intel has changed more than just IR but haven't paid attention) but I think it's closer anyways
                  Last edited by bridgman; 06-22-2014, 02:08 PM.

                  Comment


                  • #10
                    Stupid 5 minute limit. 5 minutes and 30 seconds would be much better

                    I think the software renderer for classic mesa HWL might be called swrast.

                    Comment


                    • #11
                      Originally posted by xeekei View Post
                      Then I guess I wonder what the difference between Gallium and DRI is. Are they competing? Or do they need each other?
                      I'm blindly walking on a swamp, but I recall hearing that Gallium turned all hardware-dependent API calls into an intermediate representation (IR) called TGSI; it allows every driver under its umbrella to support any API for which there exists a state tracker (a translator between API calls and TGSI). Thus, each driver either provides API interfaces by itself (as Intel's driver do) or plugs into Gallium and works with TGSI.

                      (Please, correct me if I am wrong.)

                      bridgman's answer, however, holds more truth than any I could give you.

                      Comment


                      • #12
                        Originally posted by kalrish View Post
                        I'm blindly walking on a swamp, but I recall hearing that Gallium turned all hardware-dependent API calls into an intermediate representation (IR) called TGSI; it allows every driver under its umbrella to support any API for which there exists a state tracker (a translator between API calls and TGSI). Thus, each driver either provides API interfaces by itself (as Intel's driver do) or plugs into Gallium and works with TGSI.
                        Yep. One of the confusing things was that when Gallium3D was introduced there was obviously discussion and documentation about the new API and IR, but since the info was aimed at existing Mesa developers nobody bothered to document that there was an existing API and IR because "everyone knew that".

                        In that sense Gallium3D is just a newer and different interface for hardware drivers with some definite advantages, but the "which is best" question was hotly debated until everyone got tired of the debate (which suggests that one may not be obviously better than the other). Some teams decided to go with Gallium3D and others decided to stay with classic Mesa and make changes (eg using GLSL IR) to address specific concerns. My impression is that the decisions were a function of both perceived technical advantages/disadvantages and the degree of investment in classic Mesa at the time.
                        Last edited by bridgman; 06-22-2014, 04:13 PM.

                        Comment


                        • #13
                          Originally posted by kalrish View Post
                          but I recall hearing that Gallium turned all hardware-dependent API calls into an intermediate representation (IR) called TGSI; it allows every driver under its umbrella to support any API for which there exists a state tracker (a translator between API calls and TGSI). Thus, each driver either provides API interfaces by itself (as Intel's driver do) or plugs into Gallium and works with TGSI.
                          One minor clarification... API calls are not turned into IR... the IR is how shader programs are described to the HW driver, while API calls perform the actual setup & drawing functions.

                          The drawing functions typically make use of shader programs, eg: "draw this list of triangles, but run vertex shader program A on every vertex in the list and use the output of the shader as vertex position & corner colours, then run fragment shader program B on every pixel in each of the resulting triangles to determine what colour should be painted in for that pixel". So you need API calls *and* IR representation of shader programs.

                          Comment


                          • #14
                            For those asking how much of this is useful to other drivers, in this case "all of it". I've only landed the driver-independent bits, since we ran into a snag with the i965 backend bits where the obvious approach doesn't do the right thing for out-of-range values.

                            Having the driver-independent bits in allows Ilia to land his nouveau support for the extension (which are on the list now) even before that's sorted out.

                            -- Chris

                            Comment


                            • #15
                              As a clarification, this hasn't actually been actively worked on for months -- they're just old patches that were rattling around on the mailing list, had review tags, and would be useful

                              Comment

                              Working...
                              X