Announcement

Collapse
No announcement yet.

Gallium3D Is Getting Closer To Support NIR As An Alternate IR

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

  • #11
    Originally posted by Hi-Angel View Post
    CrystalGamma if you're going to use that file, note that the combinations — as noted in the README — are collected in a way to not conflict with the default ones. You might probably want to rebind some of them in a way, overwritting the existing ones, yet more comfortable. E.g. the superscript letters like "ⁿ" are produced by default with «Compose + ^ + ^ + n», because «Compose + ^ n» would produce "n̂". But at first superscript letters are needed more often, and at second the file have combining Unicode cap too, i.e. "̂"
    Thanks for the tip. But first I have to get .XCompose working as it is. It turns out support for that just came out in GTK 3.20, so I have to risk installing that.

    EDIT: can't get it to work. Any help would be appreciated.
    Last edited by CrystalGamma; 28 March 2016, 09:42 AM.

    Comment


    • #12
      Originally posted by CrystalGamma View Post

      Thanks for the tip. But first I have to get .XCompose working as it is. It turns out support for that just came out in GTK 3.20, so I have to risk installing that.
      I'm not sure what the sentence in the linked changelog means, but XCompose support is done by input method, and have been there for ages. You have to call «im-config», and choose there «XIM» as the default input method. Otherwise Compose key might work incorrectly in different toolkits, like Qt.

      I'm really curious of how is that done in Wayland.

      Comment


      • #13
        Originally posted by CrystalGamma View Post

        Disclaimer: I do not work on Mesa or any other GPU driver. Confirmation from people involved would be appreciated.

        There are AFAIK 5 major IRs in Mesa: GLSL IR, which is basically an abstract syntax tree of GLSL. This is originally where the Intel driver used ,to do its optimizations.
        Now the Intel driver converts into NIR (the second IR) and optimizes in that form.
        yup, this is basically right.. if you want to nitpick there are also driver specific IR's (for example, nouveau has codegen where it does a lot of the opt passes that are done in NIR for intel/vc4/freedreno)

        Originally posted by CrystalGamma View Post
        Then there is TGSI, the original IR for Gallium. Gallium used to convert GLSL IR ⇒ TGSI before passing to the pipe drivers. Now apparently Gallium drivers can accept NIR as well.
        Then, SPIR-V. I think there was work to make Gallium drivers accept SPIR-V as well, but maybe that is now irrelevant since SPIR-V ⇔ NIR is (so I've heard) really easy, because that's what they were designed for.
        Lastly, certain drivers (at least radeonsi) create LLVM IR and let LLVM create their GPU-specific ISA for them.

        So no, this is not directly relevant to Intel, except that maybe now developers of gallium drivers may work on NIR optimizations as well.
        fwiw, vc4 and freedreno have already been using NIR for a while now, but after a TGSI -> NIR conversion. Some information is lost along the way, and presumably the extra conversions aren't idea for compile time (although in the grand scheme of all the things a compiler does I wouldn't expect them to be a large percentage).

        I believe i965 already uses some of the lowering passes that I wrote, and some of the new passes that are part of this patchset for gallium NIR support should also be useful... Jason mentioned that the lower_io_types pass should at least be helpful for link-time optimizations for vulkan/anv. (And vc4 and freedreno already share a lot of the lowering passes in common.) Ofc vc4/freedreno also benefit immensely from the passes that intel has implemented.

        One thing I should mention, and probably should have put this in the cover-letter of the patchset, but I'm expecting the direct glsl->nir path to be useful for adding mediump (half-precision) support for GLES. The work being done for fp64 support in NIR lays the groundwork to go in the opposite direction (less precision). And having to plumb that through TGSI is probably not terribly useful (since it is mostly something supported by GPU's designed for GLES).

        Comment


        • #14
          Originally posted by CrystalGamma View Post
          EDIT: can't get it to work. Any help would be appreciated.
          What's the problem? Did you choose XIM in im-config?

          Comment


          • #15
            Originally posted by Hi-Angel View Post
            What's the problem? Did you choose XIM in im-config?
            I'm using Wayland, so I don't think that applies … regardless, I don't even know what im-config is.

            Comment


            • #16
              Originally posted by CrystalGamma View Post

              I'm using Wayland, so I don't think that applies … regardless, I don't even know what im-config is.
              Aww, I see… In fact, I am going to switch to Wayland too once kwin would get primary selection working. I think for Wayland there's a need to dig either in libinput and its configuration, or into WM settings (since libinput is used by WM, as I understand). Probably, the syntax of XCompose would change, and could even be different for every WM — however, I hope it wouldn't be hard to write a script converting the old XCompose file into the appropriate format.

              Comment

              Working...
              X