Re: OT: cpu spiking
Hi, just for reference: Couldn't persuade the closed source driver to use vsync with the suggested methods (or setting vblank_mode=1), but removing the idle routine altogether and implementing redraw with either tick or timers got rid of the cpu load. Thanks a lot! Best, Orm Am Sonntag, den 29. Mai 2022 um 19:54:35 Uhr (-0500) schrieb Bart Botta: > It sounds like you are running without vsync on one of the drivers, > which means you are displaying frames as fast as you can. "As fast as > you can" usually means either "100% CPU" or "100% GPU" (sometimes > "100% RAM or bus bandwidth"). > > Check the settings for the driver to see if vsync has been forced to > off, or defaulting to off. > > I don't think there is an easy way to control vsync from glut (and > drivers can ignore what programs say anyway), but for a test you can > try something like: > > #+unix > (let ((p (glut:get-proc-address "glxSwapIntervalEXT"))) > (unless (cffi:null-pointer-p p) > (cffi:foreign-funcall-pointer p () :int 1 :int))) ;; 0 to > disable vsync, 2 to run at half monitor frame rate, etc > > in glut:display-window :before > > Note that just checking for a null pointer like that is wrong, and you > should be checking for the presence of the extension first, which > would require some more work with CFFI to get and parse the glx > extension string. > > For the case where you aren't drawing anything, I think 100% CPU is > expected. Per freeglut docs, the idle callback is "called continuously > from freeglut while no events are received", which sounds like it > would use 100% CPU. You might try using glut:tick instead (with > :tick-interval argument to window instance creation), as in the > shader-vao example, which runs on a timer instead of constantly. > > On Sun, May 29, 2022 at 1:46 PM Orm Finnendahl > wrote: > > > > Hi, > > > > I might have been a bit unprecise and I just found out it might be > > off topic for this list (see below): This is all related to my laptop > > running an AMD ryzen 7 integrated cpu/gpu on a linux arch system with > > latest sbcl/slime/emacs. > > > > Running (cl-glut-examples:gears) using the open source radeon driver, > > everything works as expected and the REPL reports a framerate of 60 > > fps. > > > > Using the closed source pro driver of amd, the framerate goes up to > > ca. 1000 fps and the cpu maxes out. Putting a timer in the display > > function (calling #'glut:post-redisplay), the framerate goes down, but > > the cpu is still above 100%. > > > > I just found out that this is also true for the glxgears program: > > running it with the open source driver give 60 fps, using it with the > > pro driver gives 12000 fps and the cpu maxes out. > > > > Even as this therefore seems to be more realted to the graphics driver > > than cl I'd still appreciate if anyone has an idea, how to deal with > > this... > > > > > > -- > > Orm > > > >
Re: OT: cpu spiking
It sounds like you are running without vsync on one of the drivers, which means you are displaying frames as fast as you can. "As fast as you can" usually means either "100% CPU" or "100% GPU" (sometimes "100% RAM or bus bandwidth"). Check the settings for the driver to see if vsync has been forced to off, or defaulting to off. I don't think there is an easy way to control vsync from glut (and drivers can ignore what programs say anyway), but for a test you can try something like: #+unix (let ((p (glut:get-proc-address "glxSwapIntervalEXT"))) (unless (cffi:null-pointer-p p) (cffi:foreign-funcall-pointer p () :int 1 :int))) ;; 0 to disable vsync, 2 to run at half monitor frame rate, etc in glut:display-window :before Note that just checking for a null pointer like that is wrong, and you should be checking for the presence of the extension first, which would require some more work with CFFI to get and parse the glx extension string. For the case where you aren't drawing anything, I think 100% CPU is expected. Per freeglut docs, the idle callback is "called continuously from freeglut while no events are received", which sounds like it would use 100% CPU. You might try using glut:tick instead (with :tick-interval argument to window instance creation), as in the shader-vao example, which runs on a timer instead of constantly. On Sun, May 29, 2022 at 1:46 PM Orm Finnendahl wrote: > > Hi, > > I might have been a bit unprecise and I just found out it might be > off topic for this list (see below): This is all related to my laptop > running an AMD ryzen 7 integrated cpu/gpu on a linux arch system with > latest sbcl/slime/emacs. > > Running (cl-glut-examples:gears) using the open source radeon driver, > everything works as expected and the REPL reports a framerate of 60 > fps. > > Using the closed source pro driver of amd, the framerate goes up to > ca. 1000 fps and the cpu maxes out. Putting a timer in the display > function (calling #'glut:post-redisplay), the framerate goes down, but > the cpu is still above 100%. > > I just found out that this is also true for the glxgears program: > running it with the open source driver give 60 fps, using it with the > pro driver gives 12000 fps and the cpu maxes out. > > Even as this therefore seems to be more realted to the graphics driver > than cl I'd still appreciate if anyone has an idea, how to deal with > this... > > > -- > Orm > >
OT: cpu spiking
Hi, I might have been a bit unprecise and I just found out it might be off topic for this list (see below): This is all related to my laptop running an AMD ryzen 7 integrated cpu/gpu on a linux arch system with latest sbcl/slime/emacs. Running (cl-glut-examples:gears) using the open source radeon driver, everything works as expected and the REPL reports a framerate of 60 fps. Using the closed source pro driver of amd, the framerate goes up to ca. 1000 fps and the cpu maxes out. Putting a timer in the display function (calling #'glut:post-redisplay), the framerate goes down, but the cpu is still above 100%. I just found out that this is also true for the glxgears program: running it with the open source driver give 60 fps, using it with the pro driver gives 12000 fps and the cpu maxes out. Even as this therefore seems to be more realted to the graphics driver than cl I'd still appreciate if anyone has an idea, how to deal with this... -- Orm
