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
[Mesa-dev] [ANNOUNCE] Mesa 19.1.8
Mesa 19.1.8 is now available. NOTE: It is anticipated that 19.1.8 will be the final release in the 19.1 series. Users of 19.1 are encouraged to migrate to the 19.2 series in order to obtain future fixes. Apologies for the big delay in this release; there were several regressions that we were investigating, which prevented the pre-release to be on time. Subject: [ANNOUNCE] mesa 19.1.8 To: mesa-annou...@lists.freedesktop.org Cc: mesa-dev@lists.freedesktop.org Adam Jackson (1): docs: Update bug report URLs for the gitlab migration Alan Coopersmith (5): c99_compat.h: Don't try to use 'restrict' in C++ code util: Make Solaris implemention of p_atomic_add work with gcc util: Workaround lack of flock on Solaris meson: recognize "sunos" as the system name for Solaris intel/common: include unistd.h for ioctl() prototype on Solaris Andreas Gottschling (1): drisw: Fix shared memory leak on drawable resize Andres Gomez (3): docs: Add the maximum implemented Vulkan API version in 19.1 rel notes docs/features: Update VK_KHR_display_swapchain status egl: Remove the 565 pbuffer-only EGL config under X11. Andrii Simiklit (1): glsl: disallow incompatible matrices multiplication Arcady Goldmints-Orlov (1): anv: fix descriptor limits on gen8 Bas Nieuwenhuizen (2): tu: Set up glsl types. radv: Add workaround for hang in The Surge 2. Danylo Piliaiev (1): st/nine: Ignore D3DSIO_RET if it is the last instruction in a shader Dylan Baker (5): meson: fix logic for generating .pc files with old glvnd meson: Try finding libxvmcw via pkg-config before using find_library meson: Link xvmc with libxv meson: gallium media state trackers require libdrm with x11 meson: Only error building gallium video without libdrm when the platform is drm Eric Engestrom (4): gl: drop incorrect pkg-config file for glvnd meson: re-add incorrect pkg-config files with GLVND for backward compatibility util/anon_file: add missing #include util/anon_file: const string param Erik Faye-Lund (1): glsl: correct bitcast-helpers Greg V (1): util: add anon_file.h for all memfd/temp file usage Haihao Xiang (1): i965: support AYUV/XYUV for external import only Hal Gentz (1): gallium/osmesa: Fix the inability to set no context as current. Jason Ekstrand (2): nir/repair_ssa: Replace the unreachable check with the phi builder intel/fs: Fix fs_inst::flags_read for ANY/ALL predicates Juan A. Suarez Romero (12): docs: add sha256 checksums for 19.1.7 cherry-ignore: add explicit 19.2 only nominations cherry-ignore: add explicit 19.3 only nominations Revert "Revert "intel/fs: Move the scalar-region conversion to the generator."" cherry-ignore: Revert "gallium: remove PIPE_CAP_TEXTURE_SHADOW_MAP" bin/get-pick-list.sh: sha1 commits can be smaller than 8 chars cherry-ignore: nir/opt_large_constants: Handle store writemasks cherry-ignore: util: added missing headers in anon-file cherry-ignore: radv: Fix condition for skipping the continue CS. cherry-ignore: Revert "radv: disable viewport clamping even if FS doesn't write Z" Update version to 19.1.8 docs: add release notes for 19.1.8 Ken Mays (1): haiku: fix Mesa build Kenneth Graunke (4): iris: Initialize ice->state.prim_mode to an invalid value intel: Increase Gen11 compute shader scratch IDs to 64. iris: Disable CCS_E for 32-bit floating point textures. iris: Fix iris_rebind_buffer() for VBOs with non-zero offsets. Lionel Landwerlin (5): anv: gem-stubs: return a valid fd got anv_gem_userptr() intel: use proper label for Comet Lake skus mesa: don't forget to clear _Layer field on texture unit intel: fix subslice computation from topology data intel/isl: Set null surface format to R32_UINT Marek Olšák (1): gallium/vl: don't set PIPE_HANDLE_USAGE_EXPLICIT_FLUSH Matt Turner (1): util: Drop preprocessor guards for glibc-2.12 Michel Dänzer (1): radeonsi: fix VAAPI segfault due to various bugs Michel Zou (2): scons: add py3 support scons: For MinGW use -posix flag. Paulo Zanoni (1): intel/fs: fix SHADER_OPCODE_CLUSTER_BROADCAST for SIMD32 Prodea Alexandru-Liviu (1): scons/MSYS2-MinGW-W64: Fix build options defaults Rhys Perry (2): radv: always emit a position export in gs copy shaders nir/opt_remove_phis: handle phis with no sources Samuel Iglesias Gonsálvez (1): intel/nir: do not apply the fsin and fcos trig workarounds for consts Stephen Barber (1): nouveau: add idep_nir_headers as dep for libnouveau Tapani Pälli (3): iris: close screen fd on iris_destroy_screen egl: check for NULL value like eglGetSyncAttribKHR does util: fix os_create_anonymous_file on android pal1000 (2): scons/windows: Support build
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
