Announcement

Collapse
No announcement yet.

Assembly Shader Rework Hitting Mesa Today

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

  • #16
    Originally posted by Laughing1 View Post
    What verson of opengl does that require?
    Not sure, but the i965 driver supports opengl 2.1.

    Comment


    • #17
      Does this change affect Gallium3D?

      Comment


      • #18
        I believe so, but not 100% sure. From what I can see, the interface between upper level mesa code and a Gallium3D driver includes a routine which converts Mesa IR to TGSI just before sending it to the driver.

        http://cgit.freedesktop.org/mesa/mes...mesa_to_tgsi.c

        The existence of that code (and the absence of a native TGSI code generator anywhere I could find) implies that existing Mesa code for parsing application shader programs and generating IR is still used, then the results are converted to TGSI at the last minute. The conversion appears to be very lightweight -- which fits with and supports Nicolai's decision to convert TGSI *back* to classic Mesa IR in the 3xx-5xx Gallium3D driver so that the existing shader compiler work could be re-used.

        So "probably" yes.
        Last edited by bridgman; 08-22-2009, 02:22 PM.

        Comment


        • #19
          It would be nice to see some benchmarks with the latest git code. Also, is Mesa 7.6 going to be released in time for the fall distribution updates?

          Comment


          • #20
            Originally posted by crumja View Post
            It would be nice to see some benchmarks with the latest git code. Also, is Mesa 7.6 going to be released in time for the fall distribution updates?
            You know, answering questions like that one sounds a bit like donating your money so other people get to buy a rope for your own hanging. :3

            Comment


            • #21
              Originally posted by RealNC View Post
              Well, it's not like it was fast before As they fix the code and implement needed features, the speed gets to acceptable levels. It's starting to come together at last.
              I think there is misunderstanding here, GL applications won't get faster with this code. What get faster is shader parsing. GL applications submit shader in a textual form the GL implementation has to parse it and translate it into some IR. The new merged code speedup this transformation. Thing is a proper GL application will submit its shader once and then reuse it so that the shader transformation shouldn't happen much in any proper GL applications in the end it won't speedup Doom or any games. Still it's a valuable improvement.

              Comment


              • #22
                I guess it might improve startup times for apps with lots of shaders ?

                Comment


                • #23
                  By the way, the problem with Doom was caused by the shaders having DOS newlines, instead of Unix ones. Sometimes it's the smalles things which goes wrong...

                  Should have been fixed by now, but the patch doesn't seem to have been pushed?

                  Comment


                  • #24
                    Originally posted by MostAwesomeDude View Post
                    If you actually have something to report, and don't think that it's because of your CFLAGS, then file a bug.
                    This kind of Portage QA Notice is generally a bug in the package, yeah. It automatically scans the build output for compiler warnings that are a sign something's wrong with the code; Debian does something similar on its package build infrastructure. This one is indeed very likely to cause a crash: see http://wiki.debian.org/ImplicitPointerConversions (though Debian apparently only considers it an outright build failure on Itanium).

                    I actually need to file a bug report for similar issues in a different bit of Mesa git (the r600 driver and possibly the other radeon drivers).

                    Comment

                    Working...
                    X