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

Erik Faye-Lund erik.faye-lund at collabora.com
Mon Oct 21 09:37:13 UTC 2019


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?

2. How will these things blow up?

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

> 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



More information about the mesa-dev mailing list