00:15 mareko: zmike: I'll just add it as a documented failure in our fails files
00:15 mareko: what is "xfail" in the ci files?
00:18 zmike: expected fail
00:18 zmike: I think it should still be reported
00:18 zmike: so I guess I'll do that once I know what test it is
00:37 mareko: here's what I've found so far:
00:37 mareko: # glcts bug - it doesn't expect VS uniforms to be eliminated when they only
00:37 mareko: # determine a VS output that's not read by TCS
00:37 mareko: KHR-GL46.gpu_shader_fp64.fp64.state_query,Fail
00:37 mareko: # A uniform is propagated from GS to FS due to varying optimizations, but the test doesn't
00:38 mareko: # expect that and instead it expects GL_REFERENCED_BY_GEOMETRY_SHADER to return 1.
00:38 mareko: dEQP-GLES31.functional.geometry_shading.query.referenced_by_geometry_shader,Fail
05:00 airlied: gfxstrand: uugh looks like might need to pipe the beta flags down unfortunately
05:00 airlied: let's see how my python is doing today
05:56 airlied: gfxstrand: okay I did the horrible thing, it's in 21806 now
07:53 bbrezillon: danvet: yes, that means it can fail asynchronously, and since we're talking about VM bind failures, it puts the VM in an inconsistent state, likely leading to DEVICE_LOST errors further down the road
08:00 airlied: just writing your own pgtable management seems simpler :-P
08:01 danvet: bbrezillon, yeah that doesn't sound like the best idea
08:01 danvet: better maybe than kernel deadlock, but you shouldn't just trash apps as part of your kernel locking scheme :-)
08:01 bbrezillon: airlied: yeah, actually I've been considering that after you pointed it out a couple weeks back
08:02 danvet: oh is this "it's part of the iommu framework" fun?
08:02 bbrezillon: then had this discussion with robclark and robmur01 who seemed to think it was still preferable to use the iommu/io-pagetable logic...
08:07 bbrezillon: and as robmur01 pointed out, the pre-allocation/reservation might make the situation even worse on memory-constrained systems, because queued VM_BIND jobs will be holding pages (most of the time, more pages than they actually need), while the system is struggling to find memory.
08:14 bbrezillon: that's not something that can be solved by duplicating the pagetable logic, it's inherent to the async VM_BIND model
08:35 bbrezillon: robmur01: in your '1/512 * N * M' formula, aren't you omitting intermediate levels of the page table tree?
11:20 robmur01: bbrezillon: that would be the "somewhat more than", since I couldn't be bothered to quantify 1/512^2+1/512^3 ;)
11:42 gawin: which drivers require llvm? maybe in longer run it'd be better to nuke these drivers from amber? llvmpipe, radeonsi and radv?
11:43 gawin: (amber doesn't build with llvm16)
11:43 ishitatsuyuki: iirc there are also other drivers that uses llvm, but I don't really know much about anything other than AMD
11:44 ishitatsuyuki: for radv, you can disable llvm and still get it to build (the llvm backend and disassembler will be missing)
12:05 MrCooper: gawin: yeah, IIRC amber is about non-Gallium drivers, none of which use LLVM
12:52 mattst88: I think amber also includes SWR, which uses llvm?
12:53 mattst88: at least insofar as SWR exists...
13:24 zmike: mareko: are you sure about your notes for KHR-GL46.gpu_shader_fp64.fp64.state_query ? this test has no shaders
13:29 zmike: as for dEQP-GLES31.functional.geometry_shading.query.referenced_by_geometry_shader, are you expecting that the test should also check the fs or just that the test be structured in such a way that the uniform can't be promoted?
13:37 zmike: mareko: also do you recall for https://gitlab.freedesktop.org/mesa/mesa/-/issues/8163 if the test was supposed to be using ALWAYS or NEVER?
13:46 robclark: bbrezillon, airlied, robmur01: writing our own pgtable builder doesn't really solve the root problem.. it would still need to figure out how to have enough pages avail to do mappings in fence signaling path, so all it really accomplishes is moar codez.. both panfrost and msm skip the iommu framework and use io-pgtable directly so we aren't completely constrained by iommu framework
14:42 tomeu: gfxstrand: I'm scratching my head over the code that vton generates for exp()
14:42 tomeu: my HW has a exp instruction, but I don't see a way of using it
14:57 llyyr: with vulkan-beta=true, I get build errors about missing prototypes in genX_video.c
14:59 tomeu: ah, I discovered native_exp()
14:59 tomeu: so nm
14:59 daniels: lol
14:59 daniels: tomeu: yeah, was about to say exactly that
14:59 tomeu: frustratingly enough, native_exp() works as expected, but libclc's impl doesn't :/
14:59 daniels: src/compiler/spirv/vtn_opencl.c has the list of stuff we have to remap into libclc helpers, because the hardware is never precise enough to satisfy the CL spec
14:59 daniels: \o/
14:59 karolherbst: tomeu: how rude of libclc
15:00 karolherbst: why is it failing tho?
15:00 karolherbst: the libclc stuff _can_ be a bit scuffed and overengineered
15:01 tomeu: it is failing in a big way:
15:01 tomeu: Expecting 2.585710 (0x40257c44) with tolerance 0.000001 (3 ulps), but got 3235601.000000 (0x4a457c44)
15:01 karolherbst: though exp is really just a bunch of mad
15:02 tomeu: hopefully it is just a bug in etnaviv
15:02 karolherbst: mhhh
15:02 karolherbst: ehh..
15:03 karolherbst: there is also some subnormal stuff really funky
15:03 tomeu: daniels: the blob does use their exp() instruction for this, but I haven't ran the CTS yet
15:03 karolherbst: exp in hardware? insane
15:05 tomeu: well, maybe in FW, they seem to add a lot of stuff directly from the khronos specs
15:05 karolherbst: uhh
15:05 karolherbst: interesting
15:06 karolherbst: we don't really have a great way to select based on the driver, but maybe we need a callback sooner or later where drivers can select what they actually support in hw
15:06 tomeu: their first gen was heavily inspired on DX 1.0 ^_^
15:06 karolherbst: if it works with support for denormals then yeah,, should use the native stuff
15:06 karolherbst: but I also have to fix the denormal situation at some point
16:11 gfxstrand: tomeu: Is it Native_exp2 or a base-10 exp or is it the one that needs full precision?
16:12 tomeu: gfxstrand: native_exp()
16:13 gfxstrand: karolherbst, tomeu: If we want Native_exp in HW, we can add a nir_op_fexp
16:14 karolherbst: so uhm.. what's failing?
16:14 gfxstrand: We just need to make sure we also add opt_algebraic lowering for it. Should just be exp2() * M_LOG2E
16:14 karolherbst: ohhh...
16:14 karolherbst: wait
16:14 gfxstrand: Or we can make vtn call that instead of libclc
16:15 karolherbst: right.. we use nir_fexp for exp
16:15 gfxstrand: Hrm... Looks like vtn already should be calling that.
16:15 karolherbst: nir_fexp = exp2(b * M_LOG2E)
16:15 karolherbst: ehh x
16:15 karolherbst: but mhh
16:16 karolherbst: tomeu: soo.. the code using exp2 fails?
16:17 tomeu: the kernel using exp() instead of native_exp() fails, but I have found the bug and is unrelated to anything exp
16:17 karolherbst: okay
16:18 tomeu: just a problem with encoding immediates
16:18 karolherbst: ahh
16:18 karolherbst: yeah, I was confused on what's the problem here
16:18 karolherbst: _but_ if you say you have fexp natively, we could skip the fexp to fexp2 + mul lowering
16:18 karolherbst: for native_exp that is
16:18 tomeu: I was just curious about what the plan was regarding using these native instructions when available
16:19 karolherbst: we just use whatever we have in nir
16:19 tomeu: as I will hopefully move to perf work soon
16:19 karolherbst: nice
18:59 dcbaker: PSA: I am working on the next meas 23.0 stable release, the situation with the CI is slowing things down. I'll be cutting the release as soon as possible
19:06 eric_engestrom: thanks for letting us know dcbaker :)
19:25 daniels: dcbaker: please bounce questions off us if we can help with CI
19:26 dcbaker: daniels: will do. anholt pointed me at the solution to my most pressing question
19:42 zmike: anyone have ideas on how I might wrangle driconf into having multiple internal driconfs? I want to set an entry on some drivers and not set it on others
19:45 jenatali: Can't you already add per-driver entries?
19:45 zmike: this is for the internal driconf that the frontend sees
19:45 zmike: so it's already per-driver
19:46 jenatali: Right. Maybe I'm not understanding what you're looking for then?
19:46 zmike: I'm trying to enable glthread by default on some drivers (current behavior) and then disable it on other drivers (new behavior)
19:47 jenatali: Right, there's a driver name entry in driconf already so you can add per-driver entries
19:47 zmike: 🤔
19:49 zmike: I thought that was just for the external driconf files
19:50 jenatali: There's plenty of <device driver="..."> entries in 00-mesa-defaults.conf
19:50 zmike: yeah but I think that's handled differently than the ones that are inlined into the loader
19:51 jenatali: I don't see how it would be...
19:51 zmike: that's why I'm asking since I don't see any other drivers that have different sets of internal driconf values
19:51 jenatali: The frontend gets the driver name and passes it to the driconf parser, which either loads an XML file or uses the pre-parsed data
19:52 jenatali: Different sets of internal driconf values?
19:52 jenatali: I see plenty of glthread options for radensi only in the default conf file
19:52 zmike: I'm talking about the driconf_<driver>.h files in the driver dir
19:55 jenatali: Looks like those are just #included into the driver-specific arrays in drm_helper.h?
19:55 zmike: yes
19:55 jenatali: I guess I'm still not following what you're trying to do :)
19:55 zmike: I'm trying to figure out how to have two sets of those that can be swapped between
19:56 jenatali: Based on what?
19:56 zmike: but it's hard
19:56 zmike: based on what the driver wants
19:56 jenatali: I see, like a callback?
19:56 zmike: not sure
19:56 zmike: wanted to ask here before I took out my chainsaw
19:58 jenatali: Looks like currently it's all handled before the screen is created
19:58 zmike: does seem that way
20:01 jenatali: Yeah seems like you'd need a chainsaw, I don't see any existing extension point for dynamic driconf selection for gallium
20:03 zmike: rats