Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[xsrc/trunk]: xsrc/external/mit/xf86-video-amdgpu/dist initial import of xf86...
details: https://anonhg.NetBSD.org/xsrc/rev/8b80d0653e2f
branches: trunk
changeset: 10192:8b80d0653e2f
user: mrg <mrg%NetBSD.org@localhost>
date: Fri Mar 08 10:11:25 2019 +0000
description:
initial import of xf86-video-amdgpu-19.0.0
diffstat:
external/mit/xf86-video-amdgpu/dist/ChangeLog | 807 +++++++++++++
external/mit/xf86-video-amdgpu/dist/Makefile.am | 2 +-
external/mit/xf86-video-amdgpu/dist/Makefile.in | 6 +-
external/mit/xf86-video-amdgpu/dist/README.md | 21 +
external/mit/xf86-video-amdgpu/dist/configure | 20 +-
external/mit/xf86-video-amdgpu/dist/configure.ac | 2 +-
external/mit/xf86-video-amdgpu/dist/man/amdgpu.man | 9 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_bo_helper.c | 15 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_dri2.c | 29 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_dri2.h | 1 +
external/mit/xf86-video-amdgpu/dist/src/amdgpu_dri3.c | 31 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_drm_queue.c | 129 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_drm_queue.h | 3 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_drv.h | 12 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_glamor.c | 14 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_glamor.h | 21 +
external/mit/xf86-video-amdgpu/dist/src/amdgpu_kms.c | 459 +++++-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_present.c | 58 +-
external/mit/xf86-video-amdgpu/dist/src/amdgpu_probe.c | 16 +
external/mit/xf86-video-amdgpu/dist/src/amdgpu_probe.h | 4 +-
external/mit/xf86-video-amdgpu/dist/src/drmmode_display.c | 464 ++++--
external/mit/xf86-video-amdgpu/dist/src/drmmode_display.h | 33 +-
22 files changed, 1777 insertions(+), 379 deletions(-)
diffs (truncated from 3410 to 300 lines):
diff -r 6bb12b421d1a -r 8b80d0653e2f external/mit/xf86-video-amdgpu/dist/ChangeLog
--- a/external/mit/xf86-video-amdgpu/dist/ChangeLog Fri Mar 08 09:59:44 2019 +0000
+++ b/external/mit/xf86-video-amdgpu/dist/ChangeLog Fri Mar 08 10:11:25 2019 +0000
@@ -1,3 +1,810 @@
+commit 9534bf3bb33d14cd3a5af08e36ef42b309647fc7
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Wed Mar 6 12:05:14 2019 +0100
+
+ Bump version for the 19.0.0 release
+
+commit a2b32e72fdaff3007a79b84929997d8176c2d512
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Fri Mar 1 17:42:08 2019 +0100
+
+ present: Don't check tiling parameters with DC & DRM minor version >= 31
+
+ Current DC handles any changes of tiling parameters for flips.
+
+ v2:
+ * Just check all tiling bits if DRM minor < 31 or DC is disabled.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit 2798244be78df3ef3a7841597577506bfbe50156
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Fri Mar 1 17:47:24 2019 +0100
+
+ Make drmmode_cm_enabled an inline function
+
+ So that it can be used outside of drmmode_display.c as well.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit 72653455e4f652ca6c7c290c7f1e8a889b77f5ce
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Fri Mar 1 17:35:48 2019 +0100
+
+ Revert "Remove set but unused amdgpu_dri2::pKernelDRMVersion"
+
+ This reverts commit 720a61000aeb139005bd8125908cec66a6e69554.
+
+ We're going to make use of it now.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit 28cd209ebf20561e65d14fa2e8bbfaedf6965948
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Wed Feb 27 17:35:26 2019 +0100
+
+ Revert "gitlab-ci: Only run docker-image stage if relevant source files change"
+
+ This reverts commit 9c23076b9e81c36ac2408c491f9b2d546829ee8e.
+
+ Some scenarios have come to light where this failed to ensure the docker
+ image exists:
+
+ * If the master branch of a forked repository is used for an MR which
+ doesn't modify .gitlab-ci.yml, the docker-image job may not run.
+ * If the docker-image job of the first pipeline in a forked repository
+ is cancelled or fails for any reason, and .gitlab-ci.yml isn't
+ modified for the next pipeline run.
+
+commit 09be74a3d1dd9604336d9a27f98d132b262dcbaf
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Thu Feb 28 17:31:55 2019 +0100
+
+ dri2: Call drm_queue_handle_deferred in dri2_deferred_event
+
+ drm_queue_handler just puts the event on the signalled list; without
+ calling drm_queue_handle_deferred, actual processing of the event may be
+ delayed indefinitely, e.g. until another event arrives from the kernel.
+
+ This could result in DRI2 clients hanging during DPMS off.
+
+ Fixes: 739181c8d3334 "Add amdgpu_drm_handle_event wrapper for
+ drmHandleEvent"
+ Reviewed-by: Aaron Liu <aaron.liu%amd.com@localhost>
+ Tested-by: Aaron Liu <aaron.liu%amd.com@localhost>
+
+commit a636f42b496b0604ca00a144690ece61d1a88a27
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Wed Feb 27 18:43:27 2019 +0100
+
+ present: Check that flip and screen pixmap pitches match
+
+ If they don't, flipping will result in corrupted display.
+
+ Test case:
+
+ * Run Xorg at 1920x1080 with no window manager
+ * glxgears -geometry 2048x1080
+
+ The Present extension code in xserver 1.21 will check for this.
+
+ Tested-by: Jax Lin <jax.lin%amd.com@localhost>
+
+commit bd090f389f19f1f4a3f662ffdd891345a3899539
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Tue Feb 12 17:57:17 2019 +0100
+
+ Call amdgpu_present_set_screen_vrr from amdgpu_vrr_property_update
+
+ If the window is currently flipping.
+
+ This might make a difference when the property gets disabled: Variable
+ refresh will now be disabled immediately in that case, instead of only
+ when the window can no longer use page flipping at all.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit d9be5d712d469595e1e610f7294bc670ca3b1985
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Tue Feb 12 12:26:25 2019 +0100
+
+ Make use of property request wrappers for VRR property
+
+ Instead of scanning for PropertyNotify events. Reasons:
+
+ * Works even if no client listens to PropertyNotify events for the
+ window.
+ * No overhead on delivery of unrelated events, and no overhead at all
+ if Option "VariableRefresh" is disabled.
+
+ v2:
+ * Use shorter variable name amdgpu_vrr_atom.
+ * Call MakeAtom regardless of info->instance_id, for robustness vs VRR
+ being enabled in some but not all AMDGPU screens.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit ef8fbe33b7d97f7fb5518db9c0e4d2dcbf2fab6f
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Thu Jan 17 18:41:11 2019 +0100
+
+ Wrap change/delete window property request handlers
+
+ Preparation for the following change.
+
+ v2:
+ * Add comments explaining what the wrappers are wrapping.
+ * Use global amdgpu_property_vectors_wrapped to keep track of whether
+ the vectors need to be (un)wrapped, for robustness against VRR being
+ enabled in some but not all AMDGPU screens.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit 09a45ff8fe3ac07bafa3a0822b1598c41f9ca200
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Tue Feb 12 13:01:04 2019 +0100
+
+ Don't enable the VRR support code for GPU screens
+
+ Windows aren't associated with GPU screens, and amdgpu_present_flip is
+ never called for them, so VRR can never actually be enabled for them.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit 2a3d00dc7ed2b4fca698e2d699e1b94da6d0ddb8
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Tue Feb 12 18:12:23 2019 +0100
+
+ Don't register a window private if VRR is disabled
+
+ It's not used in that case.
+
+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas%amd.com@localhost>
+
+commit 5f91be77e059d0c4a4268ec10cbd9aa1052f53eb
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Mon Feb 11 18:32:07 2019 +0100
+
+ gitlab-ci: Don't rely on $CI_PROJECT_NAME
+
+ The name of a forked repository can be changed later, in which case this
+ would fail to refer to the main repository.
+
+ Pointed out by Eric Engestrom in
+ https://gitlab.freedesktop.org/mesa/mesa/merge_requests/224 .
+
+commit 9c23076b9e81c36ac2408c491f9b2d546829ee8e
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Thu Feb 7 17:35:13 2019 +0100
+
+ gitlab-ci: Only run docker-image stage if relevant source files change
+
+ Otherwise there's normally no need to run it. It will also run when a
+ new branch is created, which ensures that the docker image always exists
+ (e.g. in a newly forked repository).
+
+ Inspired by https://gitlab.freedesktop.org/mesa/mesa/merge_requests/143
+
+commit 9045fb310f88780e250e60b80431ca153330e61b
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Thu Jan 24 18:31:40 2019 +0100
+
+ Keep waiting for a pending flip if drm_handle_event returns 0
+
+ drm_wait_pending_flip stopped waiting if drm_handle_event returned 0,
+ but that might have processed only some unrelated DRM events. As long as
+ the flip is pending, we have to keep waiting for its completion event.
+
+ Noticed while working on the previous fix.
+
+ Acked-by: Alex Deucher <alexander.deucher%amd.com@localhost>
+
+commit 3ff2cc225f6bc08364ee007fa54e9d0150adaf11
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Tue Jan 22 18:36:56 2019 +0100
+
+ Call drmHandleEvent again if it was interrupted by a signal
+
+ drmHandleEvent can be interrupted by a signal in read(), in which case
+ it doesn't process any events but returns -1, which
+ drm_handle_event propagated to its callers. This could cause the
+ following failure cascade:
+
+ 1. drm_wait_pending_flip stopped waiting for a pending flip.
+ 2. Its caller cleared drmmode_crtc->flip_pending before the flip
+ completed.
+ 3. Another flip was attempted but got an unexpected EBUSY error because
+ the previous flip was still pending.
+ 4. TearFree was disabled due to the error.
+
+ The solution is to call drmHandleEvent if it was interrupted by a
+ signal. We can do that in drm_handle_event, because when that is called,
+ either it is known that there are events ready to be processed, or the
+ caller has to wait for events to arrive anyway.
+
+ v2:
+ * Use ErrorF instead of xf86DrvMsg with hard-coded screen 0.
+
+ Bugzilla: https://bugs.freedesktop.org/109364
+ Reviewed-by: Alex Deucher <alexander.deucher%amd.com@localhost> # v1
+
+commit e72a02ba1d35743fefd939458b9d8cddce86e7f5
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Wed Jan 16 10:26:59 2019 +0100
+
+ Only update drmmode_crtc->flip_pending after actually submitting a flip
+
+ And only clear it if it matches the framebuffer of the completed flip
+ being processed.
+
+ Fixes
+
+ (WW) AMDGPU(0): flip queue failed: Device or resource busy
+ (WW) AMDGPU(0): Page flip failed: Device or resource busy
+ (EE) AMDGPU(0): present flip failed
+
+ due to clobbering drmmode_crtc->flip_pending.
+
+ Reproducer: Enable TearFree, run warzone2100 fullscreen, toggle
+ Vertical sync on/off under Video Options. Discovered while investigating
+ https://bugs.freedesktop.org/109364 .
+
+ Acked-by: Alex Deucher <alexander.deucher%amd.com@localhost>
+
+commit a1b479c7d0066c481af920f297d6af9009dda11e
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Tue Jan 15 17:55:27 2019 +0100
+
+ Don't allow TearFree scanout flips to complete in the same vblank period
+
+ We were using a relative target of 0, meaning "complete the flip ASAP".
+ This could result in the flip sometimes, but not always completing in
+ the same vertical blank period where the corresponding drawing occurred,
+ potentially causing judder artifacts with applications updating their
+ window contents synchronized to the display refresh. A good way to test
+ this is the vsynctester.com site in a windowed browser, where the judder
+ results in the large "VSYNC" text intermittently appearing red or cyan
+ instead of the expected gray.
+
+ To avoid this, use a relative target MSC of 1, meaning that if a
+ vertical blank period is in progress, the flip will only complete in the
+ next one.
+
+ Reported by Julian Tempel and Brandon Wright in
+ https://bugs.freedesktop.org/106175 .
+
+ Reviewed-by: Alex Deucher <alexander.deucher%amd.com@localhost>
+
+commit bf326f2ea19daa6c8da23d6788ff301ae70b8e69
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Thu Jan 10 18:33:04 2019 +0100
+
+ glamor: Avoid glamor_create_pixmap for pixmaps backing windows
+
+ If the compositing manager uses direct rendering (as is usually the case
+ these days), the storage of a pixmap allocated by glamor_create_pixmap
+ needs to be reallocated for sharing it with the compositing manager.
+ Instead, allocate pixmap storage which can be shared directly.
+
+ Acked-by: Alex Deucher <alexander.deucher%amd.com@localhost>
+
+commit ebd32b1c07208f8dbe853e089f5e4b7c6a7a658a
+Author: Michel Dänzer <michel.daenzer%amd.com@localhost>
+Date: Wed Jan 9 18:57:08 2019 +0100
+
+ dri2: Flush in dri2_create_buffer2 after calling glamor_set_pixmap_bo
+
Home |
Main Index |
Thread Index |
Old Index