Dave,
A single fix for a performance regression.
The following changes since commit 45db98e54242f3ae94bdcfbfe754e743252eb168:
Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2014-03-07 09:27:22 +1000)
are available in the git repository at:
git://people.freedesktop.org/~thomash/linux tags/ttm-fixes-3.14-2014-03-12
for you to fetch changes up to 0e6d6ec02f867fe8d1f785312b7343b21052322f:
drm/ttm: Work around performance regression with …
[View More]VM_PFNMAP (2014-03-12 14:07:24 +0100)
----------------------------------------------------------------
Pull request of 2014-03-12
----------------------------------------------------------------
Thomas Hellstrom (1):
drm/ttm: Work around performance regression with VM_PFNMAP
drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=42162
--- Comment #27 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> ---
Taking a tip from https://bugs.freedesktop.org/show_bug.cgi?id=58382, I tried
suspending using "pm-suspend --quirk-test --quirk-s3-mode" and this works for
me too. Using this, the display *does* get re-enabled on resume.
--
You are receiving this mail because:
You are the assignee for the bug.
One of the stepping stones on the way to atomic/nuclear operation is to expose
all types of hardware planes to userspace via a consistent interface. Until
now, the DRM plane interface has only operated on planes that drivers consider
"overlay" or "sprite" planes; primary planes were simply represented by extra
state hanging off the CRTC, and cursor planes had no direct representation in
userspace, but were manipulated via separate ioctl's. This patch set begins
the process of unifying the …
[View More]various plane types into a single, consistent
interface.
With this patchset, userspace clients that set a
DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit will receive a full list
of all hardware planes, including primary planes and cursor planes, not just
the overlay/sprite planes that have historically been returned. Userspace
should be able to make drmModeSetPlane() calls against any type of plane and
have them operate as expected (to the extent supported by the underlying
hardware).
This benefits of this unified interface will be most evident once driver state
is fully property-ized as part of the upcoming atomic modeset / nuclear
pageflip work. However there are a few benefits that may be achieved even
before then:
* Drivers for hardware with scaling-capable primary planes may honor userspace
scaling requests for the primary plane made with the drmModeSetPlane() call.
Previously there was no interface that allowed userspace to specify desired
scaling on primary planes.
* Drivers for hardware that may disable primary planes independently from
the underlying CRTC may now do so when userspace passes a NULL framebuffer
to the drmModeSetPlane() interface.
This patchset is organized as follows:
- Patch 1 updates the DRM core with the general concept of multiple plane
types and prepares for there to be multiple types of planes on the
DRM plane list.
- Patch 2 adds a set of primary plane helper functions that drivers may use
to quickly support plane operations against primary planes. These helpers
implement plane update operations by calling into the driver's modeset
interface. These helpers are optional; drivers are free to provide their
own implementation.
- Patches 3 and 4 update loops over the DRM plane list in the exynos and i915
drivers to ignore non-overlay planes. This ensures that the behavior of
these loops will not change when new plane types show up on the DRM plane
list in future patches.
- Patch 5 adds a "plane type" property that allows userspace to identify
the types of the planes it receives. Note that we replace the 'priv'
parameter to drm_plane_init() with the type that should be used for
this property; in doing so, we create the first opportunity for
non-overlay planes to appear on the DRM plane list for some drivers (
msm, omap, and imx), although they will not be visible to userspace at
this time.
- Patch 6 updates all drivers to call drm_primary_helper_create_plane() before
CRTC creation and then pass the resulting plane to drm_crtc_init(). This
will create a primary plane via the primary plane helper and add it to the
DRM plane list. Note that this is the first time that *all* drivers will
have non-overlay planes on their plane list (msm, omap, and imx had their
previously-private planes show up in the plane list in patch 5).
These non-overlay planes still cannot be exposed to userspace.
- Patch 7 drops the 'fb' field from drm_crtc and switches everything to
using crtc->primary->fb instead.
- Patch 8 adds the client capability bit which allows userspace to request
the full plane list rather than just the overlay list. This is the first
patch that may have a userspace-visible effect.
- Patch 9 is a simple function name update in i915 to avoid confusion.
- Patch 10 replaces the primary plane helper usage in i915 with a custom
implementation of primary planes. On Intel hardware, we can disable the
primary plane without disabling the entire CRTC; the custom implementation
here allows us to avoid that limitation assumed by the helpers.
This patch set is still a work in progress. Specific work that still needs to
be done:
* Update msm, omap, and imx to properly associate their primary planes with
the appropriate CRTC (and stop creating a separate dummy primary plane). At
the moment the formerly "private" planes that these drivers use are created
as primary planes, but they're never specifically associated with the
correct CRTC (i.e., passed at drm_crtc_init()). I think this should be
pretty straightforward, but I just haven't had enough time to look through
how those drivers are structured yet to make the change. [suggested by Rob
Clark]
* Add cursor plane implementation. The general infrastructure necessary to
support cursors is present, but no default helpers exist yet and no driver
actually registers any cursor planes.
* Add extra read-only plane properties to inform userspace of what a plane's
true limitations and capabilities are. Although the "plane type" property
is probably enough to get by with something like a driver-specific DDX in
userspace, hardware-independent userspace like Weston will need more
information about what can and can't be done with each plane. This is
especially important for cursor planes since they can largely be viewed as
additional overlay planes that just have some extra limitations attached.
* Disallow usage of legacy cursor interfaces by clients that request universal
plane support. Make the new, unified interface the only interface for
clients that can support it. [suggested by Ville Syrjälä]
Matt Roper (10):
drm: Add support for multiple plane types
drm: Add primary plane helpers
drm/exynos: Restrict plane loops to only operate on overlay planes
drm/i915: Restrict plane loops to only operate on overlay planes
drm: Add plane type property
drm: Specify primary plane at CRTC initialization
drm: Replace crtc fb with primary plane fb
drm: Allow userspace to ask for full plane list (universal planes)
drm/i915: Rename similar plane functions to avoid confusion
drm/i915: Intel-specific primary plane handling
drivers/gpu/drm/armada/armada_crtc.c | 4 +-
drivers/gpu/drm/armada/armada_overlay.c | 3 +-
drivers/gpu/drm/ast/ast_mode.c | 4 +-
drivers/gpu/drm/bochs/bochs_kms.c | 4 +-
drivers/gpu/drm/cirrus/cirrus_mode.c | 4 +-
drivers/gpu/drm/drm_crtc.c | 447 ++++++++++++++++++++++------
drivers/gpu/drm/drm_crtc_helper.c | 21 +-
drivers/gpu/drm/drm_fb_helper.c | 9 +-
drivers/gpu/drm/drm_ioctl.c | 5 +
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 +
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_irq.c | 4 +-
drivers/gpu/drm/i915/intel_display.c | 238 +++++++++++----
drivers/gpu/drm/i915/intel_dp.c | 5 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/intel_pm.c | 39 +--
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 4 +-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 4 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 4 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 24 +-
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 8 +-
drivers/gpu/drm/nouveau/nv50_display.c | 21 +-
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 4 +-
drivers/gpu/drm/qxl/qxl_display.c | 4 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 20 +-
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 3 +-
drivers/gpu/drm/radeon/radeon_display.c | 8 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 16 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 +-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 +-
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
drivers/gpu/drm/tegra/dc.c | 7 +-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +-
drivers/gpu/drm/udl/udl_modeset.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +-
drivers/staging/imx-drm/imx-drm-core.c | 4 +-
drivers/staging/imx-drm/ipuv3-plane.c | 4 +-
include/drm/drmP.h | 5 +
include/drm/drm_crtc.h | 108 ++++++-
include/uapi/drm/drm.h | 8 +
55 files changed, 853 insertions(+), 275 deletions(-)
--
1.8.5.1
[View Less]
A performance regression was introduced in TTM in linux 3.13 when we started using
VM_PFNMAP for shared mappings. In theory this should've been faster due to
less page book-keeping but it appears like VM_PFNMAP + x86 PAT + write-combine
is a particularly cpu-hungry combination, as seen by largely increased
cpu-usage on r200 GL video playback.
Until we've sorted out why, revert to always use VM_MIXEDMAP.
Reference: freedesktop.org bugzilla bug #75719
Reported-and-tested-by: <smoki00790(a)…
[View More]gmail.com>
Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 801231c..0ce48e5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -339,11 +339,13 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
vma->vm_private_data = bo;
/*
- * PFNMAP is faster than MIXEDMAP due to reduced page
- * administration. So use MIXEDMAP only if private VMA, where
- * we need to support COW.
+ * We'd like to use VM_PFNMAP on shared mappings, where
+ * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
+ * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
+ * bad for performance. Until that has been sorted out, use
+ * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
*/
- vma->vm_flags |= (vma->vm_flags & VM_SHARED) ? VM_PFNMAP : VM_MIXEDMAP;
+ vma->vm_flags |= VM_MIXEDMAP;
vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
out_unref:
@@ -359,7 +361,7 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
vma->vm_ops = &ttm_bo_vm_ops;
vma->vm_private_data = ttm_bo_reference(bo);
- vma->vm_flags |= (vma->vm_flags & VM_SHARED) ? VM_PFNMAP : VM_MIXEDMAP;
+ vma->vm_flags |= VM_MIXEDMAP;
vma->vm_flags |= VM_IO | VM_DONTEXPAND;
return 0;
}
--
1.7.10.4
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=76046
Priority: medium
Bug ID: 76046
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [r600g][RV635][LLVM shader] Chrome aborts GPU
acceleration
Severity: normal
Classification: Unclassified
OS: All
Reporter: shawn.starr(a)rogers.com
Hardware: Other
Status: NEW
Version: unspecified
Component: Drivers/…
[View More]Gallium/r600
Product: Mesa
Forcing GPU accelration on r600g w/ (now using LLVM R600_LLVM=1 default it
seems) causes an assert to be thrown.
Components:
kernel-3.14.0-0.rc5.git2.2.fc21.x86_64
mesa-dri-drivers-10.1-1.20140305.fc21.x86_64
llvm-libs-3.4-4.fc21.x86_64
libdrm-2.4.52-1.fc21.x86_64
$ google-chrome --ignore-gpu-blacklist &
[1] 6174
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[6206:6206:0311/190002:ERROR:sandbox_linux.cc(268)] InitializeSandbox() called
with multiple threads in process gpu-process
/chrome/chrome --type=gpu-process --channel=6174.0.484233088
--user-data-dir=/home/spstarr/.config/google-chrome-beta --disable-breakpad
--supports-dual-gpus=false --gpu-driver-bug-workarounds=0,1,28
--gpu-vendor-id=0x1002 --gpu-device-id=0x9591 --gpu-driver-vendor
--gpu-driver-version --user-data-dir=/h: sb/sb_bc_parser.cpp:265: int
r600_sb::bc_parser::decode_alu_group(r600_sb::cf_node*, unsigned int&, unsigned
int&): Assertion `!"alu slot assignment failed"' failed.
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[6348:6348:0311/190007:ERROR:sandbox_linux.cc(268)] InitializeSandbox() called
with multiple threads in process gpu-process
/chrome/chrome --type=gpu-process --channel=6174.7.1540935881
--user-data-dir=/home/spstarr/.config/google-chrome-beta --disable-breakpad
--supports-dual-gpus=false --gpu-driver-bug-workarounds=0,1,2,28
--gpu-vendor-id=0x1002 --gpu-device-id=0x9591 --gpu-driver-vendor=Mesa
--gpu-driver-version=10.1.0 --user-data-dir=/h: sb/sb_bc_parser.cpp:265: int
r600_sb::bc_parser::decode_alu_group(r600_sb::cf_node*, unsigned int&, unsigned
int&): Assertion `!"alu slot assignment failed"' failed.
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[6354:6354:0311/190008:ERROR:sandbox_linux.cc(268)] InitializeSandbox() called
with multiple threads in process gpu-process
/chrome/chrome --type=gpu-process --channel=6174.8.352379127
--user-data-dir=/home/spstarr/.config/google-chrome-beta --disable-breakpad
--supports-dual-gpus=false --gpu-driver-bug-workarounds=0,1,2,28
--gpu-vendor-id=0x1002 --gpu-device-id=0x9591 --gpu-driver-vendor=Mesa
--gpu-driver-version=10.1.0 --user-data-dir=/h: sb/sb_bc_parser.cpp:265: int
r600_sb::bc_parser::decode_alu_group(r600_sb::cf_node*, unsigned int&, unsigned
int&): Assertion `!"alu slot assignment failed"' failed.
[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]