+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
+---- Thread: Near 100% CPU in fullscreen (/showthread.php?tid=32159)
- phunqe - 2008-07-27
I'm having the same thing now. 100% CPU, nothing suggested in this thread is working.
nVidia 8600GT SVN 14506 Ubuntu 8.04.
- pike - 2008-07-27
it's a brand new issue, we suspect it might be related to http://trac.xbmc.org/changeset/14430
- snappz - 2008-07-27
I'm using nvidia 7150 and have not had a problem with HD content before, but am now experiencing 100% usage on 1 core (dual core), but only when I have my screen Res set to 1920x1080(full screen)
If I leave it set to Auto and launch XBMC in a window and make it full screen with \ it works fine.
I only noticed this yesterday when I got a 1080p HDMI lcd. Never noticed it when using a 1368x768 lcd via dvi.
When this happens even navigation is dropping frames.
- nurgle - 2008-07-27
pike Wrote:it's a brand new issue, we suspect it might be related to http://trac.xbmc.org/changeset/14430
I can confirm this. After reverting this change and recompiling, CPU usage is again minimal in full screen.
- phunqe - 2008-07-27
Alright, cool. I'l reverting as we speak as well.
I hope you can find the reason for those needing the change
- ovyg - 2008-07-27
I've tried reverting the change, but it doesn't work for me on the ATI card -- still 100% CPU.
Instead, see this patch: http://trac.xbmc.org/ticket/4382 , which I think is the proper solution for drivers with this behaviour.
I've also opened a bug against the ATI driver, as promised: http://ati.cchtml.com/show_bug.cgi?id=1223
- althekiller - 2008-07-28
The problem was introduced when elupus fixed the tearing issue on intel gfx. The change only seemed to cause problems for nvidia users and is now only enable if intel gfx are detected.
- ubikdood - 2008-07-28
ARGH. I also have 100% cpu when xbmc is idle. (nvidia GeForce 7600 GS)
I'm using r14529.
If I revert guilib/Surface.cpp back to 14120, the problem goes away.
Code:
14:24:33 T:3061086048 M:208191488 INFO: GL_VENDOR = NVIDIA Corporation
14:24:33 T:3061086048 M:208064512 INFO: GL_RENDERER = GeForce 7600 GS/AGP/SSE2/3DNOW!
14:24:33 T:3061086048 M:208064512 INFO: GL_VERSION = 2.1.1 NVIDIA 100.14.19- elupus - 2008-07-28
ubikdood:
give me a full debug log on pastebin or similar
- elupus - 2008-07-28
For those of you that have this 100% cpu usage bug. What are your driconf settings set to? now i don't know if the ATI/NVIDIA respect that, but one can always hope.
- tsint - 2008-07-28
Code:
fredrik@htpc:~$ driconf
libGL is too old.?
Standard 8.04, 8600GT and SVN 14513
- ubikdood - 2008-07-28
elupus Wrote:ubikdood:
give me a full debug log on pastebin or similar
Oh, boy... After retesting both scenarios :
14529 + 14120 Surface.cpp
14529 + 14514 Surface.cpp
Now they both yield low cpu usages (!).
I don't get it. Yesterday I rebuilt everything several times, with different versions. They all had 100% cpu.
Today, after running xbmc once with 14120 Surface.cpp, the problem just went away (14120 or 14514 Surface.cpp).
The testing process involved restarting X and reloading nvidia's binary driver.
Can't help you further. I apologize for any confusion. What a mess...
- Gaarv - 2008-07-29
ovyg Wrote:I've tried reverting the change, but it doesn't work for me on the ATI card -- still 100% CPU.
Instead, see this patch: http://trac.xbmc.org/ticket/4382 , which I think is the proper solution for drivers with this behaviour.
I've also opened a bug against the ATI driver, as promised: http://ati.cchtml.com/show_bug.cgi?id=1223
Sorry, didnt had the time to test it earlier... I reverted to 14484 and applied the patch, gave the env variable that suited for me (60) and run Xbmc.
Indeed, the cpu is then down to 3-5% but all the load is now on the Xorg process
Nothing noticeable on use but still the kinda same issue.Did you noticed that too ovyg ?
- ovyg - 2008-07-29
Hi Gaarv,
Xorg does not take CPU for me at all. Here's the thing: your earlier log suggests that the magic value for you is 20, not 60. Namely, 1000/50 -- I noticed delays of 50 ms between all your buffer swaps. Can you try that?
We were having this exact discussion on the trac, whether we should always set the value to the refresh rate, or it should sometimes be different, based on your example.
Can you also try this command:
%__GL_SYNC_TO_VBLANK=1 glxgears
304 frames in 5.0 seconds = 60.600 FPS
....
and report the FPS value in your case?
- Gaarv - 2008-07-29
Im using proprietary drivers from ATI (8.6). Reporting :
Code:
$ __GL_SYNC_TO_VBLANK=1 glxgears
305 frames in 5.0 seconds = 60.862 FPS
300 frames in 5.0 seconds = 59.995 FPS
300 frames in 5.0 seconds = 59.995 FPS
$ __GL_SYNC_TO_VBLANK=1 fgl_glxgears
Using GLX_SGIX_pbuffer
292 frames in 5.0 seconds = 58.400 FPS
300 frames in 5.0 seconds = 60.000 FPS
300 frames in 5.0 seconds = 60.000 FPS
$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: ATI Radeon HD 3200 GraphicsI understood from the comments that the XBMC_VSYNC_WORKAROUND_HZ value should be the same as the active refresh rate, maybe I was wrong ? I will try with 20.
Code:
$xrandr -q --verbose
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 (0x91) normal (normal) 0mm x 0mm
Identifier: 0x90
Timestamp: 20412
Subpixel: horizontal rgb
Clones:
CRTC: 0
CRTCs: 0
1920x1080 (0x91) 124.4MHz
h: width 1920 start 0 end 0 total 1920 skew 0 clock 64.8KHz
v: height 1080 start 0 end 0 total 1080 clock 60.0Hz