| Age | Commit message (Collapse) | Author |
|---|
|
This is a simple patch to avoid cherry-picking all of
b5c9de10ba3a811f312e622b97ee5e601bd3b74f.
|
|
The variable "intel" is unused when building i830_video.c without XvMC
support which results in a compiler warning:
i830_video.c: In function 'i830_copy_video_data':
i830_video.c:1443: warning: unused variable `intel'
Trivial fix via #ifdef.
|
|
Now that libdrm 2.4.16 is released (and already required) we can
unconditionally enable this.
Please add something like this to the release-notes/NEWS file:
* Overlay support for kernel modesetting. This needs at least kernel
v2.6.33 to work. A backport to 2.6.32 is available at:
http://gitorious.org/daniel-s-linux-stuff/linux-kernel/commits/intel-kms-overlay-for-2.6.32
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This reverts commit 3f11bbec420080151406c203af292e55177e77d1.
For unknown reasons, enabling tiling for the glyph cache is causing
glyph corruption both across suspend and resume and VT switching, on a
wide range of chipsets (reports include both i8xx and gm45)
This strongly suggests that we are handling tiling, or updates to tiled
buffers, incorrectly across i915_gem_idle(). However, until we can find
the root cause, we want to fix this regression before the next stable
release, so simply revert this patch. :(
Fixes:
[Bug 25406] fonts garbled after resuming from suspend since 6729b508
http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Beware the potential buffer overflow.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
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>
|
|
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>
|
|
Only the kernel knows whether the mapping requires a flush, so do not
preempt it.
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 b9b159c49854d8d9d2207946bb583537bb0d48d6 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>
|
|
Should have been in libdrm to begin with.
|
|
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This modification is redundant since the routing is done in the blend
unit anyway.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In commit e581ceb, I modified the shader generation to accommodate mixed
textures and solids but missed applying the new computed sampler for the
mask.
References:
Bug 23803 [bisected i915] gnome characters disappear
http://bugs.freedesktop.org/show_bug.cgi?id=23803
Bug 25031 rendering and color corruption since 14109abf
http://bugs.freedesktop.org/show_bug.cgi?id=25031
Bug 25047 [945GM bisected] rendercheck/repeat/triangles regressed
http://bugs.freedesktop.org/show_bug.cgi?id=25047
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>
|
|
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>
|
|
Simple warnings for unused variables and C99-style declarations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Apparently Debian packages were having to manually add these files
back in. Distribute them in the first place like we meant to.
|
|
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>
|
|
This reverts commit a851139c2141f6da370186148f2836e18b2acf83.
It broke the build, and I don't see why we should be supporting this
anyway.
Conflicts:
configure.ac
src/Makefile.am
|
|
I guess this is the sort of failure due to rebase-happiness that makes
Linus yell at us for rebasing.
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
It's poor style, and has confused new developers.
|
|
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>
|
