On Tue, Oct 2, 2018 at 6:36 PM Rob Clark <robdcl...@gmail.com> wrote:
>
> On Tue, Oct 2, 2018 at 6:30 PM Marek Olšák <mar...@gmail.com> wrote:
> >
> > From: Marek Olšák <marek.ol...@amd.com>
> >
> > ---
> > src/util/u_queue.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/src/util/u_queue.c b/src/util/u_queue.c
> > index 22d2cdd0fa2..9dd1a69ed7a 100644
> > --- a/src/util/u_queue.c
> > +++ b/src/util/u_queue.c
> > @@ -232,20 +232,32 @@ struct thread_input {
> > };
> >
> > static int
> > util_queue_thread_func(void *input)
> > {
> > struct util_queue *queue = ((struct thread_input*)input)->queue;
> > int thread_index = ((struct thread_input*)input)->thread_index;
> >
> > free(input);
> >
> > +#ifdef HAVE_PTHREAD_SETAFFINITY
> > + /* Don't inherit the thread affinity from the parent thread.
> > + * Set the full mask.
> > + */
> > + cpu_set_t cpuset;
> > + CPU_ZERO(&cpuset);
> > + for (unsigned i = 0; i < CPU_SETSIZE; i++)
> > + CPU_SET(i, &cpuset);
> > +
> > + pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
> > +#endif
>
>
> Just curious (and maybe I missed some previous discussion), would this
> override taskset?
>
> Asking because when benchmarking on big/little arm SoCs I tend to use
> taskset to pin things to either the fast cores or slow cores, to
> eliminate a source of uncertainty in the result. (And I use u_queue
> to split of the 2nd half of batch submits, Ie. the part that generates
> gmem/tiling cmds and does the kernel submit ioctl). Would be slightly
> annoying to loose that ability to control which group of cores the
> u_queue thread runs on.
>
> (But admittedly this is kind of an edge case, so I guess an env var to
> override the behavior would be ok.)
I don't know, but I guess it affects it.
pipe_context::set_context_param(ctx,
PIPE_CONTEXT_PARAM_PIN_THREADS_TO_L3_CACHE, L3_group_index); is
similar to what you need.
The ideal option would be to have such default behavior on ARM that is
the most desirable. An env var is the second option.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
