Announcement

Collapse
No announcement yet.

Intel TTM Officially Dies, Code Stripped Away In Mesa

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

  • Intel TTM Officially Dies, Code Stripped Away In Mesa

    Phoronix: TTM Officially Dies, Code Striped Away In Mesa

    TTM, or Translation Table Maps, the memory manager developed by Tungsten Graphics, is now dead. TTM has been dwindling away since last year when Intel introduced the Graphics Execution Manager (which has since entered the mainline Linux kernel), but now the code for this memory manager has been dropped from Mesa and its Intel driver. The Intel Linux graphics stack has migrated entirely to using GEM instead of TTM, while other open-source drivers are using a combination of the GEM API with some TTM code (a GEM-ified TTM manager)...

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

  • #2
    s/striped/stripped/g

    Comment


    • #3
      Originally posted by curaga View Post
      s/striped/stripped/g
      Oops, thanks.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        So, what does this mean for non-Intel drivers? The ones using a GEM-ified TTM. Does that mean TTM code will move into the individual drivers?

        Comment


        • #5
          So, what now? Will a replacement be made? Will everyone now move entirely to GEM?

          Comment


          • #6
            I believe this commit removed TTM-related code from the Intel Gallium3D driver tree in Mesa, and should not affect other drivers.

            Comment


            • #7
              Ah, thanks, bridgman.

              Comment


              • #8
                Originally posted by phoronix View Post
                Phoronix: TTM Officially Dies, Code Striped Away In Mesa

                TTM, or Translation Table Maps, the memory manager developed by Tungsten Graphics, is now dead.
                This is a new low in Phoronix sensationalism. Did you forget about your own articles about the nouveau, radeon and via drivers using TTM?

                Comment


                • #9
                  If I understand correctly, GEM is a memory manager API while TTM works behind the scenes in most of the free drivers these days. Since Intel removed the last trace of TTM from their driver, what are they using instead?

                  Does it have a name? How does it differ from TTM? Or have I misunderstood and Intel is using a "GEM memory manager"?

                  Comment


                  • #10
                    Originally posted by Culex View Post
                    If I understand correctly, GEM is a memory manager API while TTM works behind the scenes in most of the free drivers these days. Since Intel removed the last trace of TTM from their driver, what are they using instead?

                    Does it have a name? How does it differ from TTM? Or have I misunderstood and Intel is using a "GEM memory manager"?
                    Intel uses GEM fully, other drivers use a mix

                    Comment


                    • #11
                      I'm guessing the GEM API is layered to you can use just the kernel interface or also have it do all the work for you.

                      Comment


                      • #12
                        It also gets confusing because GEM defines some calls as "driver specific", so you have "the Intel implementation of GEM" vs other implementations of GEM where the driver-specific calls are definied differently. I'm guessing that those driver-specific calls are where TTM shows through, but I stress that is only a guess.

                        I suspect that when people talk about "entirely GEM" they really mean "Intel's implementation of GEM with its particular driver-specific calls", not something that is "more true to GEM" than any other implementation.

                        A few months back the discussion on the boards was primarily around the fact that Keith felt the GEM code he had written should be directly useable on non-Intel GPUs, while other devs working on those GPUs disagreed. Given that you have knowledgeable, experienced people on both sides of the argument it's not at all clear which of them is right; the best anyone can do is add their own opinion to the mix. I suspect the true answer is along the lines of "yeah, I guess we could use the code Keith wrote but it would be a lot more work and risk than leveraging what we already have running (ie TTM)".

                        The other source of confusion is that in an IGP part (Integrated Graphics Processor), there is no dedicated video memory, just a reserved area of system memory, so with the right cache tricks the CPU can access that reserved area of memory like it was system memory (more quickly) rather than accessing it through the GPU. This is useful for IGP parts but not applicable to discrete parts with their separate video memory, so I suspect there is some sentiment that some of the Intel GEM code is not applicable to discrete GPUs. No idea how true this is these days.

                        The important point to understand is that system memory can be accessed more quickly than dedicated video memory by the *CPU*, while dedicated video memory can be accessed more quickly than system memory by the *GPU*.
                        Last edited by bridgman; 02-14-2009, 12:08 AM.

                        Comment

                        Working...
                        X