From owner-freebsd-x11@FreeBSD.ORG Fri Apr 16 16:35:18 2010 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 134891065675 for ; Fri, 16 Apr 2010 16:35:18 +0000 (UTC) (envelope-from rakadambi@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id DC8738FC17 for ; Fri, 16 Apr 2010 16:35:17 +0000 (UTC) Received: by pzk39 with SMTP id 39so2073180pzk.7 for ; Fri, 16 Apr 2010 09:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=cyHUDHq1LTR/9L3SaFQzR/J3+qDJWyd7+yGCos3lXV4=; b=CwTnGAj7+mkN9I17zDGF0GJTyw9bszeOlTI1TtoQLFd4MksOKdr8UyCvAc2q2gvSr+ Ky8T3XRhaZWK9GP8uPavuUd43W1QzricOXzIjKzQBFHbsJ3euPKn9RfTluStGRMny+1v xlWVyz+Hhmc39BXnKIsOr1El0JIwX6Lgcd44c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oHfyigWfVg+gwoUk/Cv64eBxNONmxJ8tjfYABbG/X8Yc5zZ1xduBou6yxInGjJZKX9 xExraNEFx0rHW+upKJzc2rhvhFUYsyD+7oap/N56afeN7G7bq3Ar5A55DtxEmz6BlmLw qSdIk400FxlS9azkT6sQOp7KlkKifJNautBns= MIME-Version: 1.0 Received: by 10.143.12.10 with HTTP; Fri, 16 Apr 2010 09:35:17 -0700 (PDT) Date: Fri, 16 Apr 2010 12:35:17 -0400 Received: by 10.142.208.5 with SMTP id f5mr995257wfg.295.1271435717234; Fri, 16 Apr 2010 09:35:17 -0700 (PDT) Message-ID: From: "R. Aditya Kadambi" To: freebsd-x11@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Parts of drm ported to DragonFlyBSD and a GSoC offer to help with GEM/KMS 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: Fri, 16 Apr 2010 16:35:18 -0000 This seems like a great development. So, is this the beginning of KMS work for ATI on FreeBSD? On Fri, Apr 16, 2010 at 7:40 AM, wrote: > Send freebsd-x11 mailing list submissions to > freebsd-x11@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > or, via email, send a message with subject or body 'help' to > freebsd-x11-request@freebsd.org > > You can reach the person managing the list at > freebsd-x11-owner@freebsd.org > > Message: 20 > Date: Fri, 9 Apr 2010 09:31:54 -0700 > From: David Shao > Subject: Parts of drm ported to DragonFlyBSD and a GSoC offer to help > with GEM/KMS > To: freebsd-x11@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > A big thanks to Robert Noland and an offer to help. > > Parts of the drm from current have been ported to DragonFlyBSD 2.7.0 > development, x86_64, and are being tested in git branches. With the > latest git versions of the X.org stack including Mesa and libdrm, the > usual demos from Mesa can be run for r600. What has been specifically > tested is a Radeon HD 4550 on a Shuttle SG45H7, Intel 64-bit. An > evolving report can be seen at > > http://www.dragonflybsd.org/docs/developer/GEMdrmKMS/ > > I readily recognize that I hardly did much more than cut and paste of > already existing FreeBSD code. I even used the kern_subr.c and hash.h > code to have a hashtable implementation with hashdestroy(). > > I am a CS masters student at San Jose State who will be submitting a > GSoC application to create a cross-BSD porting layer for GEM/KMS. I > have an idea of preserving as much of the Linux code as possible so > that it is easier to contribute back to the drm developers who have > enough problems just finishing their code for Linux. > > >From what I can tell the next step is to basically reimplement some > version of Linux's idr (small integer ID management) API using radix > trees, or more simply just to see performance, to get any version of > the API, brute force the searches using the current red-black tree. I > welcome correction, but looking at the code what exists now is a > partial solution using unrhdr where the smallest available integer is > returned while what the idr API is being used for sometimes calls for > the smallest available integer above a certain floor. This kind of > problem appears in several aspects of kernel programming which is no > doubt why Linux implemented this abstraction. And there is hardly a > shortage of radix tree implementations available for the BSDs to use. > > >