Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26

Thread: A Mesa Branch Provides GLSL IR To TGSI Translator

  1. #21
    Join Date
    Sep 2010
    Posts
    147

    Default

    Quote Originally Posted by Kano View Post
    Which apps/games look differently with your special mesa branch?
    None that I know of. Hopefully none at all, since the behavior should stay the same.

    Quote Originally Posted by Kano View Post
    How often do you update from mesa master?
    I plan to merge it whenever there is something I need to adapt my code to, or once every week or two otherwise. Basically, whenever I need to so that my branch doesn't fall significantly behind master.

    Quote Originally Posted by Kano View Post
    Should games run faster?
    Short answer: no.

    Long answer:
    Not really. Conversion from Mesa IR to TGSI doesn't have much effect on the quality of the shader code since the instructions have an almost 1:1 correspondence.

    In theory, it should actually be a bit slower currently since _mesa_optimize_program is no longer used, and my optimization passes which replace it are less advanced. However, I have yet to find a program in which there is any noticeable difference in performance, at least with the nv50 driver.

  2. #22
    Join Date
    Sep 2010
    Posts
    147

    Default

    I should amend my last answer. Although there are no performance improvements yet as far as I know, there will likely be a few improvements as the translator progresses. Some code which was being emitted after the optimization passes can be pushed up to a slightly higher level so that the copy propagation, dead code elimination, and register consolidation passes can be run on it. I have no idea whether it will be significant; we'll just have to see once I get there.

  3. #23

    Thumbs up

    Quote Originally Posted by Plombo View Post
    Wow, I just spent several hours of my life tracking down the issue with the Nexuiz title screen and the 0 A.D. water (same issue), and the patch that finally fixed it is a whopping 13 lines long.
    0 A.D. confirmed fixed.

    Quote Originally Posted by Plombo View Post
    I plan to merge it whenever there is something I need to adapt my code to, or once every week or two otherwise. Basically, whenever I need to so that my branch doesn't fall significantly behind master.
    What still do you plan to add before submitting it for mainline inclusion?

  4. #24
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    540

    Default

    Nice work, indeed I had left with the impression, that TSGI will be dropped in flavour of GLSL IR. Since TSGI was invented because it is so close to direct3d internal represenation, and proprietary drivers will be just ported to TSGI from existing windows drivers. That didn't worked that way, so GLSL IR can be used for most convinience. Intel will be happy with it, I thing. What is your oppinion on this?

  5. #25
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    Quote Originally Posted by Drago View Post
    Nice work, indeed I had left with the impression, that TSGI will be dropped in flavour of GLSL IR. Since TSGI was invented because it is so close to direct3d internal represenation, and proprietary drivers will be just ported to TSGI from existing windows drivers. That didn't worked that way, so GLSL IR can be used for most convinience. Intel will be happy with it, I thing. What is your oppinion on this?
    My impression was that no decisions had been made yet; state trackers are still being written to use TGSI, Intel still intends to try generating HW instructions directly from GLSL IR rather than Mesa IR, and work is still proceeding on LunarGLASS. I guess the open questions are (a) whether GLSL IR will turn out to be a good fit for compute-type operations (eg OpenCL on GPU) and (b) how much of the existing LLVM optimizations LunarGLASS will be able to effectively leverage on GPUs.

    There are probably important (c), (d) and (e) questions as well but I haven't had time to look at the IRs very much yet

    AFAIK there was no expectation that proprietary drivers would be ported across to TGSI; the idea was simply to reflect the fact that for the last few years hardware had been designed more around DX requirements than around OpenGL requirements.

  6. #26
    Join Date
    Sep 2010
    Posts
    147

    Default

    Quote Originally Posted by oibaf View Post
    What still do you plan to add before submitting it for mainline inclusion?
    Well, it still has some remnants of Mesa IR even now. Most noticeably, the Mesa IR opcodes are still used instead of TGSI opcodes in glsl_to_tgsi_instruction. The parameter and attribute lists are also still stored in the format used by Mesa IR. I'll want to remove all of these Mesa IR remnants before submitting it for inclusion in master.

    Also, the translator started out as basically a copy-paste (albeit heavily modified) of ir_to_mesa and st_mesa_to_tgsi. Although it's come a long way since then, some code in the TGSI generator (the part based on st_mesa_to_tgsi) should be pushed up into the GLSL IR translator (the part based on ir_to_mesa).

    It'll also need a few other miscellaneous cleanups.

    Quote Originally Posted by Drago View Post
    Nice work, indeed I had left with the impression, that TSGI will be dropped in flavour of GLSL IR. Since TSGI was invented because it is so close to direct3d internal represenation, and proprietary drivers will be just ported to TSGI from existing windows drivers. That didn't worked that way, so GLSL IR can be used for most convinience. Intel will be happy with it, I thing. What is your oppinion on this?
    I hope that GLSL IR can be used directly by Gallium drivers and state trackers someday, at least as a cap (Gallium terminology) that drivers can enable if they support GLSL IR, so that it can be used instead of TGSI if both the driver and the state tracker support it.

    With that said, though, it's much easier said than done. Gallium and the GLSL compiler were not designed to go together. The GLSL compiler follows OpenGL semantics, whereas Gallium uses a mix of Direct3D and OpenGL semantics. For example, as I understand it, Gallium has fairly strict rules regarding dependencies of pipe drivers; the GLSL compiler wasn't written with this in mind.

    But if GLSL IR can make it into Gallium, I think it will be a huge win for drivers. Also, it won't make my GLSL to TGSI translator obsolete like you might think - it will probably just move out of the Mesa state tracker and become a Gallium auxiliary component as a transitional fallback for drivers that can't handle GLSL IR - softpipe comes to mind as a driver that would want to use it, since a GLSL IR interpreter would be cumbersome and a TGSI interpreter isn't.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •