00:00dcbaker: looking at it again (it's been a long time since I've looked at the piglit framework seriously) it looks right, it's using all ordered containers
00:00anholt: The extensions attribute is using a set, so you do get randomly shuffled content there
00:01anholt: looks like it gets serialized directly, so if I make it an array then you get different container in the encoding and I have no idea what the consequences of that are
00:01dcbaker: which class is this in?
00:02anholt: FastSkip's extensions
00:02anholt: which get encoded in the xml
00:03dcbaker: gah, python with type annotations is terrible, I can't jump to definition :(
00:07dcbaker: it looks like that's only used at runtime and it's only used for 'is $var in $set`, which should be fine, but changing it to a list shouldn't hurt anything other than performance
00:09dcbaker: no idea if it helps, but there is a place in the static shader test discovery where we should be sorting and aren't
00:11anholt: do we have anything other than vs_in that would be taking some fraction of the test list so that that kind of ordering should matter?
00:11dcbaker: I don't think in any other case the ordering matters
00:11anholt: confirmed shaders.xml different.
00:12anholt: https://people.freedesktop.org/~anholt/first.txt and second.txt
00:13dcbaker: I have a `wip/2021-01/fix-ordering` branch on my gitlab piglit tree that might help (not sure)
00:15dcbaker: I have another idea for a bigger hammer, but that will make the serializer take more memory at build time
00:22anholt: oh, oh no
00:22dcbaker: should I be scared?
00:23anholt: take a look at "<Test name="spec@amd_shader_trinary_minmax@execution@built-in-functions" type="multi_shader"> in a no-isolation xml
00:23anholt: maybe multi_shader is better than I'm imagining, but how is that skips list supposed to work?
00:24anholt: maybe they do line up 1:1 to the files.
00:27dcbaker: the skips look correct to me, that's all done by index in the framework
00:27alyssa: Is the mesa build broken for anyone else?
00:27dcbaker: so tit looks at each file, reads the same index skip section, decides if that test will run, and then only passes the ones it thinks should to shader runner
00:27alyssa: ../src/compiler/glsl/gl_nir_linker.h unknown types, etc
00:28dcbaker: the way that all got written and serialized is… a huge pile of hacks
00:28dcbaker: but a huge pile of hacks with a rediculous number of tests
00:29anholt: we definitely have a non-reproducible ordering of the shaders in the multi_shader tests.
00:29alyssa:trying a clean build with clear ccache
00:29anholt: and that feels like it should be fixed.
00:30alyssa: --nope, still broken. what.
00:30alyssa: am I awake? this could be a mesa dream/nightmare..
00:30dcbaker: anholt: agreed
00:30anholt: alyssa: someone missing a build dep on generated code again?
00:31anholt: (I swear, meson's primary deficiency, not detecting those)
00:32dcbaker: I've been thinking about that, I think it might be easier to solve with ninja, if you had a way to force ninja to generate CUSTOM_TARGETS as late in the DAG as possible
00:33dcbaker:has way too many meson projects…
00:33anholt: dcbaker: so that people stumble across it sooner, because the job launches later most of the time?
00:33alyssa: anholt: https://rosenzweig.io/fix.diff
00:34alyssa: ^ This fixes it (I mean, still building but..) it seems like a hack and not addressing the actual issue
00:34anholt: did you somehow install a nir.h? :)
00:34alyssa: ---Oh, __builtin_ffs(0
00:34alyssa: Yes. Somehow I did end up with an emptynir.h in src/compiler
00:34alyssa: I'll show myself out, sorry.
00:35dcbaker: right, if you force them as late in the DAG as possible if there's anything that depends on them but doesn't declare it the build is sure to fail
00:36anholt: dcbaker: in fix-ordering, might I suggest just sorting files instead of sorted()ing twice? and don't sorted(existing), then, so that existing builds can get fixed up with a sorted list.
00:36dcbaker: yeah, that makes more sense
00:37anholt: I'm kind of betting this might just clear up our instability by hiding whatever underlying bug there is, but if it means I get to rebuild containers again, I'll take it.
00:37dcbaker: I'm sure at the time I was trying to just optimize build time
00:37dcbaker: because on my 2 thread HSW I cared a lot about that
00:37dcbaker: I'm still thinking about rewriting that generator anywa
00:38dcbaker: that's the one that generates 2 gigs of shader tests
00:38dcbaker: it would be nice to not do that
00:38anholt: yes, please (once we get this resolved). it would be great to be able to run at least some subset of these tests on hw. vs_in is just unused without it.
00:39dcbaker: My plan is to add a `--quick` switch that does some kind of internal short list
00:39dcbaker: we have a few other very exhastive tests that do that
00:39dcbaker: Paul and Curro tests I think
00:44anholt: I have a lot of sympathy for exhaustive tests, but doing them in shader_runner is bananas.
00:44anholt: we could really use an exhaustive test for idivs in shaders.
00:45dcbaker: I think that was the one that when it landed took 4 minutes to run. So I optimized the crap out of it. Then it got extended to generate even more tests ☹️
07:16imirkin: can i get a second opinion on whether https://www.khronos.org/registry/OpenGL/extensions/NV/NV_shader_atomic_int64.txt adds support for these operations on shared memory?
07:18imirkin: aha, looks like `mem` is allowed to refer to shared memory, per the text in the table it's adding to
07:18imirkin: nevermind, all good :)
08:38imirkin: airlied: does virgl rely on tgsi in any way? if so, does it rely on the bit encoding of things like instructions/etc?
20:39Vanfanel: Hi. When iterating on a connector modes, what's the expected order of the modes by size and by refresh? Is there an "standard" order?
21:34imirkin: Vanfanel: i think you can safely assume randomized order
21:34imirkin: Vanfanel: certain modes may be marked as preferred though
21:34imirkin: and there should be one that's super-preferred... i forget the name of that
21:36imirkin: or maybe not. iirc there's a concept of "native" somewhere, but maybe not in the modes
21:58Vanfanel: imirkin: ok, understood. I have to find a "closest mode", so if they are randomized, I'll have to use the SDL internal ordered modes list...
21:59Vanfanel: imirkin: I think that you mean the DRM_PMODE_PREFERRED or something similar
21:59emersion: EDID has a concept of native modes iirc
22:17imirkin: Vanfanel: yes. but several modes could have that designation iirc
22:18imirkin: not sure
22:36pcercuei: Vanfanel: you are working on a better (?) KMS/DRM backend for SDL2, right?
22:49Vanfanel: pcercuei: yes, I am improving it. I have mostly rewritten it by now..
22:53imirkin: dcbaker: ever seen something like this in piglit? http://paste.debian.net/hidden/3d28c369/
22:53pcercuei: That's great. SDL2's KMS/DRM backend never really worked here
23:21imirkin: mareko: how do i trigger index_bounds_valid == false for a non-indexed draw? it seems like with simple attempts, i get it == true and the min/max index are set as expected
23:21imirkin: [with client-side buffers]
23:44pcercuei: I think I see a use-after-free in DRM code...
23:59emersion: can you elaborate?