Revision for GSoC incomplete
authordavshao <davshao@web>
Sun, 30 May 2010 19:36:40 +0000 (12:36 -0700)
committerCharlie <root@leaf.dragonflybsd.org>
Sun, 30 May 2010 19:36:40 +0000 (12:36 -0700)
docs/developer/GEMdrmKMS/index.mdwn

index 34fcb6f..e692d0f 100644 (file)
@@ -1,24 +1,54 @@
 # Port of GEM and KMS
 
-## Status
+A [Google Summer of Code 2010](http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2010) project.
 
-The latest drm code from FreeBSD 9.x current has been successfully ported to DragonFly BSD, [patch](http://leaf.dragonflybsd.org/~davshao/r600fbsd.diff) and git branch **r600fbsd** git://leaf.dragonflybsd.org/~davshao/dragonfly.git, and tested with a Radeon HD 4550 on an x86_64 machine (Shuttle SG45H7).  However it must be remembered that testing has only been done with this one graphics card and it is completely unknown whether say an Intel machine will lock up solid.  Also nothing was done to port the extensive Via drivers FreeBSD has already ported.
+Student: David Shao
 
-## Introduction or what the heck is being talked about
+Mentor: Matthew Dillon
 
-We are talking about modern graphics card drivers that have already or are in the process of being written for Linux.  Fortunately for the BSDs the source code that is the basis of these drivers, part hosted in git repositories accessible from [freedesktop.org](http://cgit.freedesktop.org/), and even the part that is now residing in the Linux kernel, is mostly licensed under terms compatible with the [MIT X License](http://www.opensource.org/licenses/mit-license.php), and therefore can be directly ported to DragonFly.
+## Introduction
+
+We port to the BSDs modern graphics card drivers that have already or are in the process of being written for Linux.  Fortunately for the BSDs the source code that is the basis of these drivers, userland hosted in git repositories accessible from [freedesktop.org](http://cgit.freedesktop.org/), and even the part that is now residing in the Linux kernel, is mostly licensed under terms compatible with the [MIT X License](http://www.opensource.org/licenses/mit-license.php), and therefore can be directly ported to the BSDs
+without licensing issues.
 
 When we refer to DRM, we are referring to the [Direct Render Manager](http://dri.freedesktop.org/wiki/DRM) that is a kernel module arbitrating requests for various graphics related services.  Because of this acronym, the source code for DragonFly's DRM module can be found in directory **sys/dev/drm**, while the source code for Linux'd DRM module has been split into **include/drm** hosting common header files and **drivers/gpu/drm**.  Furthermore the Linux files have had vendor specific code split off into their own separate directories, a change the BSDs should consider since having all files in one directory is becoming rather unwieldy.
 
-## Previous work makes the port possible
+We feel the fastest path to porting is through the DragonFly BSD project, but we intend for our code to be the basis for
+ports to all the BSDs.
+
+## Acknowledgment to the FreeBSD Project
+
+We must acknowledge the hard work that previous porters of DRM such as Robert Noland of the FreeBSD project have already
+accomplished in translating much of earlier DRM to BSD kernel semantics.  Simply take a diff of the FreeBSD and DragonFlyBSD
+versions of DRM and one can readily see that the hard work of translating the semantics of the locking for the Linux drivers
+has mostly been done, and better still can be done almost automatically.  Furthermore the FreeBSD port has translated calls
+to manipulating hardware devices such as for AGP.
+
+## Goal
+
+We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible.
+The developers of X.org / freedesktop.org related graphics drivers have their current efforts focused on Linux
+because they have to get something working anywhere as fast as possible.  It is the BSDs responsibility to keep
+up with these efforts and to contribute back to these developers to justify the developers continuing
+to generously license their drm code under terms compatible with those of the BSD licenses.
 
-Simply take a diff of the FreeBSD and DragonFlyBSD versions of DRM and one can readily see that the hard work of translating the semantics of the locking for the Linux drivers has mostly been done, and better still can be done almost automatically.  The FreeBSD port represents the limits of what can be ported having worked out exclusive access mechanisms, but not having completely worked out equivalents of other Linux APIs such as **idr**, small integer ID management.
+It is especially vital for Linux drm GEM, TTM, KMS code to be ported immediately to the BSDs because developers
+are in the process of removing userland modesetting code from current graphics drivers.  To paraphrase what
+we have been told by freedesktop.org developers, if we do not port this code, very shortly the BSDs will be
+left only using the simplest VESA driver at 1024 x 768 resolution with no hardware acceleration.
+
+We believe that limiting divergence from Linux's drm code is the clearest path for the BSDs to be able
+to follow the latest drm developments.
+
+
+## Status
+
+The latest drm code from FreeBSD 9.x current has been successfully ported to DragonFly BSD, [patch](http://leaf.dragonflybsd.org/~davshao/r600fbsd.diff) and git branch **r600fbsd** git://leaf.dragonflybsd.org/~davshao/dragonfly.git, and tested with a Radeon HD 4550 on an x86_64 machine (Shuttle SG45H7).  However it must be remembered that testing has only been done with this one graphics card and it is completely unknown whether say an Intel machine will lock up solid.  Also nothing was done to port the extensive Via drivers FreeBSD has already ported.
 
-## What has been done and should be done
+### Sample **dmesg* output
 
 The software used for graphics whether the kernel or Mesa is surprisingly resilient.  As long as it compiles it will try and find a way with dealing with other mismatched components by falling back on default behavior.  Working on a fast x86_64 machine, it is easy to be lulled into a false sense that things are working properly unless one checks the logs.
 
-### **dmesg* output
 
 Here the proper kernel module appears to be loaded.  I wasted quite a bit of time earlier this week not realizing an error that led to the kernel module not being loaded at all that appeared from the messages to be a device non-existence problem.