| Message ID | 20210210171650.3656817-1-ccom@randomderp.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [FFmpeg-devel] libsvtav1: Add logical_processors option | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
On 10/02/2021 17:16, Christopher Degawa wrote: > From: Christopher Degawa <christopher.degawa@intel.com> > > Equivalent to the --lp option for SvtAv1EncApp, and is the only way > to control how much cpu power svt-av1 uses for now > > Not using thread_count as it would be preferable to reserve that until > svt-av1 properly implements a threads option Then what does it actually do? The description below about the number of logical threads to run sounds pretty much exactly like what the threads option does. > 0 == getconf _NPROCESSORS_ONLN > > Signed-off-by: Christopher Degawa <christopher.degawa@intel.com> > --- > libavcodec/libsvtav1.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c > index eb6043bcac..2296735f25 100644 > --- a/libavcodec/libsvtav1.c > +++ b/libavcodec/libsvtav1.c > @@ -71,6 +71,8 @@ typedef struct SvtContext { > > int tile_columns; > int tile_rows; > + > + unsigned logical_processors; > } SvtContext; > > static const struct { > @@ -218,6 +220,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration *param, > param->tile_columns = svt_enc->tile_columns; > param->tile_rows = svt_enc->tile_rows; > > + param->logical_processors = svt_enc->logical_processors; > + > return 0; > } > > @@ -533,6 +537,9 @@ static const AVOption options[] = { > { "tile_columns", "Log2 of number of tile columns to use", OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VE}, > { "tile_rows", "Log2 of number of tile rows to use", OFFSET(tile_rows), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 6, VE}, > > + { "logical_processors", "Number of logical processors to run the encoder on, threads are managed by the OS scheduler", OFFSET(logical_processors), > + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE }, > + > {NULL}, > }; > > - Mark
Based on my limited understanding of the code, it's limiting the usage using pthread_setaffinity_np and CPU_SET on Linux to limit the process to certain CPUs, but it also has a default and max of the return of `sysconf(_SC_NPROCESSORS_ONLN)`. According to Hassene Tmar of SVT-AV1, it is a "target core count that SVT would do a best effort to achieve" and "--lp 8 might still produce 50 threads". It does not actually limit how many threads are deployed.
On Wed, Feb 10, 2021 at 11:08 PM Mark Thompson <sw@jkqxz.net> wrote: > On 10/02/2021 17:16, Christopher Degawa wrote: > > From: Christopher Degawa <christopher.degawa@intel.com> > > > > Equivalent to the --lp option for SvtAv1EncApp, and is the only way > > to control how much cpu power svt-av1 uses for now > > > > Not using thread_count as it would be preferable to reserve that until > > svt-av1 properly implements a threads option > > Then what does it actually do? The description below about the number of > logical threads to run sounds pretty much exactly like what the threads > option does. > > Threads option is limited to filters that do filtering by calling execute(), internal threading code of libavfilter. > > 0 == getconf _NPROCESSORS_ONLN > > > > Signed-off-by: Christopher Degawa <christopher.degawa@intel.com> > > --- > > libavcodec/libsvtav1.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c > > index eb6043bcac..2296735f25 100644 > > --- a/libavcodec/libsvtav1.c > > +++ b/libavcodec/libsvtav1.c > > @@ -71,6 +71,8 @@ typedef struct SvtContext { > > > > int tile_columns; > > int tile_rows; > > + > > + unsigned logical_processors; > > } SvtContext; > > > > static const struct { > > @@ -218,6 +220,8 @@ static int > config_enc_params(EbSvtAv1EncConfiguration *param, > > param->tile_columns = svt_enc->tile_columns; > > param->tile_rows = svt_enc->tile_rows; > > > > + param->logical_processors = svt_enc->logical_processors; > > + > > return 0; > > } > > > > @@ -533,6 +537,9 @@ static const AVOption options[] = { > > { "tile_columns", "Log2 of number of tile columns to use", > OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VE}, > > { "tile_rows", "Log2 of number of tile rows to use", > OFFSET(tile_rows), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 6, VE}, > > > > + { "logical_processors", "Number of logical processors to run the > encoder on, threads are managed by the OS scheduler", > OFFSET(logical_processors), > > + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE }, > > + > > {NULL}, > > }; > > > > > > - Mark > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 10/02/2021 23:49, Christopher Degawa wrote: > Based on my limited understanding of the code, it's limiting the usage > using pthread_setaffinity_np and CPU_SET on Linux to limit the process to > certain CPUs, but it also has a default and max of the return of > `sysconf(_SC_NPROCESSORS_ONLN)`. According to Hassene Tmar of SVT-AV1, it > is a "target core count that SVT would do a best effort to achieve" and > "--lp 8 might still produce 50 threads". It does not actually limit how > many threads are deployed. IMO people who want to do things with processor affinity should use the flexible tools that their OS provides to do it (on Linux, that's taskset for the ffmpeg utility and sched_setaffinity() for library users). Having a specific and weird special case option is not obviously useful. (In particular, not warning that it's changing processor affinity in a tricky way is making the option a footgun - if I run two instances of ffmpeg then the intuitive thing to do would be to pass my number of cpus / 2 to each, which would give me a result much worse than passing nothing at all.) That said, if you have a general use-case where this is helpful and the documentation explains what it is doing (and warns about the bad cases) then maybe? Thanks, - Mark
On 10/02/2021 23:53, Paul B Mahol wrote: > On Wed, Feb 10, 2021 at 11:08 PM Mark Thompson <sw@jkqxz.net> wrote: > >> On 10/02/2021 17:16, Christopher Degawa wrote: >>> From: Christopher Degawa <christopher.degawa@intel.com> >>> >>> Equivalent to the --lp option for SvtAv1EncApp, and is the only way >>> to control how much cpu power svt-av1 uses for now >>> >>> Not using thread_count as it would be preferable to reserve that until >>> svt-av1 properly implements a threads option >> >> Then what does it actually do? The description below about the number of >> logical threads to run sounds pretty much exactly like what the threads >> option does. >> >> > Threads option is limited to filters that do filtering by calling > execute(), internal threading code of libavfilter. This would be from AVCodecContext.thread_count, not anything in libavfilter. - Mark
On Thu, Feb 11, 2021 at 11:15 PM Mark Thompson <sw@jkqxz.net> wrote: > On 10/02/2021 23:53, Paul B Mahol wrote: > > On Wed, Feb 10, 2021 at 11:08 PM Mark Thompson <sw@jkqxz.net> wrote: > > > >> On 10/02/2021 17:16, Christopher Degawa wrote: > >>> From: Christopher Degawa <christopher.degawa@intel.com> > >>> > >>> Equivalent to the --lp option for SvtAv1EncApp, and is the only way > >>> to control how much cpu power svt-av1 uses for now > >>> > >>> Not using thread_count as it would be preferable to reserve that until > >>> svt-av1 properly implements a threads option > >> > >> Then what does it actually do? The description below about the number > of > >> logical threads to run sounds pretty much exactly like what the threads > >> option does. > >> > >> > > Threads option is limited to filters that do filtering by calling > > execute(), internal threading code of libavfilter. > > This would be from AVCodecContext.thread_count, not anything in > libavfilter. > > Yes, but it is same .execute thing. But I agree with rest of your views. > - Mark > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
> > That said, if you have a general use-case where this is helpful and the > documentation explains what it is doing (and warns about the bad cases) > then maybe? > The main use case we have internally is to able to run multiple instances of SvtAv1EncApp with `--lp 1` without worrying about potentially choking out all of them and also for testing for potential single versus multi-core issues. Also, it seems my wording was wrong and it's not to "certain CPUs", but to a "certain number of CPUs"
On Sun, Feb 14, 2021 at 12:27 PM Christopher Degawa <ccom@randomderp.com> wrote: > That said, if you have a general use-case where this is helpful and the >> documentation explains what it is doing (and warns about the bad cases) >> then maybe? >> > > The main use case we have internally is to able to run multiple instances > of SvtAv1EncApp with `--lp 1` without worrying about potentially choking > out all of them and also for testing for potential single versus multi-core > issues. Also, it seems my wording was wrong and it's not to "certain CPUs", > but to a "certain number of CPUs" > Another usage for this option would be to limit the amount of memory used as right now the ram usage is tied to the numbers of cores used.
On 17/02/2021 18:58, Christopher Degawa wrote: > On Sun, Feb 14, 2021 at 12:27 PM Christopher Degawa <ccom@randomderp.com> > wrote: > >> That said, if you have a general use-case where this is helpful and the >>> documentation explains what it is doing (and warns about the bad cases) >>> then maybe? >>> >> >> The main use case we have internally is to able to run multiple instances >> of SvtAv1EncApp with `--lp 1` without worrying about potentially choking >> out all of them and also for testing for potential single versus multi-core >> issues. Also, it seems my wording was wrong and it's not to "certain CPUs", >> but to a "certain number of CPUs" >> > > Another usage for this option would be to limit the amount of memory used > as right now the ram usage is tied to the numbers of cores used. So what does it actually do, then? I just tried running with it here and all of my threads get default affinity, so whatever it is actually doing it seems like it is nothing to do with logical processors. It changes the thread count slightly but still makes lots of threads. It does seem like the number correlates somehow with how much CPU it uses, but it's not an upper bound. - Mark
> > It does seem like the number correlates somehow with how much CPU it > uses, but it's not an upper bound. > If it isn't, then that might be an issue, but the idea is that with the logical_processor option you can limit the amount of ram a single encoder instance will use since on a system with a lot of cores, but not much ram, the encoder will error out when it tries to allocate more than what is available. I can probably add that to the doc as the potential use case. https://gitlab.com/AOMediaCodec/SVT-AV1#hardware
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c index eb6043bcac..2296735f25 100644 --- a/libavcodec/libsvtav1.c +++ b/libavcodec/libsvtav1.c @@ -71,6 +71,8 @@ typedef struct SvtContext { int tile_columns; int tile_rows; + + unsigned logical_processors; } SvtContext; static const struct { @@ -218,6 +220,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration *param, param->tile_columns = svt_enc->tile_columns; param->tile_rows = svt_enc->tile_rows; + param->logical_processors = svt_enc->logical_processors; + return 0; } @@ -533,6 +537,9 @@ static const AVOption options[] = { { "tile_columns", "Log2 of number of tile columns to use", OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VE}, { "tile_rows", "Log2 of number of tile rows to use", OFFSET(tile_rows), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 6, VE}, + { "logical_processors", "Number of logical processors to run the encoder on, threads are managed by the OS scheduler", OFFSET(logical_processors), + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE }, + {NULL}, };