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

[Edward O'Callaghan]

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"
> <funfunctor at folklore1984.net <mailto:funfunctor at 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
>     > <funfunctor at folklore1984.net <mailto:funfunctor at 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
>     >>> <funfunctor at folklore1984.net
>     <mailto:funfunctor at 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
>     <kenneth at 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
>     <ernstp at gmail.com <mailto:ernstp at 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
>     >
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170211/7f49edad/attachment.sig>