mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: linux-kernel@vger.kernel.org
Subject: [resubmit] Add GEM to i915 DRM driver
Date: Tue, 26 Aug 2008 12:43:06 -0700	[thread overview]
Message-ID: <1219779789-8368-1-git-send-email-eric@anholt.net> (raw)

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://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

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
function.

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).



             reply	other threads:[~2008-08-26 19:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-26 19:43 Eric Anholt [this message]
2008-08-26 19:43 ` [PATCH] Export shmem_file_setup for DRM-GEM Eric Anholt
2008-08-26 19:43   ` [PATCH] Export kmap_atomic_pfn " Eric Anholt
2008-08-26 19:43     ` [PATCH] drm: Add GEM ("graphics execution manager") to i915 driver Eric Anholt
2008-08-27 13:36     ` [PATCH] Export kmap_atomic_pfn for DRM-GEM Nick Piggin
2008-08-27 16:52       ` Eric Anholt
2008-08-28  0:22         ` Nick Piggin
2008-09-22 17:59           ` Jesse Barnes
2008-09-23 16:32             ` Eric Anholt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1219779789-8368-1-git-send-email-eric@anholt.net \
    --to=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®