Re: Is "perfectly equal monitors" really required to reclock MCLK
On Fri, Jan 13, 2023 at 11:22 AM Christian König wrote: > Totally, as far as I know VRR is currently a complete show stopper for > reclocking the MCLK. > > But on the other hand VRR could potentially be used to artificially > create some overlapping VBLANK period to do the actually reclocking. > Interesting idea. > > We might want to ping Harry or somebody else form the DC team if they > have thought about that yet. Did you hear from them? I feel like I'm wasting a feature of my two screens by not using VRR. -- Braiam
Re: Is "perfectly equal monitors" really required to reclock MCLK
AMD RX 590. Forgot to include it. How do I know the blanking period? Would variable refresh rate mess up with that? On Fri, Jan 13, 2023 at 10:57 AM Alex Deucher wrote: > > On Fri, Jan 13, 2023 at 9:47 AM Braiam wrote: > > > > Hi, > > > > I have two monitors with the current following configuration: > > > > Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384 > > DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted > > right x axis y axis) 597mm x 336mm > >2560x1440164.83 + 59.95 + 120.05* 96.0172.0160.01 > > 143.97 120.0074.97 > > [snip] > > DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x > > axis y axis) 597mm x 336mm > >2560x1440165.00 + 59.95 + 120.06* 96.0472.0160.01 > > 50.0148.01 144.00 119.9999.99 > > [snip] > > HDMI-A-0 disconnected (normal left inverted right x axis y axis) > > HDMI-A-1 disconnected (normal left inverted right x axis y axis) > > DVI-D-0 disconnected (normal left inverted right x axis y axis) > > > > The pp_profile_mode: > > > > NUMMODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST > > SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL > > 0 BOOTUP_DEFAULT:--- > > --- > > 1 3D_FULL_SCREEN *:0 100 30 > > 10 60 25 > > 2 POWER_SAVING: 100 30 > > --- > > 3VIDEO:--- > > 10 16 31 > > 4 VR:0 11 50 > > 0 100 10 > > 5 COMPUTE:05 30 > > --- > > 6 CUSTOM:--- > > --- > > > > I have set their refresh rate to 72.01 which is a mode equal for both, > > and the MCLK wasn't downclocked either. They are branded HP and > > Scepter. Using a vtty doesn't help either. > > > > Is having the exact same monitor really required? If not, how can I > > check what is causing > > the memory clock to be pegged that high? > > It depends what GPU you have. Older ones can only reclock memory > during the vertical blanking period assuming it's long enough as the > whole reclocking process takes a certain amount of time. If it > doesn't happen during the blanking period you will get visible > glitches on the screen when the reclock happens. If the vertical > blanking period is not long enough or if the vblank periods are not > aligned when using multiple monitors, the driver doesn't reclock. The > mode lines (not just the refresh rate) have to be the exact same for > the vblanks to line up when using multiple monitors. Your best bet is > to take the mode line you want to use from one monitor and apply it to > the other monitor. Newer GPUs have more flexibility and can reclock > memory in more situations, but there are still some monitors where the > timing may not work out. > > What GPU do you have? > > Alex -- Braiam
Is "perfectly equal monitors" really required to reclock MCLK
Hi, I have two monitors with the current following configuration: Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384 DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440164.83 + 59.95 + 120.05* 96.0172.0160.01 143.97 120.0074.97 [snip] DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440165.00 + 59.95 + 120.06* 96.0472.0160.01 50.0148.01 144.00 119.9999.99 [snip] HDMI-A-0 disconnected (normal left inverted right x axis y axis) HDMI-A-1 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) The pp_profile_mode: NUMMODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL 0 BOOTUP_DEFAULT:--- --- 1 3D_FULL_SCREEN *:0 100 30 10 60 25 2 POWER_SAVING: 100 30 --- 3VIDEO:--- 10 16 31 4 VR:0 11 50 0 100 10 5 COMPUTE:05 30 --- 6 CUSTOM:--- --- I have set their refresh rate to 72.01 which is a mode equal for both, and the MCLK wasn't downclocked either. They are branded HP and Scepter. Using a vtty doesn't help either. Is having the exact same monitor really required? If not, how can I check what is causing the memory clock to be pegged that high? I'm using 6.0.0-6-amd64 from Debian testing. -- Braiam
Re: How to get useful information other than "the whole system locks up"?
Decided to simply contact the manufacturer and ask them for the latest vBIOS. Though it didn't crash the days before changing the bios, it hasn't crashed the days later. Plus points since opencl also seems to be working fine now, rather than making the card crash too (or refusing to work altogether). Seems that one of the things to take into account for crashing cards is if the bios is modified. -- Braiam ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: How to get useful information other than "the whole system locks up"?
On Sat, Apr 6, 2019 at 3:25 PM Braiam wrote: > > At this point I decided that the system isn't going to recover, so I > tried to soft-reboot it, but it only ended locked and had to hard > reboot. > > I've found this bug[1] that seems related, user watching videos. I > will try removing vaapi and check if that improves anything. > > [1]: https://bugs.freedesktop.org/show_bug.cgi?id=106547 > Removing libva didn't help. Lock ups still occur frequently. A new symptom is that video doesn't need to be visible on the display for the lockup to occur. -rc4 didn't improve the situation either. Lockups are still instantaneous, I haven't had another one where the gpu doesn't drag all the system. -- Braiam ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: How to get useful information other than "the whole system locks up"?
40 [135699.406170] INFO: task kworker/2:0:29950 blocked for more than 120 seconds. [135699.406171] Tainted: GW 5.1.0-rc3 #1 [135699.406173] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [135699.406174] kworker/2:0 D0 29950 2 0x8000 [135699.406179] Workqueue: events drm_sched_job_timedout [gpu_sched] [135699.406180] Call Trace: [135699.406183] ? __schedule+0x2d4/0x870 [135699.406185] schedule+0x28/0x70 [135699.406187] schedule_preempt_disabled+0xa/0x10 [135699.406190] __mutex_lock.isra.8+0x2d0/0x4a0 [135699.406277] amdgpu_device_lock_adev+0x15/0x37 [amdgpu] [135699.406364] amdgpu_device_gpu_recover+0x69/0x743 [amdgpu] [135699.406453] amdgpu_job_timedout+0xfc/0x120 [amdgpu] [135699.406457] drm_sched_job_timedout+0x39/0x60 [gpu_sched] [135699.406460] process_one_work+0x1a7/0x3b0 [135699.406463] worker_thread+0x30/0x390 [135699.406465] ? create_worker+0x1a0/0x1a0 [135699.406467] kthread+0x112/0x130 [135699.406468] ? __kthread_parkme+0x70/0x70 [135699.406471] ret_from_fork+0x22/0x40 At this point I decided that the system isn't going to recover, so I tried to soft-reboot it, but it only ended locked and had to hard reboot. I've found this bug[1] that seems related, user watching videos. I will try removing vaapi and check if that improves anything. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=106547 On Wed, Apr 3, 2019 at 6:38 PM Braiam wrote: > > On Wed, Apr 3, 2019 at 2:02 PM Alex Deucher wrote: > > > > On Wed, Apr 3, 2019 at 2:58 AM Braiam wrote: > > > > > > Hi, > > > > > > I have a Sapphire Technology Hawaii XT (R9 290X) using amdgpu driver > > > with kernel 5.1.0-rc3. > > > The issue happens with current 4.19.0 debian testing, 4.20-trunk, > > > 5.0.0-trunk and rc2 and 3. > > > > > > It usually happens when I'm reproducing video, but I haven't figured > > > out a way to reproduce it. It > > > happened once without reproducing. I'm aware that the support is > > > experimental, but radeon > > > driver doesn't seems capable of direct rendering on this card dropping > > > to llvmepipe. > > > > Radeon should work out of the box. Maybe something is messed up with > > your install? > > Doubtful, since I used 2200G without issues. Only change was using amdgpu > due games being particularly slow. > > > > > > > > > I had a ssh server installed in case I could log in while it crashes, > > > and the only relevant > > > line I found was: > > > > > > drm:amdgpu job timeout [amdgpu]] **ERROR** ring gfx timeout, signaled > > > seq=399919, emitted seq=399921 > > > > > > But that turned several bug reports which seems to have been fixed and > > > the context and symptoms are too different to mine. > > > > > > > You appear to be experiencing a GPU lockup. Unfortunately, there can > > be many things that cause it, so it really helps to have a good > > reproducer case. You might try a newer version of mesa or llvm. What > > does your "reproducing video" work flow use? What apps, APIs are > > involved? > > By "reproducing video" I mean watching videos from either Youtube/Netflix > with Firefox or mpv for local files. But note that I've experienced at > least one lock up > without any video on screen (I don't remember if there was something paused > on the background). > > Using mesa 18.3.4, and according to glxinfo DRM 3.30.0, LLVM 7.0.1. With > vulkan, vdpau and va drivers on the same version. I gave up and removed > any and every instance of the rocm package, since the module couldn't > compile on the kernel. > > Another detail about the lock up: the screen doesn't freeze but no > signal is emitted, > so my monitor goes to sleep. > > Upgraded to mesa 19.0.1 and llvm 8.0.0, although I didn't see anything > relevant on the > changelogs that could affect my experience. > > > > > > Alex > > > > > I have tried forcing the amdgpu xorg driver with same results (was > > > using radeon). > > > > > > -- > > > Braiam > > > ___ > > > amd-gfx mailing list > > > amd-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > -- > Braiam -- Braiam ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: How to get useful information other than "the whole system locks up"?
On Wed, Apr 3, 2019 at 2:02 PM Alex Deucher wrote: > > On Wed, Apr 3, 2019 at 2:58 AM Braiam wrote: > > > > Hi, > > > > I have a Sapphire Technology Hawaii XT (R9 290X) using amdgpu driver > > with kernel 5.1.0-rc3. > > The issue happens with current 4.19.0 debian testing, 4.20-trunk, > > 5.0.0-trunk and rc2 and 3. > > > > It usually happens when I'm reproducing video, but I haven't figured > > out a way to reproduce it. It > > happened once without reproducing. I'm aware that the support is > > experimental, but radeon > > driver doesn't seems capable of direct rendering on this card dropping > > to llvmepipe. > > Radeon should work out of the box. Maybe something is messed up with > your install? Doubtful, since I used 2200G without issues. Only change was using amdgpu due games being particularly slow. > > > > > I had a ssh server installed in case I could log in while it crashes, > > and the only relevant > > line I found was: > > > > drm:amdgpu job timeout [amdgpu]] **ERROR** ring gfx timeout, signaled > > seq=399919, emitted seq=399921 > > > > But that turned several bug reports which seems to have been fixed and > > the context and symptoms are too different to mine. > > > > You appear to be experiencing a GPU lockup. Unfortunately, there can > be many things that cause it, so it really helps to have a good > reproducer case. You might try a newer version of mesa or llvm. What > does your "reproducing video" work flow use? What apps, APIs are > involved? By "reproducing video" I mean watching videos from either Youtube/Netflix with Firefox or mpv for local files. But note that I've experienced at least one lock up without any video on screen (I don't remember if there was something paused on the background). Using mesa 18.3.4, and according to glxinfo DRM 3.30.0, LLVM 7.0.1. With vulkan, vdpau and va drivers on the same version. I gave up and removed any and every instance of the rocm package, since the module couldn't compile on the kernel. Another detail about the lock up: the screen doesn't freeze but no signal is emitted, so my monitor goes to sleep. Upgraded to mesa 19.0.1 and llvm 8.0.0, although I didn't see anything relevant on the changelogs that could affect my experience. > > Alex > > > I have tried forcing the amdgpu xorg driver with same results (was > > using radeon). > > > > -- > > Braiam > > ___ > > amd-gfx mailing list > > amd-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx -- Braiam ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
How to get useful information other than "the whole system locks up"?
Hi, I have a Sapphire Technology Hawaii XT (R9 290X) using amdgpu driver with kernel 5.1.0-rc3. The issue happens with current 4.19.0 debian testing, 4.20-trunk, 5.0.0-trunk and rc2 and 3. It usually happens when I'm reproducing video, but I haven't figured out a way to reproduce it. It happened once without reproducing. I'm aware that the support is experimental, but radeon driver doesn't seems capable of direct rendering on this card dropping to llvmepipe. I had a ssh server installed in case I could log in while it crashes, and the only relevant line I found was: drm:amdgpu job timeout [amdgpu]] **ERROR** ring gfx timeout, signaled seq=399919, emitted seq=399921 But that turned several bug reports which seems to have been fixed and the context and symptoms are too different to mine. I have tried forcing the amdgpu xorg driver with same results (was using radeon). -- Braiam ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
