Re: [Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var
Possibly worth noting as another point for reference is that zink also uses variables. On Sun, Oct 11, 2020, 11:08 AM Jason Ekstrand wrote: > First off, I should point out that the AMD NIR -> LLVM translator is, > as far as I know, the only NIR back-end that consumes variables at > all. Most back-ends assume that all variable access is completely > lowered away before the back-end ever sees it. How this is done > depends on the variable mode. > > For nir_var_shader_temp, these are typically converted to > nir_var_function_temp by nir_lower_global_vars_to_local after function > inlining has completed. For nir_var_function_temp, it's some > combination of nir_lower_vars_to_ssa, nir_lower_indirect_derefs, and > nir_lower_locals_to_regs. If the back-end wants to be able to handle > indirect access (such as with a non-constant array index) directly, it > will typically use nir_lower_locals_to_regs. If the back-end doesn't > want to handle indirects, it will use nir_lower_indirect_derefs to get > rid of any indirects at which point nir_lower_vars_to_ssa will get rid > of all access to nir_var_function_temp variables assuming complete > deref chains. (Incomplete deref chains can happen with OpenCL kernel > so they require a different approach.) > > Next, we have driver-internal I/O for things like vertex attributes, > varyings, and uniforms, i.e. nir_var_shader_in, nir_var_shader_out, > and nir_var_uniform. This is typically handled by nir_lower_io. This > call takes a type_size callback function which it ses to lay out the > I/O data in some sort of index space. For nir_var_uniform, this is > often bytes (but doesn't have to be). For nir_var_shader_in and > nir_var_shader_out, it's typically in units of vec4 locations. The > result of this lowering is a bunch of load/store_input/output > intrinsics. For FS inputs, nir_lower_io can optionally produce > interpolation intrinsics instead. > > The final major category is external I/O. For this, we use > nir_lower_explicit_io and friends. One difference between > nir_lower_io and nir_lower_explicit_io is that nir_lower_explicit_io > expects types to have explicit layout information (which is always in > units of bytes) rather than taking it from a callback. Another > difference is that nir_lower_explicit_io is capable of handling > incomplete deref chains where pointer casts, pointer arithmetic, and > other weirdness may exist while nir_lower_io assumes full deref chains > all the time. For Vulkan, we need explicit type layout information > because that's what we get from SPIR-V and we need partial deref > chains because of extensions like VK_KHR_variable_pointers. For > OpenGL, we have neither of those things but we use > nir_lower_explicit_io anyway because we want the consistency and > because the std140/430 layouts are a little too complex to describe > with the callback used by nir_lower_io. > > Lastly, we have nir_var_system_value which is lowered by > nir_lower_system_values and nir_lower_cs_system_values. > > I hope that helps. I should really turn this into a blog post or, > better yet, real documentation > > --Jason > > On Sun, Oct 11, 2020 at 6:27 AM vivek pandya > wrote: > > > > I see that > > visit_load_var() in ~/mesa/src/amd/llvm/ac_nir_to_llvm.c > > > > assumes that nir_variable used in this intrinsic can have few specific > mods only. > > > > For example variable can not have nir_var_mem_shared , if such mod > encountered it will execute unreachable() code. > > > > Is there any nir pass that needs to be run before nir_to_llvm > translation? > > > > Sincerely, > > Vivek > > ___ > > 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 mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] piglit/mesa marge access => DONE
Thanks all! On Mon, Aug 3, 2020, 12:20 PM Kenneth Graunke wrote: > On Friday, July 31, 2020 7:14:49 AM PDT Mike Blumenkrantz wrote: > > Hi, > > > > I'd like to request marge access for the piglit and mesa gitlab projects. > > I've been contributing a number of patches here (primarily to > > zink/gallium), and this would be useful in my continued work. > > > > > > Regards, > > Mike (zmike) > > > > +1 from me! > > I just granted you Developer access to gitlab.freedesktop.org/mesa, > including Mesa, Piglit, and other related projects. > > --Ken > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] piglit/mesa marge access
Hi, I'd like to request marge access for the piglit and mesa gitlab projects. I've been contributing a number of patches here (primarily to zink/gallium), and this would be useful in my continued work. Regards, Mike (zmike) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Gitlab Labels
Hi All, I was thinking it'd be nice to have labels in Mesa for difficulty in order to help both newer and more experienced contributors choose issues/MRs which fit their level of comfort and available time. This might look like: * easy * challenging * impossible Naturally we could then also create a task to document these labels, which I assume we would tag as "impossible". Regards, Mike ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] v3dv is Vulkan 1.0 conformant
Hey, congrats! That's awesome! On Tue, Nov 24, 2020 at 6:24 AM apinheiro wrote: > So just a for your information, we submitted v3dv for Vulkan 1.0 > conformance around one month ago, in behalf of the Raspberry Foundation, > and it is not official [1]. Here the Foundation blog post [2]. > > We want to thanks everybody that helped with this, but specially to Eric > Anholt, as without the foundation of the v3d driver he wrote, all the > answers to our questions and doubts, and all his patch reviews, we would > not be able to do get this done in less than a year, that is (imho) a > really nice time frame. > > Right now we are working on improving the current stack, with several > clean-ups, performance improvements, and adding some optional 1.0 > features. 1.1 is one the table but still not the main development focus. > We will see as we keep adding "popular" optional 1.0 features. > > BR > > [1] > > https://www.khronos.org/conformance/adopters/conformant-products#submission_530 > > [2] https://www.raspberrypi.org/blog/vulkan-update-were-conformant/ > > ___ > 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] st/pbo: fix pbo uploads without PIPE_CAP_TGSI_VS_LAYER_VIEWPORT
Hi Ilia, I'm not entirely sure what you're asking here. This patch doesn't change anything related to gl_Layer reads, it just forces the geometry shader codepath unconditionally when VS_LAYER_VIEWPORT isn't enabled in order to successfully write the gl_Layer output. If anything, this should be beneficial to those nvidia chipsets based on your description since previously the fragment shader would've had nothing to read. Mike On Mon, Dec 14, 2020 at 10:48 AM Ilia Mirkin wrote: > Hey Mike, > > This is in reference to your change > > https://cgit.freedesktop.org/mesa/mesa/commit/?id=614c2ac2f48955537efcfefaf0609d6c03e5 > . > > A fragment shader should still be able to read gl_Layer even without > PIPE_CAP_TGSI_VS_LAYER_VIEWPORT. A frag shader can read gl_Layer any > time ARB_fragment_layer_viewport is supported -- I forget the precise > conditions for it, but basically any DX10 hardware supports that. > > However the VS_LAYER_VIEWPORT feature isn't supported on any NVIDIA > hardware until fairly late models (GM20x+). So this will regress the > majority case (single-layer) on all NVIDIA hw. > > Can you instead adjust the conditions to allow this for the drivers > that implement layer/viewport sysvals in frag shaders? Or just > implement ARB_fragment_layer_viewport in zink? > > Thanks, > > -ilia > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Developer access
+1 always in favor of getting more people into the review pipeline On Thu, Jan 21, 2021 at 10:05 AM Alyssa Rosenzweig < alyssa.rosenzw...@collabora.com> wrote: > Hi all, > > Icecream95[1], a long-time Mesa/Panfrost contributor, has requested > developer access to mesa on the GitLab issue tracker [2]. Quoting here > for convenience of those who monitor the mailing list but not the > tracker: > > > @alyssa keeps complaining about getting poked to assign stuff to Marge > > for me, so I think it's finally time to ask for Mesa developer access, > > so I can do the endless retries until CI stops flaking myself. > > > > Assuming a platform with char as unsigned, I think my 210 patches in > > Mesa is more than the 32 commits some have suggested to be required > > for the lofty privilege of labelling MRs and bothering the merge bot. > > All else being equal, with my Panfrost maintainer hat, I am in favour. > Marge Bot access would reduce merge friction for their frequent > contributions, given the substantial timezone difference with our team > at Collabora. Additionally, labeling access would ease triage for us; > although I subscribe specifically to Panfrost MRs, I have to monitor all > MRs to ensure I haven't missed any from them, a frequent occurrence. > > [ The cynic reads: This is more for my benefit than theirs ;-) ] > > Thanks, > > Alyssa > > [1] https://gitlab.freedesktop.org/icecream95 > [2] https://gitlab.freedesktop.org/mesa/mesa/-/issues/4135 > ___ > 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 (master): lavapipe: bump maxMemoryAllocationCount
This is mostly to deal with zink atm because there's no allocator/suballocator in use, meaning every resource gets its own alloc. There's a ticket (https://gitlab.freedesktop.org/mesa/mesa/-/issues/4293) for implementing aux/pb, but I don't have a timeline for that right now. Mike On Wed, Mar 17, 2021 at 10:25 PM Brian Paul wrote: > On 3/17/21 6:12 PM, GitLab Mirror wrote: > > Module: Mesa > > Branch: master > > Commit: 23100f3b6531d7055ae4d42e07bda09d991ea438 > > URL: > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcgit.freedesktop.org%2Fmesa%2Fmesa%2Fcommit%2F%3Fid%3D23100f3b6531d7055ae4d42e07bda09d991ea438data=04%7C01%7Cbrianp%40vmware.com%7Cd05b2a74f4bd48bf385208d8e9a28db1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516231677082505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=d3Ypjgh4TYqFsQDUbFCY956sLSv1hpqG4NP2OwP4it4%3Dreserved=0 > > > > Author: Dave Airlie > > Date: Wed Mar 17 13:33:14 2021 +1000 > > > > lavapipe: bump maxMemoryAllocationCount > > > > not sure why this was so low > > 4096 is the minimum maximum that Vulkan supports. I believe that's what > Nvidia and AMD's Windows Vulkan drivers say. > > If you want your Vulkan app to be really cross-platform it's a limit to > be aware of. > > -Brian > > > > > > Reviewed-By: Mike Blumenkrantz > > Reviewed-by: Adam Jackson > > Part-of: < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F9644data=04%7C01%7Cbrianp%40vmware.com%7Cd05b2a74f4bd48bf385208d8e9a28db1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516231677082505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=uzbWE3%2FG6AupVIc0kOYl8n5XcKw%2FcufKmK3tDEzhTyE%3Dreserved=0 > > > > > > --- > > > > src/gallium/frontends/lavapipe/lvp_device.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/gallium/frontends/lavapipe/lvp_device.c > b/src/gallium/frontends/lavapipe/lvp_device.c > > index 61edf15dd0a..b087e2a7d68 100644 > > --- a/src/gallium/frontends/lavapipe/lvp_device.c > > +++ b/src/gallium/frontends/lavapipe/lvp_device.c > > @@ -574,7 +574,7 @@ VKAPI_ATTR void VKAPI_CALL > lvp_GetPhysicalDeviceProperties(VkPhysicalDevice phys > > .maxUniformBufferRange= > pdevice->pscreen->get_shader_param(pdevice->pscreen, PIPE_SHADER_FRAGMENT, > PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE), > > .maxStorageBufferRange= > pdevice->pscreen->get_param(pdevice->pscreen, > PIPE_CAP_MAX_SHADER_BUFFER_SIZE), > > .maxPushConstantsSize = > MAX_PUSH_CONSTANTS_SIZE, > > - .maxMemoryAllocationCount = 4096, > > + .maxMemoryAllocationCount = UINT32_MAX, > > .maxSamplerAllocationCount= 32 * 1024, > > .bufferImageGranularity = 64, /* A cache line > */ > > .sparseAddressSpaceSize = 0, > > > > ___ > > mesa-commit mailing list > > mesa-com...@lists.freedesktop.org > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-commitdata=04%7C01%7Cbrianp%40vmware.com%7Cd05b2a74f4bd48bf385208d8e9a28db1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637516231677082505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=j0T9KnefIkBponHxMLxgKi8xBIMHYAydsEWV9ESBsSQ%3Dreserved=0 > > > > ___ > 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 21.0 release
zink ones done here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9504 On Wed, Mar 10, 2021 at 3:39 PM Dylan Baker wrote: > Hi list, > > I think we're just about ready for the mesa 21.0 release. Sorry I've > been really about this. Here's a lis tof all outstanding patches that > either don't apply, or don't compile. If you see something here you'd > like to backport for 21.0.0 please let me know. Otherwise I'm planning > to make the release tomorrow. > > Cheers, > Dylan > > 6a29632dd2 Revert "glcpp: disable 'windows' tests" > > > > > bd1705a480 vulkan: Make vk_debug_report_callback derive from > vk_object_base > > > > 366fb28dac ci: Fix MESA_TEMPLATES_COMMIT value > > > > > 0464117ad9 ci: remove nouveau from shader-db runs > > > > > 04df0cb4ae zink: VK_KHR_draw_indirect_count is a device extension > > > > > 942ba4e341 zink: unset generated TCS if its parent TESS is unset > > > > > bddc0e023c radeonsi: fix read from compute / write from draw sync > > > > > a67d3e7c9e radeonsi: fix si_check_render_feedback > > > > > 0f7379e308 ci: tracie dashboard URLs only in the failure after the > testcase > > > > cff5c40fc3 pan/bi: Fix blend shaders using LD_TILE with MRT > > > > > c0c03f29e0 lavapipe: implement physical device group enumeration > > > > > b6b3b38434 turnip: consider HW limit on number of views when apply > multipos opt > > > > 5a340c0929 vulkan/util: add api to reset object magic + private data. > > > > > 226c7ae2a8 lavapipe: reset object base on recycled command buffers > > > > > 8b44e45347 intel/perf: fix roll over PERF_CNT counter accumulation > > > > > 5f1b354472 aco: calculate all p_as_uniform and v_readfirstlane_b32 sources > in WQM > > > > 3d3f21f0be ci: add libdrm to the x86_test-vk container > > > > > 0a939e788f lavapipe: reorder descriptor set stages to get correct binding > > > > > abc724e440 lavapipe: sort bindings before creating descriptor set > > > > > db67d9c0d1 radeonsi: don't crash on NULL images in > si_check_needs_implicit_sync > > > > 8955d179d3 anv: fix MI_PREDICATE_RESULT write > > > > > 3436e5295b pan/bi: Treat +DISCARD.f32 as message-passing > > > > > 2c02740a8c intel/mi_builder: Use AddCSMMIOStartOffset for LRI > > > > > ea27f2bf09 zink: Fix a thinko in instance > setup___ > 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] Outstanding Mesa 21.0 patches
Hi, I'll take care of all the lavapipe ones and get a MR up for you later today. Mike On Fri, Apr 9, 2021, 12:39 PM Dylan Baker wrote: > Hi all, > > I've been a little behind on release work recently, and I'm tryinng to > cleanup the backlog of patches against the 21.0 branch that haven't been > applied but have been nominated. Below is the list of outstanding > patches that either don't apply, or cause regressions. If you'd like to > have these applied please provide a backport, otherwise I'm going to > mark all of these as "denominated". > > Cheers, > Dylan > > > 6a29632dd2 Revert "glcpp: disable 'windows' tests" > > > > > bd1705a480 vulkan: Make vk_debug_report_callback derive from > vk_object_base > > > > 366fb28dac ci: Fix MESA_TEMPLATES_COMMIT value > > > > > 0464117ad9 ci: remove nouveau from shader-db runs > > > > > 0f7379e308 ci: tracie dashboard URLs only in the failure after the > testcase > > > > cff5c40fc3 pan/bi: Fix blend shaders using LD_TILE with MRT > > > > > c0c03f29e0 lavapipe: implement physical device group enumeration > > > > > b6b3b38434 turnip: consider HW limit on number of views when apply > multipos opt > > > > 5a340c0929 vulkan/util: add api to reset object magic + private data. > > > > > 226c7ae2a8 lavapipe: reset object base on recycled command buffers > > > > > 8b44e45347 intel/perf: fix roll over PERF_CNT counter accumulation > > > > > 3d3f21f0be ci: add libdrm to the x86_test-vk container > > > > > 0a939e788f lavapipe: reorder descriptor set stages to get correct binding > > > > > abc724e440 lavapipe: sort bindings before creating descriptor set > > > > > 3436e5295b pan/bi: Treat +DISCARD.f32 as message-passing > > > > > 2c02740a8c intel/mi_builder: Use AddCSMMIOStartOffset for LRI > > > > > d4f21b53f2 nir/range_analysis: Add "is finite" range analysis tracking > > > > > aa5d38decd nir/range_analysis: Add "is a number" range analysis tracking > > > > > f4a7dbc58f nir/range_analysis: Fix analysis of fmin, fmax, or fsat with > NaN source > > > > 30cf07cc8a lavapipe: fix primitive-restart for uint8 indices > > > > > 32eb74e1e1 ac/gpu_info: fix more non-coherent RB and GL2 combinations > > > > > 799a931d12 anv/apply_pipeline_layout: Rework the early pass index/offset > helpers > > > > 3257ab9f23 radv: Dedupe winsyses per device. > > > > > 90632ae7b3 lavapipe: stop tracking draw start/count on rendering state > > > > > f7acdb1d1d st/glthread: allow for invalid L3 cache id. > > > > > a5d5cbdf08 freedreno: Fix file descriptor leak. > > > > > 61cf77583a lavapipe: Free sorted descriptor array. > > > > > 33d87eeb5a gallium: add PIPE_CAP_ALLOW_DYNAMIC_VAO_FASTPATH > > > > > 1df3a00dcd iris: disable dynamic VAO fastpath on GFX version 9 > > > > > 9413c6aec3 mesa: Add anything dynamically indexed before any > non-dynamically indexed > > > > fe53c22294 lavapipe: fix only clearing depth or stencil paths. > > > > > fe5349f70c freedreno/a6xx: Fix alpha tests. > > > > > e4ef5f0433 mesa/st: ignore texture_index if tex_instr has deref src > > > > > 363c1ef0c0 gallium/u_threaded: split draws that don't fit in a batch > > > > > 961361cdc9 aco: ensure loops nested in a WQM loop are in WQM > > > > > 0845cabc72 vulkan: Track dependencies of Python > imports___ > 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] Outstanding Mesa 21.0 patches
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10144 should do it. On Fri, Apr 9, 2021 at 12:50 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hi, > > I'll take care of all the lavapipe ones and get a MR up for you later > today. > > > Mike > > On Fri, Apr 9, 2021, 12:39 PM Dylan Baker wrote: > >> Hi all, >> >> I've been a little behind on release work recently, and I'm tryinng to >> cleanup the backlog of patches against the 21.0 branch that haven't been >> applied but have been nominated. Below is the list of outstanding >> patches that either don't apply, or cause regressions. If you'd like to >> have these applied please provide a backport, otherwise I'm going to >> mark all of these as "denominated". >> >> Cheers, >> Dylan >> >> >> 6a29632dd2 Revert "glcpp: disable 'windows' tests" >> >> >> >> >> bd1705a480 vulkan: Make vk_debug_report_callback derive from >> vk_object_base >> >> >> >> 366fb28dac ci: Fix MESA_TEMPLATES_COMMIT value >> >> >> >> >> 0464117ad9 ci: remove nouveau from shader-db runs >> >> >> >> >> 0f7379e308 ci: tracie dashboard URLs only in the failure after the >> testcase >> >> >> >> cff5c40fc3 pan/bi: Fix blend shaders using LD_TILE with MRT >> >> >> >> >> c0c03f29e0 lavapipe: implement physical device group enumeration >> >> >> >> >> b6b3b38434 turnip: consider HW limit on number of views when apply >> multipos opt >> >> >> >> 5a340c0929 vulkan/util: add api to reset object magic + private data. >> >> >> >> >> 226c7ae2a8 lavapipe: reset object base on recycled command buffers >> >> >> >> >> 8b44e45347 intel/perf: fix roll over PERF_CNT counter accumulation >> >> >> >> >> 3d3f21f0be ci: add libdrm to the x86_test-vk container >> >> >> >> >> 0a939e788f lavapipe: reorder descriptor set stages to get correct >> binding >> >> >> >> abc724e440 lavapipe: sort bindings before creating descriptor set >> >> >> >> >> 3436e5295b pan/bi: Treat +DISCARD.f32 as message-passing >> >> >> >> >> 2c02740a8c intel/mi_builder: Use AddCSMMIOStartOffset for LRI >> >> >> >> >> d4f21b53f2 nir/range_analysis: Add "is finite" range analysis tracking >> >> >> >> >> aa5d38decd nir/range_analysis: Add "is a number" range analysis tracking >> >> >> >> >> f4a7dbc58f nir/range_analysis: Fix analysis of fmin, fmax, or fsat with >> NaN source >> >> >> >> 30cf07cc8a lavapipe: fix primitive-restart for uint8 indices >> >> >> >> >> 32eb74e1e1 ac/gpu_info: fix more non-coherent RB and GL2 combinations >> >> >> >> >> 799a931d12 anv/apply_pipeline_layout: Rework the early pass index/offset >> helpers >> >> >> >> 3257ab9f23 radv: Dedupe winsyses per device. >> >> >> >> >> 90632ae7b3 lavapipe: stop tracking draw start/count on rendering state >> >> >> >> >> f7acdb1d1d st/glthread: allow for invalid L3 cache id. >> >> >> >> >> a5d5cbdf08 freedreno: Fix file descriptor leak. >> >> >> >> >> 61cf77583a lavapipe: Free sorted descriptor array. >> >> >> >> >> 33d87eeb5a gallium: add PIPE_CAP_ALLOW_DYNAMIC_VAO_FASTPATH >> >> >> >> >> 1df3a00dcd iris: disable dynamic VAO fastpath on GFX version 9 >> >> >> >> >> 9413c6aec3 mesa: Add anything dynamically indexed before any >> non-dynamically indexed >> >> >> >> fe53c22294 lavapipe: fix only clearing depth or stencil paths. >> >> >> >> >> fe5349f70c freedreno/a6xx: Fix alpha tests. >> >> >> >> >> e4ef5f0433 mesa/st: ignore texture_index if tex_instr has deref src >> >> >> >> >> 363c1ef0c0 gallium/u_threaded: split draws that don't fit in a batch >> >> >> >> >> 961361cdc9 aco: ensure loops nested in a WQM loop are in WQM >> >> >> >> >> 0845cabc72 vulkan: Track dependencies of Python >> imports___ >> 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] outstanding patches for 21.2
You can drop the zink patches, I have a hard time figuring out how time works these days. On Wed, Sep 15, 2021, 1:09 PM Dylan Baker wrote: > Hi everyone, there's a few patch now outstanding for the 21.2 branch, > and I'd like to get some help from the relavent develoeprs on either > backporting them, or droping them. I've commented them as relavent > > 2021-08-10 FIXES a79ac1bee1 freedreno: Use correct key for binning pass > shader > > 2021-08-11 CC 89e452883a pan/bi: Use FABSNEG pseudo ops for modifier > prop > - Alyssa : I think you'd said you'd be okay dropping the nomination of >this patch for 21.2? > > 2021-08-11 CC ac636f5adb pan/bi: Use FCLAMP pseudo op for clamp prop > - Alyssa : but you wanted this one? > > 2021-08-17 FIXES 48b1b159ff llvmpipe: take intersection with bbox for > non-legacy points > 2021-08-20 CC 4a51366144 panfrost: Evaluate blend shaders per-sample > 2021-08-23 CC 5c4b54ce96 pan/mdg: Handle swapped 565 and 1010102 unorm > 2021-08-23 CC e245468eb4 panfrost: Port v5 blend shader issue to > blitter > 2021-08-24 CC 16b4916432 panfrost: Take a ctx when > submitting/destroying > 2021-08-25 CC 2e464e69b9 intel/isl: Fix halign/valign of uncompressed > views > 2021-08-26 CC e0533ebf16 intel/compiler: INT DIV function does not > support source modifiers > 2021-08-31 FIXES 291d0795a3 llvmpipe/fs: fix multisample depth/stencil fs > writes. > 2021-09-01 FIXES 6373dd814a ir3/a6xx,freedreno: account for resinfo > return size dependency on IBO_0_FMT > 2021-09-03 CC f241bd3749 aco: don't coalesce constant copies into > non-power-of-two sizes > > 2021-09-03 CC 268158a758 aco/optimize_postRA: Use iterators instead of > operator[] of std::array. > - There's been some pretty significant changes to the code between main >and 21.2, it's not clear to me that we can use iterators on 21.2, but >maybe someone else wants to lok at it? > > 2021-09-13 FIXES eb7d2ef070 zink: initialize > zink_descriptor_layout_key::use_count on create > - This adds a completely new function to 21.2 > > 2021-09-13 FIXES a810e58051 zink: use bind_stages for pipeline barrier > generation > - This adds a completely new file to 21.2 > > Thanks, > Dylan
Re: [Mesa-dev] Workflow Proposal
On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen wrote: > On Wed, Oct 6, 2021 at 7:07 PM Jason Ekstrand > wrote: > > > > On Wed, Oct 6, 2021 at 11:24 AM Emma Anholt wrote: > > > > > > On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz > > > wrote: > > > > > > > > Hi, > > > > > > > > It's recently come to my attention that gitlab has Approvals. Was > anyone else aware of this feature? You can just click a button and have > your name recorded in the system as having signed off on landing a patch? > Blew my mind. > > > > > > > > So with that being said, we also have this thing in the Mesa repo > where everyone* has to constantly be adding these esoteric tags like > Reviewed-by (I reviewed it), and Acked-by (I rubber stamped it), or > Tested-by (I compiled it and maybe ran glxgears), and so forth. > > > > > > > > * Except some incredibly smart people already know where I'm going > with this > > > > > > > > Instead of continuing to have to manually update each patch with the > appropriate and definitely-unforgeable tags, what if we just used Approvals > in the UI instead? We could then have marge-bot require approvals as needed > in components and bring reviewing into the current year. Just think: no > more rewriting all the commit logs and force-pushing the branch again > before you merge! > > > > > > > > Anyway, I thought maybe this would be a nice idea to improve > everyone's workflows. What do other people think? > > > > My primary grip with approvals or the button is that it's the wrong > > granularity. It's per-MR instead of per-patch. When people are > > regularly posting MRs that touch a bunch of different stuff, per-patch > > review is pretty common. I'm not sure I want to lose that. :-/ > > Would it be an option to get Marge to not remove existing Rb tags, so > we could get the streamlined process where possible and fall back if > the MRs turn more complicated? > If people really, truly care about per-patch Approval, couldn't they just split out patches from bigger MRs and get Approvals there? Otherwise it should be trivial enough to check the gitlab MR and see who reviewed which patch if it becomes an issue at a later date. Odds are at that point you're already going to the MR to see wtf someone was thinking... > > (as an aside I think we should just drop the tags in git, but I'll > take anything that moves us forward) > > > > --Jason > > > > > I would love to see this be the process across Mesa. We already don't > > > rewrite commit messages for freedreno and i915g, and I only have to do > > > the rebase (busy-)work for my projects in other areas of the tree. > > > > > > I don't think we should have marge-bot require approvals > > > per-component, though. There are times when an MR only incidentally > > > touches a component (for example, changing function signatures in > > > gallium), and actually getting a dev from every driver to sign off on > > > it would be too much. >
[Mesa-dev] Workflow Proposal
Hi, It's recently come to my attention that gitlab has Approvals. Was anyone else aware of this feature? You can just click a button and have your name recorded in the system as having signed off on landing a patch? Blew my mind. So with that being said, we also have this thing in the Mesa repo where everyone* has to constantly be adding these esoteric tags like Reviewed-by (I reviewed it), and Acked-by (I rubber stamped it), or Tested-by (I compiled it and maybe ran glxgears), and so forth. * Except some incredibly smart people already know where I'm going with this Instead of continuing to have to manually update each patch with the appropriate and definitely-unforgeable tags, what if we just used Approvals in the UI instead? We could then have marge-bot require approvals as needed in components and bring reviewing into the current year. Just think: no more rewriting all the commit logs and force-pushing the branch again before you merge! Anyway, I thought maybe this would be a nice idea to improve everyone's workflows. What do other people think? Mike
Re: [Mesa-dev] Workflow Proposal
On Wed, Oct 6, 2021 at 2:46 PM Jason Ekstrand wrote: > On Wed, Oct 6, 2021 at 12:37 PM Mike Blumenkrantz > wrote: > > > > On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen < > b...@basnieuwenhuizen.nl> wrote: > >> > >> On Wed, Oct 6, 2021 at 7:07 PM Jason Ekstrand > wrote: > >> > > >> > On Wed, Oct 6, 2021 at 11:24 AM Emma Anholt wrote: > >> > > > >> > > On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz > >> > > wrote: > >> > > > > >> > > > Hi, > >> > > > > >> > > > It's recently come to my attention that gitlab has Approvals. Was > anyone else aware of this feature? You can just click a button and have > your name recorded in the system as having signed off on landing a patch? > Blew my mind. > >> > > > > >> > > > So with that being said, we also have this thing in the Mesa repo > where everyone* has to constantly be adding these esoteric tags like > Reviewed-by (I reviewed it), and Acked-by (I rubber stamped it), or > Tested-by (I compiled it and maybe ran glxgears), and so forth. > >> > > > > >> > > > * Except some incredibly smart people already know where I'm > going with this > >> > > > > >> > > > Instead of continuing to have to manually update each patch with > the appropriate and definitely-unforgeable tags, what if we just used > Approvals in the UI instead? We could then have marge-bot require approvals > as needed in components and bring reviewing into the current year. Just > think: no more rewriting all the commit logs and force-pushing the branch > again before you merge! > >> > > > > >> > > > Anyway, I thought maybe this would be a nice idea to improve > everyone's workflows. What do other people think? > >> > > >> > My primary grip with approvals or the button is that it's the wrong > >> > granularity. It's per-MR instead of per-patch. When people are > >> > regularly posting MRs that touch a bunch of different stuff, per-patch > >> > review is pretty common. I'm not sure I want to lose that. :-/ > >> > >> Would it be an option to get Marge to not remove existing Rb tags, so > >> we could get the streamlined process where possible and fall back if > >> the MRs turn more complicated? > > > > > > If people really, truly care about per-patch Approval, couldn't they > just split out patches from bigger MRs and get Approvals there? Otherwise > it should be trivial enough to check the gitlab MR and see who reviewed > which patch if it becomes an issue at a later date. Odds are at that point > you're already going to the MR to see wtf someone was thinking... > > That's a really easy thing to say but this is an actual problem and > one I hit on a regular basis. Take, for instance, this MR: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13045 > > What am I supposed to do? Should I post one MR and merge it as soon > as at least one representative from each touched driver approves? On > the above MR, I've gotten quite a few people to sign off on the > search-and-replace driver patch but no one has yet to look at the > common bits. How do I know when those are reviewed? Or should I > assume everyone who clicks "approve" reviewed every part of the MR > that touches their driver. That would mean the common bits would get > reviewed 6 times which, while great for code quality, is a waste of > review time. > > Or maybe I can split it up. Make one MR with all the common > improvements, then 6 per-driver MRs and then another big MR that goes > on top of the per-driver MRs? In that case, because GitLab also > doesn't have a concept of MR dependencies, the initial common patches > are going to be in all 8, and everything's going to be in the last > one. How the "what did they review?" confusion is even worse. > > And, no, I can't trust people to approve the MR they intend to. Just > the other day, I posted !13184 which explicitly said in the > description that it's based on !13156 and you (Mike) reviewed a patch > from !13156 on !13184. > And I stand by that review! > > Or should I post the one MR for common code first and then wait for > that to land before posting the per-driver MRs. That doesn't work out > well because can be very important, when reviewing common code, to see > how it impacts your driver. > > Just to be clear, the above are all genuine questions. I want the > button-based review process as much as the next person but I have
Re: git and Marge troubles this week
We might want to consider pushing out the branch point a week anyway to help people get CTS in order? On Fri, Jan 7, 2022 at 1:08 PM Ian Romanick wrote: > Blarg. That all sounds awful. I think (hope!) I speak for everyone when > I say that we all appreciate your and daniels' efforts to keep this big > piece of machinery working. > > If the problems persist much longer, should we consider pushing out the > 22.0 branch point? > > On 1/6/22 9:36 PM, Emma Anholt wrote: > > As you've probably noticed, there have been issues with git access > > this week. The fd.o sysadmins are desperately trying to stay on > > vacation because they do deserve a break, but have still been working > > on the problem and a couple of solutions haven't worked out yet. > > Hopefully we'll have some news soon. > > > > Due to these ongoing git timeouts, our CI runners have been getting > > bogged down with stalled jobs and causing a lot of spurious failures > > where the pipeline doesn't get all its jobs assigned to runners before > > Marge gives up. Today, I asked daniels to bump Marge's pipeline > > timeout to 4 hours (up from 1). To get MRs flowing at a similar rate > > despite the longer total pipeline times, we also enabled batch mode as > > described at > https://github.com/smarkets/marge-bot/blob/master/README.md#batching-merge-requests > . > > > > It means there are now theoretical cases as described in the README > > where Marge might merge a set of code that leaves main broken. > > However, those cases are pretty obscure, and I expect that failure > > rate to be much lower than the existing "you can merge flaky code" > > failure rate and worth the risk. > > > > Hopefully this gets us all productive again. >
Spam
Hi, As everyone has likely noticed, we've had a significant uptick of spam on Mesa-related IRC channels lately. Sometimes these occurrences go on for many hours before someone takes action. I'd like to request that all commonly-affected channels (#dri-devel, #intel-3d, #freedesktop, ???) take some time over the next week and staff up on more moderators for greater coverage. Mike
Re: Mesa 20.0 backlog
You can just drop the zink patches. I'll make a staging MR for the lavapipe one. Thanks again for all your work! On Fri, Apr 22, 2022 at 12:56 AM Dylan Baker wrote: > Hi all, > > I've spent a good deal of time this week crushing the backlog of > patches on the mesa 20.0 series before making the release today. As such > there are not only a dozen outstanding patches, mostly for zink, which I > couldn't figure out how to correctly backport. > > I've touched base with Lionel about the anv patches, but the remaning > patches I'd appreciate guidance on what you'd like to do with them. > > 2022-03-14 FIXES d5870c45ae panfrost: Optimise recalculation of max > sampler view > 2022-03-24 FIXES f348103fce anv: fix dynamic state emission > 2022-03-24 FIXES a4f502de32 anv: fix > VK_DYNAMIC_STATE_COLOR_WRITE_ENABLE_EXT state > 2022-03-24 FIXES 1d250b7b95 anv: fix color write enable interaction with > color mask > 2022-03-30 CC 4eca6e3e5d lavapipe: fix xfb availability query copying > 2022-04-05 CC 3dcb80da9d zink: fix barrier generation for ssbo > descriptors > 2022-04-11 FIXES dd078d13cb zink: fix tessellation shader key matching. > 2022-04-13 FIXES bbdf22ce13 radv: Fix barriers with cp dma > 2022-04-18 CC 8806f444a5 zink: fix extended restart prim types without > dynamic state2 > 2022-04-21 CC 373c8001d6 zink: set VK_QUERY_RESULT_WAIT_BIT when > copying to qbo > 2022-04-21 CC a056cbc691 zink: fix synchronization when drawing from > streamout > 2022-04-21 CC fc5edf9b68 zink: fix xfb counter buffer barriers > 2022-04-21 CC e509598470 zink: remove xfb_barrier flag > > Cheers, > Dylan
Re: Mesa 20.0 backlog
Actually I lied: the lavapipe patch can't be applied to that branch, so it can be ignored too. On Fri, Apr 22, 2022 at 6:53 AM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > You can just drop the zink patches. I'll make a staging MR for the > lavapipe one. > > Thanks again for all your work! > > On Fri, Apr 22, 2022 at 12:56 AM Dylan Baker wrote: > >> Hi all, >> >> I've spent a good deal of time this week crushing the backlog of >> patches on the mesa 20.0 series before making the release today. As such >> there are not only a dozen outstanding patches, mostly for zink, which I >> couldn't figure out how to correctly backport. >> >> I've touched base with Lionel about the anv patches, but the remaning >> patches I'd appreciate guidance on what you'd like to do with them. >> >> 2022-03-14 FIXES d5870c45ae panfrost: Optimise recalculation of max >> sampler view >> 2022-03-24 FIXES f348103fce anv: fix dynamic state emission >> 2022-03-24 FIXES a4f502de32 anv: fix >> VK_DYNAMIC_STATE_COLOR_WRITE_ENABLE_EXT state >> 2022-03-24 FIXES 1d250b7b95 anv: fix color write enable interaction with >> color mask >> 2022-03-30 CC 4eca6e3e5d lavapipe: fix xfb availability query copying >> 2022-04-05 CC 3dcb80da9d zink: fix barrier generation for ssbo >> descriptors >> 2022-04-11 FIXES dd078d13cb zink: fix tessellation shader key matching. >> 2022-04-13 FIXES bbdf22ce13 radv: Fix barriers with cp dma >> 2022-04-18 CC 8806f444a5 zink: fix extended restart prim types >> without dynamic state2 >> 2022-04-21 CC 373c8001d6 zink: set VK_QUERY_RESULT_WAIT_BIT when >> copying to qbo >> 2022-04-21 CC a056cbc691 zink: fix synchronization when drawing from >> streamout >> 2022-04-21 CC fc5edf9b68 zink: fix xfb counter buffer barriers >> 2022-04-21 CC e509598470 zink: remove xfb_barrier flag >> >> Cheers, >> Dylan > >
GL Error Handling: Is Mesa Broken?
Hi, I did a GL 4.6 CTS run today on a very recent version of CTS, and I found a class of tests which target failure cases (specifically return codes) for various API. A number of these tests failed, which means they fail for all Mesa drivers, which means the upcoming CTS release will be impossible for any Mesa driver to achieve conformance with. I'd ask any and all GL experts to check out this ticket https://gitlab.freedesktop.org/mesa/mesa/-/issues/6851 and try to help see whether the tests in question are broken or whether Mesa is broken. Mike
gallium pruning
Hi, In accordance with some gitlab discussions, I'm looking at removing rbug/xvmc/graw tests https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18705 If you have feedback about this, please comment on the merge request. Mike
Zink MR signoff tags
Hi, After some vigorous and robust discussion with Erik, we've decided that zink will no longer require any rb/ab/etb tags to be applied to patches in MRs. Following in Turnip's footsteps, any MR that receives sufficient reviewage in gitlab comments can be merged directly with no further action necessary. Mike
IRC moderation
Hi, We went through this already some time ago, but we've been getting increasing amounts of spam in #dri-devel, and the current number/availability of moderators doesn't appear to be sufficient. Can we add some people to the ops list to improve the situation? Thanks, Mike
Re: Increase memory size of Lavapipe device?
Hm that should probably query the total available memory on the system. You can submit an MR to make that change if you're interested? Mike On Tue, Apr 11, 2023 at 9:35 AM George Karpathios wrote: > Hi list, > > I'd like to ask how I can increase the memory of the Lavapipe device > over 2GB that vulkaninfo reports. I didn't find any configuration options > or environment variables available. Should I just manually change the size > property at lvp_device.c:1441 and rebuild or is it more complicated? Thanks > in advance. > > Best regards, > George >
Re: Performance issues with Lavapipe in Windows (?)
Looks like it's compiling a lot of shader variants. You could try adding a return at the top of update_inline_shader_state() to see if it's trying too hard to inline. On Fri, Apr 7, 2023 at 9:53 AM George Karpathios wrote: > Hi again, thank you Adam & Marek for your feedback! I appreciate it. > > Unfortunately It's the same amount of time even if I skip the swapchain. I > have profiled some seconds of the execution using Visual Studio's profiler > (with the swapchain, normally) while panning an almost empty scene, and > it's identifying a hotpath. I have uploaded 2 screenshots of the call tree > at https://imgur.com/a/cxtXdOz if you'd like to check it out. > > Another thing I'd like to note is that by using Mesa 23.1-dev (instead of > 23.0.1) I got a nice performance boost of ~2-3x. However it's still > performing slower than what I'd expect on this system (right now it takes > 60ms for 10 lines so I feel that something weird is still going on). Big > congratulations on your tremendous work anyway. > > Best regards, > George > > > On Tue, Apr 4, 2023 at 9:24 PM Adam Jackson wrote: > >> My first suspicion would be to rule out window system interaction. If you >> render to your own VkImage instead of to a swapchain, how fast can you go? >> >> - ajax >> >> >> On Tue, Apr 4, 2023 at 12:56 PM George Karpathios >> wrote: >> >>> Hi list, I hope all is well. >>> >>> I would like to ask if there are any known issues regarding the >>> performance of Lavapipe in Windows 10. >>> >>> I'm trying to add support for Vulkan software rendering into a >>> relatively large 3d modeling/rendering application, so I opted to try Mesa >>> and Lavapipe. I built LLVM 16.0.0 and Mesa 23.0.1 using the documentation >>> (thanks for that!). My environment is an 8-core Intel i7 (with an >>> integrated iGPU) with 32GiB RAM, an nVidia RTX 3070 and Visual Studio >>> 2019/MSVC. >>> >>> The build procedure seems to be ok (Release builds, proper linking with >>> either MT or MD runtime libraries, proper DLL loading via VK_ICD_FILENAMES) >>> but the performance I'm getting during runtime is very slow. It looks like >>> it needs 1-1.5 seconds to render a virtually empty scene (think just a >>> floor grid of lines) and over 15-20 seconds for a frame of a few thousand >>> vertices. The CPU utilisation also seems to be low, under 20-25%. >>> >>> I understand that the information I provide is probably vague, but at >>> this point I just want to rule some probable causes out, like is there any >>> version of LLVM or Mesa or combination of them that is known to have such >>> issues? Maybe some build/installation configuration parameter or >>> environment variable that is important in Windows specifically and I may >>> have missed (I tried tweaking LP_NUM_THREADS but didn't change anything) ? >>> Anything that could point me in the right direction is highly valuable & >>> appreciated. >>> >>> Also probably worth noting is the fact that the vkcube(pp) demo from the >>> Vulkan SDK seems to run ok with Lavapipe, but in this case I also notice >>> (in task manager) a ~50% utilization of the integrated iGPU (why?). In the >>> aforementioned larger application I don't notice any usage of the >>> integrated iGPU. >>> >>> Any advice on what I could check/double check is more than welcome. >>> Thank you in advance for your time. >>> >>> Best regards, >>> George >>> >>> >>>
Re: Performance issues with Lavapipe in Windows (?)
You can try deleting the lvp_find_inlinable_uniforms() call from lvp_pipeline.c as a temporary workaround. I'll try something on my end to make this less stupid. On Fri, Apr 7, 2023 at 10:22 AM George Karpathios wrote: > Awesome, thanks for the tip! > > Well now I indeed get *very* nice frame times. Great catch, thank you! > But I don't see anything on the viewport, I guess due to the early return. > How should I proceed? > > Best regards, > George > > > On Fri, Apr 7, 2023 at 4:56 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > >> Looks like it's compiling a lot of shader variants. >> >> You could try adding a return at the top of update_inline_shader_state() >> to see if it's trying too hard to inline. >> >> On Fri, Apr 7, 2023 at 9:53 AM George Karpathios >> wrote: >> >>> Hi again, thank you Adam & Marek for your feedback! I appreciate it. >>> >>> Unfortunately It's the same amount of time even if I skip the swapchain. >>> I have profiled some seconds of the execution using Visual Studio's >>> profiler (with the swapchain, normally) while panning an almost empty >>> scene, and it's identifying a hotpath. I have uploaded 2 screenshots of the >>> call tree at https://imgur.com/a/cxtXdOz if you'd like to check it >>> out. >>> >>> Another thing I'd like to note is that by using Mesa 23.1-dev (instead >>> of 23.0.1) I got a nice performance boost of ~2-3x. However it's still >>> performing slower than what I'd expect on this system (right now it takes >>> 60ms for 10 lines so I feel that something weird is still going on). Big >>> congratulations on your tremendous work anyway. >>> >>> Best regards, >>> George >>> >>> >>> On Tue, Apr 4, 2023 at 9:24 PM Adam Jackson wrote: >>> >>>> My first suspicion would be to rule out window system interaction. If >>>> you render to your own VkImage instead of to a swapchain, how fast can you >>>> go? >>>> >>>> - ajax >>>> >>>> >>>> On Tue, Apr 4, 2023 at 12:56 PM George Karpathios >>>> wrote: >>>> >>>>> Hi list, I hope all is well. >>>>> >>>>> I would like to ask if there are any known issues regarding the >>>>> performance of Lavapipe in Windows 10. >>>>> >>>>> I'm trying to add support for Vulkan software rendering into a >>>>> relatively large 3d modeling/rendering application, so I opted to try Mesa >>>>> and Lavapipe. I built LLVM 16.0.0 and Mesa 23.0.1 using the documentation >>>>> (thanks for that!). My environment is an 8-core Intel i7 (with an >>>>> integrated iGPU) with 32GiB RAM, an nVidia RTX 3070 and Visual Studio >>>>> 2019/MSVC. >>>>> >>>>> The build procedure seems to be ok (Release builds, proper linking >>>>> with either MT or MD runtime libraries, proper DLL loading via >>>>> VK_ICD_FILENAMES) but the performance I'm getting during runtime is very >>>>> slow. It looks like it needs 1-1.5 seconds to render a virtually empty >>>>> scene (think just a floor grid of lines) and over 15-20 seconds for a >>>>> frame of a few thousand vertices. The CPU utilisation also seems to be >>>>> low, >>>>> under 20-25%. >>>>> >>>>> I understand that the information I provide is probably vague, but at >>>>> this point I just want to rule some probable causes out, like is there any >>>>> version of LLVM or Mesa or combination of them that is known to have such >>>>> issues? Maybe some build/installation configuration parameter or >>>>> environment variable that is important in Windows specifically and I may >>>>> have missed (I tried tweaking LP_NUM_THREADS but didn't change anything) ? >>>>> Anything that could point me in the right direction is highly valuable & >>>>> appreciated. >>>>> >>>>> Also probably worth noting is the fact that the vkcube(pp) demo from >>>>> the Vulkan SDK seems to run ok with Lavapipe, but in this case I also >>>>> notice (in task manager) a ~50% utilization of the integrated iGPU (why?). >>>>> In the aforementioned larger application I don't notice any usage of the >>>>> integrated iGPU. >>>>> >>>>> Any advice on what I could check/double check is more than welcome. >>>>> Thank you in advance for your time. >>>>> >>>>> Best regards, >>>>> George >>>>> >>>>> >>>>>
Re: Lavapipe performance question during interactive drawing
Hi, Can you try commenting out the same lines from last time and see whether that affects anything? Mike On Fri, May 5, 2023 at 7:30 AM George Karpathios wrote: > Hi list, > > I'm using Lavapipe for Vulkan software rendering support in a modeling > application. I notice a large performance hit (with any Mesa version) in > the following scenario: The user clicks & drags the mouse in order to > create a simple shape (e.g. plane, cube, sphere) dynamically and the result > is being rendered (basic gray shading) in real-time alongside the movement > of the mouse. Lavapipe seems to be struggling a bit to keep up with this > action as the frame time goes up to over 1 second. On the other hand, on a > more "static" scene I can get great fps (30-60) while panning/rotating a > scene, after Mike Blumenkrantz's recent improvements (many thanks for those > again!). > > I've uploaded a screenshot of the VS profiler showing the hot path at > https://imgur.com/a/qZBkB51 and I'd appreciate hearing your thoughts on > this. Thanks once more for your time. > > Best regards, > George >
Re: Lavapipe performance question during interactive drawing
Anything as long as it exhibits the issue. On Fri, May 5, 2023 at 11:52 AM George Karpathios wrote: > Not sure, I may have to get approval first. Will see what I can do. If so, > are there any specific options you'd like enabled? Thanks > > Best regards, > George > > On Fri, May 5, 2023 at 5:33 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > >> Can you provide a gfxreconstruct of the scenario? >> >> On Fri, May 5, 2023 at 10:32 AM George Karpathios >> wrote: >> >>> Hi Mike, >>> >>> Thanks for responding. I commented the call >>> to lvp_find_inlinable_uniforms() in lvp_pipeline.c but unfortunately it >>> didn't help this time. It may have gotten a bit worse actually. >>> >>> Best regards, >>> George >>> >>> >>> On Fri, May 5, 2023 at 3:08 PM Mike Blumenkrantz < >>> michael.blumenkra...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> Can you try commenting out the same lines from last time and see >>>> whether that affects anything? >>>> >>>> >>>> Mike >>>> >>>> On Fri, May 5, 2023 at 7:30 AM George Karpathios >>>> wrote: >>>> >>>>> Hi list, >>>>> >>>>> I'm using Lavapipe for Vulkan software rendering support in a modeling >>>>> application. I notice a large performance hit (with any Mesa version) in >>>>> the following scenario: The user clicks & drags the mouse in order to >>>>> create a simple shape (e.g. plane, cube, sphere) dynamically and the >>>>> result >>>>> is being rendered (basic gray shading) in real-time alongside the movement >>>>> of the mouse. Lavapipe seems to be struggling a bit to keep up with this >>>>> action as the frame time goes up to over 1 second. On the other hand, on a >>>>> more "static" scene I can get great fps (30-60) while panning/rotating a >>>>> scene, after Mike Blumenkrantz's recent improvements (many thanks for >>>>> those >>>>> again!). >>>>> >>>>> I've uploaded a screenshot of the VS profiler showing the hot path at >>>>> https://imgur.com/a/qZBkB51 and I'd appreciate hearing your thoughts >>>>> on this. Thanks once more for your time. >>>>> >>>>> Best regards, >>>>> George >>>>> >>>>
Re: Lavapipe performance question during interactive drawing
Can you provide a gfxreconstruct of the scenario? On Fri, May 5, 2023 at 10:32 AM George Karpathios wrote: > Hi Mike, > > Thanks for responding. I commented the call > to lvp_find_inlinable_uniforms() in lvp_pipeline.c but unfortunately it > didn't help this time. It may have gotten a bit worse actually. > > Best regards, > George > > > On Fri, May 5, 2023 at 3:08 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > >> Hi, >> >> Can you try commenting out the same lines from last time and see whether >> that affects anything? >> >> >> Mike >> >> On Fri, May 5, 2023 at 7:30 AM George Karpathios >> wrote: >> >>> Hi list, >>> >>> I'm using Lavapipe for Vulkan software rendering support in a modeling >>> application. I notice a large performance hit (with any Mesa version) in >>> the following scenario: The user clicks & drags the mouse in order to >>> create a simple shape (e.g. plane, cube, sphere) dynamically and the result >>> is being rendered (basic gray shading) in real-time alongside the movement >>> of the mouse. Lavapipe seems to be struggling a bit to keep up with this >>> action as the frame time goes up to over 1 second. On the other hand, on a >>> more "static" scene I can get great fps (30-60) while panning/rotating a >>> scene, after Mike Blumenkrantz's recent improvements (many thanks for those >>> again!). >>> >>> I've uploaded a screenshot of the VS profiler showing the hot path at >>> https://imgur.com/a/qZBkB51 and I'd appreciate hearing your thoughts >>> on this. Thanks once more for your time. >>> >>> Best regards, >>> George >>> >>
CI formatting pre-hook
Hi, In recent times, Mesa CI has grown the clang-format job which enforces formatting in some parts of the tree. I hate this job, and I think the majority of Mesa developers also hate this job. This majority is, of course, excluding a small number of very vocal enthusiasts, as seen in e.g., https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23719 (a response to an admittedly unilateral action). Why do I hate this formatting job, you might be asking. Let's look at a test pipeline from a recent refactoring series: https://gitlab.freedesktop.org/zmike/mesa/-/pipelines/1108274. Oh no, clang-format failed. https://gitlab.freedesktop.org/zmike/mesa/-/jobs/55270157 Out of 4 hunks it rejected, all the fails are nonsensical line wrapping preferences that nobody cares about. In some cases, my changes didn't even affect the rejected lines, and yet somehow I am now responsible for "fixing" them. It's not the first time I've seen this sort of thing, and, even if line wrapping heuristics improve, I'm sure it won't be the last time this situation occurs. These types of CI fails are a waste of both CI time and collective developer effort. If people want to enforce code formatting across their little part of the tree, that should be the responsibility of the reviewer. To that end, I've created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27702 which changes errors in clang-format jobs to warnings. If the job fails, the pipeline can still succeed. I think this is a better balance between people who want to opt-in to formatting checks for their parts of the tree and people who absolutely don't: if a reviewer cares about formatting, they're free to run a test pipeline and check the format job's results. If they aren't happy with it, they can block the MR until changes are addressed. This also provides some leeway where obviously stupid changes proposed by the job (as above) can be ignored. Thoughts? Mike
Re: Future direction of the Mesa Vulkan runtime (or "should we build a new gallium?")
On one hand I think it's a great idea. Moving code out of drivers to common means fixing bugs helps everyone, and implementing new features is the same. On the other hand, everyone's already got code that works, which means both a lot of work to switch that code over to common and then the usual cycle of fixing regressions. Gallium is generally pretty great now, so my gut says a 'Zirkonium' common layer is eventually gonna be pretty good too, assuming it can provide the same sorts of efficiency gains; vulkan is a lot thinner than GL, which means CPU utilization becomes more noticable very easily. I'm not saying I'll dive in head first tomorrow, but generally speaking I think 10 years from now it'll be a nice thing to have. Mike On Fri, Jan 19, 2024, 4:02 PM Faith Ekstrand wrote: > Yeah, this one's gonna hit Phoronix... > > When we started writing Vulkan drivers back in the day, there was this > notion that Vulkan was a low-level API that directly targets hardware. > Vulkan drivers were these super thin things that just blasted packets > straight into the hardware. What little code was common was small and > pretty easy to just copy+paste around. It was a nice thought... > > What's happened in the intervening 8 years is that Vulkan has grown. A lot. > > We already have several places where we're doing significant layering. > It started with sharing the WSI code and some Python for generating > dispatch tables. Later we added common synchronization code and a few > vkFoo2 wrappers. Then render passes and... > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024 > > That's been my project the last couple weeks: A common VkPipeline > implementation built on top of an ESO-like interface. The big > deviation this MR makes from prior art is that I make no attempt at > pretending it's a layered implementation. The vtable for shader > objects looks like ESO but takes its own path when it's useful to do > so. For instance, shader creation always consumes NIR and a handful of > lowering passes are run for you. It's no st_glsl_to_nir but it is a > bit opinionated. Also, a few of the bits that are missing from ESO > such as robustness have been added to the interface. > > In my mind, this marks a pretty fundamental shift in how the Vulkan > runtime works, at least in my mind. Previously, everything was > designed to be a toolbox where you can kind of pick and choose what > you want to use. Also, everything at least tried to act like a layer > where you still implemented Vulkan but you could leave out bits like > render passes if you implemented the new thing and were okay with the > layer. With the ESO code, you implement something that isn't Vulkan > entrypoints and the actual entrypoints live in the runtime. This lets > us expand and adjust the interface as needed for our purposes as well > as sanitize certain things even in the modern API. > > The result is that NVK is starting to feel like a gallium driver. > > So here's the question: do we like this? Do we want to push in this > direction? Should we start making more things work more this way? I'm > not looking for MRs just yet nor do I have more reworks directly > planned. I'm more looking for thoughts and opinions as to how the > various Vulkan driver teams feel about this. We'll leave the detailed > planning for the Mesa issue tracker. > > It's worth noting that, even though I said we've tried to keep things > layerish, there are other parts of the runtime that look like this. > The synchronization code is a good example. The vk_sync interface is > pretty significantly different from the Vulkan objects it's used to > implement. That's worked out pretty well, IMO. With as complicated as > something like pipelines or synchronization are, trying to keep the > illusion of a layer just isn't practical. > > So, do we like this? Should we be pushing more towards drivers being a > backed of the runtime instead of a user of it? > > Now, before anyone asks, no, I don't really want to build a multi-API > abstraction with a Vulkan state tracker. If we were doing this 5 years > ago and Zink didn't already exist, one might be able to make an > argument for pushing in that direction. However, that would add a huge > amount of weight to the project and make it even harder to develop the > runtime than it already is and for little benefit at this point. > > Here's a few other constraints on what I'm thinking: > > 1. I want it to still be possible for drivers to implement an > extension without piles of runtime plumbing or even bypass the runtime > on occasion as needed. > > 2. I don't want to recreate the gallium cap disaster drivers should > know exactly what they're advertising. We may want to have some > internal features or properties that are used by the runtime to make > decisions but they'll be in addition to the features and properties in > Vulkan. > > 3. We've got some meta stuff already but we probably want more. > However, I don't want to
Re: Intel clc dependency
This doesn't solve the problem about missing CLC, but I pass
-Dintel_rt=disabled to avoid the whole thing.
On Fri, Apr 5, 2024, 6:05 PM Brian Paul wrote:
> I'm trying to build the Intel Vulkan driver. First time in a few
> months. I'm having build problems related to clc. I'm on Ubuntu 22.04
>
>
> [...]
> [1347/3181] Generating src/intel/vulkan/...om command (wrapped by meson
> to set env)
> FAILED:
> src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h
> env MESA_SHADER_CACHE_DISABLE=true MESA_SPIRV_LOG_LEVEL=error
> /home/brianp/build3/mesa/build/src/intel/compiler/intel_clc -p dg2
> --prefix gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable -e
> BFS_pass1_indexed_batchable --in
> ../src/intel/vulkan/grl/gpu/bvh_build_BFS.cl --in
> /home/brianp/build3/mesa/src/intel/vulkan/grl/gpu/libs/
> lsc_intrinsics_fallback.cl
> -o
> src/intel/vulkan/grl/gfx125_bvh_build_BFS_BFS_pass1_indexed_batchable.h
> -- -cl-std=cl2.0 -D__OPENCL_VERSION__=200 -DMAX_HW_SIMD_WIDTH=16
> -DMAX_WORKGROUP_SIZE=16
> -I/home/brianp/build3/mesa/src/intel/vulkan/grl/gpu
> -I/home/brianp/build3/mesa/src/intel/vulkan/grl/include
> ERROR: libclc shader missing. Consider installing the libclc package
> Aborted (core dumped)
>
> I've installed every clc-related package I could find. I've tried
> several options for the 'intel-clc' option without luck.
>
> BTW, the description of intel-clc in meson_options.txt looks suspect:
>
> option(
>'intel-clc',
>type : 'combo',
>deprecated: {'true': 'enabled', 'false': 'disabled'},
>value : 'disabled',
>choices : [
> 'enabled', 'disabled', 'system',
>],
>description : 'Build the intel-clc compiler (enables Vulkan Intel ' +
> 'Ray Tracing on supported hardware).'
> )
>
> The default is 'disabled' but that's deprecated? Choices include
> 'enabled' but that's deprecated too?
>
> Any tips for building the ToT Intel Vulkan driver?
>
> -Brian
>
> --
> This electronic communication and the information and any files
> transmitted
> with it, or attached to it, are confidential and are intended solely for
> the use of the individual or entity to whom it is addressed and may
> contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are
> not the intended recipient or the person responsible for delivering the
> e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
>
