From owner-freebsd-x11@FreeBSD.ORG Tue Nov 29 18:37:00 2011 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFF91065748 for ; Tue, 29 Nov 2011 18:37:00 +0000 (UTC) (envelope-from akirchhoff135014@comcast.net) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1758FC1D for ; Tue, 29 Nov 2011 18:36:59 +0000 (UTC) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pATIaxli030367 for ; Tue, 29 Nov 2011 13:36:59 -0500 Authentication-Results: cm-omr7 smtp.user=adamk@mckella280.com; auth=pass (CRAM-MD5) X-Authenticated-UID: adamk@mckella280.com Received: from [67.103.204.242] ([67.103.204.242:37345] helo=memory.visualtech.com) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0E/8B-04871-94625DE4; Tue, 29 Nov 2011 13:36:58 -0500 Message-ID: <4ED52648.9020908@comcast.net> Date: Tue, 29 Nov 2011 13:36:56 -0500 From: Adam K Kirchhoff User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111118 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-x11@freebsd.org References: <20111128092008.GA58668@onelab2.iet.unipi.it> <20111129100035.24025c26@ernst.jennejohn.org> <201111291304.15998.jkim@FreeBSD.org> <4ED52241.5040104@comcast.net> In-Reply-To: <4ED52241.5040104@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: suggested xorg-compatible video HW for FreeBSD/amd64 ? X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 18:37:00 -0000 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... ? :-)