dri-devel February 2021

dri-devel@lists.freedesktop.org

314 participants
684 discussions

Re: [PATCH v4] Add power/gpu_frequency tracepoint.
by Peiyong Lin 12 Mar '21

12 Mar '21

On Thu, Oct 22, 2020 at 10:34 AM Peiyong Lin <lpy(a)google.com> wrote: > > Historically there is no common trace event for GPU frequency, in > downstream Android each different hardware vendor implements their own > way to expose GPU frequency, for example as a debugfs node. This patch > standardize it as a common trace event in upstream linux kernel to help > the ecosystem have a common implementation across hardware vendors. > Toolings in the Linux ecosystem will benefit from this especially in the > downstream Android, where this information is critical to graphics > developers. > > Signed-off-by: Peiyong Lin <lpy(a)google.com> > --- > > Changelog since v3: > - Correct copyright title. > > Changelog since v2: > - Add more comments to indicate when the event should be emitted. > - Change state to frequency. > > Changelog since v1: > - Use %u in TP_printk > > drivers/gpu/Makefile | 1 + > drivers/gpu/trace/Kconfig | 3 +++ > drivers/gpu/trace/Makefile | 1 + > drivers/gpu/trace/trace_gpu_frequency.c | 13 ++++++++++ > include/trace/events/power.h | 33 +++++++++++++++++++++++++ > 5 files changed, 51 insertions(+) > create mode 100644 drivers/gpu/trace/trace_gpu_frequency.c > > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile > index 835c88318cec..f289a47eb031 100644 > --- a/drivers/gpu/Makefile > +++ b/drivers/gpu/Makefile > @@ -6,3 +6,4 @@ obj-$(CONFIG_TEGRA_HOST1X) += host1x/ > obj-y += drm/ vga/ > obj-$(CONFIG_IMX_IPUV3_CORE) += ipu-v3/ > obj-$(CONFIG_TRACE_GPU_MEM) += trace/ > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace/ > diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig > index c24e9edd022e..ac4aec8d5845 100644 > --- a/drivers/gpu/trace/Kconfig > +++ b/drivers/gpu/trace/Kconfig > @@ -2,3 +2,6 @@ > > config TRACE_GPU_MEM > bool > + > +config TRACE_GPU_FREQUENCY > + bool > diff --git a/drivers/gpu/trace/Makefile b/drivers/gpu/trace/Makefile > index b70fbdc5847f..2b7ae69327d6 100644 > --- a/drivers/gpu/trace/Makefile > +++ b/drivers/gpu/trace/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_TRACE_GPU_MEM) += trace_gpu_mem.o > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace_gpu_frequency.o > diff --git a/drivers/gpu/trace/trace_gpu_frequency.c b/drivers/gpu/trace/trace_gpu_frequency.c > new file mode 100644 > index 000000000000..668fabd6b77a > --- /dev/null > +++ b/drivers/gpu/trace/trace_gpu_frequency.c > @@ -0,0 +1,13 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * GPU frequency trace points > + * > + * Copyright (C) 2020 Google LLC > + */ > + > +#include <linux/module.h> > + > +#define CREATE_TRACE_POINTS > +#include <trace/events/power.h> > + > +EXPORT_TRACEPOINT_SYMBOL(gpu_frequency); > diff --git a/include/trace/events/power.h b/include/trace/events/power.h > index af5018aa9517..343825a76953 100644 > --- a/include/trace/events/power.h > +++ b/include/trace/events/power.h > @@ -500,6 +500,39 @@ DEFINE_EVENT(dev_pm_qos_request, dev_pm_qos_remove_request, > > TP_ARGS(name, type, new_value) > ); > + > +/** > + * gpu_frequency - Reports the GPU frequency in GPU clock domains. > + * > + * This event should be emitted whenever there's a GPU frequency change happens, > + * or a GPU goes from idle state to active state, or vice versa. > + * > + * When the GPU goes from idle state to active state, this event should report > + * the GPU frequency of the active state. When the GPU goes from active state to > + * idle state, this event should report a zero frequency value. > + * > + * @frequency: New frequency (in KHz) > + * @gpu_id: Id for each GPU clock domain > + */ > +TRACE_EVENT(gpu_frequency, > + > + TP_PROTO(unsigned int frequency, unsigned int gpu_id), > + > + TP_ARGS(frequency, gpu_id), > + > + TP_STRUCT__entry( > + __field(unsigned int, frequency) > + __field(unsigned int, gpu_id) > + ), > + > + TP_fast_assign( > + __entry->frequency = frequency; > + __entry->gpu_id = gpu_id; > + ), > + > + TP_printk("frequency=%u gpu_id=%u", > + __entry->frequency, __entry->gpu_id) > +); > #endif /* _TRACE_POWER_H */ > > /* This part must be outside protection */ > -- > 2.29.0.rc1.297.gfa9743e501-goog > Hi there, Per request, re-send this patch with dri-devel@ list CCed. Thanks, Peiyong

3 5

[Bug 210321] New: /display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu]
by bugzilla-daemon＠bugzilla.kernel.org 12 Mar '21

12 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=210321 Bug ID: 210321 Summary: /display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu] Product: Drivers Version: 2.5 Kernel Version: 5.10.0-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: vladi(a)aresgate.net Regression: No Been happening since 5.9 [Mon Nov 23 08:42:42 2020] ------------[ cut here ]------------ [Mon Nov 23 08:42:42 2020] WARNING: CPU: 15 PID: 155 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:3240 dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu] [Mon Nov 23 08:42:42 2020] Modules linked in: autofs4 ipv6 tcp_bic binfmt_misc btusb btrtl btbcm btintel bluetooth snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_usb_audio snd_hda_codec snd_hwdep snd_usbmidi_lib snd_hda_core rfkill amdgpu ecdh_generic snd_pcm ecc snd_seq_midi mousedev snd_seq_midi_event snd_rawmidi cdc_acm input_leds led_class iommu_v2 evdev gpu_sched snd_seq ttm i2c_algo_bit snd_seq_device drm_kms_helper snd_timer syscopyarea sysfillrect sysimgblt fb_sys_fops snd drm k10temp ccp soundcore sha1_generic button efivarfs dm_crypt encrypted_keys dm_mod r8169 realtek mdio_devres libphy usbhid [Mon Nov 23 08:42:42 2020] CPU: 15 PID: 155 Comm: kworker/15:1 Not tainted 5.10.0-rc5 #50 [Mon Nov 23 08:42:42 2020] Hardware name: Micro-Star International Co., Ltd. MS-7B89/B450M MORTAR (MS-7B89), BIOS 1.D0 01/06/2020 [Mon Nov 23 08:42:42 2020] Workqueue: events drm_mode_rmfb_work_fn [drm] [Mon Nov 23 08:42:42 2020] RIP: 0010:dcn20_validate_bandwidth_fp+0x8b/0xd0 [amdgpu] [Mon Nov 23 08:42:42 2020] Code: 00 7b 2b 22 85 14 1f 00 00 75 26 f2 0f 11 85 58 26 00 00 31 d2 48 89 ee 4c 89 e7 e8 8f f6 ff ff 89 c2 22 95 14 1f 00 00 75 33 <0f> 0b eb 03 90 75 d2 66 0f 12 14 24 f2 0f 11 95 58 26 00 00 48 83 [Mon Nov 23 08:42:42 2020] RSP: 0018:ffffa93000607c28 EFLAGS: 00010246 [Mon Nov 23 08:42:42 2020] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 000000000001876f [Mon Nov 23 08:42:42 2020] RDX: 0000000000000000 RSI: 211d5948abbbab22 RDI: 00000000000261a0 [Mon Nov 23 08:42:42 2020] RBP: ffff8d0cab2a0000 R08: ffff8d0cab2a1ec8 R09: ffff8d0c8e440000 [Mon Nov 23 08:42:42 2020] R10: ffff8d0c86dde000 R11: 0000000100000001 R12: ffff8d0c8e440000 [Mon Nov 23 08:42:42 2020] R13: 0000000000000000 R14: ffff8d0cab2a0000 R15: ffff8d0c85b20308 [Mon Nov 23 08:42:42 2020] FS: 0000000000000000(0000) GS:ffff8d0f8efc0000(0000) knlGS:0000000000000000 [Mon Nov 23 08:42:42 2020] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Mon Nov 23 08:42:42 2020] CR2: 000056169e9dd940 CR3: 00000001114fa000 CR4: 0000000000350ee0 [Mon Nov 23 08:42:42 2020] Call Trace: [Mon Nov 23 08:42:42 2020] dcn20_validate_bandwidth+0x2d/0x50 [amdgpu] [Mon Nov 23 08:42:42 2020] dc_validate_global_state+0x279/0x300 [amdgpu] [Mon Nov 23 08:42:42 2020] amdgpu_dm_atomic_check+0xb39/0xc30 [amdgpu] [Mon Nov 23 08:42:42 2020] drm_atomic_check_only+0x557/0x7e0 [drm] [Mon Nov 23 08:42:42 2020] drm_atomic_commit+0x19/0x70 [drm] [Mon Nov 23 08:42:42 2020] drm_framebuffer_remove+0x395/0x430 [drm] [Mon Nov 23 08:42:42 2020] drm_mode_rmfb_work_fn+0x37/0x50 [drm] [Mon Nov 23 08:42:42 2020] process_one_work+0x1ae/0x300 [Mon Nov 23 08:42:42 2020] worker_thread+0x1f6/0x3e0 [Mon Nov 23 08:42:42 2020] ? rescuer_thread+0x410/0x410 [Mon Nov 23 08:42:42 2020] kthread+0x12a/0x150 [Mon Nov 23 08:42:42 2020] ? kthread_create_worker_on_cpu+0x70/0x70 [Mon Nov 23 08:42:42 2020] ret_from_fork+0x22/0x30 [Mon Nov 23 08:42:42 2020] ---[ end trace cb43a970abd417bb ]--- ❯ emerge --info Portage 3.0.9 (python 3.7.9-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-10.2.0, glibc-2.32-r2, 5.10.0-rc5 x86_64) ================================================================= System uname: Linux-5.10.0-rc5-x86_64-AMD_Ryzen_7_3700X_8-Core_Processor-with-gentoo-2.7 KiB Mem: 16419668 total, 12449312 free KiB Swap: 16137212 total, 16137212 free Timestamp of repository gentoo: Mon, 23 Nov 2020 15:05:42 +0000 Head commit of repository gentoo: b98ac916976c6de90fd633bcb2b579f57762a23c Head commit of repository lto-overlay: 3c0f2f8521d5d8e5180e742bee80f93e64575b38 Head commit of repository mv: 45f322abb49bf38da282afe2aa8c287d99c9e630 Head commit of repository steam-overlay: 6ed5630096d43208168572264f204d40e6b2a5c0 Head commit of repository eroen: 168c481db277e12e30ba6dea71a774337512ce32 Head commit of repository mva: 88a3abdfc840fc7d5645a0570fc0c6b03a45218d sh bash 5.0_p18 ld GNU ld (Gentoo 2.34 p6) 2.34.0 distcc 3.3.3 x86_64-pc-linux-gnu [disabled] ccache version 3.7.12 [disabled] app-shells/bash: 5.0_p18::gentoo dev-java/java-config: 2.3.1::gentoo dev-lang/perl: 5.30.3::gentoo dev-lang/python: 2.7.18-r4::gentoo, 3.7.9::gentoo, 3.8.6::gentoo, 3.9.0::gentoo dev-util/ccache: 3.7.12::gentoo dev-util/cmake: 3.17.4-r1::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.7::gentoo sys-apps/openrc: 0.42.1::gentoo sys-apps/sandbox: 2.20::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo sys-devel/automake: 1.16.1-r1::gentoo sys-devel/binutils: 2.34-r2::gentoo sys-devel/gcc: 10.2.0-r3::gentoo sys-devel/gcc-config: 2.3.2-r1::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers) sys-libs/glibc: 2.32-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo priority: -1000 x-portage location: /usr/local/portage masters: gentoo priority: 0 lto-overlay location: /usr/local/portage/lto-overlay sync-type: git sync-uri: https://github.com/InBetweenNames/gentooLTO.git masters: gentoo mv priority: 50 mv location: /usr/local/portage/mv sync-type: git sync-uri: https://anongit.gentoo.org/git/user/mv.git masters: gentoo priority: 50 steam-overlay location: /usr/local/portage/steam sync-type: git sync-uri: https://github.com/anyc/steam-overlay.git masters: gentoo priority: 50 eroen location: /usr/local/portage/eroen sync-type: git sync-uri: https://anongit.gentoo.org/git/user/eroen.git masters: gentoo priority: 9999 mva location: /usr/local/portage/mva sync-type: git sync-uri: https://github.com/msva/mva-overlay.git masters: gentoo priority: 9999 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=znver2 -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=auto -fuse-linker-plugin -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=znver2 -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=auto -fuse-linker-plugin -pipe" DISTDIR="/usr/portage/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en bg" MAKEOPTS="-j17 -l9" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/cache/gentoo" USE="X a52 aac aalib acl acpi activities adns aio alsa amd64 asf bash-completion berkdb bluetooth branding btrfs bzip2 cairo caps cdda cdr chroot cli crypt cryptsetup cups curl custom-cflags custom-optimization dav1d dbus declarative device-mapper dri dts dv dvd dvdr egl elogind emboss encode exif faac faad ffmpeg flac fortran gbm gdbm gif glamor gles gles2 glib gnutls gold gpg graphite gstreamer gui hwaccel iconv icu imap inotify introspection iproute2 ipv6 irc ithreads iwd jpeg jumbo-build kde kerberos kipi kwallet lcms libaom libglvnd libinput libnotify libtirpc lto lzo mad maps matroska melt mng mp3 mp4 mpd mpeg mtp multilib ncurses networkmanager nls nptl offensive ogg ogm opengl openmp opus otr ozone pam pango pcre pdf pdfimport pgo phonon pic plasma png policykit ppds pulseaudio qml qt5 rar rav1e rdp readline rpc sasl screencast sdl seccomp semantic-desktop speex spell split-usr sql ssl startup-notification svg system-av1 system-cairo system-ffmpeg system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-llvm system-mesa system-webp theora threads thumbnail tidy tiff truetype udev udisks unicode upower usb user-session v4l vaapi vcd vim-syntax vnc vorbis vpx wayland widgets x264 xattr xcb xml xv xvfb xvid zip zlib zsh-completion" ABI_X86="64 32" ADA_TARGET="gnat_2018" ALSA_CARDS="hda_intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc efi-64" INPUT_DEVICES="keyboard libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2 php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" RUBY_TARGETS="ruby25 ruby26" SANE_BACKENDS="fujitsu" USERLAND="GNU" VIDEO_CARDS="amdgpu radeonsi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[PATCH] RFC: i915: Drop relocation support on Gen12+
by Jason Ekstrand 12 Mar '21

12 Mar '21

The Vulkan driver in Mesa for Intel hardware never uses relocations if it's running on a version of i915 that supports at least softpin which all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is only supported by iris which never uses relocations. The older i965 driver in Mesa does use relocations but it only supports Intel hardware through Gen11 and has been deprecated for all hardware Gen9+. The entire relocation UAPI and related infrastructure, therefore, doesn't have any open-source userspace consumer starting with Gen12. Rejecting relocations starting with Gen12 has the benefit that we don't have to bother supporting it on platforms with local memory. Given how much CPU touching of memory is required for relocations, not having to do so on platforms where not all memory is directly CPU-accessible carries significant advantages. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 4f9c1f5a4dedb..e10c93aff945d 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1533,7 +1533,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct i915_vma *vma) return err; } -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) +static int check_relocations(const struct i915_execbuffer *eb, + const struct drm_i915_gem_exec_object2 *entry) { const char __user *addr, *end; unsigned long size; @@ -1543,6 +1544,9 @@ static int check_relocations(const struct drm_i915_gem_exec_object2 *entry) if (size == 0) return 0; + if (size && eb->reloc_cache.gen >= 12) + return -EINVAL; + if (size > N_RELOC(ULONG_MAX)) return -EINVAL; @@ -1576,7 +1580,7 @@ static int eb_copy_relocations(const struct i915_execbuffer *eb) if (nreloc == 0) continue; - err = check_relocations(&eb->exec[i]); + err = check_relocations(eb, &eb->exec[i]); if (err) goto err; -- 2.26.2

9 23

[PATCH] dma-fence: Document recoverable page fault implications
by Daniel Vetter 12 Mar '21

12 Mar '21

Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. This documentation section explains what's the potential problem, and the remedies we've discussed, roughly ordered from best to worst. v2: Linus -> Linux typoe (Dave) v3: - Make it clear drivers only need to implement one option (Christian) - Make it clearer that implicit sync is out the window with exclusive fences (Christian) - Add the fairly theoretical option of segementing the memory (either statically or through dynamic checks at runtime for which piece of memory is managed how) and explain why it's not a great idea (Felix) References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd… Cc: Dave Airlie <airlied(a)gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Cc: Felix Kuehling <felix.kuehling(a)amd.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- Documentation/driver-api/dma-buf.rst | 76 ++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..7f37ec30d9fd 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,79 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linux rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. Specifically this means implicit synchronization will not be possible. +The exception is when page faults are only used as migration hints and never to +on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few options to prevent this problem, one of which drivers need to +ensure: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no useful reservation mechanics, + all workloads must be flushed from the GPU when switching between jobs + requiring DMA fences or jobs requiring page fault handling: This means all DMA + fences must complete before a compute job with page fault handling can be + inserted into the scheduler queue. And vice versa, before a DMA fence can be + made visible anywhere in the system, all compute workloads must be preempted + to guarantee all pending GPU page faults are flushed. + +- Only a fairly theoretical option would be to untangle these dependencies when + allocating memory to repair hardware page faults, either through separate + memory blocks or runtime tracking of the full dependency graph of all DMA + fences. This results very wide impact on the kernel, since resolving the page + on the CPU side can itself involve a page fault. It is much more feasible and + robust to limit the impact of handling hardware page faults to the specific + driver. + +Note that workloads that run on independent hardware like copy engines or other +GPUs do not have any impact. This allows us to keep using DMA fences internally +in the kernel even for resolving hardware page faults, e.g. by using copy +engines to clear or copy memory needed to resolve the page fault. + +In some ways this page fault problem is a special case of the `Infinite DMA +Fences` discussions: Infinite fences from compute workloads are allowed to +depend on DMA fences, but not the other way around. And not even the page fault +problem is new, because some other CPU thread in userspace might +hit a page fault which holds up a userspace fence - supporting page faults on +GPUs doesn't anything fundamentally new. -- 2.30.0

4 7

[PATCH v5 0/7] drm: add simpledrm driver
by David Herrmann 12 Mar '21

12 Mar '21

Hey On request of Noralf, I picked up the patches and prepared v5. Works fine with Xorg, if configured according to: https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html If anyone knows how to make Xorg pick it up dynamically without such a static configuration, please let me know. Thanks David David Herrmann (7): x86/sysfb: add support for 64bit EFI lfb_base x86/sysfb: fix lfb_size calculation of/platform: expose of_platform_device_destroy() video: add generic framebuffer eviction drm: switch to sysfb_evict_conflicts() drm: add SimpleDRM driver drm/simpledrm: add fbdev fallback support MAINTAINERS | 6 + arch/x86/kernel/sysfb_simplefb.c | 39 ++- drivers/gpu/drm/Kconfig | 3 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 +- drivers/gpu/drm/bochs/bochs_drv.c | 19 +- drivers/gpu/drm/i915/i915_drv.c | 73 +--- drivers/gpu/drm/mgag200/mgag200_drv.c | 27 +- drivers/gpu/drm/mgag200/mgag200_main.c | 9 - drivers/gpu/drm/nouveau/nouveau_drm.c | 33 +- drivers/gpu/drm/radeon/radeon_drv.c | 24 +- drivers/gpu/drm/simpledrm/Kconfig | 19 ++ drivers/gpu/drm/simpledrm/Makefile | 9 + drivers/gpu/drm/simpledrm/simpledrm.h | 91 +++++ drivers/gpu/drm/simpledrm/simpledrm_damage.c | 194 +++++++++++ drivers/gpu/drm/simpledrm/simpledrm_drv.c | 477 +++++++++++++++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 143 ++++++++ drivers/gpu/drm/simpledrm/simpledrm_gem.c | 109 ++++++ drivers/gpu/drm/simpledrm/simpledrm_kms.c | 270 +++++++++++++++ drivers/gpu/drm/simpledrm/simpledrm_of.c | 265 +++++++++++++++ drivers/gpu/drm/sun4i/sun4i_drv.c | 24 +- drivers/gpu/drm/vc4/vc4_drv.c | 25 +- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +- drivers/of/platform.c | 35 +- drivers/video/Kconfig | 4 + drivers/video/Makefile | 1 + drivers/video/sysfb.c | 327 ++++++++++++++++++ include/linux/of_platform.h | 1 + include/linux/sysfb.h | 34 ++ 29 files changed, 2054 insertions(+), 256 deletions(-) create mode 100644 drivers/gpu/drm/simpledrm/Kconfig create mode 100644 drivers/gpu/drm/simpledrm/Makefile create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_of.c create mode 100644 drivers/video/sysfb.c create mode 100644 include/linux/sysfb.h -- 2.9.3

5 28

[PATCH 1/2] dma-buf: Require VM_PFNMAP vma for mmap
by Daniel Vetter 12 Mar '21

12 Mar '21

tldr; DMA buffers aren't normal memory, expecting that you can use them like that (like calling get_user_pages works, or that they're accounting like any other normal memory) cannot be guaranteed. Since some userspace only runs on integrated devices, where all buffers are actually all resident system memory, there's a huge temptation to assume that a struct page is always present and useable like for any more pagecache backed mmap. This has the potential to result in a uapi nightmare. To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which blocks get_user_pages and all the other struct page based infrastructure for everyone. In spirit this is the uapi counterpart to the kernel-internal CONFIG_DMABUF_DEBUG. Motivated by a recent patch which wanted to swich the system dma-buf heap to vm_insert_page instead of vm_insert_pfn. v2: Jason brought up that we also want to guarantee that all ptes have the pte_special flag set, to catch fast get_user_pages (on architectures that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would still allow vm_insert_page, but limiting to VM_PFNMAP will catch that. >From auditing the various functions to insert pfn pte entires (vm_insert_pfn_prot, remap_pfn_range and all it's callers like dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so this should be the correct flag to check for. References: https://lore.kernel.org/lkml/CAKMK7uHi+mG0z0HUmNt13QCCvutuRVjpcR0NjRL12k-Wb… Acked-by: Christian König <christian.koenig(a)amd.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f264b70c383e..06cb1d2e9fdc 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = { static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) { struct dma_buf *dmabuf; + int ret; if (!is_dma_buf_file(file)) return -EINVAL; @@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) dmabuf->size >> PAGE_SHIFT) return -EINVAL; - return dmabuf->ops->mmap(dmabuf, vma); + ret = dmabuf->ops->mmap(dmabuf, vma); + + WARN_ON(!(vma->vm_flags & VM_PFNMAP)); + + return ret; } static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) @@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, unsigned long pgoff) { + int ret; + if (WARN_ON(!dmabuf || !vma)) return -EINVAL; @@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, vma_set_file(vma, dmabuf->file); vma->vm_pgoff = pgoff; - return dmabuf->ops->mmap(dmabuf, vma); + ret = dmabuf->ops->mmap(dmabuf, vma); + + WARN_ON(!(vma->vm_flags & VM_PFNMAP)); + + return ret; } EXPORT_SYMBOL_GPL(dma_buf_mmap); -- 2.30.0

9 37

[PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1
by Douglas Anderson 11 Mar '21

11 Mar '21

This series is to get the N116BCA-EA1 panel working. Most of the patches are simple, but on hardware I have in front of me the panel sometimes doesn't come up. I'm still working with the hardware manufacturer to get to the bottom of it, but I've got it working with retries. Adding the retries doesn't seem like an insane thing to do and makes some of the error handling more robust, so I've gone ahead and included those patches here. Hopefully they look OK. Changes in v2: - Set the "unprepared_time" so if we retry we give the proper delay. - ("drm/panel-simple: Don't wait longer for HPD...") new for v2. - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2. - ("dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1") new for v2. - ("drm/panel-simple: Add N116BCA-EA1") new for v2. Douglas Anderson (5): drm/panel-simple: Undo enable if HPD never asserts drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay drm/panel-simple: Retry if we timeout waiting for HPD dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1 drm/panel-simple: Add N116BCA-EA1 .../bindings/display/panel/panel-simple.yaml | 2 + drivers/gpu/drm/panel/panel-simple.c | 84 +++++++++++++++++-- 2 files changed, 80 insertions(+), 6 deletions(-) -- 2.30.0.284.gd98b1dd5eaa7-goog

5 20

[PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage.
by Sebastian Andrzej Siewior 11 Mar '21

11 Mar '21

Folks, in the discussion about preempt count consistency across kernel configurations: https://lore.kernel.org/r/20200914204209.256266093@linutronix.de/ it was concluded that the usage of in_interrupt() and related context checks should be removed from non-core code. In the long run, usage of 'preemptible, in_*irq etc.' should be banned from driver code completely. This series addresses parts of the amdgpu driver. There are still call sites left in in the amdgpu driver. v1…v2: - Limit to admgpu only - use "bool" instead of "bool == true" Sebastian

3 9

KMSAN: kernel-infoleak in compat_drm_wait_vblank
by syzbot 11 Mar '21

11 Mar '21

Hello, syzbot found the following issue on: HEAD commit: 29ad81a1 arch/x86: add missing include to sparsemem.h git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=111e6312d00000 kernel config: https://syzkaller.appspot.com/x/.config?x=c8e3b38ca92283e dashboard link: https://syzkaller.appspot.com/bug?extid=620cf21140fc7e772a5d compiler: Debian clang version 11.0.1-2 userspace arch: i386 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+620cf21140fc7e772a5d(a)syzkaller.appspotmail.com ===================================================== BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 CPU: 1 PID: 26999 Comm: syz-executor.2 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 kmsan_internal_check_memory+0x484/0x520 mm/kmsan/kmsan.c:437 kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0x1ac/0x270 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:209 [inline] compat_drm_wait_vblank+0x36f/0x450 drivers/gpu/drm/drm_ioc32.c:866 drm_compat_ioctl+0x3f6/0x590 drivers/gpu/drm/drm_ioc32.c:995 __do_compat_sys_ioctl fs/ioctl.c:842 [inline] __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c RIP: 0023:0xf7f47549 Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f55415fc EFLAGS: 00000296 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000c018643a RDX: 0000000020000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 compat_drm_wait_vblank+0x43c/0x450 drivers/gpu/drm/drm_ioc32.c:865 drm_compat_ioctl+0x3f6/0x590 drivers/gpu/drm/drm_ioc32.c:995 __do_compat_sys_ioctl fs/ioctl.c:842 [inline] __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c Local variable ----req@compat_drm_wait_vblank created at: compat_drm_wait_vblank+0x7b/0x450 drivers/gpu/drm/drm_ioc32.c:849 compat_drm_wait_vblank+0x7b/0x450 drivers/gpu/drm/drm_ioc32.c:849 Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff88814ffe3c98 Data copied to user address 0000000020000100 ===================================================== --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

3 2

[PATCH 00/35] Add HMM-based SVM memory manager to KFD
by Felix Kuehling 11 Mar '21

11 Mar '21

This is the first version of our HMM based shared virtual memory manager for KFD. There are still a number of known issues that we're working through (see below). This will likely lead to some pretty significant changes in MMU notifier handling and locking on the migration code paths. So don't get hung up on those details yet. But I think this is a good time to start getting feedback. We're pretty confident about the ioctl API, which is both simple and extensible for the future. (see patches 4,16) The user mode side of the API can be found here: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-w… I'd also like another pair of eyes on how we're interfacing with the GPU VM code in amdgpu_vm.c (see patches 12,13), retry page fault handling (24,25), and some retry IRQ handling changes (32). Known issues: * won't work with IOMMU enabled, we need to dma_map all pages properly * still working on some race conditions and random bugs * performance is not great yet Alex Sierra (12): drm/amdgpu: replace per_device_list by array drm/amdkfd: helper to convert gpu id and idx drm/amdkfd: add xnack enabled flag to kfd_process drm/amdkfd: add ioctl to configure and query xnack retries drm/amdkfd: invalidate tables on page retry fault drm/amdkfd: page table restore through svm API drm/amdkfd: SVM API call to restore page tables drm/amdkfd: add svm_bo reference for eviction fence drm/amdgpu: add param bit flag to create SVM BOs drm/amdkfd: add svm_bo eviction mechanism support drm/amdgpu: svm bo enable_signal call condition drm/amdgpu: add svm_bo eviction to enable_signal cb Philip Yang (23): drm/amdkfd: select kernel DEVICE_PRIVATE option drm/amdkfd: add svm ioctl API drm/amdkfd: Add SVM API support capability bits drm/amdkfd: register svm range drm/amdkfd: add svm ioctl GET_ATTR op drm/amdgpu: add common HMM get pages function drm/amdkfd: validate svm range system memory drm/amdkfd: register overlap system memory range drm/amdkfd: deregister svm range drm/amdgpu: export vm update mapping interface drm/amdkfd: map svm range to GPUs drm/amdkfd: svm range eviction and restore drm/amdkfd: register HMM device private zone drm/amdkfd: validate vram svm range from TTM drm/amdkfd: support xgmi same hive mapping drm/amdkfd: copy memory through gart table drm/amdkfd: HMM migrate ram to vram drm/amdkfd: HMM migrate vram to ram drm/amdgpu: reserve fence slot to update page table drm/amdgpu: enable retry fault wptr overflow drm/amdkfd: refine migration policy with xnack on drm/amdkfd: add svm range validate timestamp drm/amdkfd: multiple gpu migrate vram to vram drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 16 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 83 + drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h | 7 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 5 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 90 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 47 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 10 + drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 32 +- drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 32 +- drivers/gpu/drm/amd/amdkfd/Kconfig | 1 + drivers/gpu/drm/amd/amdkfd/Makefile | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 170 +- drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 8 +- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 866 ++++++ drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 59 + drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 52 +- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 200 +- .../amd/amdkfd/kfd_process_queue_manager.c | 6 +- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2564 +++++++++++++++++ drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 135 + drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 10 +- include/uapi/linux/kfd_ioctl.h | 169 +- 26 files changed, 4296 insertions(+), 291 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_migrate.h create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_svm.c create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_svm.h -- 2.29.2

7 83

← Newer
1
...
11
12
13
14
15
16
17
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2021