Re: [Nouveau] qemu -display sdl,gl=on also eats CPU
В сообщении от Monday 17 August 2020 08:09:37 вы написали: > The DDX eating CPU isn't intrinsically bad. Did you check where perf > says the CPU time is going? Could be doing copies/etc. I think Xorg ended up eating ~13% CPU after I quit most programs, but it was definitely better than much higher CPU usage before your patches. I saw no additional debug messages in X log, so probably you covered my specific case well. qemu was eating CPU in nouveau_dri.so/libdrm_nouveau.so.2.0.0, so I suspected something like 'too many error reports from vblanks' may happen there, too. Unfortunately, my standard build command for mesa included --strip, so opreport -c was not giving any additional details ... I just recompiled DDX again with if 0'ed debug message, will see how it works alone, and then retry mesa build/qemu long-uptime testing ... > > On Mon, Aug 17, 2020 at 12:52 AM Andrew Randrianasulu > 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 > > > > 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 stopped, 0 zombie > > %Cpu(s): 40,6 us, 6,1 sy, 0,3 ni, 49,2 id, 0,8 wa, 0,0 hi, 2,9 si, > > 0,0 st > > MiB Mem : 11875,3 total, 3535,7 free, 3339,3 used, 5000,3 buff/cache > > MiB Swap: 1145,0 total, 1131,2 free, 13,8 used. 4874,7 avail Mem > > > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > > 6215 guest 20 0 1455160 951768 45560 R 99,3 7,8 710:44.44 > > qemu-system-x86 > > 12655 guest 20 0 2459848 1,5g 126708 R 59,1 12,6 217:53.21 > > seamonkey > > 1991 root 20 0 178112 109500 28840 S 20,9 0,9 187:20.05 Xorg > > 2068 guest 20 0 104932 51660 30764 S 5,6 0,4 54:08.99 > > ktorrent > > 6031 root 20 0 0 0 0 I 2,0 0,0 0:20.24 > > kworker/0:3-events > > 3697 guest 20 0 382432 20308 13696 S 1,7 0,2 91:38.13 xmms > > 2064 guest 20 0 55868 37048 23976 S 1,3 0,3 2:38.47 konsole > > 2319 guest 20 0 40160 21248 18548 S 1,3 0,2 12:36.63 gkrellm > > 5853 root 20 0 0 0 0 I 0,7 0,0 0:07.21 > > kworker/2:2-events > > > > opreport after operf --pid 6215 said: > > > > opreport > > Using /home/guest/botva/src/xf86-video-nouveau/oprofile_data/samples/ for > > samples directory. > > 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 10 > > CPU_CLK_UNHALT...| > > samples| %| > > -- > >260163 100.000 qemu-system-x86_64 > > CPU_CLK_UNHALT...| > > samples| %| > > -- > >144120 55.3960 nouveau_dri.so > > 87990 33.8211 libdrm_nouveau.so.2.0.0 > > 11783 4.5291 libpixman-1.so.0.38.0 > > 7884 3.0304 kallsyms > > 5310 2.0410 libc-2.30.so > > 689 0.2648 ld-2.30.so > > 519 0.1995 nouveau > > 501 0.1926 qemu-system-x86_64 > > 456 0.1753 ttm > > 239 0.0919 kvm > > 211 0.0811 kvm_amd > >81 0.0311 libpthread-2.30.so > >76 0.0292 drm > >49 0.0188 libSDL2-2.0.so.0.12.0 > >43 0.0165 libxcb.so.1.1.0 > >36 0.0138 libGL.so.1.2.0 > >31 0.0119 libX11.so.6.3.0 > >24 0.0092 snd_pcm > >23 0.0088 snd_hda_codec > >20 0.0077 libglib-2.0.so.0.5800.1 > >11 0.0042 snd_timer > > 9 0.0035 libglapi.so.0.0.0 > > 8 0.0031 libdrm.so.2.4.0 > > 7 0.0027 snd_aloop > > 7 0.0027 snd_hda_intel > > 7 0.0027 libxshmfence.so.1.0.0 > > 7 0.0027 libgcc_s.so.1 > > 5 0.0019 [vdso] (tgid:6215 range:0xf7f9f000-0xf7f9) > > 5 0.0019 snd_hda_core > > 4 0.0015 r8169 > > 3 0.0012 libahci > > 2 7.7e-04 ohci_hcd > > 2 7.7e-04 libxcb-present.so.0.0.0 > > 1 3.8e-04 libatomic.so.1.1.0 > > > > so, may be similar fix needed for mesa, too? > > > > ow, I started it in ddx src directory :} need to cleanup there. But at > > least data is 100 > > > > ___ > > Nouveau mailing list > > Nouveau@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/nouveau > ___ Nouveau mailing list Nouveau@lists.freedesktop.org
Re: [Nouveau] qemu -display sdl,gl=on also eats CPU
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 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 > > 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 stopped, 0 zombie > %Cpu(s): 40,6 us, 6,1 sy, 0,3 ni, 49,2 id, 0,8 wa, 0,0 hi, 2,9 si, 0,0 > st > MiB Mem : 11875,3 total, 3535,7 free, 3339,3 used, 5000,3 buff/cache > MiB Swap: 1145,0 total, 1131,2 free, 13,8 used. 4874,7 avail Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 6215 guest 20 0 1455160 951768 45560 R 99,3 7,8 710:44.44 > qemu-system-x86 > 12655 guest 20 0 2459848 1,5g 126708 R 59,1 12,6 217:53.21 seamonkey > 1991 root 20 0 178112 109500 28840 S 20,9 0,9 187:20.05 Xorg > 2068 guest 20 0 104932 51660 30764 S 5,6 0,4 54:08.99 ktorrent > 6031 root 20 0 0 0 0 I 2,0 0,0 0:20.24 > kworker/0:3-events > 3697 guest 20 0 382432 20308 13696 S 1,7 0,2 91:38.13 xmms > 2064 guest 20 0 55868 37048 23976 S 1,3 0,3 2:38.47 konsole > 2319 guest 20 0 40160 21248 18548 S 1,3 0,2 12:36.63 gkrellm > 5853 root 20 0 0 0 0 I 0,7 0,0 0:07.21 > kworker/2:2-events > > opreport after operf --pid 6215 said: > > opreport > Using /home/guest/botva/src/xf86-video-nouveau/oprofile_data/samples/ for > samples directory. > 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 10 > CPU_CLK_UNHALT...| > samples| %| > -- >260163 100.000 qemu-system-x86_64 > CPU_CLK_UNHALT...| > samples| %| > -- >144120 55.3960 nouveau_dri.so > 87990 33.8211 libdrm_nouveau.so.2.0.0 > 11783 4.5291 libpixman-1.so.0.38.0 > 7884 3.0304 kallsyms > 5310 2.0410 libc-2.30.so > 689 0.2648 ld-2.30.so > 519 0.1995 nouveau > 501 0.1926 qemu-system-x86_64 > 456 0.1753 ttm > 239 0.0919 kvm > 211 0.0811 kvm_amd >81 0.0311 libpthread-2.30.so >76 0.0292 drm >49 0.0188 libSDL2-2.0.so.0.12.0 >43 0.0165 libxcb.so.1.1.0 >36 0.0138 libGL.so.1.2.0 >31 0.0119 libX11.so.6.3.0 >24 0.0092 snd_pcm >23 0.0088 snd_hda_codec >20 0.0077 libglib-2.0.so.0.5800.1 >11 0.0042 snd_timer > 9 0.0035 libglapi.so.0.0.0 > 8 0.0031 libdrm.so.2.4.0 > 7 0.0027 snd_aloop > 7 0.0027 snd_hda_intel > 7 0.0027 libxshmfence.so.1.0.0 > 7 0.0027 libgcc_s.so.1 > 5 0.0019 [vdso] (tgid:6215 range:0xf7f9f000-0xf7f9) > 5 0.0019 snd_hda_core > 4 0.0015 r8169 > 3 0.0012 libahci > 2 7.7e-04 ohci_hcd > 2 7.7e-04 libxcb-present.so.0.0.0 > 1 3.8e-04 libatomic.so.1.1.0 > > so, may be similar fix needed for mesa, too? > > ow, I started it in ddx src directory :} need to cleanup there. But at least > data is 100 > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] qemu -display sdl,gl=on also eats CPU
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 stopped, 0 zombie %Cpu(s): 40,6 us, 6,1 sy, 0,3 ni, 49,2 id, 0,8 wa, 0,0 hi, 2,9 si, 0,0 st MiB Mem : 11875,3 total, 3535,7 free, 3339,3 used, 5000,3 buff/cache MiB Swap: 1145,0 total, 1131,2 free, 13,8 used. 4874,7 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 6215 guest 20 0 1455160 951768 45560 R 99,3 7,8 710:44.44 qemu-system-x86 12655 guest 20 0 2459848 1,5g 126708 R 59,1 12,6 217:53.21 seamonkey 1991 root 20 0 178112 109500 28840 S 20,9 0,9 187:20.05 Xorg 2068 guest 20 0 104932 51660 30764 S 5,6 0,4 54:08.99 ktorrent 6031 root 20 0 0 0 0 I 2,0 0,0 0:20.24 kworker/0:3-events 3697 guest 20 0 382432 20308 13696 S 1,7 0,2 91:38.13 xmms 2064 guest 20 0 55868 37048 23976 S 1,3 0,3 2:38.47 konsole 2319 guest 20 0 40160 21248 18548 S 1,3 0,2 12:36.63 gkrellm 5853 root 20 0 0 0 0 I 0,7 0,0 0:07.21 kworker/2:2-events opreport after operf --pid 6215 said: opreport Using /home/guest/botva/src/xf86-video-nouveau/oprofile_data/samples/ for samples directory. 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 10 CPU_CLK_UNHALT...| samples| %| -- 260163 100.000 qemu-system-x86_64 CPU_CLK_UNHALT...| samples| %| -- 144120 55.3960 nouveau_dri.so 87990 33.8211 libdrm_nouveau.so.2.0.0 11783 4.5291 libpixman-1.so.0.38.0 7884 3.0304 kallsyms 5310 2.0410 libc-2.30.so 689 0.2648 ld-2.30.so 519 0.1995 nouveau 501 0.1926 qemu-system-x86_64 456 0.1753 ttm 239 0.0919 kvm 211 0.0811 kvm_amd 81 0.0311 libpthread-2.30.so 76 0.0292 drm 49 0.0188 libSDL2-2.0.so.0.12.0 43 0.0165 libxcb.so.1.1.0 36 0.0138 libGL.so.1.2.0 31 0.0119 libX11.so.6.3.0 24 0.0092 snd_pcm 23 0.0088 snd_hda_codec 20 0.0077 libglib-2.0.so.0.5800.1 11 0.0042 snd_timer 9 0.0035 libglapi.so.0.0.0 8 0.0031 libdrm.so.2.4.0 7 0.0027 snd_aloop 7 0.0027 snd_hda_intel 7 0.0027 libxshmfence.so.1.0.0 7 0.0027 libgcc_s.so.1 5 0.0019 [vdso] (tgid:6215 range:0xf7f9f000-0xf7f9) 5 0.0019 snd_hda_core 4 0.0015 r8169 3 0.0012 libahci 2 7.7e-04 ohci_hcd 2 7.7e-04 libxcb-present.so.0.0.0 1 3.8e-04 libatomic.so.1.1.0 so, may be similar fix needed for mesa, too? ow, I started it in ddx src directory :} need to cleanup there. But at least data is 100 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drivers/nouveau_svm: fix bounds check in nouveau_svm_fault_buffer_dtor
do the bounds check before accessing the buffer element.
Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual
memory")
Signed-off-by: Gaurav Singh
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 6586d9d39874..35d24946787d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -897,7 +897,7 @@ nouveau_svm_fault_buffer_dtor(struct nouveau_svm *svm, int
id)
int i;
if (buffer->fault) {
- for (i = 0; buffer->fault[i] && i < buffer->entries; i++)
+ for (i = 0; i < buffer->entries && buffer->fault[i]; i++)
kfree(buffer->fault[i]);
kvfree(buffer->fault);
}
--
2.17.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Accumulating CPU load from Xorg process with DRI3
On Sun, Aug 16, 2020 at 8:20 AM Andrew Randrianasulu wrote: > > В сообщении от Sunday 16 August 2020 07:20:18 Ilia Mirkin написал(а): > > Well, if it's easy, try the patches I mailed to nouveau@ for the ddx. > > I applied patches manually (copy-pasted patches failed to apply by git apply, > probably whitespace/end of line issues), and now I see in X log (after I left > machine to run alone): > > [ 3584.553] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.553] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.570] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.586] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.602] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.619] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.635] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.651] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.668] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.684] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.700] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.717] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.733] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.749] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.766] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.782] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument > [ 3584.798] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid > argument Aha, appears my assumption that X_DEBUG would get skipped under normal Xorg invocations was wrong. I didn't mean for these to appear under normal circumstances. I guess I'll #if 0 it out. > > and around 6mb more of those > > but X still uses small amount of CPU: > > op - 15:04:41 up 1:32, 2 users, load average: 1,25, 1,67, 1,60 > Tasks: 220 total, 2 running, 218 sleeping, 0 stopped, 0 zombie > %Cpu(s): 22,8 us, 5,9 sy, 0,3 ni, 69,2 id, 1,4 wa, 0,0 hi, 0,4 si, 0,0 > st > MiB Mem : 11875,3 total, 7630,1 free, 1967,5 used, 2277,7 buff/cache > MiB Swap: 1145,0 total, 1145,0 free, 0,0 used. 9172,1 avail Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 2777 guest 20 0 2155076 1,2g 126108 R 84,4 10,7 69:24.46 seamonkey > 1991 root 20 0 145764 78444 27936 S 14,6 0,6 6:42.10 Xorg > 3697 guest 20 0 61208 17268 13580 S 12,6 0,1 7:34.75 xmms > 2045 guest 20 06360 3932 2668 S 2,3 0,0 0:35.90 kompmgr > 2068 guest 20 0 102664 48952 30764 S 2,3 0,4 2:35.98 ktorrent > 2049 guest 20 0 42792 27908 23684 S 1,7 0,2 0:12.72 kicker > 2319 guest 20 0 40160 21248 18548 S 1,3 0,2 0:55.63 gkrellm > 2064 guest 20 0 50900 31592 23720 S 1,0 0,3 0:25.53 konsole > 5086 root 20 0 0 0 0 I 0,7 0,0 0:02.57 > kworker/0:2-events >10 root 20 0 0 0 0 I 0,3 0,0 0:09.96 > rcu_preempt > 1918 root 20 0 0 0 0 I 0,3 0,0 0:04.78 > kworker/3:0-events > 2240 guest 20 0 59660 37848 30248 S 0,3 0,3 0:02.36 konqueror > 2389 guest 20 0 33048 22592 20376 S 0,3 0,2 0:00.24 kdesu > > with CPU frequency set to 1.4Ghz (minimum possible). Usually around 5.6%-6.0% > vblanks still work, at least glxgears from both cards still run at ~60 fps by > default > > I'll run with those patches for few more hours, but so far they seems to be > helpful. Great! -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Accumulating CPU load from Xorg process with DRI3
В сообщении от Sunday 16 August 2020 07:20:18 Ilia Mirkin написал(а): > Well, if it's easy, try the patches I mailed to nouveau@ for the ddx. I applied patches manually (copy-pasted patches failed to apply by git apply, probably whitespace/end of line issues), and now I see in X log (after I left machine to run alone): [ 3584.553] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.553] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.570] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.586] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.602] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.619] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.635] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.651] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.668] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.684] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.700] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.717] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.733] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.749] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.766] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.782] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument [ 3584.798] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid argument and around 6mb more of those but X still uses small amount of CPU: op - 15:04:41 up 1:32, 2 users, load average: 1,25, 1,67, 1,60 Tasks: 220 total, 2 running, 218 sleeping, 0 stopped, 0 zombie %Cpu(s): 22,8 us, 5,9 sy, 0,3 ni, 69,2 id, 1,4 wa, 0,0 hi, 0,4 si, 0,0 st MiB Mem : 11875,3 total, 7630,1 free, 1967,5 used, 2277,7 buff/cache MiB Swap: 1145,0 total, 1145,0 free, 0,0 used. 9172,1 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 2777 guest 20 0 2155076 1,2g 126108 R 84,4 10,7 69:24.46 seamonkey 1991 root 20 0 145764 78444 27936 S 14,6 0,6 6:42.10 Xorg 3697 guest 20 0 61208 17268 13580 S 12,6 0,1 7:34.75 xmms 2045 guest 20 06360 3932 2668 S 2,3 0,0 0:35.90 kompmgr 2068 guest 20 0 102664 48952 30764 S 2,3 0,4 2:35.98 ktorrent 2049 guest 20 0 42792 27908 23684 S 1,7 0,2 0:12.72 kicker 2319 guest 20 0 40160 21248 18548 S 1,3 0,2 0:55.63 gkrellm 2064 guest 20 0 50900 31592 23720 S 1,0 0,3 0:25.53 konsole 5086 root 20 0 0 0 0 I 0,7 0,0 0:02.57 kworker/0:2-events 10 root 20 0 0 0 0 I 0,3 0,0 0:09.96 rcu_preempt 1918 root 20 0 0 0 0 I 0,3 0,0 0:04.78 kworker/3:0-events 2240 guest 20 0 59660 37848 30248 S 0,3 0,3 0:02.36 konqueror 2389 guest 20 0 33048 22592 20376 S 0,3 0,2 0:00.24 kdesu with CPU frequency set to 1.4Ghz (minimum possible). Usually around 5.6%-6.0% vblanks still work, at least glxgears from both cards still run at ~60 fps by default I'll run with those patches for few more hours, but so far they seems to be helpful. > > On Sun, Aug 16, 2020 at 12:06 AM Andrew Randrianasulu > wrote: > > > > В сообщении от Sunday 16 August 2020 05:49:19 вы написали: > > > I've tracked down at least one source of these, which is that we don't > > > handle drmWaitVBlank errors properly in the PRESENT logic (which would > > > be used in conjunction with DRI3). These errors, broadly, will happen > > > while strings are turned off and/or in DPMS sleep. Did your monitors > > > go to sleep while a video was playing? If not, there's another path > > > for it to happen... > > > > yes, X enters dpms OFF state automatically, and sometimes I even force it > > manually > > > > xset q > > Keyboard Control: > > auto repeat: onkey click percent: 0LED mask: > > auto repeat delay: 660repeat rate: 25 > > auto repeating keys: 00ffdbbf > > fadfffefffed > > 9fff > > fff7 > > bell percent: 50bell pitch: 400bell duration: 100 > > Pointer Control: > > acceleration: 20/10threshold: 4 > > Screen Saver: > > prefer blanking: yesallow exposures: no > > timeout: 0cycle: 600 > > Colors: > > default colormap: 0x65BlackPixel: 0WhitePixel: 16777215 > > Font Path: > > > >
