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 a938673ehttps://bugs.freedesktop.org/show_bug.cgi?id=25409
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>
During shutdown from a FatalError during batchbuffer submission, it is
possible for the batch_ptr to be NULL, so we must be careful not to
append a flush on this error path.
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>
Reduce the 3 conditions into the 2 distinct cases. This has the
secondary benefit of also distinguishing between the reported errors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The kernel will only emit a flush iff the buffer is currently owned by
the GPU. Instead of presuming that the kernel must emit a flush, it is
safer to assume that it does not and so cannot mapping the buffer on to
the CPU as a synchronisation point. The most obvious counter-example is
when we map the same buffer twice without using it in a batch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These files have been dropped from the generated tar file since the
removal of UMS support. However, the bios_reader code still includes
these, so "make distcheck" fails unless these are distributed.
There's probably a cleaner fix possible, but this at least fixes the
build so that the snapshot can be pushed out.
On older chipsets (i.e. pre-i965) tiling is very restrictive and imposes
severe size and alignment constraints. Combine that with relatively
small apertures and it is very easy to create a batch buffer that
cannot be mapped into the aperture (but would otherwise fit based purely
on total object size). To prevent this we need to not use tiling for large
buffers (the very same buffers where tiling would be of most benefit!).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
make dist failed due to missing i2c_vid.h
Commit b9b159c498 Remove UMS support.
The above commit did not remove this header file from the makefile.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
When updating a buffer object for the framebuffer, we may need to
allocate a fresh pixmap private structure, for example if the pixmap is
replaced due to resize. When doing so it is then imperative to
initialise the circularly linked lists correctly.
Should fix the fault:
#0 i830_set_pixmap_bo (pixmap=0x24ab380, bo=0x24ab780) at i830_uxa.c:524
#1 0x00007f8615c629fd in drmmode_xf86crtc_resize (scrn=0x247a320, width=1280, height=800) at drmmode_display.c:1345
#2 0x000000000051246c in xf86RandR12ScreenSetSize (pScreen=0x24824f0, width=<value optimized out>, height=<value optimized
out>, mmWidth=<value optimized out>, mmHeight=<value optimized out>) at xf86RandR12.c:709
#3 0x0000000000512aa8 in xf86RandR12CreateScreenResources (pScreen=<value optimized out>) at xf86RandR12.c:839
#4 0x0000000000514ec0 in xf86CrtcCreateScreenResources (screen=0x24824f0) at xf86Crtc.c:727
#5 0x0000000000424fb3 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:215
as reported by 'buscher'.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the copy uses the 2D blitter, it uses the render cache so the source
should not require flushing if it has previously been used as a
destination.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I still have no idea how this is triggering failures, but it is. So
revert until the problem is solved.
Should fix once again:
Bug 23803 [bisected i915] gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
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>
The compile cleanup was not without fault... Apparently I don't have
XVMC enabled anymore and so missed that this variable is actually used.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Avoid waiting on dirty buffer object by streaming the upload to a fresh,
non-GPU hot buffer and blitting to the destination.
This should help to redress the regression reported in bug 18075:
[UXA] XPutImage performance regression
https://bugs.freedesktop.org/show_bug.cgi?id=18075
Using the particular synthetic benchmark in question on a g45:
Before:
9542.910448 Ops/s; put composition (!); 15x15
5623.271889 Ops/s; put composition (!); 75x75
1685.520362 Ops/s; put composition (!); 250x250
After:
40173.865300 Ops/s; put composition (!); 15x15
28670.280612 Ops/s; put composition (!); 75x75
4794.368601 Ops/s; put composition (!); 250x250
which while not stellar performance is at least an improvement. As
anticipated this has little impact on the non-fallback RENDER paths, for
instance the current cairo-xlib backend is unaffected by this change.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we track when a pixmap is active inside a batch buffer, we can avoid
unnecessary flushes of the batch when mapping a pixmap back to the CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Ensure that the render caches and texture caches are appropriately
flushed when switching a pixmap from a target to a source.
This should fix bug 24315,
[855GM] Rendering corruption in text (usually)
https://bugs.freedesktop.org/show_bug.cgi?id=24315
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>
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
Particularly noting to route alpha to the green channel when blending
with a8 destinations.
Fixes:
rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
introduced with commit 14109a.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
RENDER specifies that texels should sampled from the pixel centre. This
corrects a number of failures in the cairo test suite and a few
off-by-one bug reports.
Grey border around images
https://bugs.freedesktop.org/show_bug.cgi?id=21523
Note that the earlier attempt to fix this was subverted by the buggy use
of 1x1R textures for solid sources -- which caused the majority of text
to disappear.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Instead of allocating and utilising the texture samplers for 1x1R
solid sources and masks we can simply use the default diffuse and
specular colour channels and adjust the fragment shader appropriately.
The big advantage is the reduction in size of batches which should give
a good boost to glyph performance, irrespective of the additional boost
from using simpler shaders.
However, the motivating factor behind the switch is that our use of 1x1
textures turns out to be buggy...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the immediate victim of the overflow would be to overwrite the maximum
permissible value, the test was optimistic.
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>
It can go up to 32k. Upping this lets me use my 2560x1600 and 1920x1200
monitors in an extended desktop configuration.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
XF86DRI is defined by the SDK so not defining it here just breaks the
build. Define HAVE_DRI instead to avoid collisions.
Note: DRI2 is still enabled/disabled entirely by SDK defines.
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Remove bo pin for surface buffer access, and remove access
attempt for possible unmapped framebuffer. Using xv buffer
pointer to pass current xvmc surface bo handler, which is
assigned to src image bo and handle that the same way as in Xv.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Fixed up for conflict against the XV rework. Not tested, because
both mplayer and xine segfault with XVMC currently.]
Signed-off-by: Eric Anholt <eric@anholt.net>
Chris Wilson
Carl Worth
Gaetan Nadon
Kristian Høgsberg
Daniel Kahn Gillmor
Eric Anholt
Daniel Vetter
Jesse Barnes
Rémi Cardona
Thomas Arnhold
Zhenyu Wang