<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>