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

Emil Velikov emil.l.velikov at gmail.com
Tue Feb 7 11:54:41 UTC 2017

On 7 February 2017 at 11:23, Jan Ziak <0xe2.0x9a.0x9b at gmail.com> wrote:
> 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
Have to agree with Marek here. An explicit opt-in solution would be
nice to start with considering our resources.

> Instead, why don't you introduce a simple C/C++ variable controlling
> whether to use glthread?
> The above solution would be totally simple to implement in Mesa. A
> human-maintained whitelist is clearly a subpar solution due to
> multiple factors.
Ideally we'll have something like this as we get to the point where no
crashes or rendering issues are present.
Until then this is not an option - it will deteriorate the user
experience very significantly.

Marek, please send the series to the list and _if_ you want guard the
lot behind a configure switch.
Alternatively a big warning message [when the variable is toggled]
might be nice idea ?


More information about the mesa-dev mailing list