Bug #1721
Updated by swildner over 12 years ago
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.