The compiler was simply warning that we defined the name prior to
including the original definition, so reorder.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It is still possible for the pixmap allocator to return a software only
pixmap (i.e. without an associated GEM buffer or intel_pixmap), so check
before dereferencing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30707
Reported-by: Matthias Hopf <mhopf@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A side-effect of discriminating offscreen based on the devPrivate.ptr
was that it broke uxa_finish_access and so after any fallback to s/w on
a Pixmap, it remained in software for the reminder of its life.
Introduce an explicit boolean to mark whether or not hardware
acceleration is enabled for a pixmap (with a GEM buffer).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 48b4e224297fa807be0e2bc7a67bf7e94579e8de.
The better fix is to manually mark the pixmap when acceleration is and
is not permitted. Whilst the devPrivate.ptr are invalid upon creation,
it is not worth carring code that serves no purpose.
ModifyPixmapHeader(pixdata = NULL) does not clear the
pixmap->devPrivate.ptr, instead the NULL value is interpreted as meaning
to keep the current value. (This is similar to the interpretation of the
other invalid values like depth=-1 which also mean not to change the
current property). However pixadata=NULL is indeed a valid value, and in
7c7294e, devPrivate.ptr == NULL was used to differentiate a bo pixmap
from a system pixmap. Except that we never did clear the ptr as
intended, and so X would immediately crash.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Always avoid direct rendering to the uncached scanout buffer,
redirecting all 2D access to the shadow instead. Then for the couple of
platforms where either the BLT is not ready or cannot be trusted (i8xx)
perform the front buffer fixup using the uncached writes from the CPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
SandyBridge 2D support is far from complete, so instead of
permanently falling back and always using uncached GTT mapping for
rendering, use the shadow buffer instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To enable DRI we create GEM buffers for the client to render into with
hardware acceleration. In order to maintain coherency between any 2D
render operations with the independent 3D clients (this includes the
reading of 2D rasterisation by the direct rendering client, e.g.
compiz using texture_from_pixmap) we need to replace the shadow pixmap
with the GTT mapping. Therefore 2D rendering to a DRI buffer will be to
uncached memory and thus penalised -- but the direct rendering clients
will have full hardware acceleration.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Even with the minimal use of the BLT to copy from the GTT shadow to the
GTT scanout, i830 was still hanging. Just write to the scanout directly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By returning FALSE whilst probing if we can't find a KMS driver, we
allow X to fallback to trying the VESA driver -- rather than failing.
The initial idea for this was by Julien Cristau.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Completely unused pulling in an undesired glxproto dependency.
Reported-by: Cyril Brulebois <kibi@debian.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30554
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The acceleration code does not yet exist, so we try to use gen4 shaders
which hangs the chip and makes everybody upset. Disable it until such a
time as support is written for Sandybridge XVideo.
Reported-by: Matthias Hopf <mhopf@suse.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sandybridge requires kind of buffer must be tiling, like depth.
And we would or have all tiling cases handled fine. So not allow
user to turn off tiling on Sandybridge+ may be fine.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
With libdrm < 2.4.22, the compilation of xf86-video-intel would fail
due to an undefined DRM_MODE_CONNECTOR_eDP. We now ensure that a
sufficiently new libdrm is available before compiling.
If we are tiled, we may fail the allocation due to an EIO and so not
being able to set tiling. Try again with an untiled request in this
case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we force fallbacks, then we will only create pixmaps in system
memory, preventing DRI2 from passing valid bo names to the clients. In
this case, they will just fallback to swrast. If we disable DRI2 after
forcing fallbacks (e.g. regenerating after a GPU hang or explicitly
disabled with the shadow buffer) then it is simpler just to disable the
extension and allow mesa to use pure swrast.
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
MI_LOAD_SCAN_LINE_INCL command is not available on sandybridge.
I haven't got reply on any substitution for it, so turn it off for now.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Yes, this should be done in the higher layers. Yes, I have written code
to that. No, it is not ready, hence add the sanity check to the
SRC_COPY_BLT.
This isn't the first report that I've seen, but will be the last.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30120
Reported-by: rezbit.hex@gmail.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a slightly less risky strategy than having to remember to update
all pointers to the old Screen pixmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
An attempt to workaround the incoherency in gen2 chipsets, we avoid
using dynamic reallocation as much as possible.
The first step is to disable allocation of pixmaps using GEM and simply
create them in system memory without a backing buffer object. This
forces all rendering to use S/W fallbacks.
The second step is to allocate a shadow front buffer and assign that to
the Screen pixmap. This ensure that the front buffer remains in the GTT
and pinned for scanout. The shadow buffer will be rendered to in the
normal fashion via the Screen pixmap, and be marked dirty. In the block
handler, the dirty shadow buffer is then blitted (using the GPU) over
the front buffer. This should completely avoid having to move pages
around in the GTT and avoid incurring the wrath of those early chipsets.
Secondly, performance should be reasonable as we avoid the ping-pong
caused by the small aperture and weak GPU forcing software fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This gives us a few more standard modes on eDP panels with just a simple
fixed timing in the VBT, just like on older, LVDS attached panels.
Fixes FDO bug https://bugs.freedesktop.org/show_bug.cgi?id=30069.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The current backlight value is clamped to the valid range [0, max] and
so as we queried the value before setting the max, we forced the current
backlight to 0 and so set it to be zero on initialising the display.
Fixes:
Bug 30063 - start X will modify brightness value to zero
https://bugs.freedesktop.org/show_bug.cgi?id=30063
which is a regression due to 38f940dfea.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Quoting Adam Jackson:
"But the X driver looks like
it never sets MONITOR_EDID_COMPLETE_RAWDATA, which means the X core
doesn't know that any sections beyond the first are present, so it won't
ever hand back more than 128 bytes to clients. Boo."
This patch is based on his.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the buffer object is tiled, we need to use the fence registers to
perform the appropriate untiling for CPU access. Ensure that we always
take this path for tiled objects, regardless of their size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 9c3e34703d.
This commit is not ready, as first the driver needs to handle all
controllers, especially those that ignore the BLC and require their own
interface. Fortunately, by moving that discovery into the kernel - where
it just means finding which ACPI device is attached to the video and has a
backlight interface - the userspace code should become much more sane,
and work even with multi-gpu, multi-lid systems.
But that is for tomorrow.
Rather than assert, we should fixup the use of large A1 glyphs. However,
the simplest approach is to simply fallback to s/w.
Fixes:
Bug 29430 - [UXA] Crash due assert (uxa_pixmap_is_offscreen(src_pixmap));
https://bugs.freedesktop.org/show_bug.cgi?id=29430
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the i915 driver exposes a native ACPI interface to modify the panel
backlight use it in preference to the generic interfaces. On multi-GPU
systems, the panel backlight is meant to be connected via the IGP and
this ensures that we always find the right interface.
Fixes:
Bug 29273 - XORG Intel driver chooses wrong acpi_video to control
brightness in multi-GPU system
https://bugs.freedesktop.org/show_bug.cgi?id=29273
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Stefan Dirsch
Zhenyu Wang
Carl Worth
Matthias Hopf
Krzysztof Halasa
Jesse Barnes
Matt Turner