| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When I made libdrm stop overallocating so much memory for the purpose
of bo caching, things started scribbling on the bottom of my
frontbuffer (and vice versa, leading to GPU hangs). We had the usual
mistake of size = tiled_pitch * height instead of size = tiled_pitch *
tile_aligned_height.
|
|
We need to install the acceleration functions so that they are wrapped
by the Damage layer. This fixes the corruption under a compositing WM
introduced in commit 8700673157fdd3a87ad5150f2f30823261fec519.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
|
|
Combine all the calls to composite between prepare_composite and
done_composite into a single primitive list, rather than a primitive
call per composite().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
This slighlty improves xrender performance on fence reg starved
i8xx hw.
I've also changed a few function calls to the new names from the
compat ones while looking at the code.
The i915 textured video path is not converted because atm the xv
code does not use tiled surfaces.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We appear to have a confusion of stride in terms of pixels, pitch in
terms of bytes and the actual width of the surface.
i830_pad_drawable_width() appears to be operating aligning *pixels* to a
64 pixel boundary and has never used the chars-per-pixel causing
considerable confusion in its callers. Remove the parameter and ensure
that the callers are expecting a value in pixels returned, multiplying
by cpp where necessary to get the pitch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Both xvmc are handing in the bo in the exact same way. So move the code
to src/i830_video.c and kill this great oeuvre of spaghetti-code.
The xvmc driver ini and fini also lost their last use, kill them, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
the error message prints out a freed string, spotted during
code reappropriation to radeon driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
In the long long ago, fbOffset was used for DGA. The server now has
only one reference to fbOffset, a leftover setting of it in fbdevhw.
We can safely ignore it now, which is good since we weren't updating
it in other places where the front buffer offset could change.
|
|
|
|
|
|
|
|
The kernel's still running after we're gone. This didn't matter.
|
|
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.
|
|
|
|
Whether we're VT switched or not shouldn't impact rendering.
|
|
Yet another user of i830_memory gone for good.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
It doesn't bind anything anymore, but does a few random things.
Give it a hopefully vague enough name to cover all cases ;)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Besides the debug stuff the went away in the previous patch,
this stuff was totally unused ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Totally useless debug function from the pre-gem era. No point
to occasionally spam Xorg.log with a bogus "No memory allocations"
message.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Use the one in the drm bo instead.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
In commit 98e11210
Remove flush parameter from intel_batch_flush()
Maxi spotted that I had broken screen updating. It appears in my haste
to eliminate the extra parameter I removed a call to intel_batch_flush()
when throttling, i.e. when pushing the updates to the screen before
idling.
Should fix:
Bug 25409 [bisected] rendering corruption since a938673e
https://bugs.freedesktop.org/show_bug.cgi?id=25409
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>
|
|
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>
|
|
Simple warnings for unused variables and C99-style declarations.
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>
|
|
By dropping the frontbuffer from the crtc, the new frontbuffer
can be properly added to the crtc when the xserver is reset.
Signed-off-by: Albert Damen <albrt@gmx.net>
|
|
|
|
|
|
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)
|
|
This is replaced by intel_gpu_dump, and would no longer be used once UMS is
gone.
|
|
This does not restore the overlay on EnterVT/disable it on LeaveVT.
Does not look like this is necessary.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[anholt: Hacked in avoiding the actual kernel calls with
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
The xf86DiDGA code required that the scanout buffer always be
mappable, stay be at a fixed address in the aperture and have a
constant size. With frame buffer resizing, the latter two are no
longer true, and with KMS, we'd really prefer to not allow the former.
The only option available to the driver is to completely disable DGA
as the modes code has internal calls to the xf86DiDGA code when
fetching new modes from the hardware.
A fix for the DiDGA code will be added to the X server which will
automatically initialize DGA for mode switching and input, but not
frame buffer access, and not require any driver cooperation.
Thus, the correct solution is for the driver to not call xf86DiDGAInit
at all. For old servers, this eliminates a potential catastrophic
problem where random memory is written by the X server. New servers
will get the DIX-based behaviour automatically.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Pre-2.0, the driver supported rotation internally, rather than relying
on the X server rotation support. The last piece of this dealt with
rotating the mouse coordinates and also tried to preserve rotation
across DGA/VidModeExtension modesetting requests.
That latter bit of code broke under KMS as the rotation value was
never initialized, and when set to zero would create an invalid
configuration. This would confuse xrandr which would bail before
making any changes, leaving the user without a way to recover.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
