Announcement

Collapse
No announcement yet.

Nouveau Gallium3D Now Supports OpenGL 3.2, 3.3

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

  • Nouveau Gallium3D Now Supports OpenGL 3.2, 3.3

    Phoronix: Nouveau Gallium3D Now Supports OpenGL 3.2, 3.3

    With a fresh round of Mesa Git commits on Monday morning the support landed for OpenGL 3.2 and OpenGL 3.3 within Nouveau's NV50 and NVC0 Gallium3D drivers...

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

  • #2
    Boy, I am really disappointed in YKW....
    How its possible to write an article and not mention the fact that in essence all NV50 class cards, have feature party with binary driver now....

    Comment


    • #3
      when will r600 get 3.3. support

      Comment


      • #4
        Thanks for the shout-out, Michael!

        Originally posted by phoronix View Post
        landed for OpenGL 3.2 and OpenGL 3.3 within Nouveau's NV50 and NVC0 Gallium3D drivers
        Actually the NVC0 driver was already at OpenGL 3.2, which got turned on when the mesa state tracker got support for OpenGL 3.2. The patchset from the article included patches to move that up to 3.3 though by adding support for the 10/10/10/2-related extensions.

        Originally posted by phoronix View Post
        NVC0 (the GeForce 4 and newer; Fermi and Kepler)
        Presumably you meant GeForce 400 and newer...

        Originally posted by phoronix View Post
        All of these Nouveau changes will be part of the upcoming Mesa 10.1 release, but too bad that many Nouveau bugs and regressions remain.
        Yes, it is unfortuante that bugs/regressions exist (and even more unfortunate that in many cases they remain unreported, but what can you do). Is the suggestion that the nouveau project should concentrate exclusively on fixing bugs and avoid new feature work until there are no more bugs? Hopefully not -- most of the time the developers can't see the issues themselves, or those issues would be fixed already.

        Comment


        • #5
          Again, GLSL 150 is for GL 3.2, GL 3.3 needs GLSL 330.

          Comment


          • #6
            Originally posted by sharan View Post
            when will r600 get 3.3. support
            There is WIP support here:
            http://cgit.freedesktop.org/~airlied...0-geom-shaders

            Comment


            • #7
              Sweet! GL4 is now the next step, which will lande some nice new extension allowing even better performance on supporting hardware.

              I do wonder however if non compliant hardware like the NV50 will get GL4 support. What happens to extensions that doesn't have hardware support, do they get implemented on CPU or using GPU-compute?

              Comment


              • #8
                Interestingly, the OpenGL 3.3 changes for Nouveau were committed, while the OpenGL 3.3 updates for RadeonSI are still outstanding -- have not yet been committed. The patch set seems to be about the same size. Anyone know why that is?

                Comment


                • #9
                  Originally posted by werfu View Post
                  I do wonder however if non compliant hardware like the NV50 will get GL4 support. What happens to extensions that doesn't have hardware support, do they get implemented on CPU or using GPU-compute?
                  It's unlikely that NV50 would get GL4.0 -- that requires tesselation shaders, which NV50-class cards just don't have. The proprietary driver also only goes up to GL3.3 (for nv50), but also exposes a bunch of GL4-era extensions that are possible to implement using the hardware available. (Nouveau is definitely behind in that regard, but working on it!)

                  Comment


                  • #10
                    Originally posted by dffx View Post
                    Interestingly, the OpenGL 3.3 changes for Nouveau were committed, while the OpenGL 3.3 updates for RadeonSI are still outstanding -- have not yet been committed. The patch set seems to be about the same size. Anyone know why that is?
                    Why would you expect any correlation between the two? Different hw, different teams of people working on it, different review procedures, I posted my patchset 2 weeks earlier...

                    Comment


                    • #11
                      Originally posted by agd5f View Post
                      Testers wanted?

                      Comment


                      • #12
                        Originally posted by imirkin View Post
                        It's unlikely that NV50 would get GL4.0 -- that requires tesselation shaders, which NV50-class cards just don't have. The proprietary driver also only goes up to GL3.3 (for nv50), but also exposes a bunch of GL4-era extensions that are possible to implement using the hardware available. (Nouveau is definitely behind in that regard, but working on it!)
                        Couldn't tessalation be implented manually using an OpenCL kernel? That's what I was thinking of. It would be slower than having it hardware accelerated, but it could still be possible using software.

                        Comment


                        • #13
                          too late

                          Just when i unmerged it

                          Comment


                          • #14
                            Originally posted by imirkin View Post
                            It's unlikely that NV50 would get GL4.0 -- that requires tesselation shaders, which NV50-class cards just don't have. The proprietary driver also only goes up to GL3.3 (for nv50), but also exposes a bunch of GL4-era extensions that are possible to implement using the hardware available. (Nouveau is definitely behind in that regard, but working on it!)
                            And will be there some new support for nv40 cards? Is GL_EXT_draw_buffers2 possible (which is needed by source engine)?

                            Comment


                            • #15
                              Originally posted by werfu View Post
                              Couldn't tessalation be implented manually using an OpenCL kernel? That's what I was thinking of. It would be slower than having it hardware accelerated, but it could still be possible using software.
                              I don't think you can reasonably take the output of a vertex shader, use it as input to a CL kernel, and use that output into a fragment shader. (i think that's the pipeline, right?) At least not with any kind of reasonable speed.

                              Drivers shouldn't fake hardware support when it can't be done fast. Otherwise, it's impossible for applications to tell whether or not something works well, and you end up with applications calling all sorts of fancy API calls that slow down the application to sub 1fps speeds. While if the driver correctly states that something isn't implemented, the application can use an older technique or just skip the extra calls entirely and you end up with an application running at reasonable speeds.

                              If your hardware driver doesn't support a new enough API, you should just use LLVMPipe from the start, because it's likely to give you just as good of speed as a hardware driver falling back to software fallbacks is.
                              Last edited by smitty3268; 01-27-2014, 03:31 PM.

                              Comment

                              Working...
                              X