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 > <orm.finnend...@selma.hfmdk-frankfurt.de> 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 > > > >
