On Wed, 2008-05-28 at 17:03 -0400, Blair Sadewitz wrote: > Hello, > > 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 > its > 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 > to > udv_attach (in sys/uvm/uvm_device.[ch]) from 'voff_t' to 'vsize_t'. > Yes, this is an utterly awful hack. _DRM_SHM is basically the only memory type that shouldn't be bus_dma. It's never referenced from the graphics device. It's just for shared memory between the DRM and userland processes. Why switch to a r/w lock? That path shouldn't ever be a source of contention, and I'd rather not make our locking harder unless necessary. Are you planning on pushing NetBSD's changes back upstream? -- Eric Anholt anholt%FreeBSD.org@localhost eric%anholt.net@localhost eric.anholt%intel.com@localhost
Attachment:
signature.asc
Description: This is a digitally signed message part