[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[resubmit] Add GEM to i915 DRM driver
    This patch series brings a long-awaited kernel memory manager to the i915
    driver. This will allow us to do correct composited OpenGL, speed up
    OpenGL-based compositing, and enable framebuffer objects and other "new"
    OpenGL extensions. This patchset is also being built to enable kernel
    modesetting for a non-root, flicker-free X Server.

    This is a re-submit of the changes for DRM-GEM. It relies on patches submitted
    by airlied which are currently queued in linux-next. The tree still has all
    the changes required, based off of 2.6.27-rc4.

    git:// on the drm-gem-merge branch

    New in this edition since the original submission:

    - Exporting kmap_atomic_pfn.
    (The previous submission was slow because it was checking for the
    drm_compat.c version of this function from the external tree)
    - shmem_getpage usage replaced with read_mapping_page.
    - fixes for software fallbacks on tiled buffers.
    - speedups for software fallbacks.
    - replaced pci_read_base usage with using the MCHBAR mirror aperture
    - fixed some issues on X server exit

    What's not new in this edition:

    Still using shmem_file_setup. We need to be able to allocate objects from
    the kernel, and didn't get any clear agreement that doing a VFS dance would be
    preferable to letting us behave like other kernel subsystems and use the

    Still using small integers to identify our objects rather than fds.
    We need more than just basic syscalls on the objects -- the alternate mmap
    issue is more serious than before, for X pixmap usage. There are also the
    ioctls for cache management for software fallbacks. And the issue of
    getting high fds and large numbers of them still remained.

    Still have an issue with PAT on x86_64 -- initialization fails because
    ioremap() apparently has different semantics there than on x86 or non-PAT
    x86_64 (if somebody has mapped the space and there's a WC MTRR, the ioremap
    that defaults to UC- ends up conflicting on it and failing even though it
    seems like it's not supposed to).

     \ /
      Last update: 2008-08-26 21:47    [W:0.020 / U:3.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site