Since the change to scan-line based video sync, (rather than vblank-
based), we've only been getting tear-free video on one of the two
pipes. This fixes that bug by using the correct constant for waiting
on PIPEA.
Since we're not limited by a single overlay plane on a single pipe,
we want to not clip at all, (so that the correct video appears on
both pipes).
This fixes bug #20980 which shows a video spanning two pipes
being rendered incorrectly.
We previously had a heurstic here where we would only sync to vblank
for windows that covered more than 25% of the screen. We don't need
this anymore since the new approach to sync, (WAIT_FOR_SCANLINE_WINDOW),
is not excessively costly for small windows.
Either way, the goal is tear-free video playing. But waiting for
a scan-line window not only has the advantage of being cheaper
for small windows, but also avoids hanging the GPU in the case
of the pipe getting turned off, (by screensaver, for example),
while a batch is waiting for a VBLANK that will never occur.
This fixes that GPU hang.
Don't use bo->virtual in the begin_gtt_access case, use the framebuffer
mapping and bo offset instead.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Missed this when the GTT unmap call was added. If we don't do this we
trigger an assertion in libdrm, since the buffer has never been mapped
normally.
Fixes bug #20943.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
With -intel 2.6.3 performance was very bad when using a non gem enabled kernel
(2.6.27) and EXA. For example sauerbraten ran with 4 fps and screensaver GLBlur
with 1 fps. With -intel 2.6.1 performance was good using the same kernel.
Git bisecting led me to commit f1ed73c1ef3e3daa9f695194dcc813167cbcb53d (in 2.6
branch) "Make i830_allocate_memory take tiling parameters" as first bad commit.
Using gdb I found tiling was set exactly the same in 2.6.3 as in 2.6.1, so that
was good (TILE_XMAJOR for front, back and depth buffers).
Looking further I found the line mem->tiling = TILE_NONE; (line 961 in
src/i830_memory.c) at the end of i830_allocate_memory suspicious, as
mem->tiling now already gets set via i830_allocate_aperture and some buffers do
have tiling. Removing that line indeed fixed the performance issue. Now
sauerbraten runs with 30+ fps and GLBlur runs smoothly.
Hopefully this concludes the fixes necessary to deal with the various
combinations of kernel and user level tiling. We have several cases to
handle:
1) KMS (kernel handles all tiling)
2) UMS w/memory management + kexec fencing (kernel handles all tiling)
3) UMS w/memory mangement but no kexec fencing (userland handles tiling)
4) UMS w/o memory management (userland handles tiling)
For cases (1) & (2) we can use GTT mapping, which will give us good
performance and take care of allocating fence registers as needed. It's
important *not* to have userland set up fence regs in this case, since
the kernel will be using all of them.
For case (3), we use the begin/end GTT map functions provided by libdrm,
in combination with pinning and fence register setup in i830_memory.c to
deal with tiled surfaces. This also gives us good performance and
correctness.
For case (4) we use the old style virtual mapping + offset for dealing
with surfaces; note that UXA doesn't seem to work in this configuration
regardless of these fixes.
Fixes bug #20803.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
When disabling VGA mode, usually we don't need to touch VGA center mode.
However because of hardware reason, for Cresline, Cantiga & Eaglelake platform,
we have to disable center mode as well. The patch fixed bug- TV Out strobing regression,
reported by Robert Lowery in intel-gfx@lists.freedesktop.org mailing list.
Signed-off-by: Ma Ling <ling.ma@intel.com>
This gets output properties from kernel, then hook them up
for randr. So we can control output properties through randr
like in UMS.
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
If execbuffer is setting up fences, it also means that the kernel is
managing them at pin time, so installing one in the 2D driver in that
case is an error. The fence should stick around as long as the buffer
is pinned (the kernel won't steal these), though it will be freed at
leavevt and re-allocated at entervt.
On 965+ chips, the pin ioctl will *not* install a fence reg, but that's
also ok because all 965+ operations include tiling bits, and sw
fallbacks will be protected by prepare/finish access hooks, which will
either access the backing store or use the GTT, which will ensure proper
fencing at fault time.
Fixes#20265.
Acked-by: Eric Anholt <eric@anholt.net>
The server may have made a DPMS call before doing rotation, so after we
do the mode set with the rotated framebuffer, we need to re-enable the
corresponding output(s).
Fixes bug #20573.
Since we added the pipe A force quirk (leaving pipe A on all the time),
DPMS calls to disable it have silently returned, leaving the pipe on.
If another driver (like vesafb) has enabled it, we may end up with a bad
configuration, leading to hangs or blank screens at VT switch time.
Fixes bug #19603.
This cuts down build system noise so that warnings are more visible. The
old style output can be reenabled for build system debugging using
"make V=1", or --disable-shave at configure time.
With glyphs sitting in per-glyph pixmaps, there's no reason to use the CPU
to move them to the cache pixmap, and lots of reasons to use the accelerator.
Signed-off-by: Keith Packard <keithp@keithp.com>
EXA doesn't support KMS, so force UXA on if KMS is detected. And warn
the user if they've specified something other than UXA in their
xorg.conf.
Fixes bug #20620.
This reverts commit ddedf19f88.
After i2c STOP, control bus will return back to internal
registers. So this brings back to origin code that we switch
to DDC bus before START. But it's ideal to only issue DDC
bus switch after STOP, not before every START, which might eliminate
some complains from SDVO device, that will be another patch later.
The XVMC AM_CONDITIONAL is only needed around the library expression.
None of the other definitons will cause anything to be built without
libXvMC, but they're needed for 'make dist'.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
With this change, we always expect the 3D driver to use GEM textures
when the 2D driver uses GEM. When GEM is not available or disabled,
we fall back to legacy fixed textures.
We should use preferred input timing's clock for correct
pixel multiplier setting, otherwise we might get inconsistent
multiplier setting on pipe and SDVO device for some modes.
Ideally we'd not be using the EXA offscreen memory manager and just hand all
that memory to the fake bufmgr for non-GEM, but the fake bufmgr's too slow for
that, at least currently. So compromise and take enough memory that it will
succeed at XV allocations but hopefully not anger tiny-aperture systems too
much.
Bug #20563.
Shuang He
Carl Worth
Zhenyu Wang
Jesse Barnes
Hugo Jacques
Albert Damen
Ma, Ling
Kalev Lember
Rémi Cardona
Jesse Barnes
Keith Packard
Eric Anholt
Dan Nicholson
Kristian Høgsberg
Xiang, Haihao