similar to: Accumulating CPU load from Xorg process with DRI3

I'm aware of this issue, and am experiencing it myself. The issue is that drmmode_event_handler takes up more and more CPU time. It seems like some events are being "left behind". I haven't had time to debug it further yet though. I also have DRI3 enabled, but only very rarely do I make use of my secondary GPUs, and I'm pretty sure I've seen the problem happen without

I observed this bug for quite some time, but so far I workarounded it with just setting DRI2 (default) in xorg.conf.d/20-nouveau.conf Now with two GPU i iwsh to use DRI3, so right now it set up like this: cat /etc/X11/xorg.conf.d/20-nouveau.conf Section "Device" Identifier "Card0" Driver "nouveau" Option "PageFlip" "1" #Option

I rebuild mesa with debug symbols, and now top functions using CPU looks like this: CPU: AMD64 family15h, speed 3800 MHz (estimated) Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name symbol name ------------------------------------------------------------------------------- 222978 45.1489

The DDX eating CPU isn't intrinsically bad. Did you check where perf says the CPU time is going? Could be doing copies/etc. On Mon, Aug 17, 2020 at 12:52 AM Andrew Randrianasulu <randrianasulu at gmail.com> wrote: > > I was testing Ilia's patches for ddx, and while they definitely helped for Xorg itself, > qemu still eats a lot of CPU if launched like this > >

I was testing Ilia's patches for ddx, and while they definitely helped for Xorg itself, qemu still eats a lot of CPU if launched like this qemu-system-x86_64 -cdrom ~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 1G -display sdl,gl=on -enable-kvm and left for few hours. top - 07:38:01 up 18:05, 2 users, load average: 2,00, 1,89, 1,83 Tasks: 224 total, 3 running, 221 sleeping, 0

http://bugs.freedesktop.org/show_bug.cgi?id=23086 Summary: TNT2 doesn't start with current nouveau Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

Oops, completely forgot to link to the work_struct version of this patch: [1] https://gitlab.freedesktop.org/lyudess/linux/-/commit/f57886aebbd9631f1ee6e61b516bf73afbfe74f4 On Fri, 2020-03-27 at 16:29 -0400, Lyude Paul wrote: > Adding Tejun to this thread per-Daniel's suggestion on IRC. > > Hi Tejun! So, I don't know what your experience with modesetting related > stuff >

On Tue, Mar 17, 2020 at 08:40:58PM -0400, Lyude Paul wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Add some kind of vblank workers. The interface is similar to regular > delayed works, and also allows for re-scheduling. > > Whatever hardware programming we do in the work must be fast > (must at least complete during the vblank, sometimes during

VBLANK interrupts can be disabled immediately or with a delay, where the latter is the default. The former option can be selected by setting get_vblank_timestamp, and enabling vblank_disable_immediate in struct drm_device. The setup is only evaluated once when DRM initializes VBLANKs. Evaluating the settings on each use of vblank_disable_immediate will allow for easy integration of CRTC VBLANK

This fixes a deadlock inversion when vblank is enabled/disabled by drm. &dev->vblank_time_lock is always taken when the vblank state is toggled, which caused a deadlock when &event->lock was also taken during event_get/put. Solve the race by requiring that lock to change enable/disable state, and always keeping vblank on the event list. Core drm ignores unwanted vblanks, so extra

Mario Kleiner <mario.kleiner.de at gmail.com> writes: > With instantaneous high precision vblank timestamping > that updates at leading edge of vblank, the emulated > "hw vblank counter" from vblank timestamping which > increments at leading edge of vblank, and reliable > page flip execution and completion at leading edge > of vblank, we should meet the

Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 Author: Mario Kleiner <mario.kleiner.de at gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. Unfortunately that hack got uprooted in commit

On Fri, Jan 10, 2020 at 10:21:27AM +0100, Thomas Zimmermann wrote: > All non-legacy users of VBLANK functions in struct drm_driver have been > converted to use the respective interfaces in struct drm_crtc_funcs. The > remaining users of VBLANK callbacks in struct drm_driver are legacy drivers > with userspace modesetting. > > There are no users left of get_vblank_timestamp(), so

Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before the rework to event interface, so I guess it got reintroduced. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 7e3875d..35e526b 100644 ---

From: Daniel Vetter <daniel.vetter at ffwll.ch> Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 Author: Mario Kleiner <mario.kleiner.de at gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.

From: Daniel Vetter <daniel.vetter at ffwll.ch> Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 Author: Mario Kleiner <mario.kleiner.de at gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.

On Mon, Nov 02, 2015 at 04:45:00PM +0900, Michel Dänzer wrote: > On 31.10.2015 06:55, Daniel Vetter wrote: > > Apparently pre-nv50 pageflip events happen before the actual vblank > > period. Therefore that functionality got semi-disabled in > > > > commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 > > Author: Mario Kleiner <mario.kleiner.de at gmail.com> >

On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote: > The callback get_vblank_timestamp() is currently located in struct > drm_driver, but really belongs into struct drm_crtc_funcs. Add an > equivalent there. Driver will be converted in separate patches. > > The default implementation is drm_calc_vbltimestamp_from_scanoutpos(). > The patch adds

Mh ok, paper over in nouveau_display_fini until Ben comes up with a better idea then?! Greetings, Tobias On 7/20/17 10:13 AM, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: >> I believe the solution is to not call drm_crtc_vblank_off for atomic >> modesetting in nouveau_display_fini. I think Ben's working on it. > Yes, the goal of

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > mimic the behavior of vblank_disable_fn(), another caller of > drm_vblank_disable_and_save(). > > This avoids oopsing, while trying to