Just to clarify my email, I wasn't saying shader-cache should land before this, or that we should prioritize one over the other. I was simply venting frustration that I had to keep it rebased out of tree and keep it passing piglit when it seems I didn't need too. This is nothing against this series or Marek.

Shader-cache has been in a useful state for at least the past 6 months it would have been nice to get it in and have real users testing. I agree that this is probably the only way to get this series tested and up to scratch also. I do think we should try to at least get piglit mostly working before merging (looks like Gregory has made some progress with this) even if piglit is unlikely to be the best test case for this, it seems like it a low bar to have to clear.

Tim

On 11/02/17 00:29, Marek Olšák wrote:
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 <mailto: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>
    <mailto: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>
    <mailto: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>
    >     <mailto: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>
    <mailto: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

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to