Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]