docs/developer/GEMdrmKMS/index.mdwn

   1 # Port of GEM and KMS
   2
   3 A [Google Summer of Code 2010](http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2010) project.
   4
   5 Student: David Shao
   6
   7 Mentor: Matthew Dillon
   8
   9 ## Introduction
  10
  11 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
  12 without licensing issues.
  13
  14 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.
  15
  16 We feel the fastest path to porting is through the DragonFly BSD project, but we intend for our code to be the basis for
  17 ports to all the BSDs.
  18
  19 ## Acknowledgment to the FreeBSD Project
  20
  21 We must acknowledge the hard work that previous porters of DRM such as Robert Noland of the FreeBSD project have already
  22 accomplished in translating much of earlier DRM to BSD kernel semantics.  Simply take a diff of the FreeBSD and DragonFlyBSD
  23 versions of DRM and one can readily see that the hard work of translating the semantics of the locking for the Linux drivers
  24 has mostly been done, and better still can be done almost automatically.  Furthermore the FreeBSD port has translated calls
  25 to manipulating hardware devices such as for AGP.
  26
  27 ## Goal
  28
  29 We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible.
  30 The developers of X.org / freedesktop.org related graphics drivers have their current efforts focused on Linux
  31 because they have to get something working anywhere as fast as possible.  It is the BSDs responsibility to keep
  32 up with these efforts and to contribute back to these developers to justify the developers continuing
  33 to generously license their drm code under terms compatible with those of the BSD licenses.
  34
  35 It is especially vital for Linux drm GEM, TTM, KMS code to be ported immediately to the BSDs because developers
  36 are in the process of removing userland modesetting code from current graphics drivers.  To paraphrase what
  37 we have been told by freedesktop.org developers, if we do not port this code, very shortly the BSDs will be
  38 left only using the simplest VESA driver at 1024 x 768 resolution with no hardware acceleration.
  39
  40 We believe that limiting divergence from Linux's drm code is the clearest path for the BSDs to be able
  41 to follow the latest drm developments.
  42
  43
  44 ## Status
  45
  46 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.
  47
  48 ### Sample **dmesg* output
  49
  50 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.
  51
  52
  53 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.
  54
  55     drm0: <ATI Radeon HD 4550> on vgapci0
  56     vgapci0: child drm0 requested pci_enable_busmaster
  57     info: [drm] Initialized radeon 1.31.0 20080613
  58     info: [drm] Setting GART location based on new memory map
  59     info: [drm] Loading RV710 Microcode
  60     info: [drm] Resetting GPU
  61     info: [drm] writeback test succeeded in 1 usecs
  62
  63 ### **var/log/Xorg.0.log** output
  64
  65 Somewhere on one's system are the logs of the latest startup of the X server and the modules it finds.  There can be an alternate place if one installs a second X.org, say at */opt/xtest*, in which case instead of **/var/log/Xorg.0.log** one will look in **/opt/xtest/var/log/Xorg.0.log**.
  66
  67 Here's a case of a failure where things are fine: I am composing this wiki from within Firefox 3.6.3 on a system where the proper module fails to load and yet where because of the machine's speed there is no discernible problem.
  68
  69     drmOpenDevice: node name is /dev/dri/card0
  70     drmOpenDevice: open result is 10, (OK)
  71     drmOpenByBusid: Searching for BusID pci:0000:01:00.0
  72     drmOpenDevice: node name is /dev/dri/card0
  73     drmOpenDevice: open result is 10, (OK)
  74     drmOpenByBusid: drmOpenMinor returns 10
  75     drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
  76     (EE) AIGLX error: dlopen of /usr/pkg/lib/dri/r600_dri.so failed (Cannot open "/usr/pkg/lib/dri/r600_dri.so")
  77     (EE) AIGLX: reverting to software rendering
  78     (II) AIGLX: Loaded and initialized /usr/pkg/lib/dri/swrast_dri.so
  79
  80 The Mesa 7.4.x series simply didn't *have* an r600_drv.so driver so of course it can't be found.  Mesa happily falls back to using software rendering and nothing seems greatly wrong.
  81
  82 Now here is an example using latest Mesa and everything else from git where the driver is found:
  83
  84     [    95.404] drmOpenDevice: node name is /dev/dri/card0
  85     [    95.405] drmOpenDevice: open result is 11, (OK)
  86     [    95.405] drmOpenByBusid: Searching for BusID pci:0000:01:00.0
  87     [    95.405] drmOpenDevice: node name is /dev/dri/card0
  88     [    95.405] drmOpenDevice: open result is 11, (OK)
  89     [    95.405] drmOpenByBusid: drmOpenMinor returns 11
  90     [    95.405] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
  91     [    95.507] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
  92     [    95.507] (II) AIGLX: enabled GLX_SGI_make_current_read
  93     [    95.507] (II) AIGLX: enabled GLX_texture_from_pixmap with driver support
  94     [    95.507] (II) AIGLX: Loaded and initialized /opt/xtest/lib/dri/r600_dri.so
  95     [    95.507] (II) GLX: Initialized DRI GL provider for screen 0
  96     [    95.508] (II) RADEON(0): Setting screen physical size to 508 x 285
  97
  98 Ironically I knew I was on the right track porting the latest git versions of the X.org stack when I succeeded in locking up hard my machine.  That meant a real hardware acceleration module was being loaded by that the previous kernel could not handle it, which was why the latest drm from FreeBSD had to be imported for Radeon r600.
  99
 100 ## Disclaimer
 101
 102 Code that is uploaded to the experimental git branches has been verified to work for one graphics card only
 103 and one x86_64 system only.  It is highly likely that systems exist where using the experimental branches
 104 will leave one's system unable to use software based on X.org.  Use at one's own risk.
 105
 106 I have experienced from an ill-fated experiment forced rebooting with corruption of a ufs2 root filesystem;
 107 therefore, the same could well happen to you.  Only use this code on a system with no valuable or
 108 irreplaceable data.  I disclaim any warranty or fitness of code.
 109
 110 ## Current Progress for Google Summer of Code 2010
 111
 112 Current work on porting the Linux drm to DragonFly BSD can be found in
 113 git branch **gsocdrmalpha** git://leaf.dragonflybsd.org/~davshao/dragonfly.git
 114
 115 As of Wednesday, May 26, 2010, the first goal is to port the API from *drm.h* and *drmP.h*.
 116
 117 I have ported the easy 90% that does not require changing any working code.  The next harder step
 118 will be to fully use the already existing implementation of *list_head* to replace the custom list
 119 and locking for agp memory.
 120