| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
man/intel.man
src/i830_dri.c
src/i830_driver.c
|
|
|
|
|
|
|
|
It was broken on current kernels, and deprecated anyway.
(cherry picked from commit c7db3201106f07f3228c989014d6db5ace5378f6)
|
|
It never worked with any upstream linux kernel, and is quite heavily
deprecated. A new solution based around DRI2 will probably be
forthcoming. Pageflipping itself is next.
(cherry picked from commit c82adfd0169317efb6c2f9de0f315651f9adbae1)
|
|
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).
(cherry picked from commit 620e97bbd6a811ad69b8ac94df1fe2c9edf65549)
|
|
|
|
|
|
|
|
|
|
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.
(cherry picked from commit 0a0731c11d10392cdc55ecc04e4e3575c8b3fe57)
|
|
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.
(cherry picked from commit 940c2aad4d174b6609bdc49f8c99a4bc37926516)
|
|
fix bug #19529
(cherry picked from commit 63b4b5efac936c674dedad8125a8dbac4f000908)
|
|
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.
(cherry picked from commit 5d9d9a2e466474a0508a15b294a91507ccb3ccc1)
|
|
construct function to find precise parameters from internal spreadsheet
table on G4X platform.
Signed-off-by: Ma Ling <ling.ma@intel.com>
(cherry picked from commit 7c94227dd4fa2164bebb36234958053bf1d26c12)
|
|
These timings on G4X platform were specified by internal spreadsheet from the chipset group.
Signed-off-by: Ma Ling <ling.ma@intel.com>
(cherry picked from commit 48db5bde9298f1126dfb42f4be8a3d61166abfd8)
|
|
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.
(cherry picked from commit 3d4ee3cac1d63dfdf7b54c8ba577f3b77637499f)
|
|
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.
(cherry picked from commit bc3312fd7c03d09a231dfebfe390fe668ad15d1e)
|
|
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>
(cherry picked from commit 6cd914ef315036ce8e91c7b6492994353e8ed2d8)
|
|
Found by Hugo Jacques <hugo.jacques@verint.com>
(cherry picked from commit fad714c40078d22fff82dc0692a344f66ddf9680)
|
|
(cherry picked from commit 00de1757dd5776962bdd4c8968181878c2ebf4c9)
|
|
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>
(cherry picked from commit 087f72e1f5d7d11b8795ba80a842874f5a9bb01d)
|
|
Both methods ACPI lid and SWF bit have issues in LVDS detect from
wider testing. Fallback to origin code.
(cherry picked from commit 4f046af760b92c07f59664359453933fb5358e3d)
|
|
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.
(cherry picked from commit e964d4e53af3a47de6d09c884be1cc0044d03bea)
|
|
Need the new functions available.
(cherry picked from commit 51cf8a453c2bc2e8604bfc41a649e971c1ba5026)
|
|
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>
(cherry picked from commit 8dabcc40747bfd478f296728741240241698f165)
|
|
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.
(cherry picked from commit 375b2e40fcb17e94538a75392950e2533c1bb031)
|
|
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>
(cherry picked from commit b5b377806422c9538fa9f846819ad253c1a50846)
|
|
drm_intel_bo_unpin() was called with NULL argument.
Signed-off-by: Kalev Lember <kalev@smartlink.ee>
(cherry picked from commit 74d0713e002a9781ed00fdd10eb6f75907ae796c)
|
|
The i810 compatibility symlink has been broken since libpciaccess, so just
let it die.
(cherry picked from commit b345b4e6adf00f8b2626e5c2563fc159e2295cc5)
|
|
Don't try to clear fences that were never installed. Missed this bit in
the last fix for #20265.
(cherry picked from commit 48b91e066878db63a1558e4cd3e6d12ff9c49197)
|
|
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>
(cherry picked from commit 636d252f3b1eac687f7b11952e949c383cb86ed4)
|
|
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.
(cherry picked from commit 73db44e7ac524e84e5f0fda2d60069a9e954ad1b)
|
|
All 8xx class chips have the 66/48 split, not just 855.
Fixes #18358.
(cherry picked from commit 85e6b528582c2397ee9eb2132cd0d05ce12eb43d)
|
|
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.
(cherry picked from commit bedc894a565ce3c7a50990e3f78953fc2432ad40)
|
|
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.
(cherry picked from commit 6deb26ae7bd796e88a5dd90df5f6c35fbc44e798)
|
|
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>
(cherry picked from commit fe08b81d0f5d6f96e0124e6286bd24aba6e140ad)
(also includes revert from fe08b81d0f5d6f96e0124e6286bd24aba6e140ad)
(and revert from from 78a60e1b66fe2e8449702dd43d9b062d279af8f1)
The reverts simply eliminate some unrelated changes accidentally included
with the first commit.
|
|
Bug #20670.
(cherry picked from commit 1a6e70cd98abc63f24f710819961c24601afb59b)
|
|
In order to bypass failure in TV load detect, TV_Connector option
will always force TV as connected with user specified connector type.
(cherry picked from commit 4e95327323e3d081b565147f7738eb49c28542bc)
|
|
Bug #20585.
(cherry picked from commit 2026c57cf0a352d9e6f9d208cfb7d4d550614477)
|
|
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.
(cherry picked from commit 3ef9d85371a97ea5baee0c47787b3bb3cdaf5135)
|
|
This reverts commit ddedf19f889da2ce6d69a3afce4665e2245682fa.
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.
(cherry picked from commit dc3ff0b514b609448025680778f0e95e1980a5d8)
|
|
For multifunction encoder, forget to reset these values
will cause wrong output type in later mode setting
operations.
(cherry picked from commit c6b0135d209bdad3dbc641d0e264596eaf6f99d3)
|
|
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>
(cherry picked from commit 28e7f0d71fa09e15a68ab4f0de169474b6235093)
|
|
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.
(cherry picked from commit 2fcf4fcccfe7cfa1425985d21a144137eca07f4e)
|
|
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.
(cherry picked from commit fb6e00f40f713a87c760fc7603159ed11ea9b0d5)
|
|
This is a version number increment for the new release-candidate
tar file. As can be seen in the git history, there are no code
changes here. Instead, the incremented version simply captures
the fact that unlike .901, the .902 tar file has been built
correctly. Specifically, it was built this time on a system with
xmvclib present so all the necessary source files for building
against xmvclib are now included in the tar file.
|
|
It sure seems like a bizarre numbering scheme to me, but it also
seems like the x.org way of doing things, (at least for now).
|
|
Fixes segfaults at startup with DRI2 and load detection, or with DRI disabled
entirely.
|
