Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Mon, Oct 21, 2019 at 5:37 AM Erik Faye-Lund wrote: > 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? > Yes, there is a merge request for it: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2181 > > 2. How will these things blow up? > Incorrect rendering or GPU hangs. > > 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... > finalize_nir creates a driver-specific NIR to some degree. Feature-lowering passes run after that, so they have to deal with NIR that they are not expecting, and it can be different for each driver. I don't believe in lowering at the NIR level, because you don't get anything by optimizing e.g. clip plane code when your shaders have 1000 instructions and branches that you don't want to recompile from scratch. Lowering in st/mesa is for drivers that don't have the manpower to have good performance anyway, so it doesn't matter, and finalize_nir is not for them anyway (because they don't wanna make or can't afford to make the effort to make it work for them). Marek > > > On Fri, Oct 18, 2019 at 4:17 PM Marek Olšák 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 > > > wrote: > > > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin > > > > wrote: > > > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > > > > > 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 > > > > > > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
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 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 > > wrote: > > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin > > > wrote: > > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > > > > 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 > > > > > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, 2019-10-18 at 16:17 -0400, Marek Olšák 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. Hmm, that's not the intention. The idea is that these produce the same code as if you just wrote the relevant glsl-code... Any pointers to what goes wrong would be great if anyone can spot it. > 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. That depends on how often or if at all the variants gets compiled. In fact, we might be able to generate faster shader-code by doing this before optimizing. I guess looking at real-world benchmarks would tell us what the best solution is. ...But for Zink, there isn't really much of an option do this on a low- level; the lowest level we have is SPIR-V, and we're going pretty directly from NIR to SPIR-V; we don't have a low-level IR. We leave that up to the Vulkan driver. > Marek > > On Fri, Oct 18, 2019 at 4:08 PM Marek Olšák wrote: > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin > > wrote: > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > > > 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 > > > > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
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 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 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 wrote: >>> >>> On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin wrote: On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund 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 > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
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 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 wrote: > >> On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin wrote: >> >>> On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund >>> 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 >>> > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
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 wrote: > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin wrote: > >> On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund >> 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 >> > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin wrote: > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > 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 > > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin wrote: > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund > 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 > > > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund 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 > > 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. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote: > On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund > 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... > I was thinking just like > somewhere in st_extensions where it's checking these things -- if > GS/tess are supported, make sure caps a/b/c aren't enabled. Right. I guess that could also be done... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Thu, 2019-10-17 at 20:55 -0500, Jason Ekstrand wrote: > On Thu, Oct 17, 2019 at 10:39 AM Erik Faye-Lund < > erik.faye-l...@collabora.com> wrote: > > This is discussed in the merge request thread. Zink currently only > > support vertex and fragment shaders, so it's the only place this > > can occur. If someone wants to enable this for drivers that > > supports geometry or tesselation shaders, they would need to extend > > this code first. Unless I beat them to it, of course. I don't want > > to implement this blindly, which is why I left this out for now. > > > > If you hook the pass up and get it working on iris, you wouldn't be > implementing it blind. :-P > Not the worst idea. I gave it a quick stab, but coulnt't even get the vertex-shader only path working on Iris. I'm probably breaking some expectations in the way the lowering-pass is called or something, but I couldn't figure it out quickly, and kinda lost my motivation. Here's what I did so far: https://gitlab.freedesktop.org/kusma/mesa/tree/iris-ucp-lowering I noticed that if I also call nir_shader_gather_info after the lowering (like the current iris code does), everything seems to get clipped instead... And if I do both nir_lower_global_vars_to_local and nir_lower_vars_to_ssa, I trigger this assert: nir_lower_var_copies.c:89: emit_deref_copy_load_store: Assertion `glsl_type_is_vector_or_scalar(dst_deref->type)' failed. So... I dunno. There's probably something wrong here somewhere ;) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund 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. I was thinking just like somewhere in st_extensions where it's checking these things -- if GS/tess are supported, make sure caps a/b/c aren't enabled. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
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? Cheers, -ilia On Thu, Oct 17, 2019 at 11:39 AM Erik Faye-Lund wrote: > > This is discussed in the merge request thread. Zink currently only support > vertex and fragment shaders, so it's the only place this can occur. If > someone wants to enable this for drivers that supports geometry or > tesselation shaders, they would need to extend this code first. Unless I beat > them to it, of course. I don't want to implement this blindly, which is why I > left this out for now. > > On October 17, 2019 5:09:36 PM GMT+02:00, Ilia Mirkin > wrote: >> >> Hey Erik, >> >> Just saw your change >> https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa7414eeebf69ce7538d1 >> . It looks like you assume that the UCPs will apply in the vertex >> stage, but given that we support GL compat profiles for GL 4.0+ in >> st/mesa, the UCPs actually apply to the same stage that clip distances >> are processed in -- might be TES or GS, depending on the pipeline. >> >> Perhaps there's some reason why this works anyways that I'm not seeing... >> >> Cheers, >> >> -ilia > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
On Thu, Oct 17, 2019 at 10:39 AM Erik Faye-Lund < erik.faye-l...@collabora.com> wrote: > This is discussed in the merge request thread. Zink currently only support > vertex and fragment shaders, so it's the only place this can occur. If > someone wants to enable this for drivers that supports geometry or > tesselation shaders, they would need to extend this code first. Unless I > beat them to it, of course. I don't want to implement this blindly, which > is why I left this out for now. > If you hook the pass up and get it working on iris, you wouldn't be implementing it blind. :-P --Jason > On October 17, 2019 5:09:36 PM GMT+02:00, Ilia Mirkin < > imir...@alum.mit.edu> wrote: >> >> Hey Erik, >> >> Just saw your change >> https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa7414eeebf69ce7538d1 >> . It looks like you assume that the UCPs will apply in the vertex >> stage, but given that we support GL compat profiles for GL 4.0+ in >> st/mesa, the UCPs actually apply to the same stage that clip distances >> are processed in -- might be TES or GS, depending on the pipeline. >> >> Perhaps there's some reason why this works anyways that I'm not seeing... >> >> Cheers, >> >> -ilia >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ > 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
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
This is discussed in the merge request thread. Zink currently only support vertex and fragment shaders, so it's the only place this can occur. If someone wants to enable this for drivers that supports geometry or tesselation shaders, they would need to extend this code first. Unless I beat them to it, of course. I don't want to implement this blindly, which is why I left this out for now. On October 17, 2019 5:09:36 PM GMT+02:00, Ilia Mirkin wrote: >Hey Erik, > >Just saw your change >https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa7414eeebf69ce7538d1 >. It looks like you assume that the UCPs will apply in the vertex >stage, but given that we support GL compat profiles for GL 4.0+ in >st/mesa, the UCPs actually apply to the same stage that clip distances >are processed in -- might be TES or GS, depending on the pipeline. > >Perhaps there's some reason why this works anyways that I'm not >seeing... > >Cheers, > > -ilia -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa/st: support lowering user-clip-planes automatically
Hey Erik, Just saw your change https://cgit.freedesktop.org/mesa/mesa/commit/?id=3298aedd6e9f12cefd5aa7414eeebf69ce7538d1 . It looks like you assume that the UCPs will apply in the vertex stage, but given that we support GL compat profiles for GL 4.0+ in st/mesa, the UCPs actually apply to the same stage that clip distances are processed in -- might be TES or GS, depending on the pipeline. Perhaps there's some reason why this works anyways that I'm not seeing... Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
