Messages in this thread | | | Subject | Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM | From | Eric Anholt <> | Date | Fri, 01 Aug 2008 00:10:02 -0700 |
| |
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] | |