Rob got missed from my first scan since one commit lists his name as
just 'Rob' and 3 commits don't attribute him as author:
83d304c61a7552d80e366eecef4fed
We've added a NEWS file now, so that needs to be updated for each release.
We're also now using tag names of just <version> rather than
xf86-video-intel-<version>.
It will be nice to have release-notes under revision control, as well
being able to document issues in an obviously time-sensitive file,
(as opposed to README where we were documenting some of this previously).
This is a sorted list of everyone with more than 2 commits in the git
revision history. We also list some historical authors mentioned in the
man page, (with code presumably pre-dating the beginning of revision
history).
This was all very stale, and is better convered in intel.man. We replace
this with a list of pointers to where to get current information, (man
page, web site, and mailing list).
This code disabled front buffer tiling in KMS. Turn it on since kernel
handles all tiling now, this improves performance of x11perf -aa10text
from 97k to 286k on my 945GME.
Should help with #20761, if not totally fix it.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Li Peng <peng.li@intel.com>
Almost all digital TVs accept broadcast RGB values from 16 to 235 for each channel,
otherwise for those uncompensated videos, when RGB values are set from 0 to 255,
they will shows black and whiter clamping, which seriously degrades picture quality.
The patch will enable the broadcast RGB mode for hdtv according to user's setting.
It fixed bug #14486
If we enable kernel execbuf fence register management, it's best if the
kernel manages all fence registers. This works fine if the accel
method is managing pixmaps or doesn't use offscreen pixmaps. However
with EXA, pixmap accesses are done relative to the framebuffer BAR
mapping (pI830->FbBase) and the Screen pixmap address. So if we try to
set the screen pixmap to point at a GTT mapped (and therefore properly
fenced) address, later calls to intel_get_pixmap_offset() will call
into EXA, which will use the pseudo-random pixmap addr and the EXA
offscreen base addr (which is really just FbBase) to calculate the
offset. This will fail. So disable kernel fence reg management in the
EXA case (this is easier than adding proper EXA pixmap management to
xf86-video-intel, and makes more sense since we'll be removing EXA soon
anyway).
Fixes FDO #21027.
Also happens to fix FDO #21029 (as tested by Carl Worth <cworth@cworth.org).
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.
Carl Worth
Robert Lowery
Li Peng
Ma Ling
Jesse Barnes
Jesse Barnes
Shuang He
Zhenyu Wang
Hugo Jacques
Albert Damen
Kalev Lember
Rémi Cardona
Jesse Barnes
Keith Packard
Eric Anholt