Tweet
As I understand it the plan is to have a "standard" set of API calls (based on GEM) which are sufficient to support common functions like DRI2, then allow the remaining API calls to be implemented in a way which works best for the target hardware (this is where TTM comes in).
If I'm understanding all this correctly (which is far from a sure thing
) then what would happen is :
- Intel: GEM for both public and private functions
- Nouveau: Modify public functions to be GEM, private functions stay TTM-ish (or DRI2 could keep supporting TTM paths)
- ATI/AMD: Public functions GEM, private functions TTM-ish
Note that this is just a distillation of IRC and ml comments and I may have it all wrong, but I expect in a month it will all be more clear anyways.
There is ongoing discussion in the mailing lists and IRC channels but most of the meaty stuff happened a couple of weeks ago. The dri-devel ml and IRC are the main hotspots although the focus there has now switched to kernel modesetting (which needs memory management as a pre-requisite). I think Dave is trying to push both ahead at the same time to make sure that KMS's demands on MM are identified before MM gets finished (always a good thing).
There seems to be pretty good agreement on the high-level functionality the MM needs to provide; the reason for going in slightly different directions is that every HW platform seems to need a bunch of different parameters to the calls so the API wasn't locking down fast enough for anyone. By splitting the API into "common" and "hw-specific" sections that seemed to break the logjam.
Presumably some kind of unified "TTGem" API will fall out of this a year from now which works for everyone; the important thing is that today all the devs seem to feel they are able to proceed, and there seems to be agreement on enough common stuff to support other important initiatives like DRI2.
If I'm understanding all this correctly (which is far from a sure thing
) then what would happen is :- Intel: GEM for both public and private functions
- Nouveau: Modify public functions to be GEM, private functions stay TTM-ish (or DRI2 could keep supporting TTM paths)
- ATI/AMD: Public functions GEM, private functions TTM-ish
Note that this is just a distillation of IRC and ml comments and I may have it all wrong, but I expect in a month it will all be more clear anyways.
There is ongoing discussion in the mailing lists and IRC channels but most of the meaty stuff happened a couple of weeks ago. The dri-devel ml and IRC are the main hotspots although the focus there has now switched to kernel modesetting (which needs memory management as a pre-requisite). I think Dave is trying to push both ahead at the same time to make sure that KMS's demands on MM are identified before MM gets finished (always a good thing).
There seems to be pretty good agreement on the high-level functionality the MM needs to provide; the reason for going in slightly different directions is that every HW platform seems to need a bunch of different parameters to the calls so the API wasn't locking down fast enough for anyone. By splitting the API into "common" and "hw-specific" sections that seemed to break the logjam.
Presumably some kind of unified "TTGem" API will fall out of this a year from now which works for everyone; the important thing is that today all the devs seem to feel they are able to proceed, and there seems to be agreement on enough common stuff to support other important initiatives like DRI2.
Comment