[Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Jan Ziak]

On Mon, Feb 6, 2017 at 11:48 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Mon, Feb 6, 2017 at 9:27 PM, Jan Ziak <0xe2.0x9a.0x9b at gmail.com> wrote:
>> Hello
>>
>> I am against application profiles - in the form of "a
>> community-maintained whitelist of apps" or in any other form
>> explicitly associating the name/ID of an app with a Mesa variable
>> which controls the behavior of Mesa.
>>
>> Application profiles would be a manifestation of poor algorithms in
>> the OpenGL implementation.
>
> No, it's called incremental progress.
>
> The Mesa community doesn't have resources to develop a multithreaded
> solution that is perfect from day 1. Incremental progress will get us
> there eventually. Or not. But it's the only way to get somewhere with
> our limited resources.
>
> Marek

No. The point is: You are proposing a transient solution that isn't
automated (i.e: a solution that isn't resembling machine learning in
any way). https://en.wikipedia.org/wiki/Machine_learning

Instead, why don't you introduce a simple C/C++ variable controlling
whether to use glthread? The variable needs to be initially fed with
simple statistics about whether glthread has positive or negative
effect on performance. The simple statistics can be obtained from
alternate frame rendering:

// Machine learning
bool use_thread = 0;
float fps[2] = {};
for i=0; i<1000; i++ {
  if use_thread
    render the frame with glthread=on
  else
    render the frame with glthread=off
  fps[use_thread] += 1.0 / frame_time;
  use_thread = 1 - use_thread;
}
const bool glthread_means_higher_fps = (fps[1] > fps[0]);

// Using the learned information
while(1) {
  if glthread_means_higher_fps
    render the frame with glthread=on
  else
    render the frame with glthread=off
}

The above solution would be totally simple to implement in Mesa. A
human-maintained whitelist is clearly a subpar solution due to
multiple factors.

Jan