tech-x11 archive

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

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

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                                   

Attachment: signature.asc
Description: This is a digitally signed message part

Home | Main Index | Thread Index | Old Index