Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Thu, Sep 11, 2014 at 12:53:30PM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: That extra alignment is due to gen2 and early gen3 (if (!intel-has_relaxed_fencing) covers them). Here's the patch which changed the alignment requirment: [snip commits picked at random] This is the root commit d21d781466785c317131a8a57606925867265dc8 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Feb 22 18:31:44 2011 +0100 Fix relaxed tiling on gen2 Later we went on to disable relaxed tiling even after believing we had fixed all the kernel bugs: commit 686018f283f1d131073ef5917213e6a8ac013f26 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Apr 12 08:23:04 2011 +0100 Turn relaxed-fencing off by default for older (pre-G33) chipsets I believe the even-tile row alignment is still key to having gen2/gen3 function with relaxed fencing. If you have specific bug reports that were resolved by this patch, or specific hardware documentation which indicates that this patch is required, especially as it relates to gen2 and gen3 hardware, I'd love to see them. Try enabling relaxed fencing again. In any case, we've now got four versions of the pixmap alignment code (libdrm, uxa and sna in two varieties). They're all subtly different; one suspects that each one works on some set of problems and fails on others... Here's what the height alignment requirements are: libdrm uxa uxa sna sna +keithp=2.6.38 2.6.38 gen2 none 2 2 2 1 2 gen3 none 2 2 2 1 2 gen4+ none2 2 2 1 1 gen2 X 16 16 32 16 32 gen3 X8 8 16 8 16 gen4+ X 8 8 16 8 8 gen2 Y 16 16 32 16 32 i915 Y8 32 64 8 16 i945 Y 32 32 64 8 16 gen4+ Y 32 32 64 32 32 It looks like the SNA alignment for untiled buffers is incorrect? 965 hardware is documented to read buffers in 2x2 chunks, so a failure to height align allocations to 2 can result in reads off the end of the buffer. Reading from the scratch page is not a problem. Reading from neighbouring surfaces is of no concern. The allocation must be suitable and aligned appropriately for writes, but writes themselves are appropriately clipped. Otherwise one extra row doesn't save you from scribbling over anywhere in your gtt. For uxa's intel_set_pixmap_bo, and sna's sna_dri3_pixmap_from_fd, there's a clear requirement that the 2D driver impose no stricter alignment than libdrm, so that, buffer passing from Mesa to X will work. No. The clearest requirement is that the ddx (or other display server) must treat incoming surfaces as tainted and validate them to be sure that they work with its code paths. If it can't we have a choice of either rejecting them outright, or staging them. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote: [PATCH 2/2] Correct BO allocation alignment This patch makes UXA and Mesa agree about how buffers are allocated for images. Without this, UXA was requiring larger padding, which meant that converting some textures into pixmaps using DRI3 would fail. That extra alignment is due to gen2 and early gen3 (if (!intel-has_relaxed_fencing) covers them). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Thu, Sep 11, 2014 at 12:47:21AM -0600, Jasper St. Pierre wrote: Why doesn't mesa allocate buffers in the same way for those chips, then? Good question. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.915
Snapshot 2.99.915 (2014-09-08) == A significant change to UXA to enable MST and to keep it working on recent kernels needs some soaking before a major release, and the usual plethora of bugfixes. One other feature is the support for hardware rotations on very recent kernels. * Handle rotated scanouts that are all clear correctly. The region to update was not being computed correctly, overdrawing the wrong CRTC. https://bugs.freedesktop.org/show_bug.cgi?id=81820 * Reset cursor images after rotation and size changes https://bugs.freedesktop.org/show_bug.cgi?id=81886 https://bugs.freedesktop.org/show_bug.cgi?id=82273 https://bugs.freedesktop.org/show_bug.cgi?id=82337 * Handle stale DRI2 buffers and Client errors more gracefully * Fallback if we fail to render a glyph onto a too-large surface, e.g. direct rendering of glyphs onto extended desktops with gen2/gen3. https://bugs.archlinux.org/task/40949 * Further work to enable tiled rendering onto large surfaces in severely aperture and memory constrained devices (e.g. gen2/gen3) * Honour the Primary option from xorg.conf and mark that as the RandR primary. https://bugs.freedesktop.org/show_bug.cgi?id=82193 https://bugs.freedesktop.org/show_bug.cgi?id=82205 * Fix another Client-Window DRI2 close race https://bugs.freedesktop.org/show_bug.cgi?id=82979 * Fix incorrect discarding of GPU damage when copying over the TearFree scanout - which caused a flicker in rapidly updated elements (like simple video panes). https://bugs.freedesktop.org/show_bug.cgi?id=81973 Complete list of changes since 2.99.914 --- Chris Wilson (93): sna: Disable rendering with the DRM device whilst away from VT backlight: Set structure to safe values when not initialised sna: Keep the backlight at the same brightness when switching away backlight: Remove unused 'original' member from structure sna: Sort the outputs to provide a stable listing order configure: Expose no acceleration by default (--with-default-accel=none) sna: Fix clear shortcut for transformations sna: Clear cursor image after rotation sna: Select the panel native size of the unattached fb size sna: Always clear CRTC overrides when adjusting the mode sna: Skip grabbing the main framebuffer id sna/dri2: Also check for stale buffers before exchanges sna: Silence a compiler warning i810: Fix startup after marking GPU screens in the module sna/glyphs: Fallback to masked glyphs if rendering to a too wide dst sna/glyphs: Eliminate an extra conditional from glyphs-to-dst sna: Remove dead assertion sna: Restrict fencing to only use the low 256MiB sna: Relax restriction on fenced aperture check sna: Add some paranoid asserts around get_window_pixmap() sna: Rearrange showing cursors sna: Restore single CRTC flips sna: Add the current CRTC mode last sna: Mark the current mode as preferred if no other mode is sna: Add some extra logging for hotplugging of outputs sna: Add DSI to the list of recognised panel connectors. sna: Add intermediate modes to any output with a scaler sna: Set the RandR primary output from the option intel: Use NOACCEL to avoid a symbol clash on old Xorg sna: Enable kernel rotation support by default test: Exercise different cursor sizes sna: Flush cursor width changes uxa: Compile fix for Ubuntu 11.04 sna: Clear old cursors when resizing Prepare for spurious Xv ABI changes sna: Restore the clear before pwriting the cursor sna: Update check for static driver data on loading error intel: Log open clients on master takeover fail intel: If need be, try mounting debugfs sna: Reorder output array to match primary placement for InitialConfiguration sna: Respect monitor option DefaultModes sna: Parse output options early during initialisation sna: Separate panel checks from adding default modes sna: Suppress switch to mode messages for internal CRTC applies sna: Only apply a DPMS change for an enabled CRTC sna: Relax the square cursor assumption sna/dri2: Fix compilation with Xorg-1.12.4 sna: Use a shadow buffer for linear framebuffer sna: Do not force creation of a linear GPU bo that we don't want sna: Add error message to explain modesetting failures due to allocation sna: DBG Log all failure paths in allocating CRTC pixmaps sna: DBG log all bo allocation failure paths sna: DBG log invalid surface sizes sna: Select appropriate tiling mode for TearFree shadow buffer intel: Only dump debugfs on linux test: Only compile lowlevel-blt-bench if we have shm test: Make SHM tests in lowlevel-blt-bench optional sna: Add some DBG warnings for early PreInit
Re: [PATCH] pixmap: fix reverse optimus support with multiple heads
On Tue, Jul 30, 2013 at 01:50:48PM +1000, Dave Airlie wrote: For doing reverese optimus to multiple outputs on a secondary GPU the GPU can store the blits into a large screen pixmap, unfortunately this means we need a destination offset into the dirty code, so add a new API that just adds this interface. Signed-off-by: Dave Airlie airl...@redhat.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] linux: Automatically ShareVTs if the VT are already in graphics mode
On Wed, Aug 13, 2014 at 10:58:54AM +0100, Chris Wilson wrote: If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE will silently fail. This leads to an indefinite hang as WAITACTIVE never returns causing lockups on boot. This issue becomes apparent when the kernel driver does not install a fbdev for kernel to use for consoles and plymouth leaves the VT in graphics mode. It stops the hang on boot, but it also leaves process control on the defunct VT (i.e. ^C kills Xorg). Can we do the console switch without WAITACTIVE? Also doesn't explain why it works the second time. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] linux: Automatically ShareVTs if the VT are already in graphics mode
If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE
will silently fail. This leads to an indefinite hang as WAITACTIVE never
returns causing lockups on boot. This issue becomes apparent when the
kernel driver does not install a fbdev for kernel to use for consoles
and plymouth leaves the VT in graphics mode.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Adam Jackson a...@redhat.com
---
hw/xfree86/os-support/linux/lnx_init.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/xfree86/os-support/linux/lnx_init.c
b/hw/xfree86/os-support/linux/lnx_init.c
index 85709c6..b201310 100644
--- a/hw/xfree86/os-support/linux/lnx_init.c
+++ b/hw/xfree86/os-support/linux/lnx_init.c
@@ -86,6 +86,7 @@ xf86OpenConsole(void)
MessageType from = X_PROBED;
const char *tty0[] = { /dev/tty0, /dev/vc/0, NULL };
const char *vcs[] = { /dev/vc/%d, /dev/tty%d, NULL };
+int kdmode;
if (serverGeneration == 1) {
/*
@@ -188,6 +189,14 @@ xf86OpenConsole(void)
else
activeVT = vts.v_active;
+ /* If the console is already in graphics mode, e.g. if there is
+* no text console in the kernel, we cannot do any VT switching
+* and so must share the vt.
+*/
+ SYSCALL(ret = ioctl(xf86Info.consoleFd, KDGETMODE, kdmode));
+ if (ret == 0 kdmode == KD_GRAPHICS)
+ xf86Info.ShareVTs = TRUE;
+
#if 0
if (!KeepTty) {
/*
--
2.1.0.rc1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] udev: Do not attempt to remove GPUs for connector updates
With the advent of MST we now receive notifications through uevents of
not just the comings and goings of the GPUs themselves, but of the
individual connectors. Differentiate between these events and filter out
the calls to add/remove the actual GPU if we only have topology updates.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
---
config/udev.c | 82 ---
1 file changed, 50 insertions(+), 32 deletions(-)
diff --git a/config/udev.c b/config/udev.c
index 1e4a9d7..dbe32c4 100644
--- a/config/udev.c
+++ b/config/udev.c
@@ -69,6 +69,23 @@ static const char *itoa(int i)
return itoa_buf;
}
+static enum { NO, OTHER, GPU } is_drm_device(struct udev_device *device)
+{
+const char *sysname;
+
+if (strcmp(udev_device_get_subsystem(device), drm))
+ return NO;
+
+sysname = udev_device_get_sysname(device);
+if (strncmp(sysname, card, 4))
+ return OTHER;
+
+if (strchr(sysname, '-'))
+ return OTHER;
+
+return GPU;
+}
+
static void
device_added(struct udev_device *udev_device)
{
@@ -87,7 +104,6 @@ device_added(struct udev_device *udev_device)
dev_t devnum;
path = udev_device_get_devnode(udev_device);
-
syspath = udev_device_get_syspath(udev_device);
if (!path || !syspath)
@@ -106,21 +122,18 @@ device_added(struct udev_device *udev_device)
devnum = udev_device_get_devnum(udev_device);
#ifdef CONFIG_UDEV_KMS
-if (!strcmp(udev_device_get_subsystem(udev_device), drm)) {
-const char *sysname = udev_device_get_sysname(udev_device);
-
-if (strncmp(sysname, card, 4) != 0)
-return;
-
-/* Check for devices already added through xf86platformProbe() */
-if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))
-return;
-
-LogMessage(X_INFO, config/udev: Adding drm device (%s)\n, path);
-
-config_udev_odev_setup_attribs(path, syspath, major(devnum),
- minor(devnum), NewGPUDeviceRequest);
-return;
+switch (is_drm_device(udev_device)) {
+case NO:
+ break;
+case GPU:
+ /* Check for devices already added through xf86platformProbe() */
+ if (!xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))
{
+ LogMessage(X_INFO, config/udev: Adding drm device (%s)\n, path);
+ config_udev_odev_setup_attribs(path, syspath, major(devnum),
+ minor(devnum), NewGPUDeviceRequest);
+ }
+case OTHER:
+ return;
}
#endif
@@ -291,25 +304,30 @@ device_added(struct udev_device *udev_device)
static void
device_removed(struct udev_device *device)
{
-char *value;
+dev_t devnum = udev_device_get_devnum(device);
const char *syspath = udev_device_get_syspath(device);
+char *value;
-#ifdef CONFIG_UDEV_KMS
-if (!strcmp(udev_device_get_subsystem(device), drm)) {
-const char *sysname = udev_device_get_sysname(device);
-const char *path = udev_device_get_devnode(device);
-dev_t devnum = udev_device_get_devnum(device);
-
-if (strncmp(sysname,card, 4) != 0)
-return;
-ErrorF(removing GPU device %s %s\n, syspath, path);
-if (!path)
-return;
+if (syspath == NULL)
+ return;
-config_udev_odev_setup_attribs(path, syspath, major(devnum),
- minor(devnum), DeleteGPUDeviceRequest);
-/* Retry vtenter after a drm node removal */
-systemd_logind_vtenter();
+#ifdef CONFIG_UDEV_KMS
+switch (is_drm_device(device)) {
+case NO:
+ break;
+case GPU:
+ if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum))) {
+ const char *path = udev_device_get_devnode(device);
+ if (path) {
+ LogMessage(X_INFO, config/udev: Removing drm device (%s)\n,
path);
+ config_udev_odev_setup_attribs(path, syspath,
+ major(devnum), minor(devnum),
+ DeleteGPUDeviceRequest);
+ /* Retry vtenter after a drm node removal */
+ systemd_logind_vtenter();
+ }
+ }
+case OTHER:
return;
}
#endif
--
2.0.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.914
Snapshot 2.99.914 (2014-07-23) == And a brown paper bag to hide the rebuilding from the tarball with 'autoreconf -fi' error that arose from not distributing the libobj/ directory. Complete list of changes since 2.99.913 --- Chris Wilson (4): Fix compile failure on old Xorg with XF86_ALLOCATE_GPU_SCREEN Add automake magic required for libobj/ sna/dri2: Compile fix for old xorg/dri2 2.99.914 snapshot git tag: 2.99.914 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.914.tar.bz2 MD5: b53d96cb42fb1d71f0b671dd2064cba4 xf86-video-intel-2.99.914.tar.bz2 SHA1: a2d8415dd4be514720b8470399d5d22d9fb4caa8 xf86-video-intel-2.99.914.tar.bz2 SHA256: 78a22e5efd460b790c634caaf1afbb756046dd890482e204bb0d179baad27e46 xf86-video-intel-2.99.914.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.914.tar.gz MD5: 1298bfa698fe60583a2b410473d24df9 xf86-video-intel-2.99.914.tar.gz SHA1: e74591cad6968026e741e558fc51504bf61f62b8 xf86-video-intel-2.99.914.tar.gz SHA256: 6c26e2d5bf440ef0028aae4e00a5432f9c88f4eb61eeadb7a169cbe909b9e81b xf86-video-intel-2.99.914.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH 2/3] randr: Consider rotation of slaved crtcs when computing bounds
When creating a pixmap to cover a rotated slaved CRTC, we need to
consider its rotated size as that is the area that it occupies in the
framebuffer. The slave is then responsible for mapping the copy of the
framebuffer onto the rotated scanout - which can be the usual RandR
shadow composite method.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
---
randr/rrcrtc.c | 56
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 8f881b5..4d3e31c 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -279,27 +279,43 @@ RRCrtcPendingProperties(RRCrtcPtr crtc)
return FALSE;
}
-static void
-crtc_bounds(RRCrtcPtr crtc, int *left, int *right, int *top, int *bottom)
+static int mode_height(const RRModeRec *mode, Rotation rotation)
{
-*left = crtc-x;
-*top = crtc-y;
-
-switch (crtc-rotation) {
+switch (rotation 0xf) {
case RR_Rotate_0:
case RR_Rotate_180:
+ return mode-mode.height;
+case RR_Rotate_90:
+case RR_Rotate_270:
+ return mode-mode.width;
default:
-*right = crtc-x + crtc-mode-mode.width;
-*bottom = crtc-y + crtc-mode-mode.height;
-return;
+ return 0;
+}
+}
+
+static int mode_width(const RRModeRec *mode, Rotation rotation)
+{
+switch (rotation 0xf) {
+case RR_Rotate_0:
+case RR_Rotate_180:
+ return mode-mode.width;
case RR_Rotate_90:
case RR_Rotate_270:
-*right = crtc-x + crtc-mode-mode.height;
-*bottom = crtc-y + crtc-mode-mode.width;
-return;
+ return mode-mode.height;
+default:
+ return 0;
}
}
+static void
+crtc_bounds(RRCrtcPtr crtc, int *left, int *right, int *top, int *bottom)
+{
+*left = crtc-x;
+*top = crtc-y;
+*right = crtc-x + mode_width(crtc-mode, crtc-rotation);
+*bottom = crtc-y + mode_height(crtc-mode, crtc-rotation);
+}
+
/* overlapping counts as adjacent */
static Bool
crtcs_adjacent(const RRCrtcPtr a, const RRCrtcPtr b)
@@ -472,9 +488,9 @@ rrCheckPixmapBounding(ScreenPtr pScreen,
if (!pScrPriv-crtcs[c]-mode)
continue;
newbox.x1 = pScrPriv-crtcs[c]-x;
-newbox.x2 = pScrPriv-crtcs[c]-x +
pScrPriv-crtcs[c]-mode-mode.width;
+ newbox.x2 = pScrPriv-crtcs[c]-x +
mode_width(pScrPriv-crtcs[c]-mode, pScrPriv-crtcs[c]-rotation);
newbox.y1 = pScrPriv-crtcs[c]-y;
-newbox.y2 = pScrPriv-crtcs[c]-y +
pScrPriv-crtcs[c]-mode-mode.height;
+ newbox.y2 = pScrPriv-crtcs[c]-y +
mode_height(pScrPriv-crtcs[c]-mode, pScrPriv-crtcs[c]-rotation);
}
RegionInit(new_crtc_region, newbox, 1);
RegionUnion(total_region, total_region, new_crtc_region);
@@ -493,9 +509,9 @@ rrCheckPixmapBounding(ScreenPtr pScreen,
if (!slave_priv-crtcs[c]-mode)
continue;
newbox.x1 = slave_priv-crtcs[c]-x;
-newbox.x2 = slave_priv-crtcs[c]-x +
slave_priv-crtcs[c]-mode-mode.width;
+ newbox.x2 = slave_priv-crtcs[c]-x +
mode_width(slave_priv-crtcs[c]-mode, slave_priv-crtcs[c]-rotation);
newbox.y1 = slave_priv-crtcs[c]-y;
-newbox.y2 = slave_priv-crtcs[c]-y +
slave_priv-crtcs[c]-mode-mode.height;
+ newbox.y2 = slave_priv-crtcs[c]-y +
mode_height(slave_priv-crtcs[c]-mode, slave_priv-crtcs[c]-rotation);
}
RegionInit(new_crtc_region, newbox, 1);
RegionUnion(total_region, total_region, new_crtc_region);
@@ -560,8 +576,8 @@ RRCrtcSet(RRCrtcPtr crtc,
int width = 0, height = 0;
if (mode) {
-width = mode-mode.width;
-height = mode-mode.height;
+ width = mode_width(mode, rotation);
+ height = mode_height(mode, rotation);
}
DBG((have a master to look out for\n));
ret = rrCheckPixmapBounding(master, crtc,
@@ -1687,8 +1703,8 @@ RRReplaceScanoutPixmap(DrawablePtr pDrawable, PixmapPtr
pPixmap, Bool enable)
changed = FALSE;
if (crtc-mode crtc-x == pDrawable-x
crtc-y == pDrawable-y
-crtc-mode-mode.width == pDrawable-width
-crtc-mode-mode.height == pDrawable-height)
+ mode_width(crtc-mode, crtc-rotation) == pDrawable-width
+ mode_height(crtc-mode, crtc-rotation) == pDrawable-height)
size_fits = TRUE;
/* is the pixmap already set? */
--
1.9.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/3] randr: Suppress debug messages from prime
Hide the ErrorF used for debugging behind an ifdefed out macro.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
---
randr/rrcrtc.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 69b3ecf..8f881b5 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -25,6 +25,12 @@
#include swaprep.h
#include mipointer.h
+#if 0
+#define DBG(x) ErrorF x
+#else
+#define DBG(x)
+#endif
+
RESTYPE RRCrtcType;
/*
@@ -428,7 +434,7 @@ rrCreateSharedPixmap(RRCrtcPtr crtc, int width, int height,
ret = pScrPriv-rrCrtcSetScanoutPixmap(crtc, spix);
if (ret == FALSE) {
-ErrorF(failed to set shadow slave pixmap\n);
+DBG((failed to set shadow slave pixmap\n));
return FALSE;
}
@@ -502,7 +508,7 @@ rrCheckPixmapBounding(ScreenPtr pScreen,
if (new_width == screen_pixmap-drawable.width
new_height == screen_pixmap-drawable.height) {
-ErrorF(adjust shatters %d %d\n, newsize-x1, newsize-x2);
+DBG((adjust shatters %d %d\n, newsize-x1, newsize-x2));
} else {
pScrPriv-rrScreenSetSize(pScreen, new_width, new_height, 0, 0);
}
@@ -557,7 +563,7 @@ RRCrtcSet(RRCrtcPtr crtc,
width = mode-mode.width;
height = mode-mode.height;
}
-ErrorF(have a master to look out for\n);
+DBG((have a master to look out for\n));
ret = rrCheckPixmapBounding(master, crtc,
x, y, width, height);
if (!ret)
@@ -565,7 +571,7 @@ RRCrtcSet(RRCrtcPtr crtc,
if (pScreen-current_master) {
ret = rrCreateSharedPixmap(crtc, width, height, x, y);
-ErrorF(need to create shared pixmap %d, ret);
+DBG((need to create shared pixmap %d\n, ret));
}
}
--
1.9.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/3] randr: Initialise the contents of the slaved scanout pixmap
Before we attach the slaved scanout pixmap we need to initialize its
contents as otherwise it may be some time before it is done so in the
next block handler or perhaps even after the next drawing, and
during that time the old uninitialised contents of the pixmap is
visible.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
---
randr/rrcrtc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 4d3e31c..c86ea1c 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -24,6 +24,7 @@
#include randrstr.h
#include swaprep.h
#include mipointer.h
+#include gcstruct.h
#if 0
#define DBG(x) ErrorF x
@@ -407,6 +408,34 @@ RRCrtcDetachScanoutPixmap(RRCrtcPtr crtc)
RRCrtcChanged(crtc, TRUE);
}
+static void
+rrInitSharedPixmap(PixmapPtr mpix, PixmapPtr spix, int x, int y)
+{
+ScreenPtr pScreen = mpix-drawable.pScreen;
+SourceValidateProcPtr SourceValidate;
+GCPtr pGC;
+
+/*
+ * SourceValidate is used by the software cursor code
+ * to pull the cursor off of the screen when reading
+ * bits from the frame buffer. Bypassing this function
+ * leaves the software cursor in place
+ */
+SourceValidate = pScreen-SourceValidate;
+pScreen-SourceValidate = NULL;
+
+pGC = GetScratchGC(mpix-drawable.depth, pScreen);
+ValidateGC(mpix-drawable, pGC);
+
+pGC-ops-CopyArea(mpix-drawable, spix-drawable, pGC,
+ x, y,
+ spix-drawable.width, spix-drawable.height,
+ 0, 0);
+FreeScratchGC(pGC);
+
+pScreen-SourceValidate = SourceValidate;
+}
+
static Bool
rrCreateSharedPixmap(RRCrtcPtr crtc, int width, int height,
int x, int y)
@@ -448,6 +477,8 @@ rrCreateSharedPixmap(RRCrtcPtr crtc, int width, int height,
return FALSE;
}
+rrInitSharedPixmap(mscreenpix, mpix, x, y);
+
ret = pScrPriv-rrCrtcSetScanoutPixmap(crtc, spix);
if (ret == FALSE) {
DBG((failed to set shadow slave pixmap\n));
--
1.9.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.913
Snapshot 2.99.913 (2014-07-23) == This should be it... A few fixes from testing the new code, we should be ready for the final release. However, we do have one standout feature in this snapshot, we now officially recognise HD Graphics 5300/5500/5600, Iris Graphics 6100 and Iris Pro Graphics 6200/P6300 (formerly known as Broadwell). * Check the window actually covers the CRTC before doing a single CRTC flip, and then restore the right framebuffer after completing CRTC flips. Otherwise we would detect an error and disable an output under TearFree Regression in 2.99.912 https://bugs.freedesktop.org/show_bug.cgi?id=80191 * Fix framebuffer creation on kernels older than 3.11 Regression in 2.99.912 * Check that the damage still exists after implicit reduction Regression in 2.99.912 https://bugs.freedesktop.org/show_bug.cgi?id=77436 * Fix direction flags for fallback composited CopyAreas which caused scrolling corruption in a few configurations Regression from 2.20.0 https://bugs.freedesktop.org/show_bug.cgi?id=79843 * Do not throw away damage if there is no redundant copy https://bugs.freedesktop.org/show_bug.cgi?id=79992 * Check clipping on PolyRect before discarding the clipped damage Regression from 2.99.903 https://bugs.freedesktop.org/show_bug.cgi?id=79992 * Fix hints for GLXPixmapa, as these are never swapped and so miss invalidating the hints on SwapBuffers with the result that they are often presumed blank Regression in 2.99.912 https://bugs.freedesktop.org/show_bug.cgi?id=7 * Fix incoherent choice of source bo when constructing 8x8 tiles, incorrect pattern origin when extracting, and then fix the alignment of colour patterns for BLT operations https://bugs.freedesktop.org/show_bug.cgi?id=80033 * Disable blending with the render engine on snoopable buffers https://bugs.freedesktop.org/show_bug.cgi?id=80253 * Restore throttling to prevent client lag under heavy GPU load Regression from 2.21.10 https://bugs.freedesktop.org/show_bug.cgi?id=77436 * Use ClientGone for notifications on shared DRI2 windows to prevent rare crashes due to use-after-free of the swap requests https://bugs.freedesktop.org/show_bug.cgi?id=80157 * Ensure the mmaped CPU bo is idle before migrating damage https://bugs.freedesktop.org/show_bug.cgi?id=80560 * Fix incorrect clipping by the render engine for large DRI2 windows * Ensure that the aperture tiling fallbacks are bounded * Validate parameter to xf86-video-intel-backlight-helper more carefully (CVE-2014-4910) * Fix slaved scanouts for reverse optimus, though rotated slaves will require further patches to Xorg. https://bugs.freedesktop.org/show_bug.cgi?id=81383 * Fix build without Composite extension. * Fix build without gettline(). * UXA: Allocate and resize frontbuffer consistently to pass sanity checks https://bugs.freedesktop.org/show_bug.cgi?id=80088 * UXA: Report cached backlight value when the output is off (like sna) https://bugzilla.redhat.com/show_bug.cgi?id=1032978 * UXA: Mark outputs as off before the kernel does (like sna) This will prevent the internal panel from starting up blank in some multi-monitor configurations https://bugzilla.redhat.com/show_bug.cgi?id=1103806 Note that the DRI2 exchange mechanism introduced in 2.99.912 exposes bugs in some compositors, at least kwin and comptom, which discard DRI2 buffer invalidates rather than resourcing their texture. For example, https://bugs.kde.org/show_bug.cgi?id=336589 Note that the improved triple buffering introduced in DRI2 requires a patch to Xorg (now released upstream) to prevent crashes with DRI_PRIME. https://bugs.freedesktop.org/show_bug.cgi?id=80001 Note that DRI3/Present require tracking the relevant development trees for mesa and the xserver as they are very much still under early testing. Also be aware that Mesa provides no support for explicit fencing so Damage tracking between compositors and clients is unserialised. Complete list of changes since 2.99.912 --- Chris Wilson (254): sna: Handle the user passing Backlight sna: Tidy a few asserts on the state of crtc-flip_bo sna: Fix arguments when flipping transformed TearFree outputs sna: Expand debugging to cover gen8 BLT variations sna: Cast away compiler warning sna/dri2: Check that the window covers the whole CRTC before xchg sna: Mark the GPU as all damaged when discarding CPU bo during uploads sna: Squelch log messages for fb/pixmap tiling in the default case sna: Silence compiler warnings for discarding const Region points sna: Discard TearFree damage before checking for an overwriting upload sna: Prefer to operate inplace on the GPU rather than stall on the CPU sna: Ignore setting read-only for temporary userptr maps sna: Create a stable output name based
Re: [PATCH 14/16] xv: Drop the ClientPtr from the interface to the DDX.
On Fri, Jul 18, 2014 at 10:32:31AM -0700, Eric Anholt wrote: Nobody was using it. The ClientPtr gets used to send events back to the Client from various implementations of Xv. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] modesetting: Support native primary plane rotation
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove one
opencoded define.
v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
Use libobj for replacement ffs(), suggested by walter harms
v3: Support combinations of rotations and reflections
Eliminate use of ffs() and so remove need for libobj
v4: And remove the vestigal HAVE_FFS, spotted by Mark Kettenis
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Pekka Paalanen ppaala...@gmail.com
Cc: walter harms wha...@bfs.de
Cc: Mark Kettenis mark.kette...@xs4all.nl
---
configure.ac | 2 +-
src/drmmode_display.c | 258 --
src/drmmode_display.h | 7 +-
3 files changed, 234 insertions(+), 33 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1c1a36d..783c243 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,7 +74,7 @@ AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test $HAVE_XEXTPROTO_71
= yes ])
# Checks for header files.
AC_HEADER_STDC
-PKG_CHECK_MODULES(DRM, [libdrm = 2.4.46])
+PKG_CHECK_MODULES(DRM, [libdrm = 2.4.47])
PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.10])
AM_CONDITIONAL(DRM, test x$DRM = xyes)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c533324..93c48ac 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -56,6 +56,8 @@
#include driver.h
+#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2 /* from libdrm 2.4.55 */
+
static struct dumb_bo *dumb_bo_create(int fd,
const unsigned width, const unsigned height,
const unsigned bpp)
@@ -300,6 +302,171 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
#endif
+static void
+rotation_init(xf86CrtcPtr crtc)
+{
+ drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
+ drmmode_ptr drmmode = drmmode_crtc-drmmode;
+ drmModePlaneRes *plane_resources;
+ int i, j, k;
+
+ drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+
+ plane_resources = drmModeGetPlaneResources(drmmode-fd);
+ if (plane_resources == NULL)
+ return;
+
+ for (i = 0; drmmode_crtc-primary_plane_id == 0 i
plane_resources-count_planes; i++) {
+ drmModePlane *drm_plane;
+ drmModeObjectPropertiesPtr proplist;
+ int is_primary = -1;
+
+ drm_plane = drmModeGetPlane(drmmode-fd,
+ plane_resources-planes[i]);
+ if (drm_plane == NULL)
+ continue;
+
+ if (!(drm_plane-possible_crtcs (1 drmmode_crtc-index)))
+ goto free_plane;
+
+ proplist = drmModeObjectGetProperties(drmmode-fd,
+ drm_plane-plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (proplist == NULL)
+ goto free_plane;
+
+ for (j = 0; is_primary == -1 j proplist-count_props; j++)
{
+ drmModePropertyPtr prop;
+
+ prop = drmModeGetProperty(drmmode-fd,
proplist-props[j]);
+ if (!prop)
+ continue;
+
+ if (strcmp(prop-name, type) == 0) {
+ for (k = 0; k prop-count_enums; k++) {
+ if (prop-enums[k].value !=
proplist-prop_values[j])
+ continue;
+
+ is_primary =
strcmp(prop-enums[k].name, Primary) == 0;
+ break;
+ }
+ }
+
+ drmModeFreeProperty(prop);
+ }
+
+ if (is_primary) {
+ drmmode_crtc-primary_plane_id = drm_plane-plane_id;
+
+ for (j = 0; drmmode_crtc-rotation_prop_id == 0 j
proplist-count_props; j++) {
+ drmModePropertyPtr prop;
+
+ prop = drmModeGetProperty(drmmode-fd,
proplist-props[j]);
+ if (!prop)
+ continue;
+
+ if (strcmp(prop-name, rotation) == 0) {
+ drmmode_crtc-rotation_prop_id =
proplist-props[j];
+ drmmode_crtc-current_rotation =
proplist-prop_values[j];
+ for (k = 0; k prop-count_enums; k++)
{
+ int rr = -1;
+ if (strcmp(prop-enums[k].name,
rotate-0) == 0
[PATCH] modesetting: Support native primary plane rotation
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove some
opencoded defines.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
configure.ac | 2 +-
src/drmmode_display.c | 223 +++---
src/drmmode_display.h | 7 +-
3 files changed, 199 insertions(+), 33 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1c1a36d..0b4e857 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,7 +74,7 @@ AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test $HAVE_XEXTPROTO_71
= yes ])
# Checks for header files.
AC_HEADER_STDC
-PKG_CHECK_MODULES(DRM, [libdrm = 2.4.46])
+PKG_CHECK_MODULES(DRM, [libdrm = 2.4.54]) #.55 required for universal planes
PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.10])
AM_CONDITIONAL(DRM, test x$DRM = xyes)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c533324..aaeda39 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -56,6 +56,11 @@
#include driver.h
+#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2
+#define DRM_PLANE_TYPE_OVERLAY 0
+#define DRM_PLANE_TYPE_PRIMARY 1
+#define DRM_PLANE_TYPE_CURSOR 2
+
static struct dumb_bo *dumb_bo_create(int fd,
const unsigned width, const unsigned height,
const unsigned bpp)
@@ -300,6 +305,136 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
#endif
+static unsigned
+rotation_index(unsigned rotation)
+{
+#if _SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE = 200809L || _XOPEN_SOURCE
= 700
+ return ffs(rotation) - 1;
+#else
+ int i;
+
+ for (i = 0; i 32; i++) {
+ if ((1 i) == rotation)
+ break;
+ }
+
+ return i;
+#endif
+}
+
+static void
+rotation_init(xf86CrtcPtr crtc)
+{
+ drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
+ drmmode_ptr drmmode = drmmode_crtc-drmmode;
+ drmModePlaneRes *plane_resources;
+ int i, j, k;
+
+ drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+
+ plane_resources = drmModeGetPlaneResources(drmmode-fd);
+ if (plane_resources == NULL)
+ return;
+
+ for (i = 0; i plane_resources-count_planes; i++) {
+ drmModePlane *drm_plane;
+ drmModeObjectPropertiesPtr proplist;
+ int type = -1;
+
+ drm_plane = drmModeGetPlane(drmmode-fd,
+ plane_resources-planes[i]);
+ if (drm_plane == NULL)
+ continue;
+
+ if (!(drm_plane-possible_crtcs (1 drmmode_crtc-index)))
+ goto free_plane;
+
+ proplist = drmModeObjectGetProperties(drmmode-fd,
+ drm_plane-plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (proplist == NULL)
+ goto free_plane;
+
+ for (j = 0; type == -1 j proplist-count_props; j++) {
+ drmModePropertyPtr prop;
+
+ prop = drmModeGetProperty(drmmode-fd,
proplist-props[j]);
+ if (!prop)
+ continue;
+
+ if (strcmp(prop-name, type) == 0)
+ type = proplist-prop_values[j];
+
+ drmModeFreeProperty(prop);
+ }
+
+ if (type == DRM_PLANE_TYPE_PRIMARY) {
+ drmmode_crtc-primary_plane_id = drm_plane-plane_id;
+
+ for (j = 0; drmmode_crtc-rotation_prop_id == 0 j
proplist-count_props; j++) {
+ drmModePropertyPtr prop;
+
+ prop = drmModeGetProperty(drmmode-fd,
proplist-props[j]);
+ if (!prop)
+ continue;
+
+ if (strcmp(prop-name, rotation) == 0) {
+ drmmode_crtc-rotation_prop_id =
proplist-props[j];
+ drmmode_crtc-current_rotation =
proplist-prop_values[j];
+ for (k = 0; k prop-count_enums; k++)
{
+ int rr = -1;
+ if (strcmp(prop-enums[k].name,
rotate-0) == 0)
+ rr = RR_Rotate_0;
+ else if
(strcmp(prop-enums[k].name, rotate-90) == 0)
+ rr = RR_Rotate_90;
+ else if
(strcmp(prop-enums[k].name, rotate-180) == 0
Re: [PATCH] modesetting: Support native primary plane rotation
On Wed, Jul 09, 2014 at 10:44:17AM +0300, Pekka Paalanen wrote: On Wed, 9 Jul 2014 08:00:21 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: With the advent of universal drm planes and the introduction of generic plane properties for rotations, we can query and program the hardware for native rotation support. NOTE: this depends upon the next release of libdrm to remove some opencoded defines. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- configure.ac | 2 +- src/drmmode_display.c | 223 +++--- src/drmmode_display.h | 7 +- 3 files changed, 199 insertions(+), 33 deletions(-) diff --git a/configure.ac b/configure.ac index 1c1a36d..0b4e857 100644 --- a/configure.ac +++ b/configure.ac @@ -74,7 +74,7 @@ AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test $HAVE_XEXTPROTO_71 = yes ]) # Checks for header files. AC_HEADER_STDC -PKG_CHECK_MODULES(DRM, [libdrm = 2.4.46]) +PKG_CHECK_MODULES(DRM, [libdrm = 2.4.54]) #.55 required for universal planes PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.10]) AM_CONDITIONAL(DRM, test x$DRM = xyes) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index c533324..aaeda39 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -56,6 +56,11 @@ #include driver.h +#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2 +#define DRM_PLANE_TYPE_OVERLAY 0 +#define DRM_PLANE_TYPE_PRIMARY 1 +#define DRM_PLANE_TYPE_CURSOR 2 Hi, is this really something that is guaranteed to be kernel ABI stable? I mean, the 'type' property is an enum. I have never seen the enum (numerical) values being defined in any public ABI header. Instead, the property system has a mechanism for listing the enum values by name string. I have assumed that the name string is what is guaranteed ABI, and the numerical value is just an arbitrary handle. When I added universal planes support to Weston (not merged yet), I look up the numerical value by the name, instead of hardcoding the numerical value. Should you do the same here, or are the numerical values really (going to be) part of the ABI? Oops, I was trying to keep it generic and only use enum names and overlooked that the plane type was an enum. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] modesetting: Support native primary plane rotation
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove one
opencoded define.
v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
Use libobj for replacement ffs(), suggested by walter harms
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Pekka Paalanen ppaala...@gmail.com
Cc: walter harms wha...@bfs.de
---
configure.ac | 5 +-
libobj/ffs.c | 14
src/drmmode_display.c | 216 ++
src/drmmode_display.h | 10 ++-
4 files changed, 212 insertions(+), 33 deletions(-)
create mode 100644 libobj/ffs.c
diff --git a/configure.ac b/configure.ac
index 1c1a36d..1694465 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,10 +74,13 @@ AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test
$HAVE_XEXTPROTO_71 = yes ])
# Checks for header files.
AC_HEADER_STDC
-PKG_CHECK_MODULES(DRM, [libdrm = 2.4.46])
+PKG_CHECK_MODULES(DRM, [libdrm = 2.4.47])
PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.10])
AM_CONDITIONAL(DRM, test x$DRM = xyes)
+AC_CONFIG_LIBOBJ_DIR(libobj)
+AC_REPLACE_FUNCS(ffs)
+
PKG_CHECK_MODULES(UDEV, [libudev], [udev=yes], [udev=no])
if test x$udev = xyes; then
AC_DEFINE(HAVE_UDEV,1,[Enable udev-based monitor hotplug detection])
diff --git a/libobj/ffs.c b/libobj/ffs.c
new file mode 100644
index 000..2d44dcc
--- /dev/null
+++ b/libobj/ffs.c
@@ -0,0 +1,14 @@
+extern int ffs(unsigned int value);
+
+int ffs(unsigned int value)
+{
+ int bit;
+
+ if (value == 0)
+ return 0;
+
+ bit = 0;
+ while ((value (1 bit++)) == 0)
+ ;
+ return bit;
+}
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c533324..e854502 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -56,6 +56,8 @@
#include driver.h
+#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2 /* from libdrm 2.4.55 */
+
static struct dumb_bo *dumb_bo_create(int fd,
const unsigned width, const unsigned height,
const unsigned bpp)
@@ -300,6 +302,132 @@ create_pixmap_for_fbcon(drmmode_ptr drmmode,
#endif
+static unsigned
+rotation_index(unsigned rotation)
+{
+ return ffs(rotation) - 1;
+}
+
+static void
+rotation_init(xf86CrtcPtr crtc)
+{
+ drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
+ drmmode_ptr drmmode = drmmode_crtc-drmmode;
+ drmModePlaneRes *plane_resources;
+ int i, j, k;
+
+ drmSetClientCap(drmmode-fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+
+ plane_resources = drmModeGetPlaneResources(drmmode-fd);
+ if (plane_resources == NULL)
+ return;
+
+ for (i = 0; drmmode_crtc-primary_plane_id == 0 i
plane_resources-count_planes; i++) {
+ drmModePlane *drm_plane;
+ drmModeObjectPropertiesPtr proplist;
+ int is_primary = -1;
+
+ drm_plane = drmModeGetPlane(drmmode-fd,
+ plane_resources-planes[i]);
+ if (drm_plane == NULL)
+ continue;
+
+ if (!(drm_plane-possible_crtcs (1 drmmode_crtc-index)))
+ goto free_plane;
+
+ proplist = drmModeObjectGetProperties(drmmode-fd,
+ drm_plane-plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (proplist == NULL)
+ goto free_plane;
+
+ for (j = 0; is_primary == -1 j proplist-count_props; j++)
{
+ drmModePropertyPtr prop;
+
+ prop = drmModeGetProperty(drmmode-fd,
proplist-props[j]);
+ if (!prop)
+ continue;
+
+ if (strcmp(prop-name, type) == 0) {
+ for (k = 0; k prop-count_enums; k++) {
+ if (prop-enums[k].value !=
proplist-prop_values[j])
+ continue;
+
+ is_primary =
strcmp(prop-enums[k].name, Primary) == 0;
+ break;
+ }
+ }
+
+ drmModeFreeProperty(prop);
+ }
+
+ if (is_primary) {
+ drmmode_crtc-primary_plane_id = drm_plane-plane_id;
+
+ for (j = 0; drmmode_crtc-rotation_prop_id == 0 j
proplist-count_props; j++) {
+ drmModePropertyPtr prop;
+
+ prop = drmModeGetProperty(drmmode-fd,
proplist-props[j]);
+ if (!prop)
+ continue
Re: [PATCH] modesetting: Support native primary plane rotation
On Wed, Jul 09, 2014 at 12:57:12PM +0300, Pekka Paalanen wrote:
On Wed, 9 Jul 2014 09:19:08 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove one
opencoded define.
v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
Use libobj for replacement ffs(), suggested by walter harms
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Pekka Paalanen ppaala...@gmail.com
Cc: walter harms wha...@bfs.de
My concerns have been addressed. On a second read, I found another
suspicious thing below.
+ if (strcmp(prop-name, rotation) == 0) {
+ drmmode_crtc-rotation_prop_id =
proplist-props[j];
+ drmmode_crtc-current_rotation =
proplist-prop_values[j];
+ for (k = 0; k prop-count_enums; k++)
{
+ int rr = -1;
+ if (strcmp(prop-enums[k].name,
rotate-0) == 0)
+ rr = RR_Rotate_0;
+ else if
(strcmp(prop-enums[k].name, rotate-90) == 0)
+ rr = RR_Rotate_90;
+ else if
(strcmp(prop-enums[k].name, rotate-180) == 0)
+ rr = RR_Rotate_180;
+ else if
(strcmp(prop-enums[k].name, rotate-270) == 0)
+ rr = RR_Rotate_270;
+ else if
(strcmp(prop-enums[k].name, reflect-x) == 0)
+ rr = RR_Reflect_X;
+ else if
(strcmp(prop-enums[k].name, reflect-y) == 0)
+ rr = RR_Reflect_Y;
+ if (rr != -1) {
+
drmmode_crtc-map_rotations[rotation_index(rr)] = 1 prop-enums[k].value;
+
drmmode_crtc-supported_rotations |= rr;
Comparing the above assignments to...
+static Bool
+rotation_set(xf86CrtcPtr crtc, unsigned rotation)
+{
+ drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
+ drmmode_ptr drmmode = drmmode_crtc-drmmode;
+
+ if (drmmode_crtc-current_rotation == rotation)
+ return TRUE;
+
+ if ((drmmode_crtc-supported_rotations rotation) == 0)
+ return FALSE;
+
+ if (drmModeObjectSetProperty(drmmode-fd,
+drmmode_crtc-primary_plane_id,
+DRM_MODE_OBJECT_PLANE,
+drmmode_crtc-rotation_prop_id,
+
drmmode_crtc-map_rotations[rotation_index(rotation)]))
...the use here, it does not look like you are passing
prop-enums[k].value here. It is like you are missing ffs() here or
having a 1 too much in the assignment.
It doesn't take the enum.value but 1 enum.value.
Btw. would it be possible to do e.g. rotate-90 with reflect?
Indeed. That's an issue from only using the first index...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: screen update problems with Intel HD 4600 + virtual screen
On Mon, Jun 23, 2014 at 09:49:07AM +0200, Krzysztof Halasa wrote: khal...@piap.pl (Krzysztof Hałasa) writes: I'm having screen update problems problems with an Intel HD 4600 with panning + virtual screen. Fedora 20 + updates, CPU is Core i7 4770K, I'm using xrandr --output HDMI1 --panning 4096x2404. The physical screen size is 1920x1200. Another setup also experiencing this problem is Core i5 4200M with a 1600x900 physical screen (LVDS) and (a bit larger) virtual screen (again with panning). This happens with both UXA and SNA. ATM I'm now using SNA as UXA(?) had some probably unrelated problems with Xvideo (non)updates. Screen 0: minimum 320 x 200, current 4096 x 2404, maximum 32767 x 32767 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 4096x2404+0+0 (normal left inverted right x axis y axis) 518mm x 324mm panning 4096x2404+0+0 1920x1200 59.95*+ [etc.] DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) It looks with SNA, all is good as long as the screen isn't moved (panned) down more than 7 pixels (i.e. the screen y offset must be 0 - 7 and x offset doesn't matter): switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 0), rotation normal switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 1), rotation normal switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 2), rotation normal ... switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 6), rotation normal switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 7), rotation normal Now I scroll down 1 pixel: switch to mode 1920x1200@60.0 on pipe 0 using HDMI1, position (2176, 8), rotation normal and immediately screen isn't updated correctly. For example, an application window is created normally, but when I move it (the app window) down, the top part of the window, max 8 pixels, is left on the screen (the moved window is ok). It almost looks like the code somewhere adds the vertical screen offset twice. 8 is significant as it is the tile row height. The kernel tries to be smart and extract the panning from the surface address so that we can display a larger virtual framebuffer than the hardware can actually use. Can you reproduce the about sequence with drm.debug=6 dmesg (i.e. echo 6 /sys/module/drm/parameters/debug ; xrandr --panning... ; dmesg)? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: screen update problems with Intel HD 4600 + virtual screen
On Mon, Jun 23, 2014 at 12:47:13PM +0200, Krzysztof Halasa wrote: Chris Wilson ch...@chris-wilson.co.uk writes: Hmm. Whilst it seems odd to have a negative linear offset, I have seen it work elsewhere. Could you try setting options i915 i915_enable_fbc=0 enable_fbc=0 in /etc/modprobe.conf/intel.conf and rebuilding your initramfs? This fixed it. The negative offset isn't exactly gone, though. Many thanks. Would you like me to try something else? I'll leave that to Daniel to try and combine FBC with CRTC viewports... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH] dri2: Use the PrimeScreen when creating/reusing buffers
This fixes a segfault when we attempt to call ds-ReuseBufferNotify()
passing a Prime DRI2BufferPtr to the master backend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80001
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Michel Dänzer mic...@daenzer.net
Cc: Dave Airlie airl...@redhat.com
---
hw/xfree86/dri2/dri2.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 6dd7796..5705baa 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -415,18 +415,14 @@ DRI2DrawableGone(void *p, XID id)
}
static DRI2BufferPtr
-create_buffer(DrawablePtr pDraw,
+create_buffer(DRI2ScreenPtr ds, DrawablePtr pDraw,
unsigned int attachment, unsigned int format)
{
-ScreenPtr primeScreen;
-DRI2DrawablePtr pPriv;
-DRI2ScreenPtr ds;
DRI2BufferPtr buffer;
-pPriv = DRI2GetDrawable(pDraw);
-primeScreen = GetScreenPrime(pDraw-pScreen, pPriv-prime_id);
-ds = DRI2GetScreenPrime(pDraw-pScreen, pPriv-prime_id);
if (ds-CreateBuffer2)
-buffer = (*ds-CreateBuffer2)(primeScreen, pDraw, attachment, format);
+buffer = (*ds-CreateBuffer2)(GetScreenPrime(pDraw-pScreen,
+
DRI2GetDrawable(pDraw)-prime_id),
+ pDraw, attachment, format);
else
buffer = (*ds-CreateBuffer)(pDraw, attachment, format);
return buffer;
@@ -475,7 +471,7 @@ allocate_or_reuse_buffer(DrawablePtr pDraw, DRI2ScreenPtr
ds,
if ((old_buf 0)
|| attachment == DRI2BufferFrontLeft
|| !dimensions_match || (pPriv-buffers[old_buf]-format != format)) {
-*buffer = create_buffer (pDraw, attachment, format);
+*buffer = create_buffer(ds, pDraw, attachment, format);
return TRUE;
}
@@ -538,7 +534,7 @@ do_get_buffers(DrawablePtr pDraw, int *width, int *height,
return NULL;
}
-ds = DRI2GetScreen(pDraw-pScreen);
+ds = DRI2GetScreenPrime(pDraw-pScreen, pPriv-prime_id);
dimensions_match = (pDraw-width == pPriv-width)
(pDraw-height == pPriv-height);
--
2.0.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.912
Snapshot 2.99.912 (2014-06-10) == A final round of features. We have everything from support for variable cursor sizes, support for the DRI3 and Present extensions, improved DRI2 support, support for Xserver 1.16, userptr from kernel 3.16, and precursory support for DP multistream transport, * Avoid discarding dirty pixels when promoting a migration to cover the whole pixmap. Regression in 2.99.911 https://bugs.freedesktop.org/show_bug.cgi?id=77063 https://bugs.freedesktop.org/show_bug.cgi?id=77178 * Avoid overextending degenerate lines (and consequentially accessing pixels outside of our damaged area). https://bugs.freedesktop.org/show_bug.cgi?id=77074 * Fix subpixel glyph rendering on gen2 devices (830-865 chipsets) Regression in 2.99.911 https://bugs.freedesktop.org/show_bug.cgi?id=77201 * Share the global pixman glyph cache between ZaphodHeads https://bugs.freedesktop.org/show_bug.cgi?id=54707 * Light up all connected outputs, even if their status is unknown, on takeover from fbcon. This prevents loss of display after a resume on recent kernels, for example. https://bugs.freedesktop.org/show_bug.cgi?id=77768 * Show the video overlay (when supported by the hardware) across all outputs. https://bugs.freedesktop.org/show_bug.cgi?id=77802 * Do not discard damage when performing BLT spans inplace with the CPU. Regression from 2.20.10 * Avoid discarding IO buffers too early during their preparation for a new batch https://bugs.freedesktop.org/show_bug.cgi?id=79238 * Fix fallback handling for displaying large scaled framebuffers (that are too large to be scaled by the GPU in a single pass) https://bugs.freedesktop.org/show_bug.cgi?id=79320 * Listen to external modifications of backlight value and propagate the notifications to RandR clients. This should make the GUI report ACPI keypresses to change the backlight correctly. https://bugs.freedesktop.org/show_bug.cgi?id=79699 * UXA: fix pageflips with 3 heads. * UXA: do not report a BadMatch error for DRI2GetMsc - as clients are often unprepared and die when they get the unexpected error. Complete list of changes since 2.99.911 --- Adam Jackson (1): configure: Don't link the driver against libX11 Chris Wilson (287): intel: Refactor finding device path if unknown intel: Do not close server fds sna: Only enable cursor support if the hw cursor is supported sna: Eliminate a few conditionals in glyph fast path sna: Consolidate handling of uncacheable glyphs sna: Remove one conditional from rendering glyphs into a mask intel-virtual-output: Do not detach with DBG enabled intel-virtual-output: Add a little more DBG around damaging clones intel-virtual-output: Fix damage iteration over active list sna: Print probed maximum cursor size intel-virtual-output: Add DBG option to force 16 bit transfers sna: Tighten detection of GCs that translate to solid fills sna: Move cursor reload into crtc notify sna: Support variable sized cursors sna: Clear the surrounding areas of small cursors sna: Reorder the cursor cache search sna: Cursors only need to be cleared when they are shrunk sna: Fix 2-color to ARGB cursor conversion sna: RefCursor is too recent sna: drmGetCap is too recent for our supported versions of libdrm sna: Cursors are invariant sna: Virtual CRTCs are last, so break loops early sna: Our cursors are always square. sna: Only transform the temporary cursor coordinates sna: Suppress a compiler warning sna: Search cursor cache first sna: Regularly check that damage does exceed the pixmap sna: Promote to the GPU operations that cover the whole pixmap sna: Discard damage tracking for operations to the whole pixmap sna: Allow reassignment of inactive VMA if not mapped into the GTT sna: Use a cheaper check for a replacement operation sna: Fix predicate inversion for assertion sna: Update tiling flags after reusing inactive VMA sna: Prevent signal re-entrancy into cursor update routines sna: Silence compiler warning sna: Short-circuit repeated clearing to the same color sna/gen2+: Replace composite sources with solids where possible sna: Precompute OVER/ADD with solids to convert it into a BLT operation sna/gen7: Move constants MOCS into chipset specific info blocks sna/gen2+: Beware the unattached ShmPixmap sna: Remove unitialized use of 'cursor' sna/gen8: w/a for NULL depth buffer sna/gen8: Shrink 3DSTATE_SAMPLE_PATTERN packet sna: Avoid discarding damage when applying WHOLE hint to pixmap migration sna: Avoid double application of pixel widening for degenerate lines sna: Simplify checking for singular damage intel-virtual-output
[PATCH] dri2: Invalidate DRI2Buffers upon SetWindowPixmap updates
When transitioning to a redirected or unredirected Window, the Composite
layer modifies the Window's Pixmap. However, the DRI2Buffer for the
Drawable is still pointing to the backing bo of the old Pixmap with the
result that rendering goes astray.
This now also effects DRI2 Drawables that are touched by PresentPixmap.
v2: Fixup the function name after rebasing
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Reinis Danne reinis.da...@gmail.com
Reviewed-by: Dave Airlie airl...@redhat.com
Cc: Keith Packard kei...@keithp.com
---
hw/xfree86/dri2/dri2.c | 20
1 file changed, 20 insertions(+)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 6dd7796..5d0cb1d 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -130,6 +130,7 @@ typedef struct _DRI2Screen {
HandleExposuresProcPtr HandleExposures;
ConfigNotifyProcPtr ConfigNotify;
+SetWindowPixmapProcPtr SetWindowPixmap;
DRI2CreateBuffer2ProcPtr CreateBuffer2;
DRI2DestroyBuffer2ProcPtr DestroyBuffer2;
DRI2CopyRegion2ProcPtr CopyRegion2;
@@ -1382,6 +1383,21 @@ DRI2ConfigNotify(WindowPtr pWin, int x, int y, int w,
int h, int bw,
return Success;
}
+static void
+DRI2SetWindowPixmap(WindowPtr pWin, PixmapPtr pPix)
+{
+DrawablePtr pDraw = (DrawablePtr) pWin;
+ScreenPtr pScreen = pDraw-pScreen;
+DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
+
+pScreen-SetWindowPixmap = ds-SetWindowPixmap;
+(*pScreen-SetWindowPixmap) (pWin, pPix);
+ds-SetWindowPixmap = pScreen-SetWindowPixmap;
+pScreen-SetWindowPixmap = DRI2SetWindowPixmap;
+
+DRI2InvalidateDrawableAll(pDraw);
+}
+
#define MAX_PRIME DRI2DriverPrimeMask
static int
get_prime_id(void)
@@ -1528,6 +1544,9 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
ds-ConfigNotify = pScreen-ConfigNotify;
pScreen-ConfigNotify = DRI2ConfigNotify;
+ds-SetWindowPixmap = pScreen-SetWindowPixmap;
+pScreen-SetWindowPixmap = DRI2SetWindowPixmap;
+
xf86DrvMsg(pScreen-myNum, X_INFO, [DRI2] Setup complete\n);
for (i = 0; i sizeof(driverTypeNames) / sizeof(driverTypeNames[0]); i++)
{
if (i ds-numDrivers ds-driverNames[i]) {
@@ -1552,6 +1571,7 @@ DRI2CloseScreen(ScreenPtr pScreen)
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
pScreen-ConfigNotify = ds-ConfigNotify;
+pScreen-SetWindowPixmap = ds-SetWindowPixmap;
if (ds-prime_id)
prime_id_allocate_bitmask = ~(1 ds-prime_id);
--
2.0.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.912
Snapshot 2.99.912 (2014-06-10) == A final round of features. We have everything from support for variable cursor sizes, support for the DRI3 and Present extensions, improved DRI2 support, support for Xserver 1.16, userptr from kernel 3.16, and precursory support for DP multistream transport, * Avoid discarding dirty pixels when promoting a migration to cover the whole pixmap. Regression in 2.99.911 https://bugs.freedesktop.org/show_bug.cgi?id=77063 https://bugs.freedesktop.org/show_bug.cgi?id=77178 * Avoid overextending degenerate lines (and consequentially accessing pixels outside of our damaged area). https://bugs.freedesktop.org/show_bug.cgi?id=77074 * Fix subpixel glyph rendering on gen2 devices (830-865 chipsets) Regression in 2.99.911 https://bugs.freedesktop.org/show_bug.cgi?id=77201 * Share the global pixman glyph cache between ZaphodHeads https://bugs.freedesktop.org/show_bug.cgi?id=54707 * Light up all connected outputs, even if their status is unknown, on takeover from fbcon. This prevents loss of display after a resume on recent kernels, for example. https://bugs.freedesktop.org/show_bug.cgi?id=77768 * Show the video overlay (when supported by the hardware) across all outputs. https://bugs.freedesktop.org/show_bug.cgi?id=77802 * Do not discard damage when performing BLT spans inplace with the CPU. Regression from 2.20.10 * Avoid discarding IO buffers too early during their preparation for a new batch https://bugs.freedesktop.org/show_bug.cgi?id=79238 * Fix fallback handling for displaying large scaled framebuffers (that are too large to be scaled by the GPU in a single pass) https://bugs.freedesktop.org/show_bug.cgi?id=79320 * Listen to external modifications of backlight value and propagate the notifications to RandR clients. This should make the GUI report ACPI keypresses to change the backlight correctly. https://bugs.freedesktop.org/show_bug.cgi?id=79699 * UXA: fix pageflips with 3 heads. * UXA: do not report a BadMatch error for DRI2GetMsc - as clients are often unprepared and die when they get the unexpected error. Complete list of changes since 2.99.911 --- Adam Jackson (1): configure: Don't link the driver against libX11 Chris Wilson (287): intel: Refactor finding device path if unknown intel: Do not close server fds sna: Only enable cursor support if the hw cursor is supported sna: Eliminate a few conditionals in glyph fast path sna: Consolidate handling of uncacheable glyphs sna: Remove one conditional from rendering glyphs into a mask intel-virtual-output: Do not detach with DBG enabled intel-virtual-output: Add a little more DBG around damaging clones intel-virtual-output: Fix damage iteration over active list sna: Print probed maximum cursor size intel-virtual-output: Add DBG option to force 16 bit transfers sna: Tighten detection of GCs that translate to solid fills sna: Move cursor reload into crtc notify sna: Support variable sized cursors sna: Clear the surrounding areas of small cursors sna: Reorder the cursor cache search sna: Cursors only need to be cleared when they are shrunk sna: Fix 2-color to ARGB cursor conversion sna: RefCursor is too recent sna: drmGetCap is too recent for our supported versions of libdrm sna: Cursors are invariant sna: Virtual CRTCs are last, so break loops early sna: Our cursors are always square. sna: Only transform the temporary cursor coordinates sna: Suppress a compiler warning sna: Search cursor cache first sna: Regularly check that damage does exceed the pixmap sna: Promote to the GPU operations that cover the whole pixmap sna: Discard damage tracking for operations to the whole pixmap sna: Allow reassignment of inactive VMA if not mapped into the GTT sna: Use a cheaper check for a replacement operation sna: Fix predicate inversion for assertion sna: Update tiling flags after reusing inactive VMA sna: Prevent signal re-entrancy into cursor update routines sna: Silence compiler warning sna: Short-circuit repeated clearing to the same color sna/gen2+: Replace composite sources with solids where possible sna: Precompute OVER/ADD with solids to convert it into a BLT operation sna/gen7: Move constants MOCS into chipset specific info blocks sna/gen2+: Beware the unattached ShmPixmap sna: Remove unitialized use of 'cursor' sna/gen8: w/a for NULL depth buffer sna/gen8: Shrink 3DSTATE_SAMPLE_PATTERN packet sna: Avoid discarding damage when applying WHOLE hint to pixmap migration sna: Avoid double application of pixel widening for degenerate lines sna: Simplify checking for singular damage intel-virtual-output
Re: [PATCH] present: Queue flips for later execution. Begging for review.
On Tue, Jun 03, 2014 at 08:08:21PM -0700, Keith Packard wrote: Right, having real async flips is a prerequisite for doing this, along with sufficient mechanism to not request a flip until the buffer is idle, without forcing the X server to stall in the flip kernel call waiting. Neither the GPU or mmio pageflip ioctl stall due to outstanding rendering, except as when it is required to rewrite the PTEs. We could move that to a wq, or the buffers can be pre-emptively moved to the display cache domain before rendering. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Running DRI3 on intel-gfx
On Wed, Jun 04, 2014 at 06:37:44PM +0200, Sedat Dilek wrote: DRI2 or DRI3 running here? I did some more testing and played with UXA/SNA for intel-ddx. $ egrep -i 'dri2|dri3|present|sna|uxa' Xorg.0.log_UXA [ 8471.151] (II) intel(0): DRI2: Enabled [ 8471.151] (II) intel(0): DRI3: Enabled [ 8471.194] (II) GLX: Initialized DRI2 GL provider for screen 0 $ egrep -i 'dri2|dri3|present|sna|uxa' Xorg.0.log_SNA [ 8574.658] (II) intel(0): direct rendering: DRI2 DRI3 enabled [ 8574.658] (II) intel(0): hardware support for Present enabled [ 8574.666] (II) GLX: Initialized DRI2 GL provider for screen 0 Still unsure if I had success. Yes, the DDX is ready. Try enabling LIBGL_DEBUG to check that mesa is using DRI3. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] present: Query the right CRTC to use each time
On Mon, Jun 02, 2014 at 09:10:47PM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: (That the client can get confused and present on the wrong CRTC is an unfortunate race condition, but there needs to be a way to poll for XErrors alongside the futex signalling in order to catch when the futex will never be woken and abort.) Perhaps we should actually signal the futex even if an error is generated? That would be a bit unusual, but could avoid this problem. I don't think it is possible. The sync-fence is associated with the scanout Pixmap. We present the next Pixmap believing that it will take over and free the current scanout and so signal the old sync-fence. The more I look at it, it is just the client being too naive - it just feels like it should be possible to poll(futex_fd, xcb_fd) rather than block on either and so make writing tests easier! -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] present: Queue flips for later execution. Begging for review.
On Tue, Jun 03, 2014 at 12:27:45AM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: The driver doesn't check that the Window is still suitable for flipping, it only checks if the buffer is suitable for scanning out. I think you need to run present_check_flip_window() on all queued flips. present_check_flip_window is called when the window clip list changes. [snip] Eeek, overlooked the loop at the end of present_check_flip_window that did precisely what I was looking for. Just a mention of how the bug is observed in practice. It wasn't until you pointed out the effects of this patch on irc that I realised it fixed the same flip-unflip issue I saw during testing. Sounds good. I'll update the commit message. After thoroughly confusing myself, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] present: Queue flips for later execution. Begging for review.
On Mon, Jun 02, 2014 at 01:53:29PM -0700, Keith Packard wrote: When a flip (or unflip) is pending and a flip request comes in, leave it queued until the pending flip completes and then execute it. Signed-off-by: Keith Packard kei...@keithp.com Tested-by: Frank Binns frank.bi...@imgtec.com --- This patch has been unreviewed since January and makes swaps reliably occur on drivers that don't have async swap support, rather than happening only every other frame. I'd like to have this merged before we try to sort out Chris Wilson's bug fixes as these are all heavily inter-related. Hmm, it appears to break flip elision. When combined with Frank's patches it also stops unflipping upon window destruction. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 0/3] present: various fixes
On Sat, May 31, 2014 at 08:59:33AM +0100, Chris Wilson wrote: However, it does introduce an issue where a fence won't be signalled if the associated drawable is already freed. Scratch that. I broke my test environment. Nothing wrong with this series that I have been able to tell. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] present: Query the right CRTC to use each time
On Mon, Jun 02, 2014 at 01:04:39PM -0700, Keith Packard wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
As the CRTCs may be reconfigured between each invocation, we can not
assume that the previous CRTC we used last time will still be valid for
this call.
Is this a problem with CRTCs that are deleted? If so, hooking crtc
destruction would be pretty easy.
The problem occurs with doing something like:
xrandr --output LVDS --crtc 0
getmsc
xrandr --output LVDS --crtc 1
getmsc
(That the client can get confused and present on the wrong CRTC is
an unfortunate race condition, but there needs to be a way to poll for
XErrors alongside the futex signalling in order to catch when the futex
will never be woken and abort.)
diff --git a/present/present.c b/present/present.c
index e35de94..d1bb9d4 100644
--- a/present/present.c
+++ b/present/present.c
@@ -673,15 +673,8 @@ present_pixmap(WindowPtr window,
if (!screen_priv || !screen_priv-info)
target_crtc = NULL;
-else if (!target_crtc) {
-/* Update the CRTC if we have a pixmap or we don't have a CRTC
- */
-if (!pixmap)
-target_crtc = window_priv-crtc;
-
-if (!target_crtc)
-target_crtc = present_get_crtc(window);
-}
+else if (!target_crtc)
+target_crtc = present_get_crtc(window);
This only changes the behavior for notify_msc, and what we want there is
to continue using the same CRTC that the last swap used so that the
values are reasonable. All presents with a pixmap will continue to call
present_get_crtc each time.
Right, looking again at the loop the error hits during the
dri3_wait_for_msc() loop that doesn't break out the wait-for-event loop
due to the BadMatch from xcb_present_notify_msc(). Another annoyance
here is that for GetMSC we queue an event for the next vblank which
seems like unwanted latency.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] present: Queue flips for later execution. Begging for review.
On Mon, Jun 02, 2014 at 01:53:29PM -0700, Keith Packard wrote: When a flip (or unflip) is pending and a flip request comes in, leave it queued until the pending flip completes and then execute it. Signed-off-by: Keith Packard kei...@keithp.com Tested-by: Frank Binns frank.bi...@imgtec.com The patch relaxes the restriction that there be a single pending flip, and allows the client to queue up a series of fullscreen swaps. However, we don't recheck pixmaps for being viable for flipping after the vblank event as we rely on the ClipNotify hook aborting any flip after a Window change. I think this check now needs to scan all pending flips. Other than that, the patch does what it says on the tin, though you could mention the impact this has caused by the regular flip-unflip. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] present: Queue flips for later execution. Begging for review.
On Mon, Jun 02, 2014 at 08:56:32PM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: The patch relaxes the restriction that there be a single pending flip, and allows the client to queue up a series of fullscreen swaps. However, we don't recheck pixmaps for being viable for flipping after the vblank event as we rely on the ClipNotify hook aborting any flip after a Window change. I think this check now needs to scan all pending flips. The driver gets a 'last appeal' in the present_flip call, and if that says 'no', then the extension falls back to a copy. The driver doesn't check that the Window is still suitable for flipping, it only checks if the buffer is suitable for scanning out. I think you need to run present_check_flip_window() on all queued flips. Other than that, the patch does what it says on the tin, though you could mention the impact this has caused by the regular flip-unflip. Not sure what you mean here; are you saying that I should mention that the code fixes a bug in the existing stuff where doing sync flips will regularly cause a switch between flipping and copying? Just a mention of how the bug is observed in practice. It wasn't until you pointed out the effects of this patch on irc that I realised it fixed the same flip-unflip issue I saw during testing. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] present: Query the right CRTC to use each time
As the CRTCs may be reconfigured between each invocation, we can not
assume that the previous CRTC we used last time will still be valid for
this call. Either we need a way to validate the CRTC or, more
conveniently, query the CRTC to use each time. Note, that this still
does not validate the CRTC is passed in by the user - and xshmfence does
not mix well with asynchronous errors from X (i.e. the client can
trivially deadlock waiting for a signal that will never come).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
present/present.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/present/present.c b/present/present.c
index e35de94..d1bb9d4 100644
--- a/present/present.c
+++ b/present/present.c
@@ -673,15 +673,8 @@ present_pixmap(WindowPtr window,
if (!screen_priv || !screen_priv-info)
target_crtc = NULL;
-else if (!target_crtc) {
-/* Update the CRTC if we have a pixmap or we don't have a CRTC
- */
-if (!pixmap)
-target_crtc = window_priv-crtc;
-
-if (!target_crtc)
-target_crtc = present_get_crtc(window);
-}
+else if (!target_crtc)
+target_crtc = present_get_crtc(window);
present_get_ust_msc(window, target_crtc, ust, crtc_msc);
--
2.0.0.rc4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 0/3] present: various fixes
On Wed, May 28, 2014 at 05:40:28PM +0100, Frank Binns wrote: This is v2 of some present fixes for issues discovered when adding DRI3+present support to the PVR video driver. Patch 1 has been reworked to now always restore the screen pixmap at the point a pending flip is marked as aborted. Previously it only did this in one place and only for the root window. Patch 2 is new and deals with the same problem, but in in different way, as the old patch 2. Essentially both patches attempt to deal with resource leaks related to flipping. The old patch did this by preventing any pending flip, associated with the window being destroyed, from being aborted and destroyed during window destruction. However, this relied on the DDX waiting for all kernel events to arrive and be processed so that the necessary resource clean up was triggered. The new patch just does the clean up at the point the window is destroyed. Patch 3 is identical to the old patch 4 (as patch 3 has now been dropped). Some issues still remain but these are fixed by the following patches that are currently on the list but not in master: - [PATCH] present: Queue flips for later execution - [PATCH 3/6] present: Reorder Window teardown to avoid use-after-free Frank Binns (3): present: restore screen pixmap when aborting a flip present: clean up all current flip resources on window destruction present: sync flips unless requested not to This fixes the issues I was seeing earlier, notably the dangling vblank after applications quit. Tested-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 0/3] present: various fixes
On Sat, May 31, 2014 at 08:32:50AM +0100, Chris Wilson wrote: On Wed, May 28, 2014 at 05:40:28PM +0100, Frank Binns wrote: This is v2 of some present fixes for issues discovered when adding DRI3+present support to the PVR video driver. Patch 1 has been reworked to now always restore the screen pixmap at the point a pending flip is marked as aborted. Previously it only did this in one place and only for the root window. Patch 2 is new and deals with the same problem, but in in different way, as the old patch 2. Essentially both patches attempt to deal with resource leaks related to flipping. The old patch did this by preventing any pending flip, associated with the window being destroyed, from being aborted and destroyed during window destruction. However, this relied on the DDX waiting for all kernel events to arrive and be processed so that the necessary resource clean up was triggered. The new patch just does the clean up at the point the window is destroyed. Patch 3 is identical to the old patch 4 (as patch 3 has now been dropped). Some issues still remain but these are fixed by the following patches that are currently on the list but not in master: - [PATCH] present: Queue flips for later execution - [PATCH 3/6] present: Reorder Window teardown to avoid use-after-free Frank Binns (3): present: restore screen pixmap when aborting a flip present: clean up all current flip resources on window destruction present: sync flips unless requested not to This fixes the issues I was seeing earlier, notably the dangling vblank after applications quit. However, it does introduce an issue where a fence won't be signalled if the associated drawable is already freed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/6] xfree86: Report Present as a built-in module
This is so that drivers can do a runtime check that Present is available,
similar to existing runtime checks performed by the drivers for DRI.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/loader/loadmod.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index f92ad8d..e1f649a 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -841,6 +841,9 @@ static const char *compiled_in_modules[] = {
#if DRI3
dri3,
#endif
+#if PRESENT
+present,
+#endif
NULL
};
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 6/6] present: Set abort_flip on the pending_flip when destroying the Window
Currently, the code asserts that the abort_flip is set on the
pending_flip when the Window is closed. Presumably, it is expected that
a configure event happens before it actually closes causing the pending
present flip to be aborted. In practice, I see the assert.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
present/present_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/present/present_screen.c b/present/present_screen.c
index 0a525a8..a04317f 100644
--- a/present/present_screen.c
+++ b/present/present_screen.c
@@ -94,7 +94,7 @@ present_clear_window_flip(WindowPtr window)
present_vblank_ptr flip_pending = screen_priv-flip_pending;
if (flip_pending flip_pending-window == window) {
-assert (flip_pending-abort_flip);
+flip_pending-abort_flip = TRUE;
flip_pending-window = NULL;
}
if (screen_priv-flip_window == window)
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/6] present: Reorder Window teardown to avoid use-after-free
The cleanup sequence was slightly confused as it attempted to clear
pending events for the screen after it had freed those events from the
window's queue. Reorder the sequence so that all the clearing of events
is done first before we free any events.
==31451== Invalid read of size 4
==31451==at 0x81A6B3E: present_clear_window_flip (present_screen.c:93)
==31451==by 0x81A6C07: present_destroy_window (present_screen.c:116)
==31451==by 0x8145796: compDestroyWindow (compwindow.c:608)
==31451==by 0x8176B6B: DbeDestroyWindow (dbe.c:1318)
==31451==by 0x80B5A98: FreeWindowResources (window.c:910)
==31451==by 0x80B5D7B: DeleteWindow (window.c:978)
==31451==by 0x80A9C85: doFreeResource (resource.c:873)
==31451==by 0x80AA5F8: FreeClientResources (resource.c:1139)
==31451==by 0x807BD5E: CloseDownClient (dispatch.c:3384)
==31451==by 0x80740B5: Dispatch (dispatch.c:406)
==31451==by 0x80816CD: dix_main (main.c:296)
==31451==by 0x80D2FA1: main (stubmain.c:34)
==31451== Address 0x62ae4bc is 20 bytes inside a block of size 108 free'd
==31451==at 0x4007BCD: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==31451==by 0x81A8FDF: present_vblank_destroy (present.c:901)
==31451==by 0x81A6ADF: present_free_window_vblank (present_screen.c:79)
==31451==by 0x81A6BFC: present_destroy_window (present_screen.c:115)
==31451==by 0x8145796: compDestroyWindow (compwindow.c:608)
==31451==by 0x8176B6B: DbeDestroyWindow (dbe.c:1318)
==31451==by 0x80B5A98: FreeWindowResources (window.c:910)
==31451==by 0x80B5D7B: DeleteWindow (window.c:978)
==31451==by 0x80A9C85: doFreeResource (resource.c:873)
==31451==by 0x80AA5F8: FreeClientResources (resource.c:1139)
==31451==by 0x807BD5E: CloseDownClient (dispatch.c:3384)
==31451==by 0x80740B5: Dispatch (dispatch.c:406)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
present/present_screen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/present/present_screen.c b/present/present_screen.c
index 25ef681..b475d03 100644
--- a/present/present_screen.c
+++ b/present/present_screen.c
@@ -111,9 +111,9 @@ present_destroy_window(WindowPtr window)
if (window_priv) {
present_clear_window_notifies(window);
-present_free_events(window);
-present_free_window_vblank(window);
present_clear_window_flip(window);
+present_free_window_vblank(window);
+present_free_events(window);
free(window_priv);
}
unwrap(screen_priv, screen, DestroyWindow);
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 5/6] present: Do not free screen_priv-flip_pending until it is finished
If we close the Window prior to completing all the flips, we free the
vblank pointer but leave screen_priv-flip_pending dangling. This leads
to a host of invalid reads/writes as it is accessed from many locations,
e.g.:
==20302== Invalid write of size 4
==20302==at 0x81A8FD5: present_flip_destroy (present.c:879)
==20302==by 0x81A6A2A: present_close_screen (present_screen.c:60)
==20302==by 0x8147A5A: CursorCloseScreen (cursor.c:187)
==20302==by 0x81A3DDA: AnimCurCloseScreen (animcur.c:106)
==20302==by 0x8142F7D: compCloseScreen (compinit.c:85)
==20302==by 0x80E6D2A: VidModeClose (xf86VidMode.c:111)
==20302==by 0x496CF23: glxCloseScreen (glxscreens.c:187)
==20302==by 0x808186F: dix_main (main.c:349)
==20302==by 0x80D2FA1: main (stubmain.c:34)
==20302== Address 0x67d0780 is 104 bytes inside a block of size 108 free'd
==20302==at 0x4007BCD: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==20302==by 0x81A90AC: present_vblank_destroy (present.c:911)
==20302==by 0x81A6ADF: present_free_window_vblank (present_screen.c:79)
==20302==by 0x81A6C2C: present_destroy_window (present_screen.c:116)
==20302==by 0x8145796: compDestroyWindow (compwindow.c:608)
==20302==by 0x8176B6B: DbeDestroyWindow (dbe.c:1318)
==20302==by 0x80B5A98: FreeWindowResources (window.c:910)
==20302==by 0x80B5D7B: DeleteWindow (window.c:978)
==20302==by 0x80A9C85: doFreeResource (resource.c:873)
==20302==by 0x80AA5F8: FreeClientResources (resource.c:1139)
==20302==by 0x807BD5E: CloseDownClient (dispatch.c:3384)
==20302==by 0x80740B5: Dispatch (dispatch.c:406)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
present/present_screen.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/present/present_screen.c b/present/present_screen.c
index b475d03..0a525a8 100644
--- a/present/present_screen.c
+++ b/present/present_screen.c
@@ -72,11 +72,14 @@ static void
present_free_window_vblank(WindowPtr window)
{
present_window_priv_ptr window_priv = present_window_priv(window);
+present_screen_priv_ptr screen_priv =
present_screen_priv(window-drawable.pScreen);
+present_vblank_ptr flip_pending = screen_priv-flip_pending;
present_vblank_ptr vblank, tmp;
xorg_list_for_each_entry_safe(vblank, tmp, window_priv-vblank,
window_list) {
present_abort_vblank(window-drawable.pScreen, vblank-crtc,
vblank-event_id, vblank-target_msc);
-present_vblank_destroy(vblank);
+if (vblank != flip_pending)
+present_vblank_destroy(vblank);
}
}
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/6] xfree86: Report DRI3 as a built-in module
This is so that drivers can do a runtime check that DRI3 is available,
similar to existing runtime checks performed by the drivers for DRI and
DRI2.
v2: Only add DRI3 to the list if the module was actually built into the
server (Mark Kettenis).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Mark Kettenis mark.kette...@xs4all.nl
---
hw/xfree86/loader/loadmod.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 092bf57..f92ad8d 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -838,6 +838,9 @@ static const char *compiled_in_modules[] = {
extmod,
dri,
dri2,
+#if DRI3
+dri3,
+#endif
NULL
};
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/6] fb: Avoid installing terminal functions over pre-existing call chains
The fbWindow family of functions (Map, Unmap, Position and Destroy) are all terminal functions, that is they do not chain up to earlier extensions. This breaks those chains which leads to not only resource leaks but also dereference of dangling pointers. One such issue arises with fbScreenInit() breaking the earlier present_screen_init() and causing the Xserver to die when a Window is closed after being used with Present and fb: ==15808== Invalid read of size 4 ==15808==at 0x81A9226: dixGetPrivateAddr (privates.h:123) ==15808==by 0x81A928C: dixGetPrivate (privates.h:137) ==15808==by 0x81A92BE: present_window_priv (present_priv.h:143) ==15808==by 0x81A92EA: present_free_event (present_event.c:35) ==15808==by 0x80A9C85: doFreeResource (resource.c:873) ==15808==by 0x80AA5F8: FreeClientResources (resource.c:1139) ==15808==by 0x807BD5E: CloseDownClient (dispatch.c:3384) ==15808==by 0x80740B5: Dispatch (dispatch.c:406) ==15808==by 0x80816CD: dix_main (main.c:296) ==15808==by 0x80D2FA1: main (stubmain.c:34) ==15808== Address 0x60f38c8 is 24 bytes inside a block of size 168 free'd ==15808==at 0x4007BCD: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==15808==by 0x80A1A67: _dixFreeObjectWithPrivates (privates.c:538) ==15808==by 0x80B5E0D: DeleteWindow (window.c:991) ==15808==by 0x80A9C85: doFreeResource (resource.c:873) ==15808==by 0x80AA5F8: FreeClientResources (resource.c:1139) ==15808==by 0x807BD5E: CloseDownClient (dispatch.c:3384) ==15808==by 0x80740B5: Dispatch (dispatch.c:406) ==15808==by 0x80816CD: dix_main (main.c:296) ==15808==by 0x80D2FA1: main (stubmain.c:34) Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- fb/fbscreen.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fb/fbscreen.c b/fb/fbscreen.c index b2b9739..9876ba7 100644 --- a/fb/fbscreen.c +++ b/fb/fbscreen.c @@ -106,11 +106,15 @@ fbSetupScreen(ScreenPtr pScreen, void *pbits, /* pointer to screen bitmap */ pScreen-GetImage = fbGetImage; pScreen-GetSpans = fbGetSpans; pScreen-CreateWindow = fbCreateWindow; -pScreen-DestroyWindow = fbDestroyWindow; -pScreen-PositionWindow = fbPositionWindow; +if (pScreen-DestroyWindow == NULL) +pScreen-DestroyWindow = fbDestroyWindow; +if (pScreen-PositionWindow == NULL) +pScreen-PositionWindow = fbPositionWindow; pScreen-ChangeWindowAttributes = fbChangeWindowAttributes; -pScreen-RealizeWindow = fbMapWindow; -pScreen-UnrealizeWindow = fbUnmapWindow; +if (pScreen-RealizeWindow == NULL) +pScreen-RealizeWindow = fbMapWindow; +if (pScreen-UnrealizeWindow == NULL) +pScreen-UnrealizeWindow = fbUnmapWindow; pScreen-CopyWindow = fbCopyWindow; pScreen-CreatePixmap = fbCreatePixmap; pScreen-DestroyPixmap = fbDestroyPixmap; -- 2.0.0.rc2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/6] fb: Avoid installing terminal functions over pre-existing call chains
On Wed, May 28, 2014 at 01:31:50AM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: The fbWindow family of functions (Map, Unmap, Position and Destroy) are all terminal functions, that is they do not chain up to earlier extensions. This breaks those chains which leads to not only resource leaks but also dereference of dangling pointers. One such issue arises with fbScreenInit() breaking the earlier present_screen_init() and causing the Xserver to die when a Window is closed after being used with Present and fb: fb expects to be initialized first, before any extensions, so that its terminal functions will always be at the bottom of the call chain. Hmm, the sequence I have in UXA is wrong then. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 4/6] fb: Avoid installing terminal functions over pre-existing call chains
On Wed, May 28, 2014 at 02:15:58AM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: Hmm, the sequence I have in UXA is wrong then. Sounds like it. Indeed, that was easy enough to resolve once I knew to look in the right place. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 5/6] present: Do not free screen_priv-flip_pending until it is finished
On Wed, May 28, 2014 at 12:07:40PM +0100, Frank Binns wrote:
On 28/05/14 08:14, Chris Wilson wrote:
If we close the Window prior to completing all the flips, we free the
vblank pointer but leave screen_priv-flip_pending dangling. This leads
to a host of invalid reads/writes as it is accessed from many locations,
e.g.:
==20302== Invalid write of size 4
==20302==at 0x81A8FD5: present_flip_destroy (present.c:879)
==20302==by 0x81A6A2A: present_close_screen (present_screen.c:60)
==20302==by 0x8147A5A: CursorCloseScreen (cursor.c:187)
==20302==by 0x81A3DDA: AnimCurCloseScreen (animcur.c:106)
==20302==by 0x8142F7D: compCloseScreen (compinit.c:85)
==20302==by 0x80E6D2A: VidModeClose (xf86VidMode.c:111)
==20302==by 0x496CF23: glxCloseScreen (glxscreens.c:187)
==20302==by 0x808186F: dix_main (main.c:349)
==20302==by 0x80D2FA1: main (stubmain.c:34)
==20302== Address 0x67d0780 is 104 bytes inside a block of size 108 free'd
==20302==at 0x4007BCD: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==20302==by 0x81A90AC: present_vblank_destroy (present.c:911)
==20302==by 0x81A6ADF: present_free_window_vblank (present_screen.c:79)
==20302==by 0x81A6C2C: present_destroy_window (present_screen.c:116)
==20302==by 0x8145796: compDestroyWindow (compwindow.c:608)
==20302==by 0x8176B6B: DbeDestroyWindow (dbe.c:1318)
==20302==by 0x80B5A98: FreeWindowResources (window.c:910)
==20302==by 0x80B5D7B: DeleteWindow (window.c:978)
==20302==by 0x80A9C85: doFreeResource (resource.c:873)
==20302==by 0x80AA5F8: FreeClientResources (resource.c:1139)
==20302==by 0x807BD5E: CloseDownClient (dispatch.c:3384)
==20302==by 0x80740B5: Dispatch (dispatch.c:406)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
present/present_screen.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/present/present_screen.c b/present/present_screen.c
index b475d03..0a525a8 100644
--- a/present/present_screen.c
+++ b/present/present_screen.c
@@ -72,11 +72,14 @@ static void
present_free_window_vblank(WindowPtr window)
{
present_window_priv_ptr window_priv = present_window_priv(window);
+present_screen_priv_ptr screen_priv =
present_screen_priv(window-drawable.pScreen);
+present_vblank_ptr flip_pending = screen_priv-flip_pending;
present_vblank_ptr vblank, tmp;
xorg_list_for_each_entry_safe(vblank, tmp, window_priv-vblank,
window_list) {
present_abort_vblank(window-drawable.pScreen, vblank-crtc,
vblank-event_id, vblank-target_msc);
-present_vblank_destroy(vblank);
+if (vblank != flip_pending)
+present_vblank_destroy(vblank);
}
}
Hi Chris,
Doesn't this result in the vblank structure never being cleaned up
because the vblank event, which would normally result in it being
destroyed, gets ignored due to present_abort_vblank() being called
a couple of lines above?
True, I was thinking it would still get cleaned up through
present_flip_notify, which now never occurs.
I actually submitted a similar patch to this a month ago but never
got around to addressing Keith's review comments. See patch 2
from the following series:
http://lists.x.org/archives/xorg-devel/2014-April/042129.html
I've now gone back to looking at this so that I can address the
comments and resubmit the patches.
Ok, I'll see if these make everything quiet here as well.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 5/6] present: Do not free screen_priv-flip_pending until it is finished
On Wed, May 28, 2014 at 12:22:14PM +0100, Chris Wilson wrote:
On Wed, May 28, 2014 at 12:07:40PM +0100, Frank Binns wrote:
On 28/05/14 08:14, Chris Wilson wrote:
If we close the Window prior to completing all the flips, we free the
vblank pointer but leave screen_priv-flip_pending dangling. This leads
to a host of invalid reads/writes as it is accessed from many locations,
e.g.:
==20302== Invalid write of size 4
==20302==at 0x81A8FD5: present_flip_destroy (present.c:879)
==20302==by 0x81A6A2A: present_close_screen (present_screen.c:60)
==20302==by 0x8147A5A: CursorCloseScreen (cursor.c:187)
==20302==by 0x81A3DDA: AnimCurCloseScreen (animcur.c:106)
==20302==by 0x8142F7D: compCloseScreen (compinit.c:85)
==20302==by 0x80E6D2A: VidModeClose (xf86VidMode.c:111)
==20302==by 0x496CF23: glxCloseScreen (glxscreens.c:187)
==20302==by 0x808186F: dix_main (main.c:349)
==20302==by 0x80D2FA1: main (stubmain.c:34)
==20302== Address 0x67d0780 is 104 bytes inside a block of size 108 free'd
==20302==at 0x4007BCD: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==20302==by 0x81A90AC: present_vblank_destroy (present.c:911)
==20302==by 0x81A6ADF: present_free_window_vblank (present_screen.c:79)
==20302==by 0x81A6C2C: present_destroy_window (present_screen.c:116)
==20302==by 0x8145796: compDestroyWindow (compwindow.c:608)
==20302==by 0x8176B6B: DbeDestroyWindow (dbe.c:1318)
==20302==by 0x80B5A98: FreeWindowResources (window.c:910)
==20302==by 0x80B5D7B: DeleteWindow (window.c:978)
==20302==by 0x80A9C85: doFreeResource (resource.c:873)
==20302==by 0x80AA5F8: FreeClientResources (resource.c:1139)
==20302==by 0x807BD5E: CloseDownClient (dispatch.c:3384)
==20302==by 0x80740B5: Dispatch (dispatch.c:406)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
present/present_screen.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/present/present_screen.c b/present/present_screen.c
index b475d03..0a525a8 100644
--- a/present/present_screen.c
+++ b/present/present_screen.c
@@ -72,11 +72,14 @@ static void
present_free_window_vblank(WindowPtr window)
{
present_window_priv_ptr window_priv =
present_window_priv(window);
+present_screen_priv_ptr screen_priv =
present_screen_priv(window-drawable.pScreen);
+present_vblank_ptr flip_pending = screen_priv-flip_pending;
present_vblank_ptr vblank, tmp;
xorg_list_for_each_entry_safe(vblank, tmp, window_priv-vblank,
window_list) {
present_abort_vblank(window-drawable.pScreen, vblank-crtc,
vblank-event_id, vblank-target_msc);
-present_vblank_destroy(vblank);
+if (vblank != flip_pending)
+present_vblank_destroy(vblank);
}
}
Hi Chris,
Doesn't this result in the vblank structure never being cleaned up
because the vblank event, which would normally result in it being
destroyed, gets ignored due to present_abort_vblank() being called
a couple of lines above?
True, I was thinking it would still get cleaned up through
present_flip_notify, which now never occurs.
Except that it somehow still does even after your 4 patches, leading to
a use-after-free of screen_priv-flip_pending.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: By default, throttle after two pending swaps.
On Tue, May 13, 2014 at 09:20:45AM -0700, Jamey Sharp wrote:
On May 13, 2014 12:57 AM, Chris Wilson [1]ch...@chris-wilson.co.uk
wrote:
=0 ickle:/usr/src/piglit$ ./bin/glx-oml-sync-control-getmscrate
PIGLIT: {'result': 'pass' }
=0 ickle:/usr/src/piglit$ ./bin/glx-oml-sync-control-waitformsc
PIGLIT: {'result': 'pass' }
=0 ickle:/usr/src/piglit$
./bin/glx-oml-sync-control-swapbuffersmsc-divisor-zero
PIGLIT: {'result': 'pass' }
=0 ickle:/usr/src/piglit$
./bin/glx-oml-sync-control-swapbuffersmsc-return
Testing with default swap interval
PIGLIT: {'result': 'pass' }
Am I missing something?
Yeah, we have new tests that haven't quite been merged yet as we're
addressing Eric's review comments. Our current version, revised yesterday,
is available here:
[2]https://github.com/ThirteenFish/piglit
Make sure you do a full 'piglit-run.py -t OML_sync_control ...' as we run
the new tests in a variety of configurations, and the full-screen ones are
particularly interesting here. Though IIRC, SNA fails some of the others
as well.
Looks like there are quite a few bugs remaining in the test cases.
glXGetSyncValuesOML returns the current hardware frame counter and time
of last frame update, not the last client swap frame or swap time. You
make an assumption in the timing loop that the calls to SwapBuffers
and GetSyncValues are instantaneous and do not account for a vblank
interrupt that can happen in between updating the hardware counters.
The computation of interframe jitter is wonky, thanks to using
(new_timestamp - -1) on the first pass.
glXSwapBuffersMscOML: If divisor = 0,
the swap will occur when MSC becomes greater than or equal to
target_msc.
The minimum expected_msc is therefore the target_msc in many cases and
no time may pass at all during the timing loop if msc-delta=0.
In repeat-swapbuffers.c, you query the current hw counters before the
swap may have completed, and runs afoul of the divisor==0 logic above.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: By default, throttle after two pending swaps.
On Wed, May 14, 2014 at 06:49:10AM -0700, Jamey Sharp wrote: On Wed, May 14, 2014 at 01:31:14PM +0100, Chris Wilson wrote: On Tue, May 13, 2014 at 09:20:45AM -0700, Jamey Sharp wrote: Yeah, we have new tests that haven't quite been merged yet as we're addressing Eric's review comments. Our current version, revised yesterday, is available here: [2]https://github.com/ThirteenFish/piglit Make sure you do a full 'piglit-run.py -t OML_sync_control ...' as we run the new tests in a variety of configurations, and the full-screen ones are particularly interesting here. Though IIRC, SNA fails some of the others as well. Looks like there are quite a few bugs remaining in the test cases. Thanks for reviewing them, Chris! glXGetSyncValuesOML returns the current hardware frame counter and time of last frame update, not the last client swap frame or swap time. You make an assumption in the timing loop that the calls to SwapBuffers and GetSyncValues are instantaneous and do not account for a vblank interrupt that can happen in between updating the hardware counters. We do make that assumption, but if the assumption is violated we only emit a warning. It's a FAIL currently. And it would be very surprising if a correctly-functioning driver violated that assumption, because WaitForMsc/Sbc are required to return as soon as possible once the swap completes. So we should have something like 16ms to issue the follow-up GetSyncValues before the values will change. With divisor=0 swaps, the driver is allowed to perform immediate completion of swaps if target_msc == current_msc. So it is possible for the driver to receive a swap request and reply that it completed it that msc just prior to an interrupt occuring. We included that warning because drivers call DRI2SwapComplete with zeroes for UST and MSC, which is clearly always wrong, and this also lets us continue on to test whether they're at least syncing to vblank. The computation of interframe jitter is wonky, thanks to using (new_timestamp - -1) on the first pass. Oops, we broke that while addressing Eric's review comments on Monday. We'll fix it. (Theo, if I don't get to it first: both the if and else starting on line 182 need to be guarded with (last_timestamp = 0). We'll have to deal with the 80-column limit some other way.) glXSwapBuffersMscOML: If divisor = 0, the swap will occur when MSC becomes greater than or equal to target_msc. Yes, except: If there are multiple outstanding swaps for the same window, at most one such swap can be satisfied per increment of MSC. Right. But using the divisor=0 logic above we don't have queued frames if a client never requests a swap in the future. As soon as that happens, we end up with a steady state of swaps and fail to break out of the rut never to return to the expected fast behaviour. The minimum expected_msc is therefore the target_msc in many cases and no time may pass at all during the timing loop if msc-delta=0. Note that timing.c's main() prohibits using WaitForMsc without also setting either msc-delta or divisor, because that combination would fail in the way you describe. However, because of the above-quoted sentence in the spec, we believe that SwapBuffersMsc must behave as if we'd set msc-delta non-zero. Except when there is not an outstanding swap because the spec allows the driver to complete the swap immediately for the target_msc == current_msc with divisor == 0. In the open-source implementations, swap_interval defaults to 1 and so it does behave this way. If you override swap_interval to 0, you get non-conforming behavior, but I don't believe that's a test bug. In repeat-swapbuffers.c, you query the current hw counters before the swap may have completed, That's because that test's purpose is, as the file comment says, Verifies that glXSwapBuffersMscOML does not increment SBC more often than MSC. In that test we don't want to wait for any swaps to complete. and runs afoul of the divisor==0 logic above. Since that test only uses SwapBuffersMsc, the same reasoning applies. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: By default, throttle after two pending swaps.
On Mon, May 12, 2014 at 06:30:47PM -0700, Jamey Sharp wrote: According to Chris Wilson, the Intel driver has a horrifying kludge to get triple-buffering despite the swap_limit being set to only allow double-buffering by default. This kludge makes OML_sync_control unusable if the Intel driver goes into page-flipping mode. Since triple-buffering is preferred for most applications, let's make it the default in the server and allow the drivers to quit lying to the X server about when swaps complete. I suggest this patch be back-ported to stable releases. Since the Intel driver, at least, is already forcing applications to use triple buffering regardless of their SwapLimit setting, it must be safe. Signed-off-by: Jamey Sharp ja...@minilop.net Signed-off-by: Theo Hill theo0...@gmail.com Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Eric Anholt e...@anholt.net Cc: Matt Dew mar...@osource.org No, it is not that simple. GetBuffers() can only be allowed to proceed after the driver has arranged for the call to return the right buffers to the client. In the event that a client scheduled a future swap, most drivers will defer the buffer exchange until the swap is actually performed - limiting the client to double buffering to avoid complications in reporting the wrong buffers. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: By default, throttle after two pending swaps.
On Tue, May 13, 2014 at 12:18:49AM -0700, Jamey Sharp wrote:
On Tue, May 13, 2014 at 12:01 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Mon, May 12, 2014 at 06:30:47PM -0700, Jamey Sharp wrote:
According to Chris Wilson, the Intel driver has a horrifying kludge to
get triple-buffering despite the swap_limit being set to only allow
double-buffering by default. This kludge makes OML_sync_control unusable
if the Intel driver goes into page-flipping mode.
Since triple-buffering is preferred for most applications, let's make it
the default in the server and allow the drivers to quit lying to the X
server about when swaps complete.
No, it is not that simple. GetBuffers() can only be allowed to proceed
after the driver has arranged for the call to return the right buffers
to the client. In the event that a client scheduled a future swap, most
drivers will defer the buffer exchange until the swap is actually
performed - limiting the client to double buffering to avoid
complications in reporting the wrong buffers.
Alright. How do you believe the Intel driver's buggy and unusable
implementation of OML_sync_control should be fixed?
I'd also be delighted to see patches to make SNA pass the new Piglit
tests. I tried to fix that before I turned to UXA but I got lost in
too many different DRI2SwapComplete calls with spec-violating
parameters before I even got to checking whether it was reliably
syncing to vertical retrace. I'd be happy to send along the one patch
I could figure out if you want it though.
=0 ickle:/usr/src/piglit$ ./bin/glx-oml-sync-control-getmscrate
PIGLIT: {'result': 'pass' }
=0 ickle:/usr/src/piglit$ ./bin/glx-oml-sync-control-waitformsc
PIGLIT: {'result': 'pass' }
=0 ickle:/usr/src/piglit$
./bin/glx-oml-sync-control-swapbuffersmsc-divisor-zero
PIGLIT: {'result': 'pass' }
=0 ickle:/usr/src/piglit$ ./bin/glx-oml-sync-control-swapbuffersmsc-return
Testing with default swap interval
PIGLIT: {'result': 'pass' }
Am I missing something?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/3] sync: Serialise access to the fence before waking clients
By waking the clients before we finish the work associated with the
fence we expose ourselves to a race where the clients may see the
incomplete results.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
miext/sync/misyncshm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/miext/sync/misyncshm.c b/miext/sync/misyncshm.c
index 01f82fc..4d11b57 100644
--- a/miext/sync/misyncshm.c
+++ b/miext/sync/misyncshm.c
@@ -50,9 +50,9 @@ miSyncShmFenceSetTriggered(SyncFence * pFence)
{
SyncShmFencePrivatePtr pPriv = SYNC_FENCE_PRIV(pFence);
+miSyncFenceSetTriggered(pFence);
if (pPriv-fence)
xshmfence_trigger(pPriv-fence);
-miSyncFenceSetTriggered(pFence);
}
static void
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
DRI3 fixes
There is an issue with the DRI3 protocol that limits stride to CARD16. Even on old Intel hw we can exceed that which prevents the protocol from transporting many valid buffers. [PATCH 1/3] xfree86: Report DRI3 as a built-in module [PATCH 2/3] sync: Serialise access to the fence before waking clients [PATCH 3/3] sync: Record the associated Drawable for a shm/fd fence The first two patches are simple bug fixes, with the last being a major efficiency burden in the current API. -Chris ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/3] xfree86: Report DRI3 as a built-in module
This is so that drivers can do a runtime check that DRI3 is available,
similar to existing runtime checks performed by the drivers for DRI and
DRI2.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
hw/xfree86/loader/loadmod.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 092bf57..9f54929 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -838,6 +838,7 @@ static const char *compiled_in_modules[] = {
extmod,
dri,
dri2,
+dri3,
NULL
};
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/3] sync: Record the associated Drawable for a shm/fd fence
Alongside DRI3, SHM fences are used to serialise changes to the Pixmap
shared between the client and the xserver. By recording the associated
Drawable for a particular fence, the driver can reduce the amount of
work required for serialisation (i.e. it only has to serialise access to
one Pixmap, not all).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
miext/sync/misyncfd.c | 2 +-
miext/sync/misyncfd.h | 3 ++-
miext/sync/misyncshm.c | 11 ++-
miext/sync/misyncshm.h | 4
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/miext/sync/misyncfd.c b/miext/sync/misyncfd.c
index 93ff85f..b5fe92d 100644
--- a/miext/sync/misyncfd.c
+++ b/miext/sync/misyncfd.c
@@ -52,7 +52,7 @@ miSyncInitFenceFromFD(DrawablePtr pDraw, SyncFence *pFence,
int fd, BOOL initial
if (!priv)
return BadMatch;
-return (*priv-funcs.CreateFenceFromFd)(pDraw-pScreen, pFence, fd,
initially_triggered);
+return (*priv-funcs.CreateFenceFromFd)(pDraw-pScreen, pFence, pDraw, fd,
initially_triggered);
}
int
diff --git a/miext/sync/misyncfd.h b/miext/sync/misyncfd.h
index c1d05f9..2cb33dc 100644
--- a/miext/sync/misyncfd.h
+++ b/miext/sync/misyncfd.h
@@ -25,11 +25,12 @@
typedef int (*SyncScreenCreateFenceFromFdFunc) (ScreenPtr screen,
SyncFence *fence,
+DrawablePtr drawable,
int fd,
Bool initially_triggered);
typedef int (*SyncScreenGetFenceFdFunc) (ScreenPtr screen,
- SyncFence *fence);
+ SyncFence *fence);
#define SYNC_FD_SCREEN_FUNCS_VERSION1
diff --git a/miext/sync/misyncshm.c b/miext/sync/misyncshm.c
index 4d11b57..f954e1e 100644
--- a/miext/sync/misyncshm.c
+++ b/miext/sync/misyncshm.c
@@ -38,6 +38,7 @@
static DevPrivateKeyRec syncShmFencePrivateKey;
typedef struct _SyncShmFencePrivate {
+DrawablePtr pDrawable;
struct xshmfence*fence;
int fd;
} SyncShmFencePrivateRec, *SyncShmFencePrivatePtr;
@@ -121,12 +122,14 @@ miSyncShmScreenDestroyFence(ScreenPtr pScreen, SyncFence
* pFence)
}
static int
-miSyncShmCreateFenceFromFd(ScreenPtr pScreen, SyncFence *pFence, int fd, Bool
initially_triggered)
+miSyncShmCreateFenceFromFd(ScreenPtr pScreen, SyncFence *pFence, DrawablePtr
draw, int fd, Bool initially_triggered)
{
SyncShmFencePrivatePtr pPriv = SYNC_FENCE_PRIV(pFence);
miSyncInitFence(pScreen, pFence, initially_triggered);
+pPriv-pDrawable = draw;
+
fd = os_move_fd(fd);
pPriv-fence = xshmfence_map_shm(fd);
if (pPriv-fence) {
@@ -184,3 +187,9 @@ _X_EXPORT Bool miSyncShmScreenInit(ScreenPtr pScreen)
return TRUE;
}
+_X_EXPORT DrawablePtr
+miSyncShmFenceGetDrawable(SyncFence *pFence)
+{
+SyncShmFencePrivatePtr pPriv = SYNC_FENCE_PRIV(pFence);
+return pPriv ? pPriv-pDrawable : NULL;
+}
diff --git a/miext/sync/misyncshm.h b/miext/sync/misyncshm.h
index 23c001a..2484970 100644
--- a/miext/sync/misyncshm.h
+++ b/miext/sync/misyncshm.h
@@ -23,6 +23,10 @@
#ifndef _MISYNCSHM_H_
#define _MISYNCSHM_H_
+#include misync.h
+
extern _X_EXPORT Bool miSyncShmScreenInit(ScreenPtr pScreen);
+extern _X_EXPORT DrawablePtr miSyncShmFenceGetDrawable(SyncFence *pFence);
+
#endif /* _MISYNCSHM_H_ */
--
2.0.0.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/3] xfree86: Report DRI3 as a built-in module
On Mon, May 12, 2014 at 11:29:58AM +0200, Mark Kettenis wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon, 12 May 2014 08:12:37 +0100
This is so that drivers can do a runtime check that DRI3 is available,
similar to existing runtime checks performed by the drivers for DRI and
DRI2.
Does that run-time check actually work? It seems any check based on
compiled_in_modules would detect DRI3 even on platforms that don't
support DRI3 or if the server was built using --disable-dri3.
I was just following suit, but you are right...
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 9f54929..f92ad8d 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -838,7 +838,9 @@ static const char *compiled_in_modules[] = {
extmod,
dri,
dri2,
+#if DRI3
dri3,
+#endif
NULL
};
Should do the right thing, I think.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 09/10] dri3: Add dri3 extension framework
On Thu, Oct 31, 2013 at 03:43:41PM -0700, Keith Packard wrote:
+static void
+miSyncShmFenceSetTriggered(SyncFence * pFence)
+{
+SyncShmFencePrivatePtr pPriv = SYNC_FENCE_PRIV(pFence);
+
+if (pPriv-fence)
+xshmfence_trigger(pPriv-fence);
+miSyncFenceSetTriggered(pFence);
This is racy as the clients are woken up before the server has had a
chance to do the required work.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.911
Snapshot 2.99.911 (2014-03-19) == Hans de Geode has been working on making the Xserver work without privileges under the supervision of systemd/logind. This necessitated a few new features for us: server fds (where we are passed which fd to use to talk to our device by the Xserver who may in turn receive it from logind or other host) and a small backlight helper so that we can continue to provide a RandR backlight property when running without root privileges. * Flush when changing blend modes on Ironlake, or else single glyphs are sometimes rendered incorrectly Regression from 2.20.15 https://bugs.freedesktop.org/show_bug.cgi?id=74882 * Fix pixmap offsets for pixman fallbacks onto Composite redirected windows https://bugs.freedesktop.org/show_bug.cgi?id=73811 * Fix blending onto 8-bit destinations, typically used for generating masks in complex Render operations, on gen2 https://bugs.freedesktop.org/show_bug.cgi?id=75818 * Handle failure to create DRI bo more carefully. For example on gen3, the DDX supports pixmaps that are much, much larger than OpenGL can use and do not support the tiling modes that we request for OpenGL. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1289049 * Fix a bookkeeping bug with proxy buffers that are marked active but not actually inserted into a request (so they end up permanently active and confuse everybody). https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1289923 * Actually turn off displays with DPMS off for UXA. Regression from 2.99.903, but requires kernel commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sun Sep 29 19:15:07 2013 +0100 drm/i915: Only apply DPMS to the encoder if enabled instead for correct behaviour on Haswell. https://code.google.com/p/chromium/issues/detail?id=341135 Complete list of changes since 2.99.910 --- Chris Wilson (100): sna: Clear GPU damage flag for 1x1 writes onto a clear buffer sna: Check for overwriting damage before applying clear sna: Remove damaged region after converting CPU bo to GPU bo sna/gen6: Serialise write to DERRMR register using STORE_REGISTER_MEM sna: Defer move-to-gpu until we need to transfer GPU damage to CPU Record Video ABI version that we configure against sna: Delete redundant branch sna: Retrieve tiling for fbcon sna/gen5: Add a DBG option to force flushes between operations sna/gen5: Use the DBG option ALWAYS_FLUSH to force a full flush Revert sna/gen6: Serialise write to DERRMR register using STORE_REGISTER_MEM sna: Support native primary plane rotations intel-virtul-output: Double check timestamps intel-virtual-output: Always requery modes after OutputNotify intel-virtual-output: Fix checking for no change in output modes intel-virtual-output: Force an output probe on initial connection to remote display intel-virtual-output: Do not resize the screen whilst all outputs are off sna/gen5: Flush the render cache between operations sna: Always assign a name to the modes Revert uxa: Do not change DPMS mode on unconnected outputs sna: Enable coordinate transforms for native CRTC rotation sna: Extend native rotation support to sprites sna: Clear DPMS tracking on VT switch sna: Check for access to backlight interface uxa: Check for access to backlight interface sna: Fix comparison of previous BLT commands sna: Filter out requests to create a 0x0 frontbuffer sna: Increase the acceptable screen size range sna: Check that the backlight interface is in sysfs before access sna: Guard use of DRM_MODE_OBJECT type ids sna: Reorganise native rotation ioctls to compile on old Linux sna: Inherit the native rotation on initial output probing intel: Add a helper for setting backlight without root rights backlight: Amalgamate hardcoded priority tables backlight: Reject user overrides on OpenBSD backlight: tidy use of BACKLIGHT_CLASS intel-virtual-output: Discard unwanted events from the mouse recorder sna: Query cursor size from the kernel backlight: Make search routine for device specific backlight common sna: Do not register colormaps without any CRTCs sna: Do not attempt fallback configuration without any CRTCs sna: Tighten assertion for tiling blt fallbacks sna: Wrap inplace trapezoid operators with SIGBUS protection sna: Allow allocation to fail even when debugging sna: Use a hint to do whole image uploads inplace sna: Handle asynchronous signals from threads sna: Apply the dst offset for pixman fills sna: Assert that sigtrap is active sna: Move sigtrap wrapping closer to threaded sw composite
Re: [Intel-gfx] What to do with xf86-video-intel backlight control when running Xorg as non root
On Thu, Feb 13, 2014 at 04:52:59PM +0100, Hans de Goede wrote: Hi All, Currently xf86-video-intel is unique in that it is the only video driver which does backlight control inside the driver rather then letting something else (ie the desktop environment) deal with it. This is a problem when running the xserver without root rights because writing /sys/class/backlight/foo/brightness requires root rights. There are 2 possible (short term) solutions for this: 1) Detect that the xserver is not running as root, and don't register the backlight property on the connectors, let something else deal with it, as is done or other xf86-video-* drivers already. 2) Add a little xf86-video-intel-brightness helper on Linux which the driver execs (through pkexec) each time it needs to set the brightness. 1) of course is very KISS, so I like. 2) is not that hard either, and 1) might cause some regressions in cases where ie gsd-brightness-helper does not do the right thing, where as the intel driver does. OTOH it seems that the intel video code is mostly there to deal with older kernels, and rootless xorg will be used with newer kernels only anyways. Not registering a property that is broken seems like the fundamental first step. Would it be possible to use udev to set the access mode on the backlight properties such that the display controller does have permission to write to those files? Otherwise, it seems like we need the proxy in order to keep the xrandr property available to users and prevent those who rely upon it in scripts from seeing regressions. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Intel-gfx] What to do with xf86-video-intel backlight control when running Xorg as non root
On Thu, Feb 13, 2014 at 08:37:47PM +0100, Hans de Goede wrote:
Hi,
On 02/13/2014 05:40 PM, Chris Wilson wrote:
Otherwise, it seems like we need the
proxy in order to keep the xrandr property available to users and
prevent those who rely upon it in scripts from seeing regressions.
Right, that is what I was thinking too, so the question then becomes how
hard you will scream at me if I add something like this to xf86-video-intel
linux specific backlight code:
if (geteuid() == 0) {
/* Old write directly to /sys/class/backlight/... code */
{
else {
/* The is to avoid the xserver blocking */
snprintf(command, sizeof(command), pkexec
%s/libexec/xf86-video-intel-backlight-helper %s %d,
PREFIX, sna_output-backlight_iface, level);
r = system(command);
if (r) {
/* complain */
}
}
If you won't scream too much, and more importantly, if you will accept such
a patch (including code for the helper), then I'll try to cook up something
like this tomorrow.
I feel comfortable enough with that approach, and have nothing better to
suggest. (I would just employ the fallback case if open(O_RDWR) fails.)
And limiting the helper to only write its value into
BACKLIGHT_CLASS/%{iface}/brightness should help reduce its attack surface.
Thinking about it, it would be useful if we verified that BACKLIGHT_CLASS
(both the ddx and its helper)was a sysfs directory in the first place.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.910
Snapshot 2.99.910 (2013-02-10) == Another latent bug exposed by recent changes merit another snapshot for final testing. * Only discard damage when overwriting the dirty CPU bo, instead of discarding damage that will be shown! * Reset operation state when switching between glyph caches. https://bugs.freedesktop.org/show_bug.cgi?id=74494 * Fully reinitialise pixmaps allocated from the freed cache. Fixes a potential issue (crash or misrendering) when using some compositors. https://bugs.freedesktop.org/show_bug.cgi?id=74550 * Do not expose the TexturedVideo adaptor in UXA when it is disabled either due to a hung GPU or explicitly disabled by the user. * Restore the pipe stall when changing CC state on gen6, otherwise the GPU may not flush intermediate results from all EU resulting in render corruption (usually the occasional black box). Regression from 2.99.906 https://bugs.freedesktop.org/show_bug.cgi?id=7237 Complete list of changes since 2.99.910 --- Chris Wilson (18): sna: Undo region translation before returning sna: Allow more inplace promotions of CPU to GPU bo sna: Skip discarding CPU bo when using as a render target sna: Add some more DBG for choosing render targets sna: If IGNORE_CPU is not set we must mark the move as MOVE_READ sna: Reconstruct damage for the partially replaced discarded CPU bo sna/glyphs: Reset composite state between switching glyph formats sna/gen4: Disable use of pipecontrol invalidates again sna: Rearrange assertion to ease use of substitute cached bo sna: Tweak assert_bo_retired() to be callable on cached bo sna: Pass read hints from move-to-cpu to wait_for_shadow sna: Add some DBG around tiled blts sna: Reset composite offsets when reusing freed pixmaps sna: Add some DBG to clarify the source pixmap (for tiles) uxa: Do not expose TextureVideo Xv adapters when acceleration is disabled sna: And clear drawable-id on reused pixmaps sna/gen6: Restore stall dropped when not flushing instead 2.99.910 snapshot Edward Sheldrake (1): sna/gen4,5: Fix setting pipe control cache flush bits git tag: 2.99.910 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.910.tar.bz2 MD5: a9a5c2c15766c06a024381efe0d724bb xf86-video-intel-2.99.910.tar.bz2 SHA1: 23afc1ffc275a4114461fbf354b33d2287cc57a3 xf86-video-intel-2.99.910.tar.bz2 SHA256: 203d46064449da0e23a111418dfb189422ba96ea08707167c8dee463e2d745b1 xf86-video-intel-2.99.910.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.910.tar.gz MD5: 1486dfcd4eda31a9c72ec70bbc0cd041 xf86-video-intel-2.99.910.tar.gz SHA1: 16272838d4a67b5bc88fcaf113db25b946933eaa xf86-video-intel-2.99.910.tar.gz SHA256: 7c2dba447c1bf4acb4ec6dcdbc0821a3434ca3cc4869bdbe9f5e96e39a781a19 xf86-video-intel-2.99.910.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] xf86-video-intel 2.99.910
Snapshot 2.99.910 (2013-02-10) == Another latent bug exposed by recent changes merit another snapshot for final testing. * Only discard damage when overwriting the dirty CPU bo, instead of discarding damage that will be shown! * Reset operation state when switching between glyph caches. https://bugs.freedesktop.org/show_bug.cgi?id=74494 * Fully reinitialise pixmaps allocated from the freed cache. Fixes a potential issue (crash or misrendering) when using some compositors. https://bugs.freedesktop.org/show_bug.cgi?id=74550 * Do not expose the TexturedVideo adaptor in UXA when it is disabled either due to a hung GPU or explicitly disabled by the user. * Restore the pipe stall when changing CC state on gen6, otherwise the GPU may not flush intermediate results from all EU resulting in render corruption (usually the occasional black box). Regression from 2.99.906 https://bugs.freedesktop.org/show_bug.cgi?id=7237 Complete list of changes since 2.99.910 --- Chris Wilson (18): sna: Undo region translation before returning sna: Allow more inplace promotions of CPU to GPU bo sna: Skip discarding CPU bo when using as a render target sna: Add some more DBG for choosing render targets sna: If IGNORE_CPU is not set we must mark the move as MOVE_READ sna: Reconstruct damage for the partially replaced discarded CPU bo sna/glyphs: Reset composite state between switching glyph formats sna/gen4: Disable use of pipecontrol invalidates again sna: Rearrange assertion to ease use of substitute cached bo sna: Tweak assert_bo_retired() to be callable on cached bo sna: Pass read hints from move-to-cpu to wait_for_shadow sna: Add some DBG around tiled blts sna: Reset composite offsets when reusing freed pixmaps sna: Add some DBG to clarify the source pixmap (for tiles) uxa: Do not expose TextureVideo Xv adapters when acceleration is disabled sna: And clear drawable-id on reused pixmaps sna/gen6: Restore stall dropped when not flushing instead 2.99.910 snapshot Edward Sheldrake (1): sna/gen4,5: Fix setting pipe control cache flush bits git tag: 2.99.910 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.910.tar.bz2 MD5: a9a5c2c15766c06a024381efe0d724bb xf86-video-intel-2.99.910.tar.bz2 SHA1: 23afc1ffc275a4114461fbf354b33d2287cc57a3 xf86-video-intel-2.99.910.tar.bz2 SHA256: 203d46064449da0e23a111418dfb189422ba96ea08707167c8dee463e2d745b1 xf86-video-intel-2.99.910.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.910.tar.gz MD5: 1486dfcd4eda31a9c72ec70bbc0cd041 xf86-video-intel-2.99.910.tar.gz SHA1: 16272838d4a67b5bc88fcaf113db25b946933eaa xf86-video-intel-2.99.910.tar.gz SHA256: 7c2dba447c1bf4acb4ec6dcdbc0821a3434ca3cc4869bdbe9f5e96e39a781a19 xf86-video-intel-2.99.910.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.99.909
Snapshot 2.99.909 (2013-02-01) == Pass the brown paper bag. Ridiculously stupid bug in last minute coding. * Add Xv support using glamor acceleration in addition to adaptors provided by the UXA backend. * Fix overeager discarding of CPU damage Regression in 2.99.908 :( https://bugs.freedesktop.org/show_bug.cgi?id=74327 Complete list of changes since 2.99.908 --- Chris Wilson (6): glamor: Enable Xv support sna: Only discard CPU damage for an replacing region sna: Remark the region as damaged after uploading the rest to the GPU sna: Don't discard the GPU prior to using it for stashing CPU damage sna: Apply drawable offsets to partial CPU damage being replaced 2.99.909 snapshot git tag: 2.99.909 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.909.tar.bz2 MD5: 157bcc09a4a51b9212c8f1cbdc0be57d xf86-video-intel-2.99.909.tar.bz2 SHA1: 4af0876b623b5467a30124a408801f488b3c46a5 xf86-video-intel-2.99.909.tar.bz2 SHA256: 7541187161ee379f07591e1d2655f51e2d9772d98b34e8f21d7159d28ce70f55 xf86-video-intel-2.99.909.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.909.tar.gz MD5: 777aba03cb12fa74da006d31d5bf8bfb xf86-video-intel-2.99.909.tar.gz SHA1: 4880501d72066633271b135713bb7c858ad46d9c xf86-video-intel-2.99.909.tar.gz SHA256: 9ab471bf1ecf08d2ae8d533abf20464b6911c824681e497d8f96655327b3909d xf86-video-intel-2.99.909.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-intel 2.99.908
Snapshot 2.99.908 (2013-01-31) == A couple of regressions dashed the hopes that .907 was to be the final release candidate, so time to start the cycle again after applying a few more bugfixes. * Fix invalid pageflipping of GLXPixmaps by UXA. https://bugs.freedesktop.org/show_bug.cgi?id=73282 * Consistently treat DPMS Suspend/Standy as Off, otherwise we may incorrectly restore the backlight in UXA. * Fix disabling the backlight in UXA when querying the value whilst off https://bugs.freedesktop.org/show_bug.cgi?id=73181. * Invalidate between every operation if rendering into the source or mask. Fixes regression in 2.99.907 on Ivybridge (seen in KDE) https://bugs.freedesktop.org/show_bug.cgi?id=73208 * Check for available batch buffer state before restoring state on gen4, otherwise we overwrite surface state with commands and cause a GPU hang. https://bugs.freedesktop.org/show_bug.cgi?id=73348 * Prevent an invalid free by TearFree https://bugs.freedesktop.org/show_bug.cgi?id=73469 * Fix confusion in TearFree when it tried to pageflip to a stale bo https://bugs.freedesktop.org/show_bug.cgi?id=70905 * Initialise TearFree contents with the current frontbuffer upon creation, otherwise old content may be visible for significant fractions of a second after resume or DPMS on https://bugs.freedesktop.org/show_bug.cgi?id=73842 * Nullify the old pointer into a CPU mmapping of the bo when promoting it on the GPU. Eventually that old pointer becomes invalid and will cause the Xserver to crash. Fixes regression in 2.99.906 https://bugs.freedesktop.org/show_bug.cgi?id=73351 * Restore the serialNumber on the GC correctly after falling back to software. This was seen to cause corruption with Wine. https://bugs.freedesktop.org/show_bug.cgi?id=73856 * Do not ignore CPU damage on a pixmap unless the Composite operation will completely overwrite it. This was observed in xfce4. https://bugs.freedesktop.org/show_bug.cgi?id=69528 * Skip fake outputs during initial probe as they can cause a NULL pointer dereference. https://bugs.freedesktop.org/show_bug.cgi?id=73981 * Fix rendering of dashed zero-width lines onto 24bit buffers https://bugzilla.redhat.com/show_bug.cgi?id=1059152 * Cap the freed Pixmap cache and reuse it more often Fixes a regression in 2.99.907 that caused the memory used by X to grow until it was cleaned up during server regreneration https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1272338 Complete list of changes since 2.99.907 --- Chris Wilson (78): sna/gen7+: Emit invalidate between operations if rendering to source/mask uxa/dri: Pixmap are offscreen and not attached to any display sna: Always treat DPMSModeSuspend/Standby similar to DPMSModeOff uxa: Disable updating properties upon reading their values uxa: Always treat DPMSModeSuspend/Standby similar to DPMSModeOff sna: Remove spurious SAMPLER writemask for gen4 sna/gen4: Reduce flushes between primitive continuations sna/gen4: Check for available batch space before restoring state after CA pass sna/gen4: Use PIPE_CONTROL for a smaller hammer sna/gen4: Tidy URB_FENCE command Revert sna: Remove spurious SAMPLER writemask for gen4 sna: Add regular refcnt checks on pixmap bo sna: Include the deferred hotplug uevent propagation in DBG sna/dri: Handle TearFree vblanks whilst the pipe is off sna: Handle release of active stolen scanouts sna: Add some more paranoia around dangling pointers sna: Make the temporary upload pixmap as having a statically allocated pointer sna: Avoid allocating temporary storage for TearFree rotations sna: Regularly check that the devPrivate.ptr is valid sna: Cull the DBG spew to stderr sna: Intensify the move-to-cpu pointer paranoia sna: Nullify pixmap-devPrivate.ptr after promoting CPU bo to GPU intel: Silence a compiler warning (-Wshadow) sna: Dump fence registers upon starvation sna: Fix typo in debugfs paths sna: Refactor common routines for debugfs file dumping sna: Discard pending wait_for_shadow updates before the TearFree flip sna: Always emit an error message when an execbuffer fails sna: Use device minor to narrow search for debugfs files sna: Yield the processor if the kernel reports EAGAIN intel-virtual-output: Clone modes onto remote display intel-virtual-output: Disable remote display if SetCrtcConfig fails intel-virtual-output: Print error events for debugging sna: Increase limit on number of possible outputs intel-virtual-output: Tidy some DBG for copying new modes sna: Add some more DBG output around the clipping in sna_do_copy() sna: Short-cut the fallback
[ANNOUNCE] xf86-video-intel 2.99.909
Snapshot 2.99.909 (2013-02-01) == Pass the brown paper bag. Ridiculously stupid bug in last minute coding. * Add Xv support using glamor acceleration in addition to adaptors provided by the UXA backend. * Fix overeager discarding of CPU damage Regression in 2.99.908 :( https://bugs.freedesktop.org/show_bug.cgi?id=74327 Complete list of changes since 2.99.908 --- Chris Wilson (6): glamor: Enable Xv support sna: Only discard CPU damage for an replacing region sna: Remark the region as damaged after uploading the rest to the GPU sna: Don't discard the GPU prior to using it for stashing CPU damage sna: Apply drawable offsets to partial CPU damage being replaced 2.99.909 snapshot git tag: 2.99.909 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.909.tar.bz2 MD5: 157bcc09a4a51b9212c8f1cbdc0be57d xf86-video-intel-2.99.909.tar.bz2 SHA1: 4af0876b623b5467a30124a408801f488b3c46a5 xf86-video-intel-2.99.909.tar.bz2 SHA256: 7541187161ee379f07591e1d2655f51e2d9772d98b34e8f21d7159d28ce70f55 xf86-video-intel-2.99.909.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.99.909.tar.gz MD5: 777aba03cb12fa74da006d31d5bf8bfb xf86-video-intel-2.99.909.tar.gz SHA1: 4880501d72066633271b135713bb7c858ad46d9c xf86-video-intel-2.99.909.tar.gz SHA256: 9ab471bf1ecf08d2ae8d533abf20464b6911c824681e497d8f96655327b3909d xf86-video-intel-2.99.909.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH] render: Fix leak of filter params
==11097== 2,048 (+1,640) bytes in 32 (+26) blocks are definitely lost in loss
record 1,570 of 1,719
==11097==at 0x4C2A2DB: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11097==by 0x225EF3: SetPicturePictFilter (filter.c:339)
==11097==by 0x22DF4F: ProcRenderSetPictureFilter (render.c:1773)
==11097==by 0x15D25D: Dispatch (dispatch.c:432)
==11097==by 0x14C7B9: main (main.c:298)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
render/picture.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/render/picture.c b/render/picture.c
index 7da9310..92176fa 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -1441,6 +1441,7 @@ FreePicture(void *value, XID pid)
if (--pPicture-refcnt == 0) {
free(pPicture-transform);
+ free(pPicture-filter_params);
if (pPicture-pSourcePict) {
if (pPicture-pSourcePict-type != SourcePictTypeSolidFill)
--
1.8.5.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: Fix Client starvation with SmartScheduler priorities
On Wed, Jan 22, 2014 at 11:04:28AM -0800, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: The solution employed here is to undo the busy demotion after a period of idleness. Currently the idle boost is applied only once for a fresh client when it becomes selectable. The change is to apply that boost for all clients that remain ready for the entire duration of idle timeslice - eventually these old busy clients will be promoted sufficiently to be granted a ScheduleSlice. I think your analysis is spot-on, but the fix doesn't seem to match. By changing smart_check_tick only when it is older than 'idle', you're effectively just bumping smart_priority every other pass through the loop. Which explains why you get no starvation; all ready clients get priority bumps every other pass through the loop. But that includes the clients which are actually running, which definitely isn't what we want. I think what we want to do is simply increase the priority of clients which haven't run in a while, instead of clients which haven't been ready for a while. That's easy to check; we know the last time a client ran as that's stored in smart_start_tick. Wouldn't smart_stop_tick be a slightly better choice as that gives us the time the client became idle? Only promoting idle ready clients on each pass (rather than every ready client every other pass) seems far more in keeping with SmartScheduler! Please give this patch a try and see if it has the same effect. Indeed it does. Not all jitter between identical clients is eliminated, but I have not had the same issues whereby a set of clients would entirely stop updating. Running 16 copies of the fish-demo for 60 seconds, unpatched: 6136 +- 5586 frames (incl. ~50% stalled clients) this patch: 5915 +- 264 frames (no stalled clients) From a96c954443ab7cb907abda12c540d8b60e78e803 Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Wed, 22 Jan 2014 11:01:59 -0800 Subject: [PATCH] dix: Praise clients which haven't run for a while, rather than idle clients A client which is ready, but hasn't run for a while, should receive the same benefit as one which has simply been idle for a while. Use the smart_start_tick to see how long it has been since a client has run instead of smart_check_tick, which got reset each time a client was ready, even if it didn't get to run. Signed-off-by: Keith Packard kei...@keithp.com Tested-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: Fix Client starvation with SmartScheduler priorities
On Thu, Jan 23, 2014 at 08:56:37AM -0800, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: Wouldn't smart_stop_tick be a slightly better choice as that gives us the time the client became idle? Yeah, that makes more semantic sense. Of course, in reality because those two values are within one 'tick' of each other, it shouldn't have a great effect. Signed-off-by: Keith Packard kei...@keithp.com Tested-by: Chris Wilson ch...@chris-wilson.co.uk Do you want to send in a patch using smart_stop_tick? Or shall I update the patch I already have? I tested both. The difference, as could be expected, was in the noise. Either patch fixes the problem I encountered. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.907
Snapshot 2.99.907 (2013-12-30) == The highlight here is that things seem to be quietening down on the bug reporting front. All is not quiet as you will see below, and maybe it is just the holiday season that is approaching*, but there has been a remarkable falloff in bug reports. Lets hope this trend holds and we can make a stable release shortly! * This was intended to be sent a couple of weeks ago and the holiday season has been very quiet Oh, and acceleration support for Intel's next generation of integrated processor graphics has landed, codenamed Broadwell. * Fix potential X server infinite recursion (crash) from a gen2 bug fix Regression in 2.99.906 https://bugs.freedesktop.org/show_bug.cgi?id=71605 * Workaround a missing pipeline flush within Ivybridge, that would leave black rectangles randomly over the output https://bugs.freedesktop.org/show_bug.cgi?id=68410 * Fix tiled fills. gen2-3 and gen4+ had two different bugs that both broke rendering with small 8x8 patterns in some circumstances https://bugs.freedesktop.org/show_bug.cgi?id=71260 * Fix reads from a cropped video image using a packed pixel format. * Another clear the clear hint after DRI2 SwapBuffers, like the bug fixed in 2.99.903. Failure to clear the hint would cause read backs of the frontbuffer (Xvnc) to be blank. https://bugs.freedesktop.org/show_bug.cgi?id=72194 * Disable VSync on Baytrail https://bugs.freedesktop.org/show_bug.cgi?id=69869 * Handle partial uploads with TearFree correctly https://bugs.freedesktop.org/show_bug.cgi?id=72343 https://bugs.freedesktop.org/show_bug.cgi?id=72430 * Avoid recusing through DRI event handlers whilst processing TearFree, leading to a double free (and memory corruption) https://bugs.freedesktop.org/show_bug.cgi?id=72690 * Hide the gen4 render corruption by crippling the GPU https://bugs.freedesktop.org/show_bug.cgi?id=55500 Complete list of changes since 2.99.906 --- Chris Wilson (86): sna: Eliminate a compiler warning for a shadowed variable sna: Eliminate a compiler warning for a shadowed variable tests: Add render-composite-solid-mask sna/gen6+: Improve debug PREFER_RENDER to cover all decision points sna/gen6+: Only substitute SRC for CLEAR if using the correct source tests: Exercise render copies under a mask sna: Add the missing braces around the conditional block sna: Include valgrind leakchecks for --enable-debug=memory sna/damage: Guard against integer overflow before malloc sna/damage: Tidy up a tail return tests: Avoid dependence on undefined C sna: Process Damage relative to dst-pDrawable not its pixmap-drawable sna: Tell valgrind about the returned mode list sna/gen7: Rework random GPU flushing test: Fix compilation of render-trapezoid-image sna/gen4+: Clear redirect bo before falling back to BLT paths sna: Correct check for overwriting last BLT fill sna: Free composite boxes in the unlikely all-invalid path sna: Fix use before assignment intel-virtual-output: Fix trivial and unlikely fd leak from bumblebee failure intel-virtual-output: Check for failure to create a clone sna/gen7: Try to reduce flushes between primitive continuations sna: Set supported rotations on virtual outputs sna: Fix typo in sna_blt_fill_begin() sna: XY_SETUP_* expects the dst tiling to be set on gen4+ sna: Tidy up fallback from render composite to blt composite uxa,sna: Prevent bo exchange when pinned for non-DRI2 clients Revert intel-virtual-output: Only track the most recent visibility status of the cursor Correct type of uevent_handler sna/trapezoids: trapezoids_bounds() reports not-empty, so use it sna: Keep @NOWARNFLAGS@ last sna: Log mode switches on virtual outputs intel-virtual-output: Tweak DBG messages for copying rotation sna: Include reflections when logging mode changes intel-virtual-output: Include transforms when computing required fb size sna: Correct plurization of axis for modesetting log message intel-virtual-output: Correct clip region of rotated outputs in source framebuffer intel-virtual-output: Clone remote EDID for virtual outputs sna: Update connector-type-to-string mapping intel-virtual-output: Workaround mutter always using the same timestamp intel-virtual-output: Trim remote framebuffer to fit sna: Add a few more refcnt asserts sna: Wrap image upload with sigtrap sna: Tidy a split conditional in an picture upload sna: Prefer using userptr for PutImage into large GPU bo sna: Wrap glyph composition with sigtrap handling sna: Harden GetImage for use with very large buffers sna: Tidy up an assertion on an uninitialised variable sna: Fallback from partial
Re: HDMI 4k - Use the TMDS maximum frequency to check mode dot clock (v3)
On Mon, Dec 16, 2013 at 03:17:44PM +, Damien Lespiau wrote: This is the 3rd instance of the series to enable 4k displays. For the series, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/4] xf86-video-intel DRI3 and Present patch series
On Wed, Nov 20, 2013 at 12:53:33PM -0800, Keith Packard wrote: Here's a series of patches which provide DRI3 and Present support in the Intel 2D driver. The first two patches pave the way by synthesizing 64-bit vblank counters and extending the DRM event handling to allow for both DRI2 and DRI3 events. Then there's a patch to add DRI2 and miSyncShm support followed by a patch to add Present support. [PATCH 1/4] Support 64-bit MSC values. Handle kernel vageries about Some spurious assignments that appear to intentially drop the error code could be clarified, and intel_crtc_msc_to_sequence() is always called with a derived current_msc already to hand. The latter present path obfuscates its derived current_msc. [PATCH 2/4] Restructure DRM event handling. This won't compile against older Xorg due to xorg_list in the common code. [PATCH 3/4] Add DRI3 and miSyncShm support O_CLOEXEC needs protecting, also would appear to be candidate for a render-node. The imported and exported DRI3 pixmaps need to be pinned to prevent the driver using BO exchanges on that pixmap. DRI3 doesn't respect the xorg.conf Option for disabling. A fence is only tied to a screen and no XID or Client in particular? So it is a global operation akin to intel_flush_callback() which would be called before the Sync reply was sent. [PATCH 4/4] Add Present extension support Yikes. The patch is itself fairly innoculous, but only because the Present extension in the server appears to be repeating the worst of DRI2, including its original bugs. The fallback/non-fullscreen case is not synchronised to screen refresh (if the Client so desired), and should be passed through to the driver. The whole driver interface seems to be too low a level, baking in many assumptions, rather the usual approach of providing a set of mi routines that the driver can plug into or not as the case may be. That the WindowPixmap no longer points to the actual bo leads to a few problems, such as the CRTC misconfiguration and GetImage being broken after a PresentFlip. After a vblank_event, Present must check that the flip is still valid before execution. In the backend it is not clear whether the RRCrtc should be the primary CRTC or the only CRTC to flip. Damage is processed after the fallback but not the Flip path, the lack of Damage notification would upset Prime amongst others. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-intel 2.99.906
Snapshot 2.99.906 (2013-11-13) == Several stability fixes required after the recent tweaking of the core mechanics to handle the updated TearFree and attempting to make static analyzers happy. * Fix damage handling when rendering to a partially damaged GPU surface. Regression in 2.99.905 https://bugs.freedesktop.org/show_bug.cgi?id=70527 * Use asprintf() instead of sprintf() Regression in 2.99.905 https://bugs.freedesktop.org/show_bug.cgi?id=70835 * Improve accounting for fence overallocation on older gen2/3, and improve the tiling mechanism to fit into the same aperture constraints https://bugs.freedesktop.org/show_bug.cgi?id=70924 * Add an extra GPU flush on Sandybridge to fix some rare font corruption * Rasterise lines through all clip boxes https://bugs.freedesktop.org/show_bug.cgi?id=70802 * Fix regression from stricter handling of failures to move a GC to the GPU Regression in 2.99.905 https://bugs.freedesktop.org/show_bug.cgi?id=71415 * Fix various fail along the memcpy_xor paths, including inadequate error handling and integer overflow https://bugs.freedesktop.org/show_bug.cgi?id=70527 * Fix outside-of-target stipple uploads https://bugs.launchpad.net/bugs/1247785 * Fix clip detection for long glyphs Incomplete bug fix (causing a regression) in 2.99.905 https://bugs.freedesktop.org/show_bug.cgi?id=70527 * Fix VSync for the render engine (Xv) on Haswell https://bugs.freedesktop.org/show_bug.cgi?id=70527 Complete list of changes since 2.99.905 --- Chris Wilson (113): sna: Reset bo after allocation failure during wait-for-shadow man: Describe the TearFree option Revert sna: Remove the move-to-gpu shortcircuiting for partial GPU, no CPU damage sna: Remove the move-to-gpu shortcircuiting for partial GPU, no CPU damage sna: Fix canonical mode name to correctly use asprintf sna: Do not apply drawable offsets to DamageRegionAppend man: State the negative aspects of TearFree man: Mention the new default accel sna/io: Wrap the XOR upload paths with SIGBUS handling sna/io: Propagate failure to XOR uploads sna: Add a line of DBG for when we discard uploads into CPU bo sna: Fix overallocation of fences for BLT commands (gen2/3) sna: Remove stale mappings when replacing GPU bo sna: Don't assert indirect GPU state sna: Trim usuable fenced aperture by unfenced usage sna: Handle transient TearFree flip failures sna: Fallthrough to opportunistic flushing after aperture checks sna: Use page-count for mappable aperture size sna: Leave extra room in the mappable aperture for fence alignment sna: Defer opportunistic flush if all bo are current on the GPU sna: Account for extra guard pages around snooped BO in aperture checks sna: And be pessimistic when checking aperture limits sna: Tidy RegionNil checks sna: Quieten a couple of valgrind warnings about unknown ioctls sna: Try harder to complete writes sna: Don't attempt to move the GC back to the GPU before it is moved away sna: asserts bitmap uploads are correct sna: Check for retired upload buffers after checking for an idle ring sna: Perform an explicit retire for old active upload buffers sna: Always run the retire_buffers during ring_idle sna: Handle deferred retiring of active-buffers sna: Remove an overzealous assert sna: Fix assertion checks for fake flushing requests sna/gen7: Refactor BYT vsync using IVB routines sna: Wrap access of upload buffers with sigtrap sna: Check for wedged after submitting sna: Queue retirement when placing a BO on the deferred flushing list sna: Detect and handle mi recursion sna: Assert that the batch is in the correct mode prior to inserting BLT commands Revert sna: Detect and handle mi recursion sna: Allow limited recursion within sigtrapped routines sna: Tweak deletion of used buffers sna/gen6: Tweak flush around CC state changes sna/gen7: Flush render cache when changing CC state sna: Scale uses of aperture_mappable by PAGE_SIZE sna/gen7: Undo overzealous flushing sna: Process all clip boxes when rastering segments sna: Guard the replace-with-xor fallback path sna: Fallback when wedged and trying to use the BLT copy routines Prepare for changes in the BLT unit on future generations sna: Tweak estimate of maximum usable aperture for strict fencing sna: Add some more asserts around inactive VMA lists sna: Jump to the right escape target when bypassing a self-copy sna: Eliminate the redundancy between is_mappable/can_map sna: Discard bo-exec when unwinding a glyph no-op sna: Wrap staging buffer access with sigtrap handler sna: Use fast-path target placement if we
Re: [ANNOUNCE] xf86-video-intel 2.99.905
On Mon, Nov 04, 2013 at 09:19:51AM +, Chris Clayton wrote: Hi Chris. On 10/31/13 16:09, Chris Clayton wrote: On 10/31/13 13:58, Chris Wilson wrote: On Thu, Oct 31, 2013 at 08:29:02AM +, Chris Clayton wrote: Hi again. On 10/30/13 17:12, Chris Clayton wrote: Hi Chris, I've been trying out this driver and have been getting some text rendering problems on my KDE-3.5.10 desktop. I've also grabbed the tar ball of the latest git version of the driver (ed282456240cc0a7ae9a235ea8aea14a8b8a54ef) and get the same problem. I do not see the problem with 2.99.904. The problem is that if I open a new konqueror window, place the mouse cursor in it and then scroll the window contents with the mouse wheel, I get text in the window decorations at the bottom of the window. I've attached a snapshot of an affected konqueror window (hope it gets through your and X.org's mail filters). Sometimes the text also spills out on to the desktop itself and remains there until that part of the screen is refreshed for some reason - e.g. drag a window onto and then off the area. I have a snapshot of that too and can send it if it would help, although I guess that's unlikely. Another data point. Over the weekend I was compiling an update to ImageMagick. In fact I was compiling it on my desktop and my laptop at the same time, with the konsole window from the desktop opened on the laptop (via DISPLAY=laptop:0). The attached screenshot shows that the leakage I described in my original email can happen horizontally as well as vertically. Would it be useful if I opened a bugzilla report for this problem? Check against https://bugs.freedesktop.org/show_bug.cgi?id=71191 as Clemens has just opened that with very similar symptoms. In general I do find bugzilla easier to review (simply because all the log files and other information is all in the same) and since all the other bugs are there, that is where most of my attention is spent. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [ANNOUNCE] xf86-video-intel 2.99.905
Hi again. On 10/30/13 17:12, Chris Clayton wrote: Hi Chris, I've been trying out this driver and have been getting some text rendering problems on my KDE-3.5.10 desktop. I've also grabbed the tar ball of the latest git version of the driver (ed282456240cc0a7ae9a235ea8aea14a8b8a54ef) and get the same problem. I do not see the problem with 2.99.904. The problem is that if I open a new konqueror window, place the mouse cursor in it and then scroll the window contents with the mouse wheel, I get text in the window decorations at the bottom of the window. I've attached a snapshot of an affected konqueror window (hope it gets through your and X.org's mail filters). Sometimes the text also spills out on to the desktop itself and remains there until that part of the screen is refreshed for some reason - e.g. drag a window onto and then off the area. I have a snapshot of that too and can send it if it would help, although I guess that's unlikely. Do you have any immediate ides which change might be the culprit and I could try reverting? If not, I can clone the git tree and do a bisect. I've done a bisect and I ended up with: ec0866e86d365ae3fd9790b1b263d49fc4981220 is the first bad commit commit ec0866e86d365ae3fd9790b1b263d49fc4981220 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Oct 16 22:39:54 2013 +0100 sna/glyphs: Fix computation of extents for long strings And make sure we consider such overflowing strings for correct clipping against Windows. To offset the cost of doing a full extents check (~10% on aa10text), we introduce an approximate extents query (~1% on aa10text). The disparity should be rare, and should be an overestimate to force redundant clipping. Reported-by: Clemens Eisserer linuxhi...@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70541 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk :04 04 9f18aa33be6c0af2cd6e527943efa8dfe401c7cb 65a7be4deacaacc9c6f90a911317f40b37299bf4 M src Unfortunately, the commit doesn't revert cleanly and looks a bit too complex for me to start hacking out. However, I have confirmed that a driver built from a tarball up to and including the preceding does not have the problem, whereas one built from the tarball that includes up to and including this commit does. Let me know if I can test a patch, but please cc me as I'm not subscribed to the list. Chris Thanks Chris Clayton ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [ANNOUNCE] xf86-video-intel 2.99.905
On 10/31/13 13:58, Chris Wilson wrote: On Thu, Oct 31, 2013 at 08:29:02AM +, Chris Clayton wrote: Hi again. On 10/30/13 17:12, Chris Clayton wrote: Hi Chris, I've been trying out this driver and have been getting some text rendering problems on my KDE-3.5.10 desktop. I've also grabbed the tar ball of the latest git version of the driver (ed282456240cc0a7ae9a235ea8aea14a8b8a54ef) and get the same problem. I do not see the problem with 2.99.904. The problem is that if I open a new konqueror window, place the mouse cursor in it and then scroll the window contents with the mouse wheel, I get text in the window decorations at the bottom of the window. I've attached a snapshot of an affected konqueror window (hope it gets through your and X.org's mail filters). Sometimes the text also spills out on to the desktop itself and remains there until that part of the screen is refreshed for some reason - e.g. drag a window onto and then off the area. I have a snapshot of that too and can send it if it would help, although I guess that's unlikely. Do you have any immediate ides which change might be the culprit and I could try reverting? If not, I can clone the git tree and do a bisect. I've done a bisect and I ended up with: ec0866e86d365ae3fd9790b1b263d49fc4981220 is the first bad commit commit ec0866e86d365ae3fd9790b1b263d49fc4981220 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Oct 16 22:39:54 2013 +0100 sna/glyphs: Fix computation of extents for long strings And make sure we consider such overflowing strings for correct clipping against Windows. To offset the cost of doing a full extents check (~10% on aa10text), we introduce an approximate extents query (~1% on aa10text). The disparity should be rare, and should be an overestimate to force redundant clipping. Reported-by: Clemens Eisserer linuxhi...@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70541 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk :04 04 9f18aa33be6c0af2cd6e527943efa8dfe401c7cb 65a7be4deacaacc9c6f90a911317f40b37299bf4 M src Unfortunately, the commit doesn't revert cleanly and looks a bit too complex for me to start hacking out. However, I have confirmed that a driver built from a tarball up to and including the preceding does not have the problem, whereas one built from the tarball that includes up to and including this commit does. That's odd as that regression was fixed shortly after commit f81a7f7192a821654bc72a6b34625a6367cb8479 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Oct 18 09:19:14 2013 +0100 sna/glyphs: Remove glyph_approx_extents It didn't consider the height of the glyph above the baseline, i.e. it was fundamentally flawed. The only thing to do is to make sure that glyph_extents() is sufficiently fast never to show up in profiles. (Until then QA should spot the ~10% regression.) An alternative would be to feed the drawable clip extents to the render engine and avoid manual clipping if the clip region covers the whole drawable. Reported-by: Clemens Eisserer linuxhi...@gmail.com Reported-by: Jiri Slaby jirisl...@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70552 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk But the description of your symptoms does match up with https://bugs.freedesktop.org/attachment.cgi?id=87766 Can you please verify that you have tested with the latest? An Xorg.0.log would be the best proof. Attached are two Xorg.0.log files. As the names indicate, one is for the released 2.99.905 driver and the other is for a driver up to and including 82e6d41c2f4f343bd1854d3d8ee4b624b5d68971, which, 30 minutes or so ago, was the latest commit. Both drivers exhibit the problem I described yesterday. Chris -Chris [ 4094.326] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [ 4094.327] _XSERVTransOpen: transport open failed for inet6/laptop:0 [ 4094.327] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 4094.341] This is a pre-release version of the X server from Chris Clayton. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the xorg product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. [ 4094.341] X.Org X Server 1.14.3.901 (1.14.4 RC 1) Release Date: 2013-10-26 [ 4094.341] X Protocol Version 11, Revision 0 [ 4094.341] Build Operating System: laptop 3.12.0-rc6+ [ 4094.341] Current Operating System: Linux laptop 3.12.0-rc7+ #195 SMP PREEMPT Tue Oct 29 08:04:20 GMT 2013 x86_64 [ 4094.341] Kernel command line: root=/dev/sda3 ro resume=/dev/sda6 [ 4094.341
Re: [ANNOUNCE] xf86-video-intel 2.99.905
On Thu, Oct 31, 2013 at 08:29:02AM +, Chris Clayton wrote: Hi again. On 10/30/13 17:12, Chris Clayton wrote: Hi Chris, I've been trying out this driver and have been getting some text rendering problems on my KDE-3.5.10 desktop. I've also grabbed the tar ball of the latest git version of the driver (ed282456240cc0a7ae9a235ea8aea14a8b8a54ef) and get the same problem. I do not see the problem with 2.99.904. The problem is that if I open a new konqueror window, place the mouse cursor in it and then scroll the window contents with the mouse wheel, I get text in the window decorations at the bottom of the window. I've attached a snapshot of an affected konqueror window (hope it gets through your and X.org's mail filters). Sometimes the text also spills out on to the desktop itself and remains there until that part of the screen is refreshed for some reason - e.g. drag a window onto and then off the area. I have a snapshot of that too and can send it if it would help, although I guess that's unlikely. Do you have any immediate ides which change might be the culprit and I could try reverting? If not, I can clone the git tree and do a bisect. I've done a bisect and I ended up with: ec0866e86d365ae3fd9790b1b263d49fc4981220 is the first bad commit commit ec0866e86d365ae3fd9790b1b263d49fc4981220 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Oct 16 22:39:54 2013 +0100 sna/glyphs: Fix computation of extents for long strings And make sure we consider such overflowing strings for correct clipping against Windows. To offset the cost of doing a full extents check (~10% on aa10text), we introduce an approximate extents query (~1% on aa10text). The disparity should be rare, and should be an overestimate to force redundant clipping. Reported-by: Clemens Eisserer linuxhi...@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70541 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk :04 04 9f18aa33be6c0af2cd6e527943efa8dfe401c7cb 65a7be4deacaacc9c6f90a911317f40b37299bf4 M src Unfortunately, the commit doesn't revert cleanly and looks a bit too complex for me to start hacking out. However, I have confirmed that a driver built from a tarball up to and including the preceding does not have the problem, whereas one built from the tarball that includes up to and including this commit does. That's odd as that regression was fixed shortly after commit f81a7f7192a821654bc72a6b34625a6367cb8479 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Oct 18 09:19:14 2013 +0100 sna/glyphs: Remove glyph_approx_extents It didn't consider the height of the glyph above the baseline, i.e. it was fundamentally flawed. The only thing to do is to make sure that glyph_extents() is sufficiently fast never to show up in profiles. (Until then QA should spot the ~10% regression.) An alternative would be to feed the drawable clip extents to the render engine and avoid manual clipping if the clip region covers the whole drawable. Reported-by: Clemens Eisserer linuxhi...@gmail.com Reported-by: Jiri Slaby jirisl...@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70552 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk But the description of your symptoms does match up with https://bugs.freedesktop.org/attachment.cgi?id=87766 Can you please verify that you have tested with the latest? An Xorg.0.log would be the best proof. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] xf86-video-intel 2.99.905
Snapshot 2.99.905 (2013-10-23) == The highlight for this snapshot is the extension of TearFree to support transformed outputs, along with some polishing to eliminate its impact upon input and output latency. As always, thanks to everyone who have been testing, reporting bugs and helping to improve the stability before release. * Prevent a crash when starting with a user specified mode or position * Prevent some crashes in UXA after allocation failure * Stop marking the user's preferred backlight value as 0 if the backlight property is queried whilst the connector is disabled https://bugs.freedesktop.org/show_bug.cgi?id=70406 * Pad GETCONNECTOR ioctl for compatability between 32/64-bit userspace and kernel * Handle long glyph runs correctly https://bugs.freedesktop.org/show_bug.cgi?id=70541 * Fix clipping of stippled rectangles against clip regions https://bugs.freedesktop.org/show_bug.cgi?id=67865 * Support TearFree rendering of rotated outputs https://bugs.freedesktop.org/show_bug.cgi?id=22969 Complete list of changes since 2.99.904 --- Chris Wilson (66): sna: Upon unwinding operations, also check for exec objects to clear sna: Pass usage hint down to render fill routines sna: Prevent changes in tiling/pitch of existing framebuffers sna/gen6+: Only allow switching to BLT for fills if we have semaphores sna/gen6+: Share the common routines for ring preferrence sna/gen4+: Share a few common routines sna: Sanitize output-crtc before falling back oto xf86InitialConfiguration sna: Populate bo-size from dma-buf configure: Allow manual specification of intel-gen4asm path uxa: Abort CreateScreenResources after allocation failure uxa: Check for allocation failure in i915 video sna: Cleanup allocation of sna_output after late syscall fail sna: Update DPMS on attached outputs before disabling the CRTC sna: Cleanup up unused variables sna/trapezoids: Use the aligned fast path for fallbacks sna: Fix typo in DBG sna: Tighten has_coherent_ptr() assertion sna/gen6+: Fix calculation of 1/z for projective textures sna/gen6: Fix the invert fix sna: Assert that the mode/ring are set when marking active bo sna/trapezoids: Initialise force_fallback sna: Preserve the user backlight value for get_property calls sna: Disable updating properties upon reading their values Revert sna: Preserve the user backlight value for get_property calls sna: Speed up inplace copies from SHM pixmaps to GPU bo sna: Allow read-mappings for has_coherent_ptr() assert sna: Add DBG along all output init failure paths sna: Expand packed KMS structs for 64-bit alignment sna: Only carry 32/64-bit compat wrapper for drm_mode_get_connector sna: Fix inverted tiled CPU map check in has_coherent_ptr() sna/glyphs: Fix computation of extents for long strings sna/dri: Refactor to use the common GPU damage routine sna: Assert mapped state sna: Fix computation of clip boxes for stipple uploads sna: Check return of source_bo for a potential failure Remove defunct file 'brw_eu_util.c' from git sna/glyphs: Remove glyph_approx_extents sna: Tighten pixmap map assertions sna: Drop now obsolete assertion sna: Do a quick pass on dirty damage before reduction sna: Unmap pixmap prior to release GPU bo sna: Fix the addition of the current output Mode to the probed lists sna: Suppress log messages for unchanging EDID sna: Fix typo inside an assertion sna: Copy the EDID mode name for the current CRTC mode sna: Set the canonical name for the current mode if none match sna: Tweak opportunistic flushing to reduce power consumption sna: Improve handling of blit fallbacks for untransfomed large scanouts sna: Eliminate the synchronous wait from inside TearFree sna: Enable TearFree rendering for transformed scanouts sna: Free bo along unlikely one-off error path sna: Discard GPU bo when failing to setup the shared pixmap sna: Move gc back to GPU after failure to move it to CPU sna: Ignore overflow in CPU count rather than abort sna/trapezoids: Fix inversion of initialisation test for triangles sna: Free our CRTC private after failing to create the xf86Crtc xvmc: Handle errors along allocation path sna: Only force the TearFree exchange before a write sna: Make sure CPU damage is flushed to the TearFree shadow sna: Remove the move-to-gpu shortcircuiting for partial GPU, no CPU damage sna: Fix inconsistency in has_coherent_ptr assertion sna: Pass the async hint when pushing GPU damage for redisplay sna: Handle pending move-to-gpu for userptr uploads sna: Flush the pending move-to-gpu upon Pixmap free sna
Re: [ANNOUNCE] xf86-video-intel 2.99.904
On Tue, Oct 15, 2013 at 11:24:46PM +0200, Łukasz Maśko wrote: Dnia czwartek, 10 października 2013 16:28:28 Chris Wilson pisze: On Thu, Oct 10, 2013 at 04:27:20PM +0200, Łukasz Maśko wrote: Dnia środa, 9 października 2013 17:24:19 Chris Wilson pisze: Snapshot 2.99.904 (2013-10-09) == There is one more feature planned to be completed for 3.0, so time for a snapshot beforehand to push out the bug fixes from the last week. I don't know, if it is important, but I'm getting a segfault when I'm trying to run 2.99.904, while 2.99.903 runs without a problem. Xorg.log is attached. Users! Preferred-mode strikes again, sorry about that. commit f0bd716425d1514b62565f9a65397cd1cb2ffb3a Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Oct 10 16:22:45 2013 +0100 sna: Sanitize output-crtc before falling back oto xf86InitialConfiguration How should I understand that? Should I simply add Option AccelMethod SNA to my xorg.conf to make it work? That is a reference to a patch that fixes the calamity resulting from breaking out of the initial KMS probe early. The reason for the early exit is due to a user override in position or mode in xorg.conf. The choice you have is (a) not to use that xorg.conf, (b) use Option AccelMethod uxa or (c) apply the patch (or update if you are using a distribution that already ships that patch). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-video-intel 2.99.904
On Thu, Oct 10, 2013 at 04:27:20PM +0200, Łukasz Maśko wrote: Dnia środa, 9 października 2013 17:24:19 Chris Wilson pisze: Snapshot 2.99.904 (2013-10-09) == There is one more feature planned to be completed for 3.0, so time for a snapshot beforehand to push out the bug fixes from the last week. I don't know, if it is important, but I'm getting a segfault when I'm trying to run 2.99.904, while 2.99.903 runs without a problem. Xorg.log is attached. Users! Preferred-mode strikes again, sorry about that. commit f0bd716425d1514b62565f9a65397cd1cb2ffb3a Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Oct 10 16:22:45 2013 +0100 sna: Sanitize output-crtc before falling back oto xf86InitialConfiguration -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH] dix: Fix Client starvation with SmartScheduler priorities
Given the right mix of clients competing for server time, it is possible
for some of those clients to be starved. In a CPU bound system,
executing clients consume their entire ScheduleSlice and are demoted for
being busy. These clients then may block waiting for a reply from the
XServer freeing up CPU time such that the next client will complete its
task within the ScheduleSlice and not be demoted. In this manner, we
progressively starve more and more clients until we have sufficient CPU
time to execute the remaining ones, and under the right conditions we
will have a set that can remain permanently busy, and a set that are
blocked.
A simple example is to execute 16 identical copies of a rendering
benchmark and measure the standard deviation in the number of frames they
are able to complete within 60 seconds. (The benchmark uses client-side
throttling and so frees up CPU timeslices whilst waiting for a GetImage
reply after each frame. The benchmark doesn't listen to input events and
so does not receive the priority boost used to reduce input latency.)
Using dumbSched: 57.0 +- 0.4 fps
Using smartSched: 66.4 +- 9.8 fps
After patching: 65.2 +- 1.2 fps
More importantly, given the right conditions it is very easy to starve
clients completely. That starvation is prevented by this patch.
The solution employed here is to undo the busy demotion after a period
of idleness. Currently the idle boost is applied only once for a fresh
client when it becomes selectable. The change is to apply that boost for
all clients that remain ready for the entire duration of idle timeslice -
eventually these old busy clients will be promoted sufficiently to
be granted a ScheduleSlice.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
dix/dispatch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dix/dispatch.c b/dix/dispatch.c
index 4fecfea..0da37ae 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -259,12 +259,12 @@ SmartScheduleClient(int *clientReady, int nready)
for (i = 0; i nready; i++) {
client = clientReady[i];
pClient = clients[client];
-/* Praise clients which are idle */
+/* Praise clients which have been idle */
if ((now - pClient-smart_check_tick) = idle) {
if (pClient-smart_priority 0)
pClient-smart_priority++;
+ pClient-smart_check_tick = now;
}
-pClient-smart_check_tick = now;
/* check priority to select best client */
robin =
--
1.8.4.rc3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glx/glxdri2: Unwrap EnterVT/LeaveVT upon CloseScreen
In a similar spirit to
commit d75e8146c414bfd512ba5dbd4a83acb334bbe19b
Author: Keith Packard kei...@keithp.com
Date: Mon Jul 12 16:01:34 2010 -0700
Unwrap/rewrap EnterVT/LeaveVT completely, Fixes 28998
we need to unwrap our pScrn-EnterVT/LeaveVT hooks around server
regeneration or else we cause an infinite recursion on the next VT
switch afterwards.
Bugzilla:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1235516
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
glx/glxdri2.c | 4
1 file changed, 4 insertions(+)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 8a1fa41..57c4735 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -375,6 +375,7 @@ __glXDRIscreenDestroy(__GLXscreen * baseScreen)
{
int i;
+ScrnInfoPtr pScrn = xf86ScreenToScrn(baseScreen-pScreen);
__GLXDRIscreen *screen = (__GLXDRIscreen *) baseScreen;
(*screen-core-destroyScreen) (screen-driScreen);
@@ -389,6 +390,9 @@ __glXDRIscreenDestroy(__GLXscreen * baseScreen)
free(screen-driConfigs);
}
+pScrn-EnterVT = screen-enterVT;
+pScrn-LeaveVT = screen-leaveVT;
+
free(screen);
}
--
1.8.4.rc3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glx/glxdri2: Unwrap EnterVT/LeaveVT upon CloseScreen
In a similar spirit to
commit d75e8146c414bfd512ba5dbd4a83acb334bbe19b
Author: Keith Packard kei...@keithp.com
Date: Mon Jul 12 16:01:34 2010 -0700
Unwrap/rewrap EnterVT/LeaveVT completely, Fixes 28998
we need to unwrap our pScrn-EnterVT/LeaveVT hooks around server
regeneration or else we cause an infinite recursion on the next VT
switch afterwards.
Bugzilla:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1235516
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
glx/glxdri2.c | 4
1 file changed, 4 insertions(+)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 8a1fa41..57c4735 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -375,6 +375,7 @@ __glXDRIscreenDestroy(__GLXscreen * baseScreen)
{
int i;
+ScrnInfoPtr pScrn = xf86ScreenToScrn(baseScreen-pScreen);
__GLXDRIscreen *screen = (__GLXDRIscreen *) baseScreen;
(*screen-core-destroyScreen) (screen-driScreen);
@@ -389,6 +390,9 @@ __glXDRIscreenDestroy(__GLXscreen * baseScreen)
free(screen-driConfigs);
}
+pScrn-EnterVT = screen-enterVT;
+pScrn-LeaveVT = screen-leaveVT;
+
free(screen);
}
--
1.8.4.rc3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] sna: avoid negative timeouts
On Thu, Oct 03, 2013 at 01:29:29AM -0500, Felipe Contreras wrote: It's nice to avoid X server crashes (by not passing negative values to select(3)). For more information: http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/37388 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com Thanks for the patch, I pushed a slightly different version to consume the expired flush timeout immediately. However, in order for this to happen something within the BlockHandler must have run for at least 4ms. Which is itself very worrying - the two candidates are the throttle or lock contention. (The throttle is also prone to being influenced by a third party.) Such stalls are likely to be noticeable as jitter or judder, so if you can spot their source hopefully we can tackle the root cause. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] sna: avoid negative timeouts
On Thu, Oct 03, 2013 at 03:06:03AM -0500, Felipe Contreras wrote:
On Thu, Oct 3, 2013 at 2:36 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Oct 03, 2013 at 01:29:29AM -0500, Felipe Contreras wrote:
It's nice to avoid X server crashes (by not passing negative values to
select(3)).
For more information:
http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/37388
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Thanks for the patch, I pushed a slightly different version to consume
the expired flush timeout immediately.
However, in order for this to happen something within the BlockHandler
must have run for at least 4ms. Which is itself very worrying - the two
candidates are the throttle or lock contention. (The throttle is also
prone to being influenced by a third party.) Such stalls are likely to
be noticeable as jitter or judder, so if you can spot their source
hopefully we can tackle the root cause.
What exactly do you mean by third party? I wouldn't notice if there
was jitter because it's a loading screen, and there's absolutely no
updates on the screen; it's static.
Other users of /dev/dri/card0. The most likely cause for the delay here
is waiting for the GPU to complete an operation or for waiting for
access to the GPU.
Do you mean you would like me to add debugging in
sna_accel_block_handler() to figure exactly which block is taking too
long to complete?
Right, if you do something like:
diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 21cd342..31ea1a3 100644
@@ -15931,6 +15931,8 @@ void sna_accel_close(struct sna *sna)
void sna_accel_block_handler(struct sna *sna, struct timeval **tv)
{
+ uint32_t duration[NUM_TIMERS] = { 0 };
+
sigtrap_assert();
if (sna-kgem.need_retire)
@@ -15947,19 +15949,28 @@ void sna_accel_block_handler(struct sna *sna, struct
timeval **tv)
}
restart:
- if (sna_accel_do_flush(sna))
+ if (sna_accel_do_flush(sna)) {
+ duration[FLUSH_TIMER] = TIME;
sna_accel_flush(sna);
+ duration[FLUSH_TIMER] = TIME - duration[FLUSH_TIMER];
+ }
assert(sna_accel_scanout(sna) == NULL ||
sna_accel_scanout(sna)-gpu_bo-exec == NULL ||
sna-timer_active (1(FLUSH_TIMER)));
- if (sna_accel_do_throttle(sna))
+ if (sna_accel_do_throttle(sna)) {
+ duration[THROTTLE_TIMER] = TIME;
sna_accel_throttle(sna);
+ duration[THROTTLE_TIMER] = TIME - duration[THROTTLE_TIMER];
+ }
assert(!sna-kgem.need_retire ||
sna-timer_active (1(THROTTLE_TIMER)));
- if (sna_accel_do_expire(sna))
+ if (sna_accel_do_expire(sna)) {
+ duration[EXPIRE_TIMER] = TIME;
sna_accel_expire(sna);
+ duration[EXPIRE_TIMER] = TIME - duration[EXPIRE_TIMER];
+ }
assert(!sna-kgem.need_expire ||
sna-timer_active (1(EXPIRE_TIMER)));
@@ -15981,8 +15992,14 @@ restart:
timeout = sna-timer_expire[FLUSH_TIMER] - TIME;
DBG((%s: flush timer expires in %d [%d]\n,
__FUNCTION__, timeout, sna-timer_expire[FLUSH_TIMER]));
- if (timeout 3)
+ if (timeout 3) {
+ ErrorF(restarting timeout[%d] (%d, %d, %d)\n,
+ timeout,
+ duration[FLUSH_TIMER],
+ duration[THROTTLE_TIMER],
+ duration[EXPIRE_TIMER]);
goto restart;
+ }
if (*tv == NULL) {
*tv = sna-timer_tv;
That will hopefully catch which path is consuming too much time
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] sna: avoid negative timeouts
On Thu, Oct 03, 2013 at 04:09:32AM -0500, Felipe Contreras wrote: On Thu, Oct 3, 2013 at 3:17 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: That will hopefully catch which path is consuming too much time This is what I got: restarting timeout[2] (14, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[2] (14, 0, 0) restarting timeout[1] (15, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[1] (15, 0, 0) restarting timeout[1] (15, 0, 0) restarting timeout[-1] (17, 0, 0) Suspiciously like we block for an entire vrefresh to submit one batch. Hmm, do you mind sending me your complete Xorg.0.log? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] sna: avoid negative timeouts
On Thu, Oct 03, 2013 at 10:56:43AM -0500, Felipe Contreras wrote: On Thu, Oct 3, 2013 at 4:15 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Thu, Oct 03, 2013 at 04:09:32AM -0500, Felipe Contreras wrote: On Thu, Oct 3, 2013 at 3:17 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: That will hopefully catch which path is consuming too much time This is what I got: restarting timeout[2] (14, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[2] (14, 0, 0) restarting timeout[1] (15, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[0] (16, 0, 0) restarting timeout[1] (15, 0, 0) restarting timeout[1] (15, 0, 0) restarting timeout[-1] (17, 0, 0) Suspiciously like we block for an entire vrefresh to submit one batch. Hmm, do you mind sending me your complete Xorg.0.log? Here you go. Oh, TearFree. That explains it. I plan to fix that up very soon. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] sna: avoid negative timeouts
On Thu, Oct 03, 2013 at 11:19:56AM -0500, Felipe Contreras wrote: On Thu, Oct 3, 2013 at 11:01 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Oh, TearFree. That explains it. I plan to fix that up very soon. Cool. Any idea why this happens only in this game, and only in that exact loading screen? No. Just a perfect storm I would guess. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Random ocassional graphics freeze on Intel chipset
On Wed, Oct 02, 2013 at 09:22:18AM -0500, Alex Villacís Lasso wrote: El 02/10/13 05:19, Chris Wilson escribió: On Tue, Oct 01, 2013 at 06:15:00PM -0500, Alex Villacís Lasso wrote: I have seen this graphics freeze under stock 3.10.x from the Fedora 18 x86_64 distro, and also with vanilla compiled 3.11 and 3.12-rc3. After a few hours of working, the screen stops updating. The mouse pointer moves around and changes if moved over different parts of the screen, but the display itself does not change anymore. If I check /sys/kernel/debug/dri/0/i915_error_state right then (via a remote ssh), there is no error captured. However, if I do echo 1 /sys/kernel/debug/dri/0/i915_wedged, after a few moments an error is captured, as well as messages in the kernel log, both of which are attached. If I try to restart the gnome-shell session, I get the KMS console, and then the start of the graphic login, but then the graphic login itself freezes again. Is the attached information enough to diagnose the issue? Afaict it was a userspace hang, the GPU was rightfully idle. Only on the reset did it actually die. If I do echo 1 /sys/kernel/debug/dri/0/i915_wedged when the display is not frozen, I only get the following in dmesg, and the system keeps working normally: [ 323.441616] [drm] Manually setting wedged to 1 [ 323.441622] [drm] capturing error event; look for more information in /sys/class/drm/card0/error [ 348.955655] [drm] Manually setting wedged to 0 Is it to be expected that an userspace hang will escalate into a failed reset when setting i915_wedged to 1, without anything being actually wrong at the kernel side, at least at first? Yes, your chipset is notorious for not being able to restart the rings. We've added a few attempts to workaround the issue, but I'm not surprised if it still occasionally fails. I'd suggest looking at the stacktraces of the usual suspects and see who is waiting upon whom, or if there is a more obvious lockup. Then begin the painful process of tracing the interoperation of those two processes to try and catch the breakdown. -Chris I think Xorg is one of the usual suspects. Should gnome-shell be one too? This is a Fedora 18 desktop with gnome-shell as installed from the DVD. X and gnome-shell are the two responsible for working together and presenting your desktop, so would definitely be the first to check for an error. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-intel 2.99.903
Snapshot 2.99.903 (2013-09-28) == Lots more stabilization work, not yet peaceful enough to christen 3.0. We have everything ranging from build fixes for systems like Suse Linux Enterprise Desktop that like to backport hardware enablement to ancient packages, to fixes for hardware enabling, and some more performance tuning. * Fix VSync on Haswell. https://bugs.freedesktop.org/show_bug.cgi?id=69119 * Disable Y-tiling on gen4 - it too frequently leads to instability. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/103 * Disable same EDID detection based on property id - the kernel likes to reuse ids leading to a failure to detect the right modes on a monitor change. * Avoid issuing multiple DPMS requests to the same encoder (alised to multiple connectors) to avoid upsetting Haswell and leaving the screens blank. * Honour the user preferrence for the initial mode, even if they are being silly https://bugzilla.novell.com/show_bug.cgi?id=841696 * Clear the clear hint when apply DRI updates - to prevent some screenshots from GL windows being left blank. https://bugs.freedesktop.org/show_bug.cgi?id=69730 * Prevent a NULL dereference from trying to undo an non-existent buffer https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1228677 * Handle out-of-memory conditions far more gracefully. If the system is hard against the memory wall, then the kernel will start issuing SIGBUS even for CPU mmaps. Untrapped these will cause X to die. https://bugs.freedesktop.org/show_bug.cgi?id=67889 Complete list of changes since 2.99.902 --- Chris Wilson (72): NEWS: Fix release dates, missed the transition to September sna: Split get_drawable_deltas() sna: Only update the CRTCs after a resize if master intel-virtual-output: Debug option for forcing full redraws configure: Only assert DRI2 requirements not met if the DRI2 package is missing sna/gen7: Prefer the BLT for gt1 systems sna/gen6: Prefer the RCS on large GT systems sna/gen4+: Flush batch if idle on filling vbo sna: Remember to offset the box before asserting damage sna: Call the new __offset functions in the last commit sna/gen6+: Only apply the BLT copy w/a for self-copies sna/hsw: Fix the event selection for scanline waits on pipe A sna/hsw: Scanline waits require both DERRMR and forcewake sna: Disable use of Y-tiling for gen4 sna/gen4: Always try the BLT composite routines first sna/gen4+: Rebalance creation of vbo during batch flushing sna: Fix declaration of write intent for can_map__cpu in PutImage test: Exercise flips/blit swaps on each pipe intel: Make the option to control VSync and PageFlip explict sna: Clamp the possible-crtc mask to the real CRTCs sna: Disable same-edid detection sna: Fix off-by-one in computation of valid CRTC mask intel: Compile fixes for base install of SLED11.sp3 sna: Wrap use of dixPrivateKeyRegistered for uevents sna: Pushed dixPrivateKeyRegistered wrapper into compat-api.h intel: Fix includes for intel_options sna/gen4: Remove long dead code for forced batch emission between CA passes sna: Add output names to DBG dpms changes sna: Do not change DPMS mode on unconnected outputs uxa: Do not change DPMS mode on unconnected outputs intel-virtual-output: Hide the remote cursor on initial connection sna: Prevent invalid use of set-write-domain on scanouts when debugging sna: Don't set the mapped hint for inplace tiled accesses sna: ImageGlyphs completely overwrite the destination sna: Undo region translation after failing to begin ImageGlyphs sna: Both clear PolyGlyph and ImageGlyph are no-ops intel-virtual-overlay: Grab the server around mode manipulations sna: Track CPU/GTT maps independently sna/dri: Fix SwapbufferWait sna/dri: Report saner target_msc values for vblank_mode=0 sna/dri: Sanitize the backbuffer flip cache sna: Fix cast from u64 to pointer for 32-bit hosts sna/video: Add always-on-top to the list of Xv attributes sna: Check OPTION_PREFERRED_MODE rather than M_T_USERPREF sna/dri: Clear the clear hint upon applying DRI damage sna/dri: Prevent a NULL dereference in a DBG msg sna: Separate out copy preferrence from operating in place decision sna: Add some DBG for early flushes sna: Clear CPU damage when uploading partial images inplace sna/gen6+: Fallback to BLT composite if fallback is forced sna/gen[35]: Remove dead code for choosing between BLT/render composite sna: Add a few more asserts around tracking of bo-exec vs bo-request sna: Check that the bo exists before attempting to undo it sna: Micro-optimise copies sna: Promote self
[ANNOUNCE] xf86-video-intel 2.99.903
Snapshot 2.99.903 (2013-09-28) == Lots more stabilization work, not yet peaceful enough to christen 3.0. We have everything ranging from build fixes for systems like Suse Linux Enterprise Desktop that like to backport hardware enablement to ancient packages, to fixes for hardware enabling, and some more performance tuning. * Fix VSync on Haswell. https://bugs.freedesktop.org/show_bug.cgi?id=69119 * Disable Y-tiling on gen4 - it too frequently leads to instability. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/103 * Disable same EDID detection based on property id - the kernel likes to reuse ids leading to a failure to detect the right modes on a monitor change. * Avoid issuing multiple DPMS requests to the same encoder (alised to multiple connectors) to avoid upsetting Haswell and leaving the screens blank. * Honour the user preferrence for the initial mode, even if they are being silly https://bugzilla.novell.com/show_bug.cgi?id=841696 * Clear the clear hint when apply DRI updates - to prevent some screenshots from GL windows being left blank. https://bugs.freedesktop.org/show_bug.cgi?id=69730 * Prevent a NULL dereference from trying to undo an non-existent buffer https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1228677 * Handle out-of-memory conditions far more gracefully. If the system is hard against the memory wall, then the kernel will start issuing SIGBUS even for CPU mmaps. Untrapped these will cause X to die. https://bugs.freedesktop.org/show_bug.cgi?id=67889 Complete list of changes since 2.99.902 --- Chris Wilson (72): NEWS: Fix release dates, missed the transition to September sna: Split get_drawable_deltas() sna: Only update the CRTCs after a resize if master intel-virtual-output: Debug option for forcing full redraws configure: Only assert DRI2 requirements not met if the DRI2 package is missing sna/gen7: Prefer the BLT for gt1 systems sna/gen6: Prefer the RCS on large GT systems sna/gen4+: Flush batch if idle on filling vbo sna: Remember to offset the box before asserting damage sna: Call the new __offset functions in the last commit sna/gen6+: Only apply the BLT copy w/a for self-copies sna/hsw: Fix the event selection for scanline waits on pipe A sna/hsw: Scanline waits require both DERRMR and forcewake sna: Disable use of Y-tiling for gen4 sna/gen4: Always try the BLT composite routines first sna/gen4+: Rebalance creation of vbo during batch flushing sna: Fix declaration of write intent for can_map__cpu in PutImage test: Exercise flips/blit swaps on each pipe intel: Make the option to control VSync and PageFlip explict sna: Clamp the possible-crtc mask to the real CRTCs sna: Disable same-edid detection sna: Fix off-by-one in computation of valid CRTC mask intel: Compile fixes for base install of SLED11.sp3 sna: Wrap use of dixPrivateKeyRegistered for uevents sna: Pushed dixPrivateKeyRegistered wrapper into compat-api.h intel: Fix includes for intel_options sna/gen4: Remove long dead code for forced batch emission between CA passes sna: Add output names to DBG dpms changes sna: Do not change DPMS mode on unconnected outputs uxa: Do not change DPMS mode on unconnected outputs intel-virtual-output: Hide the remote cursor on initial connection sna: Prevent invalid use of set-write-domain on scanouts when debugging sna: Don't set the mapped hint for inplace tiled accesses sna: ImageGlyphs completely overwrite the destination sna: Undo region translation after failing to begin ImageGlyphs sna: Both clear PolyGlyph and ImageGlyph are no-ops intel-virtual-overlay: Grab the server around mode manipulations sna: Track CPU/GTT maps independently sna/dri: Fix SwapbufferWait sna/dri: Report saner target_msc values for vblank_mode=0 sna/dri: Sanitize the backbuffer flip cache sna: Fix cast from u64 to pointer for 32-bit hosts sna/video: Add always-on-top to the list of Xv attributes sna: Check OPTION_PREFERRED_MODE rather than M_T_USERPREF sna/dri: Clear the clear hint upon applying DRI damage sna/dri: Prevent a NULL dereference in a DBG msg sna: Separate out copy preferrence from operating in place decision sna: Add some DBG for early flushes sna: Clear CPU damage when uploading partial images inplace sna/gen6+: Fallback to BLT composite if fallback is forced sna/gen[35]: Remove dead code for choosing between BLT/render composite sna: Add a few more asserts around tracking of bo-exec vs bo-request sna: Check that the bo exists before attempting to undo it sna: Micro-optimise copies sna: Promote self
Re: XComposite Overlay Window usage
On Tue, Sep 24, 2013 at 09:48:06PM +0200, Jochen Keil wrote: Hello Chris, On 23.09.2013 15:19, Chris Wilson wrote: On Mon, Sep 23, 2013 at 01:23:08PM +0200, Jochen Keil wrote: Hello, I'm trying to write an application with which I'd like to draw over other windows. So far my attempts have been: * Drawing to an transparent overlay window I create myself: Main problem is to keep this window always on top of of all the other windows (repeated calls to XRaiseWindow, possible flicker) + requires a compositing manager. I took this approach (using the hw overlay plane), plus a XV_ALWAYS_ON_TOP attribute. (Eliminates the raise requirement, and allows the user to write to the scanout without waking the GPU.) Using the overlay also ensures that it appears over all windows, including the compositing manager or fullscreen games (without interferring with those). thanks for your reply. I looked for documentation for XV_ALWAYS_ON_TOP, but couldn't find any. Is there documentation available somewhere? I added it to the driver since it was the only way to achieve what I wanted, as such document is pretty sparse - the only clue is in the name. However, I figured, that what I'd like my application to do resembles more a compositing manager. In particular I wanted my windows to become transparent only on overlapping parts. For example I have an focused window which is partially occluded by an unfocused window. The unfocused window would then be drawn transparently over the focused window. Thus I think it'd be more appropriate to write a plug-in for an existing compositing manager. Indeed, that can only be done in a compositing manager. If you want to learn the fundamentals, xcompmgr is a good place to start as it is the minimal compositing manager and so easiest to understand. That should allow you to prototype your ideas quickly, if you don't want to dive into mutter/compiz/kwin straight-away. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XComposite Overlay Window usage
On Mon, Sep 23, 2013 at 01:23:08PM +0200, Jochen Keil wrote: Hello, I'm trying to write an application with which I'd like to draw over other windows. So far my attempts have been: * Drawing to an transparent overlay window I create myself: Main problem is to keep this window always on top of of all the other windows (repeated calls to XRaiseWindow, possible flicker) + requires a compositing manager. I took this approach (using the hw overlay plane), plus a XV_ALWAYS_ON_TOP attribute. (Eliminates the raise requirement, and allows the user to write to the scanout without waking the GPU.) Using the overlay also ensures that it appears over all windows, including the compositing manager or fullscreen games (without interferring with those). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Where does Xorg fallback to ?
On Mon, Sep 23, 2013 at 10:45:41AM +0800, 小飞珑 wrote: Hi, I am looking into Xorg for performance optimization, and want to do some software acceleration for the Xorg fallback functions when the hardware acceleration is not available. I am now using a notebook with intel display card. In the UXA driver, I force the driver to use fallback funcs instead of the Accelerated funcs. As in uxa/uxa-accel.c - uxa_copy_area(), I made uxa_screen-force_fallback = 1, force uxa driver to call uxa_check_copy_area()-fbCopyArea(), but the fbCopyArea seemed NOT to be the fbCopyArea in Xorg fb/fbcopy.c ! For I added return NULL immediately in the beginning of fb/fbcopy.c - fbCopyArea(), but made no difference, but if I comment the fbCopyArea() in uxa/uxa-unaccel.c the display is ruined. It seemed that the above two fbCopyArea() functions are not the same. Where did the Xorg fallback to? NOT to the fb/fbcopy.c ? I am eager to know that, could some body tell ? Thanks a lot! The right answer is don't start from there. For fallbacks, UXA uses a GTT mapping so every surface is actually in WC memory - every read is treated as uncached, and fallbacks do a lot of reads. Effort spent optimising the fb layer in this case is completely wasted. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: 回复： Where does Xorg fallback to ?
On Mon, Sep 23, 2013 at 05:13:19PM +0800, 小飞珑 wrote: The right answer is don't start from there. For fallbacks, UXA uses a GTT mapping so every surface is actually in WC memory - every read is treated as uncached, and fallbacks do a lot of reads. Effort spent optimising the fb layer in this case is completely wasted. -Chris I don't quite understand that. Or you mean that fbCopyArea() is wrapped? The fb* functions are provided by the xserver. What I am trying to point out is that UXA fundamentally uses hw in such a way that prevents optimisation. Every pointer read in fb* is uncached. Optimising an already fairly well optimised implementation will at most gain less than a percent overall. Switching to a different mapping and implementating migration will gain an order of magnitude performance improvement. Implementing 2D acceleration will gain between 5x-10x over and above the optimal fb implementation. If you read the driver more carefully you will find these answers already there. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: 回复： 回复： Where does Xorg fallbackto ?
On Mon, Sep 23, 2013 at 07:57:42PM +0800, 小飞珑 wrote: You didn't help about my question, and did not answer where the fbCopyNtoN and fbCopyArea hide. I shall repeat my simple and humble question again : are the fbCopyNtoN() and fbCopyarea() in UXA implemented in Xorg fb/fbcopy? I shall repeat myself: They do not exist in UXA, they are in the Xserver. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86: Infer VirtualSize from Driver modes
The VirtualSize inferrence was originally conceived in
commit 81ef1b6d6063c20db4963abf7b7848e235aa4ebb
Author: Adam Jackson a...@benzedrine.nwnk.net
Date: Thu Sep 14 19:18:58 2006 -0400
Mark EDID modes as driver modes. Infer virtual size from driver modes.
and made sure to prefer the modes reported by the driver.
This regressed in
commit 7bb653bedceb6180a0361ead1c612839e776ce98
Author: Olivier Fourdan ofour...@redhat.com
Date: Mon Oct 18 15:59:35 2010 -0400
modes: improve aspect ratio match for classic drivers
which switched the VirtualSize inferrence to select the largest
builtin mode. This has the side-effect of causing X to reject all valid
driver modes larger than the builtins.
Reported-by: Felix Miata mrma...@earthlink.net
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Adam Jackson a...@redhat.com
Cc: Olivier Fourdan ofour...@redhat.com
---
hw/xfree86/common/xf86Mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/common/xf86Mode.c b/hw/xfree86/common/xf86Mode.c
index 706ab64..2a11590 100644
--- a/hw/xfree86/common/xf86Mode.c
+++ b/hw/xfree86/common/xf86Mode.c
@@ -1869,10 +1869,10 @@ xf86ValidateModes(ScrnInfoPtr scrp, DisplayModePtr
availModes,
}
if (vx virtX || vy virtY) {
const int types[] = {
-M_T_BUILTIN | M_T_PREFERRED,
-M_T_BUILTIN,
M_T_DRIVER | M_T_PREFERRED,
M_T_DRIVER,
+M_T_BUILTIN | M_T_PREFERRED,
+M_T_BUILTIN,
0
};
const int ntypes = sizeof(types) / sizeof(int);
--
1.8.4.rc3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCHES] fix build on GNU/Hurd with GCC 4.8
On 09/18/13 13:29, Chris Clayton wrote: Hi Matt, On 09/18/13 05:50, Matt Dew wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, I'm guessing this won't affect you but can you verify that? I don't want a nasty loop where fixing one things breaks another. From the names of the directory that contains the files affected by the inclusion of hurd.h, I can't imagine how that patch would affect a build on linux. Still, a 32-year career in IT taught me to expect the unexpected, so I cloned the 1.14 branch, applied that patch (by hand - it's been mangled by someone's mailer) and did a simple autogen.sh / configure / make. As expected, the build completed successfully. The other patch, which Pino said affected other unix systems, is not included in the mail that arrived here, so, obviously, I haven't built with that applied. Why I didn't do this simple thing yesterday, I can't explain! I got this missing patch from the xorg-devel mail archive and applied it to the 1.14 branch. A build finished finished successfully, so from here, the patches look good. Chris Cheers, Chris thanks, Matt On 09/17/2013 12:02 PM, Samuel Thibault wrote: Hello, Pino Toscano, le Wed 28 Aug 2013 17:36:26 +0200, a écrit : with GCC 4.8, few implicit declaration of function warnings become errors, breaking the build of xserver on the Hurd. Attached there are two patches, which apply fine in both master and server-1.14-branch branches, which fix the errors providing the right includes: * the inclusion of hurd.h in Hurd parts should be straightforward * the move of the arpa/inet.h (which is POSIX) to a move general location affects any other Unix system with IPv6 support, I hope it is not a problem for all the supported platforms Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org Could somebody push that to the server? We really need it. Thanks, Samuel From ef6a236cf9b795017c9c8c4447a6735fa04bb061 Mon Sep 17 00:00:00 2001 From: Pino Toscano toscano.p...@tiscali.it Date: Wed, 28 Aug 2013 17:04:48 +0200 Subject: [PATCH] xfree86/hurd: include hurd.h Needed for using get_privileged_port. Signed-off-by: Pino Toscano toscano.p...@tiscali.it --- hw/xfree86/os-support/hurd/hurd_init.c |1 + hw/xfree86/os-support/hurd/hurd_mmap.c |1 + hw/xfree86/os-support/hurd/hurd_video.c |1 + 3 files changed, 3 insertions(+) diff --git a/hw/xfree86/os-support/hurd/hurd_init.c b/hw/xfree86/os-support/hurd/hurd_init.c index 185b2b9..fe1a764 100644 --- a/hw/xfree86/os-support/hurd/hurd_init.c +++ b/hw/xfree86/os-support/hurd/hurd_init.c @@ -42,6 +42,7 @@ #include sys/file.h #include assert.h #include mach.h +#include hurd.h int xf86ProcessArgument(int argc, char **argv, int i) diff --git a/hw/xfree86/os-support/hurd/hurd_mmap.c b/hw/xfree86/os-support/hurd/hurd_mmap.c index 6ac9efd..8e089ca 100644 --- a/hw/xfree86/os-support/hurd/hurd_mmap.c +++ b/hw/xfree86/os-support/hurd/hurd_mmap.c @@ -27,6 +27,7 @@ #includemach.h #includedevice/device.h #includemach/machine/mach_i386.h +#include hurd.h #include X11/X.h diff --git a/hw/xfree86/os-support/hurd/hurd_video.c b/hw/xfree86/os-support/hurd/hurd_video.c index 72474ba..b3b94c9 100644 --- a/hw/xfree86/os-support/hurd/hurd_video.c +++ b/hw/xfree86/os-support/hurd/hurd_video.c @@ -28,6 +28,7 @@ #include mach.h #include device/device.h #include mach/machine/mach_i386.h +#include hurd.h #include X11/X.h #include input.h - -- Matt DewKey signature: 0xF7C3 BEC3 Fingerprint: FDB1 9D94 C573 DC29 BCCB 2F9F A6BF 3771 F7C3 BEC3 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSOTEiAAoJEKa/N3H3w77DR+0H/jW12BBCYgGK2Oy25zHj6wvZ y3xKi4PK+Pyb2ad1p/hTnbmD9usl/8+tSOmOZRU7i1OgjfP7vj012aCMyr2ZMmt2 +Sd0s2dpYxoobRg/m51+IFs2PiOVfCUH6NLkkrOP6xTQny57YG207fQYED3fJWwu mFHT2CcrdjEBxd5gDc+2jxtGCz9656qTGHLTN73TKdnhGvT56Z8cIwq2VnBntiuX V6SyQe6OZziIWsZ0POKyjiIeMFBjzMIn5fwufW3FzV4L48leJPOppsSx14YSxLd1 oH3n9xAlllfnC8AugtiJRzyVPvhFr8zbXe3iC3yoiBXc79x1RaGzHXiMLaa+vNU= =zA5L -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCHES] fix build on GNU/Hurd with GCC 4.8
Hi Matt, On 09/18/13 05:50, Matt Dew wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, I'm guessing this won't affect you but can you verify that? I don't want a nasty loop where fixing one things breaks another. From the names of the directory that contains the files affected by the inclusion of hurd.h, I can't imagine how that patch would affect a build on linux. Still, a 32-year career in IT taught me to expect the unexpected, so I cloned the 1.14 branch, applied that patch (by hand - it's been mangled by someone's mailer) and did a simple autogen.sh / configure / make. As expected, the build completed successfully. The other patch, which Pino said affected other unix systems, is not included in the mail that arrived here, so, obviously, I haven't built with that applied. Cheers, Chris thanks, Matt On 09/17/2013 12:02 PM, Samuel Thibault wrote: Hello, Pino Toscano, le Wed 28 Aug 2013 17:36:26 +0200, a écrit : with GCC 4.8, few implicit declaration of function warnings become errors, breaking the build of xserver on the Hurd. Attached there are two patches, which apply fine in both master and server-1.14-branch branches, which fix the errors providing the right includes: * the inclusion of hurd.h in Hurd parts should be straightforward * the move of the arpa/inet.h (which is POSIX) to a move general location affects any other Unix system with IPv6 support, I hope it is not a problem for all the supported platforms Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org Could somebody push that to the server? We really need it. Thanks, Samuel From ef6a236cf9b795017c9c8c4447a6735fa04bb061 Mon Sep 17 00:00:00 2001 From: Pino Toscano toscano.p...@tiscali.it Date: Wed, 28 Aug 2013 17:04:48 +0200 Subject: [PATCH] xfree86/hurd: include hurd.h Needed for using get_privileged_port. Signed-off-by: Pino Toscano toscano.p...@tiscali.it --- hw/xfree86/os-support/hurd/hurd_init.c |1 + hw/xfree86/os-support/hurd/hurd_mmap.c |1 + hw/xfree86/os-support/hurd/hurd_video.c |1 + 3 files changed, 3 insertions(+) diff --git a/hw/xfree86/os-support/hurd/hurd_init.c b/hw/xfree86/os-support/hurd/hurd_init.c index 185b2b9..fe1a764 100644 --- a/hw/xfree86/os-support/hurd/hurd_init.c +++ b/hw/xfree86/os-support/hurd/hurd_init.c @@ -42,6 +42,7 @@ #include sys/file.h #include assert.h #include mach.h +#include hurd.h int xf86ProcessArgument(int argc, char **argv, int i) diff --git a/hw/xfree86/os-support/hurd/hurd_mmap.c b/hw/xfree86/os-support/hurd/hurd_mmap.c index 6ac9efd..8e089ca 100644 --- a/hw/xfree86/os-support/hurd/hurd_mmap.c +++ b/hw/xfree86/os-support/hurd/hurd_mmap.c @@ -27,6 +27,7 @@ #includemach.h #includedevice/device.h #includemach/machine/mach_i386.h +#include hurd.h #include X11/X.h diff --git a/hw/xfree86/os-support/hurd/hurd_video.c b/hw/xfree86/os-support/hurd/hurd_video.c index 72474ba..b3b94c9 100644 --- a/hw/xfree86/os-support/hurd/hurd_video.c +++ b/hw/xfree86/os-support/hurd/hurd_video.c @@ -28,6 +28,7 @@ #include mach.h #include device/device.h #include mach/machine/mach_i386.h +#include hurd.h #include X11/X.h #include input.h - -- Matt DewKey signature: 0xF7C3 BEC3 Fingerprint: FDB1 9D94 C573 DC29 BCCB 2F9F A6BF 3771 F7C3 BEC3 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSOTEiAAoJEKa/N3H3w77DR+0H/jW12BBCYgGK2Oy25zHj6wvZ y3xKi4PK+Pyb2ad1p/hTnbmD9usl/8+tSOmOZRU7i1OgjfP7vj012aCMyr2ZMmt2 +Sd0s2dpYxoobRg/m51+IFs2PiOVfCUH6NLkkrOP6xTQny57YG207fQYED3fJWwu mFHT2CcrdjEBxd5gDc+2jxtGCz9656qTGHLTN73TKdnhGvT56Z8cIwq2VnBntiuX V6SyQe6OZziIWsZ0POKyjiIeMFBjzMIn5fwufW3FzV4L48leJPOppsSx14YSxLd1 oH3n9xAlllfnC8AugtiJRzyVPvhFr8zbXe3iC3yoiBXc79x1RaGzHXiMLaa+vNU= =zA5L -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86VGAarbiter,vgaHW: Only wrap co-operating VGA drivers
On Mon, Sep 16, 2013 at 10:01:41AM +1000, Dave Airlie wrote: That would be equally true at the time the first arbiter support was added. Yet the approach taken was the pessismitic one we have today. No it wasn't, arbiter support was written years ago, and I think I developed it on an i945 and SiS PCI card, which I most certainly didn't have kernel drivers for. I stand corrected. The earlier references I could find in git were to /dev/vga_arbiter, so I presume it began that way. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86VGAarbiter,vgaHW: Only wrap co-operating VGA drivers
On Thu, Sep 12, 2013 at 06:40:18PM -0400, Daniel Stone wrote: Hi, On 12 September 2013 07:37, Chris Wilson ch...@chris-wilson.co.uk wrote: The approach taken in this patch is to first only enable VGA arbitration for drivers that require VGA resources. This is detected by moving the initialisation from the common xf86 code to the vgaHW module. This is strictly an ABI break as any driver that directly uses VGA (i.e. without using the vgaHW module) will need to make its own declaration of intent. Secondly, we then only wrap the operations with vgaarb get/put for the drivers that require VGA access. If we only have a single driver requring VGA access, we just wrap Enter/LeaveVT and lock the VGA arbiter for the entire duration that the Xserver is active. Why not add a new HW_NO_VGA flag to the GET_REQUIRED_HW_INTERFACES driverFunc() call, thus skipping the ABI break? Or flip the sense of your additional call, making it use VGA unless you opt out. I thought about the driverFunc, but it is too early. In the case of -intel, we have all generations compiled into one monolith which includes one driver (i810) that is reliant on vgaHW. Enabling it via vgaHW seemed like it would be the easiest path. Now thinks are slightly murkier as Ville says that our recent hw is snafu and requires arbitration as well. (It seems like to disable the VGA IO on Ironlake and above devices we need to disable the entire device...) The good news is that any system with an Intel Core processor and discete GPU hasn't required VGA access for the last 6 years - the bad news is that all discrete GPU systems with the same Core processor are now (from kernel 3.11) completely broken. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
