methril at gmail.com
Wed May 6 13:17:43 CEST 2009
On Wed, May 6, 2009 at 1:08 PM, Thomas White <taw at bitwiz.org.uk> wrote:
> Hi all,
> I thought I'd present a bit of an update about how things are progressing
> with getting the direct rendering infrastructure working on our hardware.
> Some people may have noticed a lot of activity in the drm-tracking branch of
> the kernel. This branch now has the following features:
> - Handling of Glamo's command queue done at the kernel level, and access
> from userspace implemented via an ioctl.
> - Glamo's VRAM managed in the kernel, with buffers being allocated from
> userspace via a GEM ioctl interface.
> - A reorganised Glamo memory map. MMC cursor and command queue buffers are
> hardcoded and fixed at compile time. Everything left after taking out
> space for the visible framebuffer, MMC, cursor and cmdq is available
> for allocation as above.
> - A few fixes for the MMC and other code to honour the new memory map.
> - Minimal decoupling of DRM from PCI.
> This all works. I can draw rectangles on the screen using Glamo's 2D engine,
> or render to an offscreen buffer before blitting to the screen. This can be
> done with a relatively simple program such as this:
> If you've been wanting to play with Glamo acceleration (2D, 3D, MPEG,
> JPEG, ...), but have been put off by the thought of handling the command
> queue and memory yourself, now might be a good time to jump in.
> For the gory details, including instructions for compiling the userspace
> parts you need to make this work, please read here:
> Next, I'm going to be working on moving EXA into this framework so that we
> can have accelerated X coexisting with "fun stuff".
> Comments welcome, as ever.
It's planned to put some effort in KMS (Kernel Mode Settings)?
It's some performance benchmarks planned? I'd like to see the benefits
of this :)
> devel mailing list
> devel at lists.openmoko.org
o0 Methril 0o
More information about the devel