hmm, initially the UCP lowering did work post var lowering (since it had work after tgsi_to_nir).. the same might not be true of the drawpix/wpos_ytransform/etc lowering that is used internally in mesa/st for variants.
I assume something like this is the issue? BR, -R On Fri, Oct 18, 2019 at 3:24 PM Marek Olšák <mar...@gmail.com> 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. 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. > > Marek > > 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
