https://bugs.freedesktop.org/show_bug.cgi?id=97260
--- Comment #20 from Kai <kai at dev.carbon-project.org> --- Created attachment 125820 --> https://bugs.freedesktop.org/attachment.cgi?id=125820&action=edit dmesg output with additional debug info from attachment 125808 (In reply to Alex Deucher from comment #16) > Does just reverting this chunk fix the issue? > > @@ -1630,6 +1631,9 @@ int radeon_modeset_init(struct radeon_device *rdev) > > rdev->ddev->mode_config.funcs = &radeon_mode_funcs; > > + if (radeon_use_pflipirq == 2 && rdev->family >= CHIP_R600) > + rdev->ddev->mode_config.async_page_flip = true; > + > if (ASIC_IS_DCE5(rdev)) { > rdev->ddev->mode_config.max_width = 16384; > rdev->ddev->mode_config.max_height = 16384; Yes, just removing the default enable here has the same effect as reverting the entire patch. (In reply to Michel Dänzer from comment #18) > Created attachment 125808 > radeon: Add some page flip debugging output > > Well, that's a surprising result of the bisection. > > I can imagine two possible causes, or possibly some combination thereof: > > * The processing of asynchronous flips or the corresponding completion > interrupts > is delayed for some reason > * Using flips instead of blits for buffer swaps lowers the load on the GPU 3D > engine, so the SMU doesn't switch to higher clocks > > The attached debugging patch should give us more information about the > former. With it applied, run the following while an affected application is > running in fullscreen: > > sudo sh -c 'echo 2 >/sys/module/drm/parameters/debug'; sleep 1; sudo sh -c > 'echo 0 >/sys/module/drm/parameters/debug' > > Then attach the resulting dmesg output. Here you go. That was generated by running XCOM 2. > BTW, does the problem still happen with Alex's current drm-next-4.9-wip > branch? Haven't tested that yet. Maybe somebody else can do that. ;-) (In reply to Michel Dänzer from comment #19) > BTW, there are some potential workarounds: > > * Disable DRI3 for affected games with the environment variable > LIBGL_DRI3_DISABLE=1 > > * Enable sync-to-vblank in affected applications, or force it with > vblank_mode=3 Well, this is going to be odd: I had VSync enabled in XCOM, since without that option I got poorer performance in the past than with it. Now, after your note here I actually *disabled* the VSync option in the game. 4.6.4 (or 4.7.0 without the offending commit/the enable removed) shows no longer a performance difference and I'm getting ~30 FPS in XCOM 2. BUT with your ASYNC patch (vanilla 4.7.0) and VSync turned of in the game gives me ALSO ~30 FPS! I'd still say this is a regression as there is no difference without your patch, but maybe this information can help you in narrowing down the cause? I hope I haven't missed any open question. Let me know if you need anything else. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160816/d6e250f6/attachment.html>
