<div dir="auto">I never disagreed with you about shader cache and I never said that glthread would be merged first. I'm just describing the situation and recent news.<div dir="auto"><br></div><div dir="auto">Marek<br><div dir="auto"><br><div class="gmail_extra"><br><div class="gmail_quote">On Feb 10, 2017 2:15 PM, "Edward O'Callaghan" <<a href="mailto:funfunctor@folklore1984.net">funfunctor@folklore1984.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wait what? You just side stepped everything I just said with regards to<br>
prioritizing the volume of work that went into shader caching over gl<br>
dispatch with essentially `gl dispatch is really great and our users<br>
friend it super useful now`.<br>
<br>
That's fine, I'm not ageist it, maybe you misinterpreted me? However<br>
that is nothing to do with what I was saying, as to reiterate my point<br>
was precise and finely scoped; We should get shader caching i's and t's<br>
dotted and crossed and help Timothy get though the last 5% there.<br>
<br>
Kind Regards,<br>
Edward.<br>
<div class="quoted-text"><br>
On 02/11/2017 12:01 AM, Marek Olšák wrote:<br>
> FYI. Civilization VI is another game that works with and benefits from<br>
> glthread. The game was just released. Even Nvidia is CPU-bound on<br>
> highest details and can't reach 45 fps with full hd. People wanting to<br>
> play Civ VI with decent frame rate will want glthread. I don't think<br>
> they care too much about our the community processes, so I expect there<br>
> will be quite a few users using out-of-tree builds of Mesa.<br>
><br>
> Also, Pierre-Loup from Valve said on IRC yesterday that they are<br>
> probably gonna ship glthread and make their own whitelist, regardless of<br>
> the outcome of this discussion. It would be preferable to have that<br>
> whitelist in master too, but that may be difficult if we can't merge it.<br>
><br>
> If distributions and vendors start shipping glthread, we might as well<br>
> merge it, because at that point there is no advantage in keeping this<br>
> out of tree if it forces users to use out of tree builds. We'll get bug<br>
> reports regardless.<br>
><br>
> Also Eero, I don't care about glmark at this very moment. It's not like<br>
> I'm merging this today, so it doesn't matter. Maybe it will matter next<br>
> week or next month. We'll likely not support glmark anyway, so the fix<br>
> will most likely be disabling multithreading on the fly than trying to<br>
> fix the crash.<br>
><br>
> Marek<br>
><br>
><br>
> On Feb 10, 2017 12:58 PM, "Edward O'Callaghan"<br>
</div><div class="quoted-text">> <<a href="mailto:funfunctor@folklore1984.net">funfunctor@folklore1984.net</a> <mailto:<a href="mailto:funfunctor@folklore1984.net">funfunctor@<wbr>folklore1984.net</a>>> wrote:<br>
><br>
><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>
</div>>     > <<a href="mailto:funfunctor@folklore1984.net">funfunctor@folklore1984.net</a> <mailto:<a href="mailto:funfunctor@folklore1984.net">funfunctor@<wbr>folklore1984.net</a>>><br>
<div class="quoted-text">>     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><br>
</div><div class="quoted-text">>     <mailto:<a href="mailto:funfunctor@folklore1984.net">funfunctor@<wbr>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<br>
>     <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<br>
</div>>     <<a href="mailto:ernstp@gmail.com">ernstp@gmail.com</a> <mailto:<a href="mailto:ernstp@gmail.com">ernstp@gmail.com</a>><br>
<div class="elided-text">>     >>>>>>>>> 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<br>
>     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<br>
>     pass<br>
>     >>>>> piglit for over a year with the same reasoning that it will be<br>
>     disable<br>
>     >>>>> by default and can only be improved with testing I can't<br>
>     possibly do on<br>
>     >>>>> my own.<br>
>     >>>>><br>
>     >>>>> Although I have no objections to this being merged I'll be<br>
>     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<br>
>     over<br>
>     >>>>> many months.<br>
>     >>>>><br>
>     >>>><br>
>     >>>> Regardless of all the chatter on this thread in and around GL<br>
>     dispatch,<br>
>     >>>> which I agree poses significant challenges to get into<br>
>     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<br>
>     that, could<br>
>     >>>> we perhaps prioritize getting the shader cache stuff in before<br>
>     >>>> attempting GL dispatch? I think this both morally and<br>
>     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<br>
>     a hard<br>
>     >> requirement for it to be merged. Maybe Timothy can weigh in on it<br>
>     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>
<br>
</div></blockquote></div><br></div></div></div></div>