From owner-freebsd-ports@FreeBSD.ORG Wed Dec 23 15:47:04 2009 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81CD4106566C; Wed, 23 Dec 2009 15:47:04 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 549888FC15; Wed, 23 Dec 2009 15:47:04 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-16-112.bna.bellsouth.net [70.156.16.112]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nBNFl1nD079958 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 10:47:02 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Alex Kozlov In-Reply-To: <20091223061535.GA90713@ravenloft.kiev.ua> References: <20091223061535.GA90713@ravenloft.kiev.ua> Content-Type: text/plain Organization: FreeBSD Date: Wed, 23 Dec 2009 09:46:56 -0600 Message-Id: <1261583216.2304.68.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: ports@FreeBSD.org, x11@FreeBSD.org, Norikatsu Shigemura Subject: Re: [HEADS UP] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx, 2nd! X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:47:04 -0000 On Wed, 2009-12-23 at 08:15 +0200, Alex Kozlov wrote: > On Tue, Dec 22, 2009 at 11:38:50PM -0600, Robert Noland wrote: > > On Wed, 2009-12-23 at 07:31 +0200, Alex Kozlov wrote: > > > On Wed, Dec 23, 2009 at 02:03:15AM +0900, Norikatsu Shigemura wrote: > > > > On Tue, 22 Dec 2009 00:26:38 -0600 Robert Noland wrote: > > > > > As much as I don't want to, I need to request a repo copy of libdrm in > > > > > order to keep nouveau working... The bits needed for r600 were added > > > > > just after 2.4.12 and the bits that broke nouveau were just before > > > > > 2.4.13... > > > > > > > > Ah, I just see! ABI breakage is building issue, I confirmed: > > > > > > > > I think simple-fully xf86-video-nouveau updating at the same > > > > time. Please see also attached patch. I confirmed that > > > > compile is OK. But I don't have any GeForce video cards. > > > > So I don't know any problems of updating it in real. > > > > > > > > And do you have any recommendation of GeForce? e.g. 9800GTX, > > > > GT260, ... I'll get one and test. I'm interested in Cuda > > > > and nvidia binary driver, too. > > > > > > > > P.S. libdrm was update to 2.4.17, so I'll update... > > > I just tested libdrm 2.4.17 with --enable-radeon-experimental-api > > > and mesalib git master. It's work quite good. Well, it worked > > > quite good before > > > > I've said it before, but I'll repeat... libdrm_radeon serves no purpose > > on FreeBSD and may cause problems. It is only used by TTM/KMS enabled > > drivers on linux. If it ever becomes useful... I'll enable it in the > > port. > Sorry. I only mean that libradeon is a harmless at the moment. Yes, the potential issue is that if it exists, the DDX driver or mesa may detect it and have build issues. > Could You please let us know rough roadmap for freebsd kernel drm? GEM: WIP no ETA Still a fair amount of work to do here figuring out how to allocate and manage the objects using the FreeBSD VM system. I am still trying to learn how to manipulate the VM system. I only know of a couple of people that truly understand it though. I think that we can get any needed functionality that we need added, but if it has to go into their queue, it may take some time. I don't know that we need any more new features to do this yet. This is primarily only used on Intel hardware, but radeon and nouveau use a TTM backend while presenting a GEM api to userland, so this has to be the first task in queue. TTM: WIP no ETA (less done than GEM) I've at least got this stubbed out, but I haven't looked at exactly what is needed to get this going yet. Overall, TTM is a bit more complex than GEM since it manages pools of memory of various types from both the system and the GPU. In the end, this may be more suited to our VM than GEM, but I'm only speculating at this point. This will be used by radeon, nouveau and possibly via at some point. KMS: glimmer in my eye... Overall, this may be easier to port, however it relies on GEM/TTM to handle all of the buffer management. I'll need to coordinate with Ed@ when we get ready to do this to integrate it with our console support. I mentioned via... I finally have hardware of the appropriate vintage to finish porting the via drm driver, thanks to Bruno Schwander. This is jumbled up with working on the above, but I have most of the code ported. I still have one file to go through and fix up, though it is the most complex bit of functionality. Once I received the board, I had to fix via agp, which I committed a couple of nights ago. I'm not sure how it has existed and been broken for as long as it had. This driver will support Unichrome chips using the openchrome DDX driver. There is an alternate via driver which uses TTM, but it doesn't ship in linux either. I had previously been sent a via chrome9 part (VX800) which unfortunately uses a different driver. I had this mostly completed, though not actually working. The primary problem here is that there is no shipping DDX driver that uses it and no open source 3d for it either. The *HUGE* issue is that I am one person... Trying to keep up with 20 or 30 developers on linux, many of whom are paid full time to work on graphics if not drm directly. Probably more, when you consider that I have to try and keep mesa and Xorg going as well. I have upstream commit rights for all of the above, so I try to make sure that when folks break things on FreeBSD that fixes get committed upstream. robert. > > > > "Merge branch 'glsl-pp-rework-2'" (e195eab9093d2a6cf55a42b2e7789c9a381b778) > > > but this is separate matter. > > > So may be enabling libdrm_radeon is not such a bad idea. > > > -- > Adios -- Robert Noland FreeBSD