No announcement yet.

Assembly Shader Rework Hitting Mesa Today

  • Filter
  • Time
  • Show
Clear All
new posts

  • #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.


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


      • #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?


        • #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 (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).