[Intel-gfx] [RFC] [PATCH 0/8] drm/i915/context

Ben Widawsky bwidawsk at gmail.com
Sat Feb 26 19:30:10 CET 2011


drivers/gpu/drm/i915/Makefile           |    1 +
drivers/gpu/drm/i915/i915_context.c     |  489 +++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_dma.c         |    8 +
drivers/gpu/drm/i915/i915_drv.h         |   41 +++
drivers/gpu/drm/i915/i915_reg.h         |    1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |   97 ++++++
drivers/gpu/drm/i915/intel_ringbuffer.h |    6 +
include/drm/i915_drm.h                  |   20 ++
8 files changed, 663 insertions(+), 0 deletions(-)

I'm sorry,  I know you're probably all getting sick of this by now... I
am too.

This patch series enables context creation and destruction via IOCTLs.
It is lacking functionality as compared to the previous patch series (as
well as what was in my fd.o repo).

While I continue to work on the client side of this feature, it would be
helpful if people could review this to find any major flaws. The
comments I have received so far (mostly from Chris and Daniel) have been
extremely helpful.

More details:
Context validation (checking if context associated bos have moved) is
gone.  Also, there are no more references to ppgtt.

I will build up the context validation as I implement the mesa side. The
plan for validation is the same as before, in that once a context bo
gets an address, the code will validate at execbuffer time if the bo is
still there, and force the client to resubmit if a bo moved. The big
open right now is whether or not a buffer is explicitly associated via
some part of the ioctl interface, or if the client code implicitly
associates buffers by setting an address for the buffer when it does
execbuffer.  The previous patches did the former, I feel the latter is a
better solution because it integrates with ppgtt a lot more nicely.
Both solutions provide a poor way to disassociate a buffer, with the
former being a bit better than the latter.

As for the ppgtt stuff, I had previously, and still believe the only
relevant part is the desired aperture size, the rest should fall in
pretty nicely with the logical context stuff.

I had a number of unit tests and stress tests which won't work because
of the previously mentioned changes. However, here is my current unit
test for the create/destroy:
http://cgit.freedesktop.org/~bwidawsk/intel-gpu-tools/diff/tests/gem_ctx_create.c?h=context_support

Here is the repo (be warned I have a tendency to push -f a lot):
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/





More information about the Intel-gfx mailing list