<div dir="auto">The only error is that virgl fails with: <div dir="auto"><br></div><div dir="auto"><span style="color:rgb(255,255,255);font-family:"gitlab mono","jetbrains mono",menlo,"dejavu sans mono","liberation mono",consolas,"ubuntu mono","courier new","andale mono","lucida console",monospace;font-size:13px;background-color:rgb(17,17,17)">ERROR - dEQP error: [  135.132231] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response 0x1200 (command 0x206)</span><br></div><div dir="auto"><br></div><div dir="auto">That's the only blocker.</div><div dir="auto"><br></div><div dir="auto">Marek</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2024, 14:03 Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://gitlab.freedesktop.org/mareko/mesa/-/commit/cdde6fcb7947514753c1a3feaee71c2212cffea6" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/mareko/mesa/-/commit/cdde6fcb7947514753c1a3feaee71c2212cffea6</a><br>
<br>
If I remember correctly, it failed some tests.<br>
<br>
Marek<br>
<br>
On Thu, Oct 3, 2024 at 3:53 AM Rocco Tormenta <<a href="mailto:rocco@tormenta.eu" target="_blank" rel="noreferrer">rocco@tormenta.eu</a>> wrote:<br>
><br>
> Hi there, apologies if this has already been asked, I couldn't find<br>
> relevant information on the matter.<br>
><br>
> Recently I've come across some faulty applications (notably, old<br>
> Minecraft versions) that were calling `glBind*` functions with IDs of<br>
> -1, resulting in very slow performance due to the hash table defaulting<br>
> to full lookups.<br>
><br>
> Skimming through the source code I've noticed that a while ago, name<br>
> reusing/sparse names were implemented using idalloc (see MR<br>
> mesa/mesa!6600), locked behind a config flag. Indeed, setting the<br>
> force_gl_names_reuse=true environment variable fixes the performance issue.<br>
><br>
> The comment on the MR that added this feature mentions that this<br>
> behavior is in line with that of major proprietary drivers, so I was<br>
> wondering why this was added as an optional flag, instead of making it<br>
> the default behavior. I did find some potential reasons that could have<br>
> blocked the transition back when it was merged, though. For example,<br>
> more recently a commit was made (MR mesa/mesa!30106) lowering virtual<br>
> memory usage of the idalloc approach from 512MB to 512KB in the<br>
> worst-case scenario, so perhaps the higher memory footpring might have<br>
> discouraged adoption at the beginning. With such low requirements now,<br>
> however, perhaps it's worth reconsidering the default choice to benefit<br>
> from higher robustness against misuse of the API.<br>
><br>
> Is there anything I missed?<br>
><br>
> Rocco<br>
><br>
</blockquote></div>