Re: Downsides of force_gl_names_reuse preventing adoption as default
The only error is that virgl fails with: ERROR - dEQP error: [ 135.132231] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response 0x1200 (command 0x206) That's the only blocker. Marek On Thu, Oct 3, 2024, 14:03 Marek Olšák wrote: > > https://gitlab.freedesktop.org/mareko/mesa/-/commit/cdde6fcb7947514753c1a3feaee71c2212cffea6 > > If I remember correctly, it failed some tests. > > Marek > > On Thu, Oct 3, 2024 at 3:53 AM Rocco Tormenta wrote: > > > > Hi there, apologies if this has already been asked, I couldn't find > > relevant information on the matter. > > > > Recently I've come across some faulty applications (notably, old > > Minecraft versions) that were calling `glBind*` functions with IDs of > > -1, resulting in very slow performance due to the hash table defaulting > > to full lookups. > > > > Skimming through the source code I've noticed that a while ago, name > > reusing/sparse names were implemented using idalloc (see MR > > mesa/mesa!6600), locked behind a config flag. Indeed, setting the > > force_gl_names_reuse=true environment variable fixes the performance > issue. > > > > The comment on the MR that added this feature mentions that this > > behavior is in line with that of major proprietary drivers, so I was > > wondering why this was added as an optional flag, instead of making it > > the default behavior. I did find some potential reasons that could have > > blocked the transition back when it was merged, though. For example, > > more recently a commit was made (MR mesa/mesa!30106) lowering virtual > > memory usage of the idalloc approach from 512MB to 512KB in the > > worst-case scenario, so perhaps the higher memory footpring might have > > discouraged adoption at the beginning. With such low requirements now, > > however, perhaps it's worth reconsidering the default choice to benefit > > from higher robustness against misuse of the API. > > > > Is there anything I missed? > > > > Rocco > > >
[ANNOUNCE] mesa 24.2.4
Hello everyone, The bugfix release 24.2.4 is now available. If you find any issues, please report them here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/new The next bugfix release is due in two weeks, on October 16th. Cheers, Eric --- Aleksi Sapon (2): llvmpipe: fix quad group helper invocation masking llvmpipe: correctly implement output variables loads Benjamin Otte (1): nvk: Don't emit critical messages during init Boris Brezillon (1): pan/va: Fix nir_op_pack_uvec4_to_uint Caio Oliveira (1): intel/brw: Skip per-primitive inputs when computing flat input mask Colin Marc (2): vulkan/video: set HEVC nuh_temporal_id_plus1 and nal_unit_type correctly radv/video: set TemporalId correctly Corentin Noël (1): virgl: Avoid a race condition on handle removal Daniel Svensson (1): zink: add spirv_info_h dep to libzink. Dave Airlie (3): radv/video/enc: report pictureAccessGranularity of CTB size. radv/video: add encode field for vcn4 radv/video: handle missing h265 feedback struct. David Heidelberg (2): freedreno/ir3: mad.x24 is not safe to lower freedreno/ir3: Do not allow 16-bit mad.x24 David Rosca (2): radeonsi/vcn: Don't reuse context with multiple VCN instances frontends/va: Fix AV1 packed header parsing Eric Engestrom (12): docs: add sha sum for 24.2.3 .pick_status.json: Update to 00c94e0cd4d46b093c20b2ec2be35ab3de3cb8a6 .pick_status.json: Mark 4b51a2c9daa92f39a2045ca48f707eb3cdb79018 as denominated .pick_status.json: Update to bf41cf2eeffca5ec102e67f9c5e9f2c65deae43f .pick_status.json: Update to f6e7520b139f45971cdfa027aee29405c13c726d .pick_status.json: Update to a74ebffc6a6193445231563cdaa4494933b6c281 .pick_status.json: Update to 85bc72ad263e0c6620fe8c74d29e68411971013b .pick_status.json: Update to 61f3294786d52f3a95f0fa314eb21d90a0485624 .pick_status.json: Update to 023277173ce1d84c448626ded21e4d2b66363b41 egl: fix dri2_from_names() call docs: add release notes for 24.2.4 VERSION: bump for 24.2.4 Erik Faye-Lund (3): panfrost: unify compressed formats panfrost: store texfeat_bit in panfrost_format panfrost: check fmt.bitfeat_bit for compressed-support Faith Ekstrand (1): nvk: Handle aspects in D32_S8_UINT copies GKraats (2): i915g: fix texture3d npot mipmaps X11: fix crash of gnome-shell if mesa is compiled with legacy-x11=dri2 Gert Wollny (2): nir/opt_algebraic: Allow two-step lowering of ftrunc@64 to use ffract@64 Revert: r600/sfn: call nir_lower_doubles explicitely" Iván Briano (4): anv: free shaders on rt pipeline compile error anv: skip rt pipeline compile if we found all shaders vulkan: use standard sample locations if there's no VkPipelineSampleLocationsStateCreateInfoEXT anv: allocate sparse descriptor buffers from the correct heap José Roberto de Souza (5): anv: Fix context id or exec queue used to open perf stream anv: Add warning about mismatch between query queues anv: Make sure all previous vm binds are done before execute perf query pool anv: Check if vkCreateQueryPool() is being created in a supported queue anv: Fix condition to clear query pool with blorp Kenneth Graunke (1): intel/brw: Don't include sync.nop in INTEL_DEBUG instruction counts Konstantin Seurer (4): radv: Initialize sqtt state before meta state lavapipe: Fix report_ray_intersection affecting terminated rays lavapipe: Do not return in report_ray_intersection radv: Fix report_ray_intersection affecting terminated rays Lionel Landwerlin (12): brw: fix virtual register splitting to not go below physical register size clc: find opencl headers from the installed llvm/clang location anv: fix missing tracking for alpha-to-coverage runtime changes anv: Only flush render target cache when detecting RT changes iris: ensure null render target for specific cases brw: move null_rt control up a layer brw: disable null_rt only if color output does not affect other outputs anv: add missing pipeline instance multiplier zink: avoid host transfer usage with sparse anv: limit 22018402687 to impacted platforms anv: consolidate pre/post draw workaround in helpers anv: optimize WA 16011107343/22018402687 Lucas Fryzek (2): drisw: Copy entire buffer ignoring damage regions egl/dri/wl: Move swrast damage region from put to swap Marek Olšák (1): nir/opt_vectorize_io: fix skipped output vectorization if inputs were vectorized Mike Blumenkrantz (4): vk/image: fix view creation for planar video aspects zink: check HAVE_LIBDRM for xf86drm.h include util/vbuf: delete/fix broken incompatible stride calc mesa: fix sample count handling for MSRTT Mohamed Ahmed (1): nvk: Block off non-2D DRM format modifier i
Re: Downsides of force_gl_names_reuse preventing adoption as default
https://gitlab.freedesktop.org/mareko/mesa/-/commit/cdde6fcb7947514753c1a3feaee71c2212cffea6 If I remember correctly, it failed some tests. Marek On Thu, Oct 3, 2024 at 3:53 AM Rocco Tormenta wrote: > > Hi there, apologies if this has already been asked, I couldn't find > relevant information on the matter. > > Recently I've come across some faulty applications (notably, old > Minecraft versions) that were calling `glBind*` functions with IDs of > -1, resulting in very slow performance due to the hash table defaulting > to full lookups. > > Skimming through the source code I've noticed that a while ago, name > reusing/sparse names were implemented using idalloc (see MR > mesa/mesa!6600), locked behind a config flag. Indeed, setting the > force_gl_names_reuse=true environment variable fixes the performance issue. > > The comment on the MR that added this feature mentions that this > behavior is in line with that of major proprietary drivers, so I was > wondering why this was added as an optional flag, instead of making it > the default behavior. I did find some potential reasons that could have > blocked the transition back when it was merged, though. For example, > more recently a commit was made (MR mesa/mesa!30106) lowering virtual > memory usage of the idalloc approach from 512MB to 512KB in the > worst-case scenario, so perhaps the higher memory footpring might have > discouraged adoption at the beginning. With such low requirements now, > however, perhaps it's worth reconsidering the default choice to benefit > from higher robustness against misuse of the API. > > Is there anything I missed? > > Rocco >
Downsides of force_gl_names_reuse preventing adoption as default
Hi there, apologies if this has already been asked, I couldn't find relevant information on the matter. Recently I've come across some faulty applications (notably, old Minecraft versions) that were calling `glBind*` functions with IDs of -1, resulting in very slow performance due to the hash table defaulting to full lookups. Skimming through the source code I've noticed that a while ago, name reusing/sparse names were implemented using idalloc (see MR mesa/mesa!6600), locked behind a config flag. Indeed, setting the force_gl_names_reuse=true environment variable fixes the performance issue. The comment on the MR that added this feature mentions that this behavior is in line with that of major proprietary drivers, so I was wondering why this was added as an optional flag, instead of making it the default behavior. I did find some potential reasons that could have blocked the transition back when it was merged, though. For example, more recently a commit was made (MR mesa/mesa!30106) lowering virtual memory usage of the idalloc approach from 512MB to 512KB in the worst-case scenario, so perhaps the higher memory footpring might have discouraged adoption at the beginning. With such low requirements now, however, perhaps it's worth reconsidering the default choice to benefit from higher robustness against misuse of the API. Is there anything I missed? Rocco
