Tungsten's New VIA DRM, Mesa Driver Published

[phoronix]

Phoronix: Tungsten's New VIA DRM, Mesa Driver Published

Earlier this month we shared that Tungsten Graphics was creating a new VIA 3D stack for one of their clients. This new work has many improvements over the current Mesa and DRM code both on the technical level as well when it comes to what's supported for use by end-users...

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

[NeoBrain]

Eh, so they're still using their own TTM instead of GEM?
Doesn't sound very sensefull to me, what about KMS and DRI2?

[russofris]

Originally Posted by NeoBrain

Eh, so they're still using their own TTM instead of GEM?
Doesn't sound very sensefull to me, what about KMS and DRI2?

Since TG developed TTM, and since development likely began prior to the kernel adoption of GEM, this is expected. I expect that the Gallium driver (when complete) will use the GEM API, but still keep the TTM MM backend.

The value of GEM lays in it's API. The current GEM MM backend is only suitable for Intel UMA hardware. This is not to say that you 'cannot' write a discreet backend MM for GEM, it's just that everyone already has the TTM bits 50-90% finished.

It's actually nice that GEM and TTM can live together.

F

[bugmenot]

Removing old unused stuff, cleaning up the interface and adding integrated memory manager functionality and command submission in the form of the new TTM
implementation.

I don't really get what going on with GEM/TTM. TTM was there, intel says "oh, thats to complex, that's overkill!" and they wrote GEM. But GEM is actually only compatible to intel hardware. Now there is a *new TTM*. Thats just great.

I don't get how this works: Does TG create a new TTM that can go into the linux kernel and that is used by radeon and radeonhd and the via driver? And what does this GEM-fied TTM mean? How does that work?

Sorry for the silly questions. :$

[TechMage89]

OK, regarding the TTM/GEM thing, this is how it went:

-Tungsten Graphics, who is in the buisness of writing graphics drivers for hardware companies, develops TTM, an API and framework for graphics memory management.

-The developers of other drivers decide that TTM can make a good driver and begin work based on it.

-Linus Torvalds reminds the devs that any API merged into the kernel *must* be stable.

-The devs realize the TTM API is very complex, and furthermore, much of it isn't used by any drivers except proprietary ones developed by TG. Therefore, it would be very hard to maintain and keep the *entire* TTM API stable.

-Intel pulls out GEM for their drivers which uses a simple, clean API and Intel-specific innards.

-The devs decide that they like the GEM API, and it should be easy to keep stable (as Linus Torvalds has required), so they adapt the TTM framework (which is already mostly developed) to work with the GEM API.


Basically, the devs have said regarding GEM "Once the API is stable, the internals can change." Basically meaning that their main concern is getting a stable memory management API out there and each do their own thing (mostly based on TTM) for the internals, to make it easier to keep the API stable.

[russofris]

Originally Posted by bugmenot

I don't get how this works: Does TG create a new TTM that can go into the linux kernel and that is used by radeon and radeonhd and the via driver? And what does this GEM-fied TTM mean? How does that work?

Sorry for the silly questions. :$

GEM and TTM have two functions. Manage memory (how to allocate it, prioritize it, and move its contents from one region to another), and provide the user/applications access to that memory through an API. It should make litle difference to end users and app developers which backend driver developers use, as long as the API is the same.

F

[Ze..]

Originally Posted by bugmenot

I don't get how this works: Does TG create a new TTM that can go into the linux kernel and that is used by radeon and radeonhd and the via driver? And what does this GEM-fied TTM mean? How does that work?

What happened with GEM is that once it was started , it changed from purely intel into a more generic framework , that graphics memory managers can build on. It's very simple , so GEM-fied TTM is where they take the low level TTM building blocks and replace them with GEM ones but still with TTM on top.

[bridgman]

I think it's the other way round. GEM on top (the exposed API) but the low level building blocks are mostly TTM.

[Ze..]

Originally Posted by bridgman

I think it's the other way round. GEM on top (the exposed API) but the low level building blocks are mostly TTM.

That would involve having TTM as the base in the kernel instead of GEM. One of the primary differences from memory about GEM vs TTM is that GEM has nowhere near as many assumptions and and a lot less locks , this makes it much simpler and thus more attractive to the kernel developers.

[bugmenot]

Thanks for the answers everyone!

But one last question: The GEM is in the kernel and works atm only for intel cards. I don't see GEM in the kernel changing, so does that mean that the drivers, that are ready to use TTM, change, that they can use GEM, but in fact they use internally still TTM?