Parts of drm ported to DragonFlyBSD and a GSoC offer to help with GEM/KMS

[R. Aditya Kadambi]

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, <freebsd-x11-request at freebsd.org> wrote:

> Send freebsd-x11 mailing list submissions to
>        freebsd-x11 at 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 at freebsd.org
>
> You can reach the person managing the list at
>        freebsd-x11-owner at freebsd.org
>
> Message: 20
> Date: Fri, 9 Apr 2010 09:31:54 -0700
> From: David Shao <davshao at gmail.com>
> Subject: Parts of drm ported to DragonFlyBSD and a GSoC offer to help
>        with    GEM/KMS
> To: freebsd-x11 at freebsd.org
> Message-ID:
>        <s2yf44ed34d1004090931k284f2a7fob65a4247025d2db0 at mail.gmail.com>
> 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.
>
>
>