tech-x11 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[RFC] drm work-in-progress (patch attached)


Attached is a patch reflecting some of the work I've done on the DRM
(the part that works, heh).  Some of the improvements:

- Use bus_dma(9) everywhere that's appropriate.
- Switch the dma_lock to a reader/writer lock.
- Fix out-of-order locking in drm_sg_free().

Please ensure that your CVS tree is up-to-date before attempting to
apply this patch, as it depends on some commits
I made yesterday.

Currently, memory for the _DRM_SHM map type is allocated with
bus_dma(9) (previously, the code used malloc(9)).
On linux, they just use 'vmalloc'--but this is not anything like
"shared memory".  I've tried using uao_create(), but thusfar have only
managed to produce page fault traps. ;)

Using the latest Mesa from pkgsrc and wip/modular-xorg-server, the
improvement by using this patch seems obvious to me: far fewer lockups
and a "snappier" feel.  If you're using wip- packages, I also
recommend using the latest radeon driver sources; I will commit a
package if there
is any demand.

Any feedback is welcome, as I'd like to know how this works with
various hardware configurations.  If you're using amd64 and you have a
non-AGP video card (especially those which use scatter/gather memory),
there is a good chance X will fail to initialize the DRM with either
"can't map ring" or some error related to locking or getting the
context SAREA.  This is because the DRM code uses 'unsigned long' as
offset type--which is part of the API.  Until this is fixed, one can
work around this insanity by changing the type of the second argument
udv_attach (in sys/uvm/uvm_device.[ch]) from 'voff_t' to 'vsize_t'.
Yes, this is an utterly awful hack.



Attachment: drm-improvement.diff
Description: Binary data

Home | Main Index | Thread Index | Old Index