Age | Commit message (Collapse) | Author |
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the maximum reported image sizes are for the source image, we should
be careful not to recommend the application use an output Window larger
than can be handled by the overlay hardware. So shrink it to fit, whilst
preserving the aspect ratio.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Libdrm's possible_clones is a mask of encoders. Xorg's possible_clones
is a mask of outputs, so we just can't do the following:
output->possible_clones = kencoder->possible_clones;
This is a problem on Haswell because, at least with the current
patches floating on the mailing list, there is more than one connector
per encoder.
This patch writes the code to properly translate libdrm's encoder mask
into Xorg's output mask.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we are forced to use the GPU bo as the target because the CPU bo is
busy, the priv->cpu flag is likely to remain set, so we need to clear it
rather than fail the assertion that is false.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Hide the impossible default case so that static analyzers are not
confused.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Since pre-g33 chipsets impose massive alignment restrictions on objects
within the aperture we need to further restrict the amount of available
space to be sure we have sufficient room to accommodate the alignment.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This helps with fitting larger operations into the small apertures of
gen2, which due to the lax accounting could trigger ENOSPC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
While playing with MPX and sw cursor I noticed page flips won't
end up misrendering some bits, so the sw cursor was replacing the
bits on the wrong pixmap.
Fix the damage handling to be correct and append damage before swapping
the pointers and process damage after.
This fixes misrendering with MPX cursors under a fullscreen compositor,
that pageflips.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[ickle: The secret is that damage is sometimes reported before the
rendering in DamageRegionAppend, and sometimes afterwards in
DamageRegionProcessPending. For instance, the software cursor operates
prior to being rendered over.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Prit Laes <plaes@plaes.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55823
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In case we need to redirect the rendering for a large render target, we
need to initialize the damage pointer.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: ttps://bugs.freedesktop.org/show_bug.cgi?id=55812
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: ttps://bugs.freedesktop.org/show_bug.cgi?id=55812
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-and-tested-by: chr.ohm@gmx.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55810
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Fortunately, the sgc->region was not used along that particular fallback
path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When is a pipelined operation, not pipelined? That is the mystery posed
by our hardware!
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51422
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Garbage xorg includes hiding genuine compiler warnings ftl once again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Timo Kamph <timo@kamph.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55700
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Be careful we not increase the batch size to span multiple pages on 865g!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we use pkg-config to determine whether to use intel-gen4asm, we
should also use it to locate the right version of intel-gen4asm to use.
This allows the user to install the assembler in a non-standard path for
cross-builds and similar.
Reported-by: Josh Tripplet <josh@freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55646
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Typing on Sunday before coffee is a very bad idea.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Be careful when cutting and pasting assertions!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=55700
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we notice that we have a CPU mmap during read synchronized and
presume that we need not take any further action. However...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=55646
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The make rules to compile shaders with intel-gen4asm referenced the .g4a
source files without using $(srcdir), which broke out-of-tree builds.
Reference .g4a source files via $(srcdir), and add $(srcdir) to m4's
include path, fixing out-of-tree builds.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55645
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
|
|
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 fallback correctly. This is primarily using for debugging
failure paths...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Revert back to basics, and clear the CPU flag everytime we use the GPU,
rather than try to avoid clearing it along some paths.
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>
|
|
I thought these were completely specified via the LOAD_STATE_IMMEDIATE
commands we used whilst seting up the render pipeline. I was wrong.
Reported-by: Timo Kamph <timo@kamph.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55455
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
So that we keep the assertion checks that without CPU damage we can not
be on the cpu.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55591
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Giovanni Mariani <mc2374@mclink.it>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55577
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>
|
|
As we need to clflush the scanout buffer as we return it to the bo cache
on SNB+, it is costly to terminate the pageflipping as soon as we drop a
frame as mesa often fails to keep up to the vrefresh rate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Notably 52b211cb15b3 was triggering a few assertions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reported-by: Roman Jarosz <kedgedev@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55508
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>
|
|
Reported-by: Marco De Michele <marco.demichele@taolab.it>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55527
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In an interesting twist during teardown, the driver info structure is
freed long before the caches. However, the glyph cache teardown was
checking to see if glamor was enabled to see if it could skip the
teardown. In fact, since we won't have created the glyph caches in that
circumstances it was safe any way.
Reported-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
One over-zealous removal too many.
Reported-by: Timo Kamph <timo@kamph.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55455
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Highly unlikely.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|