- May 09, 2009
-
-
Carl Worth authored
Which means this is the first release candidate in preparation for 2.7.1.
-
Carl Worth authored
There are some nice bug fixes here.
-
- May 08, 2009
-
-
The spec says this command takes an extra (mbz) 32-bit value, so let's provide it with one. Signed-off-by: Keith Packard <keithp@keithp.com> (cherry picked from commit ed492131)
-
If a virtual display with width > 2048 is used, the first time an XV buffer is needed will result in a BadAlloc error message, but the next time X would crash. Signed-off-by: Eric Anholt <eric@anholt.net> (cherry picked from commit d7ca870e)
-
- May 06, 2009
-
-
Carl Worth authored
i915 textured video commands are quite long, but must be contained in the same batch buffer as the 3D setup commands. When the number of clip rects for the video becomes too large for the associated commands to fit in the same batch buffer, this change breaks the sequence into pieces, ensuring that each batch contains the necessary setup sequence. Signed-off-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 8255cca2) Conflicts: src/i915_video.c
-
Carl Worth authored
The optimization of unreferencing the binding table when the relocation is posted causes the object to be dereferenced for each box in the clip list, causing general chaos in the buffer manager. It's easier to just hold a reference to the object until all of the boxes are painted and then drop it. Signed-off-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 11a853bd) Conflicts: src/i965_video.c
-
intel_batch_start_atomic takes an argument in 32-bit units, and so it must multiply that by 4 before passing it to intel_batch_require_space, which takes an argument in bytes. We should figure out what units we want to use and use the same everywhere... Signed-off-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 1142353b)
-
- Apr 17, 2009
-
-
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>
-
- Apr 16, 2009
-
-
Carl Worth authored
Thanks to Gordon Jin for these suggestions. (cherry picked from commit 73c3be1a)
-
- Apr 15, 2009
-
-
Carl Worth authored
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>. (cherry picked from commit 3fd5a1ec)
-
Carl Worth authored
Hoping to cut off some false bug reports here. (cherry picked from commit e1cace16)
-
Carl Worth authored
In preparation for new major release.
-
Carl Worth authored
These new files don't do us much good if we don't distribute them in our releases. (cherry picked from commit 9ffd1951)
-
Carl Worth authored
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). (cherry picked from commit e4cd9de2)
-
Carl Worth authored
Stale documentation considered harmful of course. (cherry picked from commit 506c810f)
-
Carl Worth authored
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). (cherry picked from commit b9716b83)
-
Carl Worth authored
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). (cherry picked from commit 8deb3a37)
-
- Apr 13, 2009
-
-
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> (cherry picked from commit 9b615a52)
-
(cherry picked from commit 05343299)
-
(cherry picked from commit 62ba7211)
-
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 (cherry picked from commit 69388953)
-
Carl Worth authored
Thanks to Jesse Barnes for the original recipe. (cherry picked from commit 6d345c49)
-
- Apr 10, 2009
-
-
Carl Worth authored
-
- Apr 08, 2009
-
-
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 620e97bb)
-
- Apr 07, 2009
-
-
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 0a0731c1)
-
Carl Worth authored
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 940c2aad)
-
fix bug #19529 (cherry picked from commit 63b4b5ef)
-
- Apr 06, 2009
-
-
Carl Worth authored
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 5d9d9a2e)
-
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 7c94227d)
-
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 48db5bde)
-
Carl Worth authored
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 3d4ee3ca)
-
Carl Worth authored
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 bc3312fd)
-
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 6cd914ef)
-
Found by Hugo Jacques <hugo.jacques@verint.com> (cherry picked from commit fad714c4)
-
(cherry picked from commit 00de1757)
-
- Apr 01, 2009
-
-
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 087f72e1)
-
Both methods ACPI lid and SWF bit have issues in LVDS detect from wider testing. Fallback to origin code. (cherry picked from commit 4f046af7)
-
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 f1ed73c1 (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 e964d4e5)
-
Need the new functions available. (cherry picked from commit 51cf8a45)
-
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 8dabcc40)
-