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.
Actually it might be crazy enough to work -- you'll generate the (potentially) wrong shader at LinkShader time, but then at draw time, the key will be regenerated (to look up the appropriate shader, at which time st->gp/etc *are* reliable), you'll discover that you're missing the right shader, and recompile. Not exactly ideal, but also not broken. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
