lkml.org 
[lkml]   [2008]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM
    From
    Date
    On Thu, 2008-07-31 at 23:58 -0700, Eric Anholt wrote:
    > From: Keith Packard <keithp@keithp.com>
    >
    > GEM needs to create shmem files and get pages related to a shmem file, and
    > using this pair of functions is the easiest way to do that.

    Looks like I need to spend more time practicing my git-send-email
    incantations. Here's the belated introduction to my patch series of

    0001-PCI-Add-pci_read_base-API.patch
    0002-Export-shmem_file_setup-and-shmem_getpage-for-DRM-GE.patch
    0003-drm-Add-GEM-graphics-execution-manager-to-i915.patch

    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 on to enable kernel
    modesetting for a non-root, flicker-free X Server.

    This patch series relies on a series of cleanups and fixes that have already
    been queued by airlied. That tree can be browsed at:
    http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next

    The main concern we expect to hear about the GEM API is the set of ioctls that
    look suspiciously like file-related syscalls. We've got small integer handles
    to things that we can read/write/mmap, flink and open and close, etc. Our
    initial plan was to use fds, but we ran into two problems as noted in drm_gem.c:

    - Process limits prevent more than 1024 or so being used at a time by
    default, and we're looking at tens of thousands of these objects used by
    a single client.
    - Inability to allocate high fds will aggravate the X Server's select()
    handling, and likely that of many GL client applications as well.

    Overall, even if we cooked up a patch to make our GEM files get fds allocated
    above some lower limit, interfering with clients fd namespace for these
    driver-internal objects sounded like a recipe for more pain than we were ready
    to sign up for. There are also concerns that for other drivers following the
    rough GEM model, they'll need to supply extra hints with mmap/pread/pwrite for
    acceptable performance ("access me through this aperture, please, because I
    know what operation I'm going to do next"). We've already discussed a
    potential mmap flag, even for the relatively simple Intel driver.

    Should there be any mail-related failures on my part, the full tree on top of
    2.6.27rc1, including what airlied has queued, is at:
    git://people.freedesktop.org/~anholt/linux-2.6 on the drm-gem-merge branch
    http://cgit.freedesktop.org/~anholt/linux-2.6/log/?h=drm-gem-merge

    --
    Eric Anholt
    eric@anholt.net eric.anholt@intel.com


    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2008-08-01 09:41    [W:4.388 / U:1.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site