https://bugzilla.kernel.org/show_bug.cgi?id=65761 Christoph Haag <haagch.christoph@xxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #115961|0 |1 is obsolete| | Attachment #119501|0 |1 is obsolete| | Attachment #119551|0 |1 is obsolete| | --- Comment #15 from Christoph Haag <haagch.christoph@xxxxxxxxxxxxxx> --- Created attachment 122811 --> https://bugzilla.kernel.org/attachment.cgi?id=122811&action=edit erratic dpm with window manager actions Okay, so we got 3.13 without crashes with default settings, so far so good, thanks so much. :) The dynpm power management is wonky. It doesn't really fit in here, but I already dumped a lot of stuff in here anyway and this report has been linked to in relation to me mentioning that the power management isn't working well yet, so here is another (not so) small point. Here is a screenshot from the tool radeon-profile. I believe over the whole period shown there I have not used the radeon GPU to render anything, but it is configured as offload slave. I also hope that this tool did not cause this behaviour, but from the fan noise I think it's happening without it too. So there are some random "short" spikes that die off after a while of doing nothing in X. However there are these longer spikes (about 5-7 seconds) when doing some window management actions. An example of that is minimizing/unminizing a window or simply changing the focus from one window to another window via the mouse. I have tested this with kwin with compositing and openbox without compositing and I think it's pretty clear that this actually causes it. Changing tabs in chromium also seems to cause it. The very quick spikes happened when I additionally ran glxgears with kwin (still everything on the Intel GPU). They died down but appeared sometimes again after doing something with the windows. With openbox on the other hand I don't see such quick spikes with glxgears. Another funny effect in openbox is that a single click on the "gears" in glxgears doesn't have an effect, but a double click produces one of the longer spikes. If I single click in chromium here in the bugtracker on the bakground or in the textarea it produces a spike too. But simply typing in the textarea does not. I don't really know what to make of those observations, but I would guess that the radeon gpu doesn't enter the dynoff state while X is running because of something related to this. A short google search didn't show anything new about radeonsi + dynoff, especially nobody who claims it's working, so maybe glamor is worth looking at? The intel gpu uses SNA and radeon obviously glamor. If the Xorg.0.log or so would be helpful, just ask. Maybe someone with a pre radeonsi gpu could test whether they have the same issue when using glamor over exa? -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
