Age | Commit message (Collapse) | Author |
|
The intention is to be able to capture the assertion in the Xorg.0.log
(journald equivalent). At the moment, it is emitted to stderr which is
difficult to capture and defeats the goal of only asking the reporter to
upload one log file.
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>
|
|
If an overlay video (using the sprite interface) is visible on multiple
outputs, we have to create and show a sprite for each.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77802
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Stranger things have happened.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In particular, it was offseting the read from the source image, but not
correcting the length to read - causing a read from beyond the end of
the source and a segfault.
Reported-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Zdenek Kabelac <zkabelac@redhat.com>
|
|
So we need to check whether the cached framebuffer matches the requested
format, or else recreate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Back in the good old days of the overlay, we only needed to care about
having a frame buffer large enough to hold the data. This changed with
the sprite interface which encodes the width x height into the
framebuffer and so we need to be careful when handing back a cached
buffer that it does indeed match the required dimensions.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are hosted, we do not own the CRTC configuration, and deferencing
the private data structures believing them to be ours, only leads to
disaster.
Based on patches by Christopher James Halse Rogers.
Reported-by: Christopher James Halse Rogers <raof@ubuntu.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
They where accidentally move the packed branch in
commit 85e89f2121bad96d34ff8df9456e2fbaa9ff7881
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 16 21:11:33 2013 +0100
sna/video: YUV420 is not supported by sprites, replace it with a RGB passthrough
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As YUV420 is not supported by any of the current sprite implementations
drop it. Instead implement some RGB passthroughs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fixes regression from
commit 195a51353c3af7bd253227da5f759f06cea01f73 [2.21.8]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 9 19:13:46 2013 +0100
sna/video: Convert to a pure Xv backend
Reported-by: Edward Sheldrake <ejsheldrake@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65479
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is to enable feature work which requires access to Client state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit ddd75d6539dcf692cb76747cd63d1f301180f18a.
This is a WIP patch, not ready for upstream. The danger of mixing topic
branches.
|
|
|
|
Each of the overlay, sprite and textured video can support XvMC
passthrough, so we need to setup an XvMC adaptor for each of our Xv
adaptors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When applying pan and zoom to a mismatched video, it would inevitably
miscompute the origin and scale factors.
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61610
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Under certain circumstances, XvScreenInit can indeed fail, so do not
bother with creatin XvMC (as it triggers internal assertions if it
cannot find our adaptor amongst Xv's).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The total frame size is less than 3 times the subsampled chroma planes
due to the additional alignment bytes.
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1104180
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>
|
|
We repeatedly set the alignment value on the first port, rather than
once for each.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=47597
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Simply ignore the cropping and copy the whole plane rather than
complicate the computation of the packed destination pixels.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Oh fun. Textured video expects the source content to be relative to the
origin, whereas overlay video expects the source at the origin.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Yikes, setting image.x2 == image.x1 meant no data was copied whilst the
video was clipped.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fortunately nobody had yet noticed that all videos were assumed to play
with a matching src/dst origin.
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>
|
|
So that we can use the same teardown path as normal scanouts.
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>
|
|
It was only ever used in conjunction with HAS_DEBUG_FULL. For debug
purposes it is as easy to redefine DBG locally. By simplifying the DBG
macro we can create it consistently and so reduce the number of compiler
warnings.
Long term, this has to be dynamic. Sigh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With the introduction of the third pipe on IvyBridge it is possible to
encounter situations where the combination of the three monitors exceed
the limits of the scanout engine and so prevent them being used at their
native resolutions. (It is conceivable to hit similar issues on earlier
generation, especially gen2/3.) One workaround, this patch, is to extend
the RandR shadow support to break the extended framebuffer into per-crtc
pixmaps.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
So that we may benefit from the caching of buffers and the automatic
selection of the preferred upload method.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Unifies available options for both UXA and SNA drivers, and
moves them into a common header file, intel_opts.h.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
|
|
Based on the work by Jesse Barnes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we wish to immediate map the vertices buffers, it is beneficial to
search the linear cache for an existing mapping to reuse first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For a singular region, we want to use a value for nboxes of 0 not 1,
fortunately if you pass in a box, it ignores the value of nboxes.
RegionInit() is a most peculiar API!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Such large bo place extreme stress on the system, for example trying to
mmap a 1GiB into the CPU domain currently fails due to a kernel bug. :(
So if you can avoid the swap thrashing during the upload, the ddx can now
handle 16k x 16k images on gen4+ on the GPU. That is fine until you want
two such images...
The real complication comes in uploading (and downloading) from such
large textures as they are too large for a single operation with
automatic detiling via either the BLT or the RENDER ring. We could do
manual tiling/switching or, as this patch does, tile the transfer in
chunks small enough to fit into either pipeline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Avoid the function call overhead by inspecting the low bit to see if it
is all-damaged already.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A VMA cache appears unavoidable thanks to compiz and an excrutiatingly
slow GTT pagefault, though it does look like it will be ineffectual
during everyday usage. Compiz (and presumably other compositing
managers) appears to be undoing all the pagefault minimisation as
demonstrated on gen5 with large XPutImage. It also appears the CPU to
memory bandwidth ratio plays a crucial role in determining whether
going straight to GTT or through the CPU cache is a win - so no trivial
heuristic.
x11perf -putimage10 -putimage500 on i5-2467m:
Before:
bare: 1150,000 2,410
compiz: 438,000 2,670
After:
bare: 1190,000 2,730
compiz: 437,000 2,690
UXA:
bare: 658,000 2,670
compiz: 389,000 2,520
On i3-330m
Before:
bare: 537,000 1,080
compiz: 263,000 398
After:
bare: 606,000 1,360
compiz: 203,000 985
UXA:
bare: 294,000 1,070
compiz: 197,000 821
On pnv:
Before:
bare: 179,000 213
compiz: 106,000 123
After:
bare: 181,000 246
compiz: 103,000 197
UXA:
bare: 114,000 312
compiz: 75,700 191
Reported-by: Michael Larabel <Michael@phoronix.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Don't just deference any old random pointer, use the one we actually
mapped in the first place!
Reported-by: Matti Hamalainen <ccr@tnsp.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42880
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|