Age | Commit message (Collapse) | Author |
|
This cleans up findstatic.pl output for the i830+ code, which resulted in
removing some code. The only odd part of this commit is the
if (0) i830_sdvo_dump() in i830_sdvo.c -- it tells the compiler that the code
is used, without using it since we want the code around while debugging.
It's also in a likely place to ask for the dump, so I think it's OK.
|
|
|
|
|
|
|
|
|
|
|
|
I don't think anyone tests this against an old server anymore.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Note that pScrn->videoRam is an 'int'.
i830_driver.c: In function ‘I830ScreenInit’:
i830_driver.c:3019: warning: overflow in implicit constant conversion
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Thanks to Robert Lowery for the sharp eyes on this one.
|
|
Stale documentation considered harmful of course.
|
|
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
|
|
Just add a dummy ret variable to shut up gcc.
|
|
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.
|
|
fix bug #19529
|
|
We need to account for a non-zero Y offset for the CRTC. Without
this, we don't sync to the correct region, so tearing becomes
visible again.
|
|
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>
|
|
Found by Hugo Jacques <hugo.jacques@verint.com>
|
|
|
|
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>
|
|
Both methods ACPI lid and SWF bit have issues in LVDS detect from
wider testing. Fallback to origin code.
|
|
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>
|
|
As wider tests showed that this doesn't work for all VBIOS, so
disable it for now and reenable it after we get reliable method.
|
|
|
|
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>
|
|
drm_intel_bo_unpin() was called with NULL argument.
Signed-off-by: Kalev Lember <kalev@smartlink.ee>
|
|
The i810 compatibility symlink has been broken since libpciaccess, so just
let it die.
|
|
Don't try to clear fences that were never installed. Missed this bit in
the last fix for #20265.
|
|
|
|
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>
|
|
This was mistakenly added in the unrelated change in revision
fe08b81d0f5d6f96e0124e6286bd24aba6e140ad
and wasn't completely reverted in the later revision
78a60e1b66fe2e8449702dd43d9b062d279af8f1
|
|
All 8xx class chips have the 66/48 split, not just 855.
Fixes #18358.
|
|
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.
|
|
construct function to find precise parameters from internal spreadsheet
table on G4X platform.
Signed-off-by: Ma Ling <ling.ma@intel.com>
|
|
These timings on G4X platform were specified by internal spreadsheet from the chipset group.
Signed-off-by: Ma Ling <ling.ma@intel.com>
|
|
This was mistakenly added in the unrelated change in revision
fe08b81d0f5d6f96e0124e6286bd24aba6e140ad
|
|
Bug #20670.
|
|
In order to bypass failure in TV load detect, TV_Connector option
will always force TV as connected with user specified connector type.
|
|
|
|
The debug dumper functions can now return NULL to indicate no output, so
we get appropriate results on 915, 945, and 965.
|
|
It's nice to know when it gets stomped on.
|