When we need to allocate a new bo for use as a gpu target, first check
if we can reuse a pixmap that has already been relocated into the
aperture as a temporary target, for instance a glyph mask or a clip mask.
Before:
backend test min(s) median(s) stddev.
xlib firefox-planet-gnome 50.568 50.873 0.30%
xcb firefox-planet-gnome 49.686 53.003 3.92%
xlib evolution 40.115 40.131 0.86%
xcb evolution 28.241 28.285 0.18%
After:
backend test min(s) median(s) stddev.
xlib firefox-planet-gnome 47.759 48.233 0.80%
xcb firefox-planet-gnome 48.611 48.657 0.87%
xlib evolution 38.954 38.991 0.05%
xcb evolution 26.561 26.654 0.19%
And even more dramatic improvements when using a font size larger than
the maximum size of the glyph cache:
xcb firefox-36-20090611: 1.79x speedup
xlib firefox-36-20090611: 1.74x speedup
xcb firefox-36-20090609: 1.62x speedup
xlib firefox-36-20090609: 1.59x speedup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once we hit this error it's unlikely that we're coming back - so don't
flood the logs with redundant information.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We know that it's clobbered at each batchbuffer, anyway. And even if
this server isn't running DRI2, it can still be clobbered at batch
start in the KMS world.
This should restore the previous level of synchronisation between
textures and pixmaps, but *does not* guarantee that a texture will be
flushed before use. tfp should be fixed so that the ddx can submit the
batch if required to flush the pixmap.
A side-effect of this patch is to rename intel_batch_flush() to
intel_batch_submit() to reduce the confusion of executing a batch buffer
with that of emitting a MI_FLUSH.
Should fix the remaining rendering corruption involving tfp [inc compiz]:
Bug 25431 [i915 bisected] piglit/texturing_tfp regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25431
Bug 25481 Wrong cursor format and cursor blink rate with compiz enabled
http://bugs.freedesktop.org/show_bug.cgi?id=25481
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we wedge the GPU then we will return -EIO for the current batch and
then attempt to reset the GPU. Meanwhile the X server detects the error,
throws a FatalError and to all intents and purposes appears to crash to
the user - whereas before it often just appeared to momentarily freeze.
Of course, on older hardware the server remains frozen until we can find
a way to reset those GPUs at runtime.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is only a single caller that wishes to forcibly append a flush
into the batch: intel_sync(). So move the logic there.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since drm may not actually set the appropriate errno after a failure, we
must use the return code instead when determining the cause of failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I incorrectly changed the logic in 285f286 and caused the batch to
always be flushed when debugging, instead of merely inserting a MI_FLUSH
between operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to detect when we require cache flushes we need to track which
domains the pixmap currently belongs to. So to do so we create a device
private structure to hold the extra information and hook it up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since batch buffers are rarely emitted by themselves but as part of a
sequence of state and vertices, the whole sequence is emitted atomically.
Here we just enforce that batches are marked as being part of an atomic
sequence as appropriate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make the following options available via xorg.conf:
Section "Driver"
Option "DebugFlushBatches" "1" # Flush the batch buffer after every
# single operation;
Option "DebugFlushCaches" "1" # Include a MI_FLUSH at the end of every
# batch buffer to force data to be
# flushed out of cache and into memory
# before the completion of the batch.
Option "DebugWait" "1" # Wait for the completion of every batch buffer
# before continuing, i.e. perform synchronous
# rendering.
EndSection
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is the beginning of the campaign to remove some of the absurd use of
Hungarian in the driver. Not that I don't like Hungarian, but I don't need
to know that pI830 is a pPointer.
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
At this point, the only remaining feature regressions should be the lack of
overlay support (about to land), and the need to update the XVMC code to work
in the presence of KMS.
Acked-by: Keith Packard <keithp@keithp.com> (in principle)
Acked-by: Carl Worth <cworth@cworth.org> (in principle)
Under KMS, directRenderingType will get set to DRI_NONE during driver
initialization. When the first batch buffer is allocated, as
directRenderingType is DRI_NONE, the GEM bufmgr would get trashed as
intel_batch_init called a fake-bufmgr specific function.
Signed-off-by: Keith Packard <keithp@keithp.com>
Prior to this patch, code that wanted to check whether GEM was present
would look at pI830->memory_manager. This turned out to be occasionally
problematic in the KMS case, since memory_manager didn't always get set
correctly. So add a new pI830->have_gem flag to make things clear in
the various code paths, and set it after GEM initializes or when KMS is
detected.
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This pre-GEM code was all sorts of broken -- see intel_bufmgr_fake.c for
the hoops that must be jumped to use that kernel interface successfully.
Yet we continued to use it even with KMS/DRI2/UXA, which may account for
some hangs.
This avoids mapping a buffer object which is being referenced
by a batch that has already been flushed, (which is a terribly
expensive operation).
On my machine this brings the performance of x11perf -aa10text
from 85k back to 150k, (where it was before a recent kernel
upgrade). Also, before this patch, when I used my X server
actively performance would drop as low as 15k---hopefully that
bug is gone with this change.
This tracks whether the last command in each batch is an MI_FLUSH command
and avoids appending another MI_FLUSH in the non-GEM cases.
Signed-off-by: Keith Packard <keithp@keithp.com>
In non-DRM mode, the driver waits for the hardware by checking the ring
pointers; when the ring is empty, it assumes the hardware is idle. However,
the hardware updates the ring pointers before executing a command, so if the
MI_BATCH_BUFFER_START is the last command in the ring, the driver will think
the hardware is idle while it may still be processing the contents of the
batch buffer. Placing NOOPs after the BATCH_BUFFER_START allows the driver
to know that the hardware has completed the batch buffer.
Signed-off-by: Keith Packard <keithp@keithp.com>
The ring commands to insert a batch buffer to the ring in i830 form were not
terminated by a call to ADVANCE_LP_RING(). This surely would have caused
chaos.
Signed-off-by: Keith Packard <keithp@keithp.com>
The old code had a directRendering boolean, the new one has an enum. A bunch
of the merges failed to remove the '!' in front of the old name, breaking a
bunch of 'we don't have DRI' tests.
Unfortunate mismatch between kernel and DRM master headers.
Kernel:
typedef struct _drm_i915_batchbuffer { ... } drm_i915_batchbuffer_t;
DRM master:
typedef struct drm_i915_batchbuffer { ... } drm_i915_batchbuffer_t;
so use the typedef rather than the morphing structure name.
There are some concerns with this, as the DRM will be setting the nonsecure
flag on the batchbuffer, and the server may be submitting some secure-only
commands. It appears to work on the 915GM test system currently.
The EmitFlush in i830_dri.c was added as a pageflipping workaround, and was
noted to not even be sufficient then. There's no reason for it to be there,
so it's removed. After that, we just have to not emit an MI_FLUSH if we
already had, and cursor movement no longer bashes memory manager.
Chris Wilson
Eric Anholt
Keith Packard
Jesse Barnes
Lukáš Hejtmánek
Dave Airlie
Carl Worth
Kristian Høgsberg