Further changes for GSoC drm page
authordavshao <davshao@web>
Sun, 30 May 2010 20:02:03 +0000 (13:02 -0700)
committerCharlie <root@leaf.dragonflybsd.org>
Sun, 30 May 2010 20:02:03 +0000 (13:02 -0700)
docs/developer/GEMdrmKMS/index.mdwn

index e692d0f..4372683 100644 (file)
@@ -40,17 +40,37 @@ left only using the simplest VESA driver at 1024 x 768 resolution with no hardwa
 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.
 
+## Disclaimer
 
-## Status
+Code that is uploaded to the experimental git branches has been verified to work for at most
+two graphics cards only, both Radeon-compatible cards.  It is highly likely that systems exist
+where replacing kernel code using the experimental git branches will leave one's system unable
+to use software based on X.org.  In particular nothing is known about systems with graphics
+hardware from other vendors such as Intel or Nvidia.
 
-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.
+We have experienced from ill-fated experiments forced rebooting with corruption of a ufs2 root filesystem;
+therefore, the same could well happen to you.  Only use this code on a system with no valuable or
+irreplaceable data.  We disclaim any warranty or fitness of code.
 
-### Sample **dmesg* output
+## Test Machines
+
+Our test machines both use Radeon-compatible graphics hardware: an
+older Radeon 9200-compatible card (r200) on an Asus P4B266 32-bit i386
+machine and a Radeon HD 4550 (r600) on a Shuttle SG45H7 64-bit x86_64 machine.
+
+We develop on the x86_64 machine then push our changes to the git experimental branch
+**gsocdrmalpha** at
 
-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.
+git://leaf.dragonflybsd.org/~davshao/dragonfly.git
 
+We then pull the changes to the i386 machine to test build and compatibility.
 
-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.
+
+### Sample **dmesg* output
+
+The software used for graphics whether the kernel or userland 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.
+
+Here the proper kernel module appears to be loaded for the x86_64 machine.  We have on previous occasions not realized 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.
 
     drm0: <ATI Radeon HD 4550> on vgapci0
     vgapci0: child drm0 requested pci_enable_busmaster
@@ -60,11 +80,21 @@ Here the proper kernel module appears to be loaded.  I wasted quite a bit of tim
     info: [drm] Resetting GPU
     info: [drm] writeback test succeeded in 1 usecs
 
+Similarly for the Radeon 9200-compatible i386 machine:
+
+    drm0: <ATI Radeon If RV250 9000> on vgapci0
+    vgapci0: child drm0 requested pci_enable_busmaster
+    info::[drm] AGP at 0xf8000000 64MB
+    info::[drm] Initialized radeon 1.31.0 20080613
+    info::[drm] Setting GART location based on new memory map
+    info::[drm] Loading R200 Microcode
+    info::[drm] writeback test succeeded in 1 usecs
+
 ### **var/log/Xorg.0.log** output
 
 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**.
 
-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.
+Here's a case of a failure on the fast x86_64 machine where things appeared to be fine: we were composing this wiki from within Firefox 3.6.3 on a system where the proper module failed to load and yet where because of the machine's speed there was no discernible problem for this application.
 
     drmOpenDevice: node name is /dev/dri/card0
     drmOpenDevice: open result is 10, (OK)
@@ -77,9 +107,9 @@ Here's a case of a failure where things are fine: I am composing this wiki from
     (EE) AIGLX: reverting to software rendering
     (II) AIGLX: Loaded and initialized /usr/pkg/lib/dri/swrast_dri.so
 
-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.
+The Mesa 7.4.x series simply does not *have* a 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.
 
-Now here is an example using latest Mesa and everything else from git where the driver is found:
+Now here is an example using latest Mesa and everything else from git on the x86_64 machine where the driver is found on the x86_64 machine:
 
     [    95.404] drmOpenDevice: node name is /dev/dri/card0
     [    95.405] drmOpenDevice: open result is 11, (OK)
@@ -95,17 +125,29 @@ Now here is an example using latest Mesa and everything else from git where the
     [    95.507] (II) GLX: Initialized DRI GL provider for screen 0
     [    95.508] (II) RADEON(0): Setting screen physical size to 508 x 285
 
-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.
+Pkgsrc on the i386 r200 machine does have a supporting driver; therefore, we obtain from its log:
 
-## Disclaimer
+    drmOpenDevice: node name is /dev/dri/card0
+    drmOpenDevice: open result is 10, (OK)
+    drmOpenByBusid: Searching for BusID pci:0000:01:00.0
+    drmOpenDevice: node name is /dev/dri/card0
+    drmOpenDevice: open result is 10, (OK)
+    drmOpenByBusid: drmOpenMinor returns 10
+    drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
+    (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
+    (II) AIGLX: enabled GLX_SGI_make_current_read
+    (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
+    (II) AIGLX: enabled GLX_texture_from_pixmap with driver support
+    (II) AIGLX: Loaded and initialized /usr/pkg/lib/dri/r200_dri.so
+    (II) GLX: Initialized DRI GL provider for screen 0
+    (II) RADEON(0): Setting screen physical size to 510 x 290
 
-Code that is uploaded to the experimental git branches has been verified to work for one graphics card only
-and one x86_64 system only.  It is highly likely that systems exist where using the experimental branches
-will leave one's system unable to use software based on X.org.  Use at one's own risk.
+Ironically we knew we were on the right track porting the latest git versions of the X.org stack when we succeeded in locking up hard our machine.  That meant a real hardware acceleration module was being loaded that the previous kernel could not handle, which was why the latest drm from FreeBSD had to be imported.
 
-I have experienced from an ill-fated experiment forced rebooting with corruption of a ufs2 root filesystem;
-therefore, the same could well happen to you.  Only use this code on a system with no valuable or
-irreplaceable data.  I disclaim any warranty or fitness of code.
+
+## 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.
 
 ## Current Progress for Google Summer of Code 2010