renderer: store used buffers per monitor #11454
Conversation
There was a problem hiding this comment.
yes, but we need a cross-monitor solution too...
I propose to make a manager like CBufferReleaseManager that has:
::add(surf, mon)::drop(mon)
Each surface stored gets a state with a std::vector<PHLMONITORREF> and it gets dropped once that vec has either 0 elements or all elements are null or disabled (in case of a monitor disconnect)
can be a way to deal with surfaces showing on more then one monitor yes, should buffers even be dropped if the rendermode isnt RENDER_MODE_NORMAL? |
uhh... in general no, but there is toplevel export, which doesn't use NORMAL, and should drop to avoid the window going stale... It already uses a flag there blockSurfaceFeedback iirc, you could use that. If the feedback isnt blocked, add it to be dropped |
|
@vaxerski did some pseudo thing here. it breaks DS here but rest seems fine. and im a bit unsure if on that visible check and also the CHLBufferReference implentation, is it like a shared pointer or do the monitors just end up with 2 different local ones so the syncreleasers are seperate and doesnt actually merge the fences of both, but just keeps them seperate one per monitor. but this is in general is the idea that should probably be done. to get buffer releases somewhat right. new_render_shed i got no clue if it broke even further. it already was here heh |
|
@vaxerski ok got buffer releases working without breaking DS or OBS now. i still dont know how to proceed with new_render_shed tho since its all sorts of wonky even before |
|
@Zebra2711 wanna test this now? i still have to figure out if there can be something done on laptops tho, seems now its blitting a lot more making it actually slower on new_render_shed when having dualgpu/external monitor tho |
|
@outfoxxed seeing you had various stall/lag issues would be neat if you could test aswell. what i do know is DS might require some finicking now that commitpendinganddoexplicit is called on new_render_scheduling while it isnt on setting it false. |
It hit my performance so hard, my hyprland on the iGPU couldn't get more than 60 fps with or without |
Lol wat in what? I finally got overlay showing 240 + 160 here and cs2 200+ on external |
unless ofc you just measured something that is vsynced, glxgears is normally. i dont think it has been correct before. hyprland pushes like 100fps if i crunch hard on the gpu before glxgears would still report 240., well if we are pageflipping at 100fps we cant exactly render glxgears at 240. |
yeah because its kinda cheating, two monitors? if so if any monitor pageflips its dropping the buffer no matter if the second monitor is still rendering it. only reason it didnt artifact or break is because clients mostly double or more buffer. so they begin working on another and once they reuse the dropped one if they do. its work is done luckily enough. i mean turn on debug:overlay = true, and see the fps. the overlay comes with its own cost so it drops a bit too but. and then run glxgears, if it isnt matching something is very off in my mind |
|
new_render_sched also hits the blitting harder in AQ if this is a dual gpu thing. and its very slow sadly, needs some work. |
what setup is it, dual gpu? dual monitors? |
did a thing, hope its moving in the right direction. but havent tested all cases since im on my laptop atm, or well with my laptop away from my desk. |
|
i think the main cause of the lag here is that hyprland is using more gpu than it normally would. Lag is reduced compared to the old version, but not much. I still feel laggy with this. Could be that my config is messing with this. I will test it out with the default config tomorrow Out of the scope of this, when I resize a window or move my mouse, the igpu usage just jumps up |
I can try to test it soon |
still think new_render_sched is borked tho still not satisfied with that |
gulafaran
force-pushed
the
eglsyncmon
branch
from
80c8e7b to
de8b43d
Compare
gulafaran
force-pushed
the
eglsyncmon
branch
from
eb373dd to
2e4fbb6
Compare
gulafaran
force-pushed
the
eglsyncmon
branch
2 times, most recently
from
8bcce63 to
da2980c
Compare
instead of storing used async bufs in the renderer and dropping them on the first monitor pageflip, store them per monitor and schedule drop on the proper fence in the new CBufferReleaseManager.
make new_render_scheduler not drop buffers to early when third frame is pending, by adding a parameter to commitPendingAndDoExplicitSync when to drop buffers. also reuse monitor inFence to reduce flushing.
remove copy paste return early from debugging.
if the buffer gets locked to another monitor add the intersecting region to monitor damage and schedule a frame.
if we have pending scanout a frame might be waiting on the sync and racing the buffer drops from said commit. try to avoid that from occuring.
move BufferReleaseManager to SurfaceManager and schedule frame callbacks and send them on presented and ahead of third monitor rendering in new frame sheduler.
remove monitor from scheduled frames on destroy.
schedule all frames instead of directly sending them.
gulafaran
force-pushed
the
eglsyncmon
branch
from
989b97b to
c5fed0f
Compare
4 participants
instead of storing used async bufs in the renderer and dropping them on the first monitor pageflip, store them per monitor and drop on the monitors pageflip.
problem before was the first monitor could be dropping the second monitors surfaces before it had even rendered them causing glitches. especially noticeable on dual gpu laptop and external monitor.
move surface frames to CSurfaceManager aswell and schedule them for scanout, and make third pending frame call it aswell in new_render_scheduling.
#TODO
fixes: #12181
maybe: #10979