[DragonFlyBSD - Bug #1721] (Closed) Patch: Port of FreeBSD Current drm, tested for r600 on x86_64

[Sascha Wildner via Redmine <bugtracker-admin@xxxxxxxxxxxxxxxxxxxxx>]

Issue #1721 has been updated by Sascha Wildner.

Description updated
Status changed from New to Closed
Assignee deleted (0)

Committed in 3f6063cc01b519b28ab36c05951d44c32dbf6a51

Thanks, David!

----------------------------------------
Bug #1721: Patch: Port of FreeBSD Current drm, tested for r600 on x86_64
http://bugs.dragonflybsd.org/issues/1721

Author: David Shao
Status: Closed
Priority: Normal
Assignee: 
Category: 
Target version: 


FreeBSD Current's sys/dev/drm, graphics drivers inside the kernel, has
been mostly ported to DragonFly with the exception of a partial
implementation (returns first integer available but no option to
specify a floor) of Linux's idr (small integer ID management) API and
with the exception of the entire via driver stack.  A diff of the
entire port, which is 100k because several new files have been
imported virtually unchanged from FreeBSD, can be found at:

http://leaf.dragonflybsd.org/~davshao/r600fbsd.diff

A git branch r600fbsd can be found at

git://leaf.dragonflybsd.org/~davshao/dragonfly.git

Due to the hard work of others previously translating the equivalents
of locking (in some sense the port can be viewed as the limits of
porting without a full implementation of Linux's idr API), not much
more was done other than making obvious replacements.

A private hashtable implementation was imported from FreeBSD's
kern/subr_hash.c and sys/hash.h because of the lack of a hashdestroy()
function in the DragonFly equivalent APIs.

The port has been tested only on a Radeon HD 4550 on an x86_64 Shuttle
SG45H7.  In particular I cannot guarantee that the port will work at
all on Intel graphics, although a few changes were made in the i915
code to add one new header file.

The major update appears to be in the Radeon section of the code.  In
particular there are tests in one file radeon_state.c that appear for
the special case of Radeons r600 or later to skip certain IRQ
processing.  Previous to the port I had succeeded in building the
latest git versions of X.org including libdrm and Mesa which enabled
me to load the hardware module in AIGLX, only the machine would lock
up hard.  After the port, indications are that the proper hardware
modules are being loaded.  For example, dmesg gives in part:

info: [drm] Initialized radeon 1.31.0 20080613
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV710 Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs

while the corresponding Xorg.0.log log file has

95.404] drmOpenDevice: node name is /dev/dri/card0
[    95.405] drmOpenDevice: open result is 11, (OK)
[    95.405] drmOpenByBusid: Searching for BusID pci:0000:01:00.0
[    95.405] drmOpenDevice: node name is /dev/dri/card0
[    95.405] drmOpenDevice: open result is 11, (OK)
[    95.405] drmOpenByBusid: drmOpenMinor returns 11
[    95.405] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
[    95.507] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[    95.507] (II) AIGLX: enabled GLX_SGI_make_current_read
[    95.507] (II) AIGLX: enabled GLX_texture_from_pixmap with driver support
[    95.507] (II) AIGLX: Loaded and initialized /opt/xtest/lib/dri/r600_dri.so
[    95.507] (II) GLX: Initialized DRI GL provider for screen 0

Note the loading of r600_dri.so.  It is very easy if anything goes
wrong for Mesa to simply fall back on the software driver, and on a
relatively fast machine it may not be easy to tell if running ordinary
applications.  With the port one can run various Mesa demos under
mesa/mesa/progs/xdemos and watch for example the wheels go round.


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account