В сообщении от Thursday 21 May 2020 17:12:21 Phyllis Smith написал(а):
Andrew, BUT I should have mentioned that there is a problem if the Settings->Preferences, Playback A, Video Driver is set to X11-OpenGL. There appears to be some thrashing. I have logged this in BT #434 and am hoping a Graphics guru can give us a hint of how to avoid this. Using X11 driver works at really good hardware speed. GG was looking at MPV to try to avoid this because according to the Forum topic "Multiple GPUs..." it works just fine there, as well as on the ffmpeg command line. I searched on the internet and found no clues. We are hoping there is some GL command to avoid the problem but we are not even close to GL experts.
Well, I remember Cin works with Pbuffers, and those may be implemented not very optimally (at least in opensource drivers). I'm not sure if compositing done to specialized pixel buffer, and then displayed with double-buffering (or just pointer dance/pageflipping around 2x sized buffer), or Cin tries to composite directly to front buffer? (with X compositing it will be not real front buffer anyway...) May be having small 'pool' of those pixel buffers will avoid stalls in decode->effects-> composite pipeline ... If you use mesa you can try to call GALLIUM_HUD=help cin and then add relevant for your GPU meters to Gallium HUD Available names: fps frametime cpu cpu0 cpu1 cpu2 cpu3 samples-passed primitives-generated ia-vertices ia-primitives vs-invocations gs-invocations gs-primitives clipper-invocations clipper-primitives-generated ps-invocations hs-invocations ds-invocations cs-invocations [..] GALLIUM_HUD=fps,frametime,cpu,instructions,samples-passed cin for example So, it will look like attached screenshot Try to avoid readbacks, like glReadPixels - they tend to be slow even for PCI-E attached GPU ... May be play with different pixelfformats (RGBA vs ARGB), some of them might be faster, or situation might change from times when this code was first implemented ....
On Thu, May 21, 2020 at 7:25 AM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Thursday 21 May 2020 16:18:49 Phyllis Smith написал(а):
Andrew:
Is there anything relevant for Cin's internal working (in case when hw decoder is used)?
Quoting GG this morning: "Not especially. It appears as a normal codec. But the data path is through the hardware."
Ah, ok (I thought may be libavcodec was picking slow path in this case)
Have good morning/day! -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
