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.
Marek On Feb 10, 2017 2:15 PM, "Edward O'Callaghan" <funfunc...@folklore1984.net> wrote: Wait what? You just side stepped everything I just said with regards to prioritizing the volume of work that went into shader caching over gl dispatch with essentially `gl dispatch is really great and our users friend it super useful now`. That's fine, I'm not ageist it, maybe you misinterpreted me? However that is nothing to do with what I was saying, as to reiterate my point was precise and finely scoped; We should get shader caching i's and t's dotted and crossed and help Timothy get though the last 5% there. Kind Regards, Edward. On 02/11/2017 12:01 AM, Marek Olšák wrote: > 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. > > 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. > > 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. > > 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. > > Marek > > > On Feb 10, 2017 12:58 PM, "Edward O'Callaghan" > <funfunc...@folklore1984.net <mailto:funfunc...@folklore1984.net>> wrote: > > > > On 02/10/2017 10:50 PM, Marek Olšák wrote: > > On Fri, Feb 10, 2017 at 12:48 PM, Edward O'Callaghan > > <funfunc...@folklore1984.net <mailto:funfunc...@folklore1984.net>> > wrote: > >> > >> > >> On 02/10/2017 10:36 PM, Marek Olšák wrote: > >>> On Fri, Feb 10, 2017 at 12:26 PM, Edward O'Callaghan > >>> <funfunc...@folklore1984.net > <mailto:funfunc...@folklore1984.net>> wrote: > >>>> > >>>> > >>>> On 02/08/2017 09:13 AM, Timothy Arceri wrote: > >>>>> On Tue, 2017-02-07 at 10:56 +0100, Marek Olšák wrote: > >>>>>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke > <kenn...@whitecape.or > >>>>>> g> wrote: > >>>>>>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote: > >>>>>>>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand > <ern...@gmail.com <mailto:ern...@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>> FYI glmark2 segfaults with mesa_glthread=true. Expected that > >>>>>>>>> some programs > >>>>>>>>> will segfault? > >>>>>>>> > >>>>>>>> Yes, even segfaults are expected with mesa_glthread=true. > >>>>>>>> > >>>>>>>> Marek > >>>>>>> > >>>>>>> Would it make sense to be crash-free or even regression-free > on at > >>>>>>> least Piglit, before merging? (Or are we there already?) > >>>>>> > >>>>>> It's not necessary. glthread is disabled by default. Nobody has > >>>>>> tested > >>>>>> piglit with glthread. That will follow after it's been merged, or > >>>>>> never if it's never merged. > >>>>> > >>>>> I've been trying to land shader-cache patches that actually do > pass > >>>>> piglit for over a year with the same reasoning that it will be > disable > >>>>> by default and can only be improved with testing I can't > possibly do on > >>>>> my own. > >>>>> > >>>>> Although I have no objections to this being merged I'll be > extremely > >>>>> frustrated if this is allowed to be merged known to not even pass > >>>>> piglit while I've wasted countless hours rebasing shader cache > over > >>>>> many months. > >>>>> > >>>> > >>>> Regardless of all the chatter on this thread in and around GL > dispatch, > >>>> which I agree poses significant challenges to get into > something 'ideal' > >>>> - which is hard to define for something like this.. > >>>> > >>>> I think Timothy makes a really fair and just case here; in > that, could > >>>> we perhaps prioritize getting the shader cache stuff in before > >>>> attempting GL dispatch? I think this both morally and > technically the > >>>> right thing to do in my humble opinion. > >>> > >>> There is a small difference. The shader cache is expected to be > >>> enabled by default, so there is a certain level of quality required. > >> > >> Hey Marek, > >> > >> I am under the impression that it being enabled by default isn't > a hard > >> requirement for it to be merged. Maybe Timothy can weigh in on it > when > >> he is online? > > > > There is no official hard requirement. Everything is a judgement call > > based on circumstances. > > Yes, OK, I agree; So why assert the above response then? Who is > expecting it to be enabled by default? To reiterate I believe Timothy > would like it merged first and foremost, then perhaps enable it by > default if that is OK with everyone. I didn't see anywhere he expected > it to be on by default. However we should wait for his response on that. > > Regards, > Edward. > > > > > Marek > > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
