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
