Yeah, I guess that is a simple/easy option..
generally it seems like it would be better not to expand the set of
possible cpu's other than to lift restrictions mesa might have imposed
upon itself elsewhere (iirc, you were trying to limit the
glthread/threaded_context stuff to run on the same cluster as the
foreground gl thread)
BR,
-R
On Wed, Oct 3, 2018 at 2:03 AM Marek Olšák <mar...@gmail.com> wrote:
>
> I could add a flag to util queue not to do this. Then your driver can use the
> flag.
>
> Marek
>
> On Tue, Oct 2, 2018, 7:00 PM Marek Olšák <mar...@gmail.com> wrote:
>>
>> 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
