TTM Memory Manager Gets Ready For Release

[bridgman]

Memory management hardware and command submission mechanisms are significantly different between GPU vendors, so each family of GPUs needs different code.

I believe that finding a "model" which could work well across all the different hardware was one of the big challenges, and one of the reasons that memory management has taken so long to design and implement.

[hax0r]

It seems also that nouveau is adding extra code to ttm. They are putting bits of ttm and gem into drm/nouveau. I was thinking it would all be generic and held in one piece. I wonder when majority of devs will jump on gallium3d bandwagon, from what I heard airlie saying is that it will happen once DRM/KMS becomes solid .

[bridgman]

I think the GEM APIs are built on top of TTM by driver code. Most of the GEM interfaces are driver-specific these days anyways.

The issue (AFAIK) was that the original version of TTM code built into the drivers a year or two ago wasn't considered sufficiently clean to go into the kernel tree, but the new version is.

[wswartzendruber]

Hang on a minute, this version of TTM will expose GEM APIs?

[mendieta]

Hopefully once TTM gets merged we'll be one step closer to merging a few of the other radeon projects.

Not to mention that Ubuntu 9.10 will apparently use 2.6.31, so there is time to see perhaps some nice progress with the open source drivers by then!

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

[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

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

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

[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!