<div dir="auto">FYI. Civilization VI is another game that works with and benefits from glthread. The game was just released. Even Nvidia is CPU-bound on highest details and can't reach 45 fps with full hd. People wanting to play Civ VI with decent frame rate will want glthread. I don't think they care too much about our the community processes, so I expect there will be quite a few users using out-of-tree builds of Mesa.<div dir="auto"><br></div><div dir="auto">Also, Pierre-Loup from Valve said on IRC yesterday that they are probably gonna ship glthread and make their own whitelist, regardless of the outcome of this discussion. It would be preferable to have that whitelist in master too, but that may be difficult if we can't merge it.</div><div dir="auto"><br></div><div dir="auto">If distributions and vendors start shipping glthread, we might as well merge it, because at that point there is no advantage in keeping this out of tree if it forces users to use out of tree builds. We'll get bug reports regardless.</div><div dir="auto"><br></div><div dir="auto">Also Eero, I don't care about glmark at this very moment. It's not like I'm merging this today, so it doesn't matter. Maybe it will matter next week or next month. We'll likely not support glmark anyway, so the fix will most likely be disabling multithreading on the fly than trying to fix the crash.</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 10, 2017 12:58 PM, "Edward O'Callaghan" <<a href="mailto:funfunctor@folklore1984.net" target="_blank">funfunctor@folklore1984.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 02/10/2017 10:50 PM, Marek Olšák wrote:<br>
> On Fri, Feb 10, 2017 at 12:48 PM, Edward O'Callaghan<br>
> <<a href="mailto:funfunctor@folklore1984.net">funfunctor@folklore1984.net</a>> wrote:<br>
>><br>
>><br>
>> On 02/10/2017 10:36 PM, Marek Olšák wrote:<br>
>>> On Fri, Feb 10, 2017 at 12:26 PM, Edward O'Callaghan<br>
>>> <<a href="mailto:funfunctor@folklore1984.net">funfunctor@folklore1984.net</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> On 02/08/2017 09:13 AM, Timothy Arceri wrote:<br>
>>>>> On Tue, 2017-02-07 at 10:56 +0100, Marek Olšák wrote:<br>
>>>>>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke <kenneth@whitecape.or<br>
>>>>>> g> wrote:<br>
>>>>>>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:<br>
>>>>>>>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand <<a href="mailto:ernstp@gmail.com">ernstp@gmail.com</a><br>
>>>>>>>>> wrote:<br>
>>>>>>>>> FYI glmark2 segfaults with mesa_glthread=true. Expected that<br>
>>>>>>>>> some programs<br>
>>>>>>>>> will segfault?<br>
>>>>>>>><br>
>>>>>>>> Yes, even segfaults are expected with mesa_glthread=true.<br>
>>>>>>>><br>
>>>>>>>> Marek<br>
>>>>>>><br>
>>>>>>> Would it make sense to be crash-free or even regression-free on at<br>
>>>>>>> least Piglit, before merging?  (Or are we there already?)<br>
>>>>>><br>
>>>>>> It's not necessary. glthread is disabled by default. Nobody has<br>
>>>>>> tested<br>
>>>>>> piglit with glthread. That will follow after it's been merged, or<br>
>>>>>> never if it's never merged.<br>
>>>>><br>
>>>>> I've been trying to land shader-cache patches that actually do pass<br>
>>>>> piglit for over a year with the same reasoning that it will be disable<br>
>>>>> by default and can only be improved with testing I can't possibly do on<br>
>>>>> my own.<br>
>>>>><br>
>>>>> Although I have no objections to this being merged I'll be extremely<br>
>>>>> frustrated if this is allowed to be merged known to not even pass<br>
>>>>> piglit while I've wasted countless hours rebasing shader cache over<br>
>>>>> many months.<br>
>>>>><br>
>>>><br>
>>>> Regardless of all the chatter on this thread in and around GL dispatch,<br>
>>>> which I agree poses significant challenges to get into something 'ideal'<br>
>>>> - which is hard to define for something like this..<br>
>>>><br>
>>>> I think Timothy makes a really fair and just case here; in that, could<br>
>>>> we perhaps prioritize getting the shader cache stuff in before<br>
>>>> attempting GL dispatch? I think this both morally and technically the<br>
>>>> right thing to do in my humble opinion.<br>
>>><br>
>>> There is a small difference. The shader cache is expected to be<br>
>>> enabled by default, so there is a certain level of quality required.<br>
>><br>
>> Hey Marek,<br>
>><br>
>> I am under the impression that it being enabled by default isn't a hard<br>
>> requirement for it to be merged. Maybe Timothy can weigh in on it when<br>
>> he is online?<br>
><br>
> There is no official hard requirement. Everything is a judgement call<br>
> based on circumstances.<br>
<br>
Yes, OK, I agree; So why assert the above response then? Who is<br>
expecting it to be enabled by default? To reiterate I believe Timothy<br>
would like it merged first and foremost, then perhaps enable it by<br>
default if that is OK with everyone. I didn't see anywhere he expected<br>
it to be on by default. However we should wait for his response on that.<br>
<br>
Regards,<br>
Edward.<br>
<br>
><br>
> Marek<br>
><br>
<br>
</blockquote></div></div>