Announcement

Collapse
No announcement yet.

What Would You Like To See Out Of Mesa 8.1?

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

  • What Would You Like To See Out Of Mesa 8.1?

    Phoronix: What Would You Like To See Out Of Mesa 8.1?

    With nearly one month having passed since the release of the highly-anticipated Mesa 8.0, where have you come to realize not full satisfaction with this open-source graphics driver library? What would you like to see improved with the next release, Mesa 8.1?..

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

  • #2
    r300g:
    • Hyper-Z Enabled by default
    • MSAA

    Comment


    • #3
      r600g - better power management (runs ~10 degrees hotter than Windows while idling) plus fan speed control.

      Comment


      • #4
        Originally posted by Michael
        Greater OpenGL 3/4 compatibility. While OpenGL 3.0 / GLSL 1.30 support is basically in place with Mesa 8.0, there's still several newer revisions to OpenGL and the OpenGL Shading Language to be addressed. By Mesa 8.1 it looks like Intel hopes to have a large portion of the OpenGL 3.1 specification covered.
        Saying that there's just several new revisions is really understating things. The differences between GL 3.0 and GL 2.1 were a lot smaller than the differences between GL 3.3 and 3.0, not to mention the differences between 4.2 and 3.0.

        GL 3.2 will likely be the hardest revision to implement due to the requirement for an entire new geometry pipeline stage. 4.0 will also be hard, but I have a feeling that the various changes necessary to make plugging in new stages will be done during the GS updates, so hopefully that transition will be easier.

        Personally, I'd like to see the DSA extension added to Mesa soon. It's available on both AMD's and NVIDIA's drivers, and it's really nice to have.

        Comment


        • #5
          I'd like to see:

          1) H.264 decoding implemented and working on r600 and newer hardware.
          2) Significant OpenGL performace improvements on r600 and newer hardware.

          Comment


          • #6
            Originally posted by elanthis View Post
            Saying that there's just several new revisions is really understating things. The differences between GL 3.0 and GL 2.1 were a lot smaller than the differences between GL 3.3 and 3.0, not to mention the differences between 4.2 and 3.0.
            No. 3.0-4.2 maybe, but 3.0-3.3 is much smaller.

            Comment


            • #7
              +1 power management.

              While sitting in meetings my laptop is quite noticeably the loudest (even though we all have the same fleet of laptops) because the fans are running at 100%, even when idling.

              Comment


              • #8
                * +1 for HD7000 support
                * Performance >= Catalyst for GL 2.1 ~ 3.3 workloads
                * Stereoscopic 3D support for HD7970
                * BluRay 3D playback support with hardware decoding

                Number of rolleyes = increasing levels of sarcasm / doubt that it'll happen (soon / if ever)

                Comment


                • #9
                  Originally posted by allquixotic View Post
                  * +1 for HD7000 support
                  * Performance >= Catalyst for GL 2.1 ~ 3.3 workloads
                  * Stereoscopic 3D support for HD7970
                  * BluRay 3D playback support with hardware decoding

                  Number of rolleyes = increasing levels of sarcasm / doubt that it'll happen (soon / if ever)
                  yes i also vote for hd7000 support and i vote for power managment.

                  but i do not have hope for the catalyst... if you wana have openGL2ES performance in apps like KDE then install the radeon driver LOL! --.

                  and the 3D stuff... there is a high chance that there is a new secret copy protection... and this means no you don't get opensource driver support for it.

                  Comment


                  • #10
                    Whatever happened to that DX10/11? Probably the one thing I'm hoping to see emerge.

                    Comment


                    • #11
                      Originally posted by smitty3268 View Post
                      No. 3.0-4.2 maybe, but 3.0-3.3 is much smaller.
                      How do you figure? No major architectural features were added in 3.0 that I can recall which weren't already _widely_ available in GL 2.1 drivers. Mostly little stuff, like just mandating the support for FP formats, adding texture arrays, VAOs, and extended FBOs -- all little stuff. Oh, on vertex transformation -- I guess that may have been a big one to implement.

                      3.1 adds a ton of new buffer types, geometry instancing, and a few other performance-essential features. 3.2 adds geometry shaders, and also fences (which I imagine are tricky to implement). 3.3 is probably the smallest of the 3.x releases (most of what I can remember as being useful in 3.3 are GLSL syntax/feature improvements that should be trivial to implement over 3.2, but there's probably other features I'm not remembering).

                      Just getting geometry shaders in is going to be a massive undertaking. Proper instancing -- including all the various other features in GL 3.1 you need to actually use instancing effectively -- is also going to be a really big item.

                      Comment


                      • #12
                        Originally posted by Dukenukemx View Post
                        Whatever happened to that DX10/11? Probably the one thing I'm hoping to see emerge.
                        The Direct3d state trackers will not be particularly useful because:
                        • OSes that don't implement the full Gallium3d stack won't be able to take advantage of the state tracker(s). So basically that means only Linux.
                        • Hardware that doesn't use Gallium3d won't be able to take advantage of the state tracker(s). That means not only the proprietary drivers, but also one of the very major open source drivers: the officially-supported Intel "classic mesa" driver, which is supporting pretty good OpenGL 3.0 on Sandy Bridge and Ivy Bridge. This also excludes hardware for which proprietary driver support exists, but no open source support exists (e.g. Radeon HD7000, Nvidia "Kepler", both of which are probably many months away from being usable on Gallium3d.)
                        • Wine is the platform that could make particularly good use of these state trackers. Basically if you aren't trying to run pre-existing Windows software with these state trackers, you are wasting your time; as far as native programs are concerned, they all use OpenGL or GLES, not Direct3d. Even if suddenly we had a lot of worthwhile native programs written to the Direct3d API as exposed by Gallium3d, we'd still have the major issue that there is a severe lack of support for this state tracker compared to the level of effort that goes into the OpenGL / GLX state trackers. So you are very likely to experience missing features and bugs when running these state trackers -- moreso than if you use OpenGL.
                        • Because Wine is designed to run on non-Linux platforms (BSD, Mac OS X), and with non-Gallium3d drivers, the Wine developers consider the first two points above to be extremely major disadvantages.
                        • Wine already has a FANTASTIC translation layer between Direct3d (8 and 9 at least, with major progress being made on 10) and OpenGL. The accomplishments they've made in terms of performance, CPU usage reduction and driver compatibility over the past few years... it's astonishing. You can play high-end games like Skyrim and Star Trek Online under wine using a Gallium3d driver. If you told me this 3 years ago, I'd have laughed you to the other side of the world. Wine is NOT "done" its job yet, but it has come an incredibly long way in its journey to becoming a fully compatible Windows program emulator while offering near-native performance. I think we should let them keep going down that path without trying to change to an unproven technology.

                        Comment


                        • #13
                          Originally posted by elanthis View Post
                          How do you figure? No major architectural features were added in 3.0 that I can recall which weren't already _widely_ available in GL 2.1 drivers. Mostly little stuff, like just mandating the support for FP formats, adding texture arrays, VAOs, and extended FBOs -- all little stuff. Oh, on vertex transformation -- I guess that may have been a big one to implement.
                          How about a little thing like integer support, something that affects the entire driver pipeline? Not sure what you mean by "widely" available features - i mean from basic minimum support only GL 2.1, not the 2.1 but almost 3.0 support that was in Mesa 7.11.

                          Some ground support for geometry shaders has already been done, and there have been UBO patches floating around as well. I'm not minimizing the amount of work still ahead, but I would fully expect GL3.3 along with some early work on GL4 extensions in Mesa 8.3 as long as the Intel devs remain focused on adding that support.

                          Comment


                          • #14
                            Proper instancing -- including all the various other features in GL 3.1 you need to actually use instancing effectively -- is also going to be a really big item.
                            Instancing was supported even before 8.0.

                            Comment


                            • #15
                              Originally posted by allquixotic View Post
                              [*]Wine already has a FANTASTIC translation layer between Direct3d (8 and 9 at least, with major progress being made on 10) and OpenGL. The accomplishments they've made in terms of performance, CPU usage reduction and driver compatibility over the past few years... it's astonishing. You can play high-end games like Skyrim and Star Trek Online under wine using a Gallium3d driver. If you told me this 3 years ago, I'd have laughed you to the other side of the world. Wine is NOT "done" its job yet, but it has come an incredibly long way in its journey to becoming a fully compatible Windows program emulator while offering near-native performance. I think we should let them keep going down that path without trying to change to an unproven technology.[/list]
                              I've tried running something simple like Portal 2, and the performance was terrible. To the point where exiting the game took a few minutes. Mind you I never tried any tweaks beyond installing Wine and proprietary drivers. I would really like to see some benchmarks on how fast games run in Wine. From what you just said, it seems I'm doing something very wrong then.

                              Comment

                              Working...
                              X