[Mesa-dev] mesa/st: support lowering user-clip-planes automatically

Marek Olšák maraeo at gmail.com
Mon Oct 21 18:39:55 UTC 2019


On Mon, Oct 21, 2019 at 5:37 AM Erik Faye-Lund <erik.faye-lund at collabora.com>
wrote:

> On Fri, 2019-10-18 at 18:23 -0400, Marek Olšák wrote:
> > Oh BTW, drivers that want to implement pipe_screen::finalize_nir to
> > improve cached shader compilation can't use any of those lowering
> > passes, because then things blow up.
>
> Two questions:
>
> 1. What is pipe_screen::finalize_nir? I can't see that in master... Is
> it something that's currently cooking in a branch / MR?
>

Yes, there is a merge request for it:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2181


>
> 2. How will these things blow up?
>

Incorrect rendering or GPU hangs.


> > The only _optional_ lowering you can do in st/mesa is clamp_color and
> > force_persample_in_shader, which covers iris at least (radeonsi
> > doesn't need any). If you need more, you either need to invest a
> > significant amount of time to make driver-specific NIR work with the
> > lowering passes, or give up on good shader cache efficiency.
>
> I would love to hear something about why this is the case...
>

finalize_nir creates a driver-specific NIR to some degree. Feature-lowering
passes run after that, so they have to deal with NIR that they are not
expecting, and it can be different for each driver.

I don't believe in lowering at the NIR level, because you don't get
anything by optimizing e.g. clip plane code when your shaders have 1000
instructions and branches that you don't want to recompile from scratch.
Lowering in st/mesa is for drivers that don't have the manpower to have
good performance anyway, so it doesn't matter, and finalize_nir is not for
them anyway (because they don't wanna make or can't afford to make the
effort to make it work for them).

Marek


>
> > On Fri, Oct 18, 2019 at 4:17 PM Marek Olšák <maraeo at gmail.com> wrote:
> > > Note that none of the lowering passes work if I enable them on
> > > radeonsi. So if you think about enabling them for your driver, I
> > > guess you have some work to do in the driver as well.
> > >
> > > On the other hand, having multiple shader variants in st/mesa is a
> > > performance disadvantage. The lowering should be done at the
> > > machine-level assembly code, so that you don't have to completely
> > > recompile from a higher-level IR.
> > >
> > > Marek
> > >
> > > On Fri, Oct 18, 2019 at 4:08 PM Marek Olšák <maraeo at gmail.com>
> > > wrote:
> > > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin <imirkin at alum.mit.edu
> > > > > wrote:
> > > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund
> > > > > <erik.faye-lund at collabora.com> wrote:
> > > > > >
> > > > > > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote:
> > > > > > > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund
> > > > > > > <erik.faye-lund at collabora.com> wrote:
> > > > > > > > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote:
> > > > > > > > > In the meanwhile (unless you plan on taking up Jason's
> > > > > > > > > suggestion),
> > > > > > > > > might I recommend some assert's for the unhandled cases
> > > > > so that
> > > > > > > > > there
> > > > > > > > > are no surprises?
> > > > > > > >
> > > > > > > > Good idea. I sent a MR for it here:
> > > > > > > >
> > > > > > > >
> > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2380
> > > > > > >
> > > > > > > Not sure that approach works, esp with SSO.
> > > > > >
> > > > > > If so, wouldn't that already be a problem with the existing
> > > > > > lower_depth_clamp-stuff, then? I mean, I just lifted the
> > > > > logic from
> > > > > > there...
> > > > >
> > > > > Yeah, that looks bogus. I'm moderately sure that checking
> > > > > "st->vp/gp/tep" at LinkShader time is wrong. Marek can probably
> > > > > confirm.
> > > >
> > > > Don't read any context states at link time. It's wrong.
> > > >
> > > > Marek
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20191021/af4f9a79/attachment.html>


More information about the mesa-dev mailing list