TTM Memory Manager Gets Ready For Release

[phoronix]

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

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

[NeoBrain]

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?

[bugmenot]

I love this! Include it!

[[Knuckles]]

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.

[Louise]

HW TCL glxgears in gallium

http://tirdc.livejournal.com/25274.html

[mendieta]

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!

[TechMage89]

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.

[Louise]

Speaking of FBO. Nouveau have just added NouveauFB for NV50.

http://nouveau.freedesktop.org/wiki/FeatureMatrix

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

[mendieta]

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

[Veerappan]

/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*