Results 1 to 10 of 10

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,660

    Default Tungsten's New VIA DRM, Mesa Driver Published

    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

  2. #2
    Join Date
    Dec 2007
    Location
    Germany
    Posts
    365

    Default

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

  3. #3
    Join Date
    Jan 2009
    Posts
    466

    Default

    Quote Originally Posted by NeoBrain View Post
    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

  4. #4
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

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

  5. #5
    Join Date
    Jul 2007
    Posts
    405

    Default

    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.

  6. #6
    Join Date
    Jan 2009
    Posts
    466

    Default

    Quote Originally Posted by bugmenot View Post
    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

  7. #7
    Join Date
    Oct 2007
    Posts
    29

    Default

    Quote Originally Posted by bugmenot View Post
    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.

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,577

    Default

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

  9. #9
    Join Date
    Oct 2007
    Posts
    29

    Default

    Quote Originally Posted by bridgman View Post
    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.

  10. #10
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •