09:38 jani: trying to wrap my head around crtc indexes with lease. suppose you have a lease with a subset of crtcs. getresources gives you the subset. then you want to access the debugfs for a crtc. the debugfs naming uses global crtc indexing, but all you have is lease relative indexes. how do figure out which debugfs directory to use?
09:39 jani: I guess this is primarily hypothetical and the answer will be "don't use debugfs with leases"... but is there a better answer?
10:36 emersion: jani: debugfs should use object IDs instead of indexes
10:37 jani: emersion: drm_debugfs_crtc_add() has name = kasprintf(GFP_KERNEL, "crtc-%d", crtc->index);
10:37 emersion: debugfs has no stable API
10:38 emersion: we could even just change this to object IDs if we wanted to
10:38 jani: not in theory, but a fundamental change like that isn't likely to go down well
10:38 emersion: there are other ways:
10:39 jani: (-> afk, will be back to read the replies)
10:39 emersion: - open the master node as read only if you can (not guaranteed in general that you can) then use object IDs to grab indexes from there
10:40 emersion: - add a new file in the crtc debugfs dir with the object id
11:27 anonymix007[m]: I'm seeing the following in dmesg on 6.17.8 with B580:... (full message at <https://matrix.org/oftc/media/v1/media/download/AR6w1ry0H0iB3tbds75nP96fyy17oMQ5cGoFvJVPurPIGGUwsHeuQZHPcWch_OfsG2UojpNaWkTRka3fF7CxQSxCea6R2howAG1hdHJpeC5vcmcvRXNlVld2Wk5zV0Nlc2RtbXNjRU1EeWZE>)
11:32 CounterPillow: what's the DRM specific version of something like linux-next? I am working on a series touching several different DRM drivers (amdgpu, i915, misc) and linux-next seems to occasionally disappear some DRM things that were already applied, so isn't a great base.
11:34 emersion: drm-tip?
11:34 CounterPillow: Where can I find that repo? docs.kernel.org doesn't list it.
11:36 CounterPillow: I guess this https://drm.pages.freedesktop.org/maintainer-tools/repositories/drm-tip.html
11:38 emersion: https://gitlab.freedesktop.org/drm/tip
16:27 pac85: so https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_lower_tex.c?ref_type=heads#L998
16:27 pac85: will subsitute
16:27 pac85: `txb(..., bias)`
16:27 pac85: with
16:27 pac85: `txl(..., lod(...) + bias)`
16:27 pac85: However, when the sampler state has bias that will be applied to both lod and txl so the state bias is suddenly applied twice.
16:27 pac85: Since we have no way of knowing what lod will be selected and no way to extract the sampler's lod_bias I guess this is yet another unfixable texture lowering?
17:51 alyssa: pac85: ...Lolz
17:51 alyssa: Probably fixable by plumbing thru the state lod_bias
17:53 pac85: alyssa: Yeah then I can substract. If I have enough space left in push constants in zink it might actually be easy to do
17:53 pac85: *sweats while counting bytes*
17:57 pac85: actually no way that will work with bindless so nvm
17:58 pac85: (for context, zink has no way of passing internal data to shaders other than push costants)
18:01 alyssa: :clown:
18:02 alyssa: have you considered using iris/radeonsi
18:02 pac85: lmao
18:02 alyssa: strongly recommended
18:04 pac85: this uber shaders stuff is truly insane I've been at it for 2 years (ok not continuously) and now I'm like fixing bugs that are all over the stack to try and pass CI
18:04 pac85: like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38514
18:05 pac85: and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38497 and others that are just in the MR
18:05 alyssa: this is why I use iris & asahi
18:07 pac85: too ez
18:08 pac85: imagine not having a driver between your driver and your hw
18:09 alyssa: kernel mode driver has entered the chat
18:11 pac85: alyssa: I still need to address zink on venus fails....
18:11 alyssa: this is why i use virtual native context
18:12 pac85: what did I get into 😭
18:19 alyssa: pac85: https://pbs.twimg.com/media/FeeHtRnWQAACmbl.jpg
18:22 pac85: alyssa: we should make a new meme with the template where there are a bunch of things stacked and a single tiny brick holding it
18:42 pac85: alyssa: https://usercontent.irccloud-cdn.com/file/rZ3TlsbA/zink.png
18:42 alyssa: "amdgpu is the size of the entire linux kernel" is the most accurate thing here
18:43 pac85: hahaha
20:42 mareko: pac85: radv could get the sampler's lod_bias in the shader because it's in the descriptor, it would work just like txs
20:43 mareko: adding GL_CLAMP into VK would probably be easier
20:45 mareko: why use zink on venus on AMD though, it's worst options of all; virgl is much faster than zink+venus, and amdgpu native-context crushes everything
20:50 pac85: mareko: how would I expose that to zink though? Some new vulkan ext to query sampler bias?
20:51 mareko: I would use radeonsi in qemu
20:52 pac85: emit_split_vector(ctx, sampler, sampler.size());
20:52 pac85: Temp descw = emit_extract_vector(ctx, sampler, 2, s1);
20:52 pac85: Temp lod_bias = bld.sop2(aco_opcode::s_bfe_u32, bld.def(s1), bld.def(s1, scc), descw,
20:52 pac85: Operand::c32(0u | (14u << 16)));
20:52 pac85: Temp frac = bld.sop2(aco_opcode::s_bfe_u32, bld.def(s1), bld.def(s1, scc), lod_bias,
20:52 pac85: Operand::c32(0u | (8u << 16)));
20:52 pac85: Temp intp = bld.sop2(aco_opcode::s_bfe_i32, bld.def(s1), bld.def(s1, scc), lod_bias,
20:52 pac85: Operand::c32(8u | (6u << 16)));
20:52 pac85: Temp f_lod_bias_frac = bld.vop1(aco_opcode::v_cvt_u32_f32, bld.def(v1), frac);
20:52 pac85: f_lod_bias_frac = bld.vop2(aco_opcode::v_mul_f32, bld.def(v1), Operand::c32(0x3b800000), f_lod_bias_frac);
20:52 pac85: Temp f_lod_bias_inp = bld.vop1(aco_opcode::v_cvt_u32_f32, bld.def(v1), intp);
20:52 mareko: outside qemu, I would also use radeonsi
20:52 pac85: I had actually written that code to debug this
20:53 pac85: mareko: yeah I know but CI tests for zink on venus
20:53 pac85: sorry meant to send as snippet https://www.irccloud.com/pastebin/wS2xgFRL/
20:55 mareko: testing zink on venus on RADV is a use case that nobody would ever use and it's a total waste of time, those CI jobs could be removed or a different host HW should be used
20:56 pac85: mareko: The venus job is actually on top of lavapipe, I just brought it up since we where talking about stacking drivers
20:56 mareko: even better, the guest driver should be lavapipe, not venus
20:57 pac85: yeah it's definitely not a realistic usecase, I do wonder the rationale behind adding that job
20:58 airlied: because it finds bugs in real use cases
20:59 airlied: CI's job isn't to model real world use cases, it's to find bugs in the software
21:02 pac85: fair enough
21:02 pac85: anyway the fail is just a timeout so I should probably just see why my branch is slower
21:03 mareko: the other questions are... who doesn't have native context today? these have it: asahi, amd, freedreno, and intel in the future maybe? who would want venus with 40% of native perf instead of adding native context support to get 99% native perf for their HW? adding native context support is much easier than writing a vulkan driver
21:04 airlied: need to put it on the nova roadmap
21:14 mareko: lower_txb_to_txl should at least note that it's broken
21:16 mareko: it may be possible to implement txb as txd where bias modifies the derivatives
21:20 mareko: txb(tex, c, bias) = txd(tex, c, ddx(c) * exp2(bias), ddy(c) * exp2(bias)) or something like that
21:20 pac85: mareko: I kinda thought about that, we can retreive the texture size and scale the derivatives based on bias. I sort of feared that the error in the end might be somewhat bad but perhaps could be good enough to pass CI? That said that pass still breaks aniso
21:22 mareko: *exp2(-bias) (probably)
21:23 pac85: I'll give it a shot
21:24 mareko: the idea is that "ddx(c) * 0.5" adds 1 to bias
21:25 mareko: I have not thought about it long enough to persuade myself that it's correct though
21:28 pac85: well it will surely mess up aniso so it's not strictly correct but it's surely more correct than the current status of the pass
22:00 pac85: mareko: it's `exp2(bias)`, larger derivatives makes it select higher lod. And yeah it actually passes the test! I'll post it as a draft since aniso that concerns me but then we can decide what to do. Thanks for the suggestion!
23:48 mareko: aniso may be undefined since hw implementations differ between vendors
23:51 mareko: if it doesn't break stuff and it fixes stuff, I'd say it's good
23:53 mareko: "zink on venus" should probably die though, virgl with zink on the host would have better perf