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 <mar...@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 <mar...@gmail.com> > > wrote: > > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin <imir...@alum.mit.edu > > > > wrote: > > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > > > > <erik.faye-l...@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-l...@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@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
