Announcement

Collapse
No announcement yet.

TTM Memory Manager Gets Ready For Release

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

  • TTM Memory Manager Gets Ready For Release

    Phoronix: TTM Memory Manager Gets Ready For Release

    With the release of the Linux 2.6.30 kernel, the merge window for new features to enter the next Linux 2.6.31 development cycle is about to open. There's been much speculation whether TTM and Radeon kernel mode-setting would enter this next mainline kernel release or if it would be dragged on for another three months, but it looks like TTM at least is getting very close to entering the mainline tree. Thomas Hellstrom of VMware/Tungsten Graphics has signaled the state of the TTM memory manager by issuing an RFC on the dri-devel list...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    ok... So if I understand this correctly, OSS drivers had no memory manager for _years_ even though one existed (TTM), then Intel came around and said "here, take GEM", then they wanted to use it, but it wasn't good enough, so they just used TTM with a GEM API...
    Why didn't they do that right at the beginning when TTM was created?

    Comment


    • #3
      I love this! Include it!

      Comment


      • #4
        Originally posted by NeoBrain View Post
        ok... So if I understand this correctly, OSS drivers had no memory manager for _years_ even though one existed (TTM), then Intel came around and said "here, take GEM", then they wanted to use it, but it wasn't good enough, so they just used TTM with a GEM API...
        Why didn't they do that right at the beginning when TTM was created?
        Not really. I think the story is more like there was no memory manager, so TTM started development. When the intel guys started working it it they discovered it was rather complex for their use cases, and imposed overheads that they didn't need, so they made an experiment to see if something simpler suited them. Their experiment was successful, and GEM came into being. It was submitted upstream and accepted.

        Because other drivers for more complex hardware needed the full extent of the features provided by TTM, it was modified to export the GEM API to the outside (userspace), while providing the same features as before, and this is the version that is being submitted.

        Comment


        • #5
          HW TCL glxgears in gallium

          Do I need to add something else? Yes? Ok. Corbin Simpson got to the point where you can run glxgears on top of a gallium accelerated mesa. He figured out what the actual issues were and pushed the changes to git a few hours ago. Good job, Corbin! Next to that Dave Airlie will be looking into…

          Comment


          • #6
            I am sure some guru here knows: in the short term, is this going to be used by both the open-source drivers and fglrx on the ati side of things? Qqalitatively, what kind of improvements should an end user expect?

            Many thanks!

            Comment


            • #7
              I am sure some guru here knows: in the short term, is this going to be used by both the open-source drivers and fglrx on the ati side of things? Qqalitatively, what kind of improvements should an end user expect?
              No, fglrx has its own memory manager unrelated to the open-source one.

              A memory manager is a critical prerequisite to a lot of things, including KMS and Gallium3d, as well as proper support for OpenGL extensions like FBO. In the near term, there may be some hiccups in the transition to a memory manager, but in the long term, it should lead to better performance and better OpenGL support.

              Also, leveraging Gallium3D, this could enable support for things like generic gpu video-decode and OpenCL support.

              Comment


              • #8
                Speaking of FBO. Nouveau have just added NouveauFB for NV50.



                And they are now WIP on KMS for all NV's.

                Comment


                • #9
                  Thanks so much TechMage98 for educating me! This brings us one step closer to my hope to see open-source 3D accel in the newer ATI chipsets by the end of 2009! BTW, I am not a GPU hacker but for what I read Gallium3D is a hge step in the right direction, leading to a lot less duplication of code down the road! Things are looking sweet for Linux graphics
                  Last edited by mendieta; 10 June 2009, 01:56 PM.

                  Comment


                  • #10
                    /me is happy.

                    Hopefully once TTM gets merged we'll be one step closer to merging a few of the other radeon projects. I've been running git versions of the kernel, drm, xf86-video-ati (radeon-rewrite), and mesa, and I am very much looking forward to returning to a stock kernel (or at least a PPA build).

                    That being said, this will make it possible for a few of the major projects to actually be merged from branches into their respective master repositories when they're done being developed/tested (some of which I'd argue are almost ready).

                    *does another happy dance*

                    Comment

                    Working...
                    X