[Cin] CFLAGS (was: Re: Crash on playback)

Andrew Randrianasulu randrianasulu at gmail.com
Mon Jan 17 18:29:35 CET 2022


cflags I tried some time ago (on 32 bit build but with avx-enabled amd cpu
fx-4300, with gcc 5.5.0)

https://github.com/Randrianasulu/CinelerraGG-slackbuild/blob/master/cinelerra-goodguy.SlackBuild

"-O3 -ffast-math -mavx -march=native -mtune=native -fopenmp"

not much use for openmp, but if you want some experiments you can try to
put some #pragma omp simd" around hot source code blocks and see if it
helps...

On Monday, January 17, 2022, Andrew Randrianasulu <randrianasulu at gmail.com>
wrote:

>
>
> On Monday, January 17, 2022, Mark Goldberg via Cin <
> cin at lists.cinelerra-gg.org> wrote:
>
>>
>> On Mon, Jan 17, 2022, 3:32 AM mat <mnieuw at zap.a2000.nl> wrote:
>>
>>>
>>>
>>> @Mark, can you confirm vdpau works on your system, outside of CinGG?
>>> Does vdpauinfo say it is OK?
>>> Does "HW device" vdpau work in the compiled version without errors,
>>> apart from the crash?
>>>
>>
>> On RHEL8 the appimage for older distros is required as glibc is older. It
>> does not work with vdpau, falling back to software. In the locally compiled
>> version it does use vdpau, but I have 4k60 f-log videos, and adding the
>> lut3d plugin slows things down such that it cannot play in real time.
>>
>
>
> you can try to hack makefiles of individual plugins (while lut3d is
> ffmpeg's one, so not sure how to influence irs compile flags individually)
> with
>  -march=native, -mavx (if you have avx instructions in your cpu), and
> other suitable flags... CinGG for now mostly cpu/memory intensive, not
> using OpenCL/cuda (unlike big commercial editors?) so setting correct cpu
> flags may give relatively big boost.
>
>
>
>> @Andrew, I have compiled multiple times and changed versions of the
>> Nvidia driver, same crash.
>>
>
> from forum post I see case when gpu decoder utilization (as seen via
> nvidia's utility) still not 0%, so it works, but probably pulling and
> pushing frames between vram and ram via pci-e bus takes cpu, too (even if
> dma should do it for free?). I remember long time ago open-source radeon
> driver developers run into some underutilization of bus so they applied big
> expensive logic analyzer (at pcie speeds!) for finding some bottlenecks....
> so I am afraid without much better developers poking graphics stack while
> Cingg is running not much can be done.. :(
>
> @Andrea, for some reason I can't download attaches from forum (because I
> have no login there?), can you add CMS.txt as attachment to email (again)?
>
> I recall older version of Final Cut (before X) has ColorSync plugin
> (probably utilizing cpu at early 2000s), so may be making lcms2 plugin will
> provide some workaround for lack of core color management? (like, you
> switch slow colorcorrection plugin/effect for color work, turn it off for
> edits... those transforms using monitor's profile tend to be math heavy if
> executed on cpu only, even with simd... )
>
>>
>> @Andrea, I have seen the forum posting. There are issues with plugins
>> slowing things down, but I will start a second thread for that.
>>
>> Latest compile is the multibit version. It's more complicated. If there
>> is another video track on the timeline below what is playing, it does not
>> crash and plays successfully.
>>
>
> sorry, I can't test this due to lack of access to my main desktop... and
> laptops here only have vaapi (may be I can recompile x86_32 version of
> cingg... those are not *my* laptops, but I have live usb stick with
> slackware /copy of my home system from ~2020)
>
>>
>> Regards,
>>
>> Mark
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220117/cdd9cb07/attachment-0001.htm>


More information about the Cin mailing list