Date: Tue, 29 Nov 2011 15:17:51 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: Adam K Kirchhoff <akirchhoff135014@comcast.net> Cc: freebsd-x11@freebsd.org Subject: Re: suggested xorg-compatible video HW for FreeBSD/amd64 ? Message-ID: <201111291518.04364.jkim@FreeBSD.org> In-Reply-To: <4ED52FF6.9070104@comcast.net> References: <20111128092008.GA58668@onelab2.iet.unipi.it> <201111291412.28576.jkim@FreeBSD.org> <4ED52FF6.9070104@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 29 November 2011 02:18 pm, Adam K Kirchhoff wrote: > On 11/29/11 14:12, Jung-uk Kim wrote: > > On Tuesday 29 November 2011 01:36 pm, Adam K Kirchhoff wrote: > >> On 11/29/11 13:19, Adam K Kirchhoff wrote: > >>> On 11/29/11 13:04, Jung-uk Kim wrote: > >>>> I believe major hurdle is porting TTM but the future of this > >>>> API is not so bright. In fact, X.org ATI driver uses GEM API > >>>> now and it is internally mapped to TTM calls by Linux DRM (aka > >>>> "GEM-ified TTM manager"). Unfortunately, as always, I don't > >>>> see clear plans from Linux/X.org developers. I can only guess > >>>> few possibilities. > >>>> > >>>> 1. Linux/X.org folks drop GEM-ified TTM and use native GEM > >>>> calls. 2. Linux/X.org folks drop GEM-ified TTM and use native > >>>> TTM calls. 3. Linux/X.org folks re-invent new wheels (again). > >>>> 4. No change. > >>>> > >>>> My guess is #1 is most likely scenario in the near future. > >>>> Even if Linux/X.org folks don't do it, we may be able to > >>>> implement it without TTM because X.org ATI driver uses GEM API > >>>> already and we do not have AMD/ATI Catalyst driver for FreeBSD > >>>> anyway. So, I guess we have two choices ATM: > >>>> > >>>> 1. Fully porting TTM, GEM-ified TTM, and KMS. > >>>> 2. Replacing GEM-ified TTM with GEM and porting KMS. > >>>> > >>>> BTW, I am not volunteering. ;-) > >>>> > >>>> Jung-uk Kim > >>>> _______________________ > >>> > >>> Every conversation I've had with the radeon driver developers > >>> on the matter, even quite recently, has led me to believe that > >>> TTM will not be going away. GEM is only appropriate for IGP > >>> GPUs. Unless that changes within GEM, I do believe TTM will be > >>> used internally on the radeon DRM indefinitely. > >>> > >>> If I had to guess, I'd say that anyone on the FreeBSD side > >>> deciding to get rid of TTM and use GEM only GEM for radeons > >>> would eventually come to the same conclusion as the developers > >>> who have been working with radeon hardware for years :-) > >> > >> Correction. GEM seems to be focused on Intel IGP GPUs. > >> According to one of the radeon developers on #radeon on > >> freenode, even radeon IGP GPUs need something like TTM. > >> > >> Honestly, I'm wondering how you came to the conclusion that > >> future of TTM is not so bright... ? :-) > > > > I know it was developed for Intel IGPs (by anholt@, former > > FreeBSD DRM maintainer). However, I was under (wrong?) > > impression that xf86-video-ati is using GEM API because it wasn't > > absolutely necessary. AFAIK, Nouveau folks also did something > > similar, OpenChrome guys are doing the same thing, etc. If TTM > > is really necessary, why "GEM on TTM" hack in the first place? > > It is my understanding that to simplify have one unified API for > interacting with the DRM code, the radeon developers (and others) > agreed/decided to use the GEM userspace API, even though the > internals (for radeon DRM) require functionality provided by TTM. Understood. > For what it's worth, the radeon developer I just spoke to even said > in order to remove TTM from the equation, "something" would have to > be recoded to do "partly what ttm does". Yes, *partly*. That's exactly what I was talking about. If porting entire TTM layer is harder than recoding to do "partly what TTM does", then it is worth considering, IMHO. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111291518.04364.jkim>