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

["Chavdar Ivanov" <ci4ic4%gmail.com@localhost>]

2008/5/28 Blair Sadewitz <blair.sadewitz%gmail.com@localhost>:
> 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.
>

I newbie question - will it test and/or work if drm is modloaded?

> 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.

Last I had a look, this worked only up to R200-R300; I wonder if R350
is supported already - while the DRM framework seems to work fine on
my office Kayak w/s with a Radeon 9800SE, I get:

...
(II) RADEON(0): Direct rendering enabled
(II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer.
(II) RADEON(0): Render acceleration disabled
...

and Xorg freezes if I run glxgears (no crash, mouse cursor moving, but
that's it, the only way to get X running again is to reboot, 'vbetool
post' hard locks (I've reported the same earlier probably).

>
> 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.

I've been confining myself mostly to i386 so far; amd64 looks much
better now in comparison to a few years ago,
so I might start regular builds of that as well; the trouble is the
decent machines I could put it on are transient,

>
> Regards,
>
> --Blair
>



-- 
----------------------------------------------------------------
/dev/random says:
        I always lie. In fact, I'm lying to you right now!
----------------------------------------------------------------
Chavdar Ivanov | Talbot Way, Small Heath Business Park
Delcam UK | Birmingham B10 0HJ, United Kingdom
Customer Support | (+44)121-6831014
----------------------------------------------------------------