02:27 anarsoul: any ideas why setting NIR_PRINT doesn't print nir representation for me anymore?
02:30 anarsoul: oops, forgot to set LD_LIBRARY_PATH
03:34 daniels: anarsoul: thanks, good by me if narmstrong acks it then
03:44 anarsoul: daniels: I have strong suspicion that there's not enough runners in baylibre lab :(
03:45 anarsoul: mali450 job is pending
03:45 daniels: anarsoul: let's see. we also had to make sure the Mesa jobs got priority over KernelCI else they never ran
03:45 daniels: ah, if it's pending on GitLab (rather than waiting on LAVA) then narmstrong can fix it by increasing the parallelism on his runner, but maybe he doesn't want that many jobs
03:46 anarsoul: see https://gitlab.freedesktop.org/anarsoul/mesa/pipelines/98320
03:49 daniels: yeah, I guess it only ever takes two jobs at a time as a throttling mechanism :\
03:51 anarsoul: but it seems to be OK with panfrost
03:52 anarsoul: I think I'll just disable mali400 jobs
03:53 anarsoul: it has weird failures in dEQP-GLES2.functional.default_vertex_attrib.* that I can't reproduce on my A64 board
03:53 anarsoul: although my board is 64-bit while H3 is 32-bit
03:54 anarsoul: anyway I don't have any 32-bit hardware to test it
03:54 daniels: yeah, just 450 would be a good start
05:39 vicky: Hi All. I'm seeing a issue with debian 10 where the login screen(greeter) is now shown with 4.19 kernel. But with debian 9 the issue is not seen
05:39 vicky: More details are in https://gitlab.freedesktop.org/drm/intel/issues/984
05:39 vicky: Any pointers would be helpful. Thank you.
08:00 narmstrong: daniels: anarsoul we have only 2 mali400 and 2 mali450 identified boards, but we can have more, but we need to target a specific board which is a serious limitation
12:40 lynxeye: anyone knows what happened to the patches for msm to switch to the drm scheduler? There was some activity back in 2018, but seems things stalled at some point...
13:15 imirkin_: anyone know offhand if fprintf(stderr) when redirected to a file is line-buffered or "regular" buffered?
13:15 imirkin_: pretty sure it's line-buffered when stderr is a tty
13:17 imirkin_: mareko: why was https://cgit.freedesktop.org/mesa/mesa/commit/?id=5b1c4e1b75fe3466e5eec799e091c7a8ec9acd0e necessary? afaik setting samplers and sampler views should be fairly independent actions
13:17 pq: imirkin_, I think 'man setbuf' answers that: "standard error stream stderr is always unbuffered by default."
13:18 imirkin_: wow, first i hear about setbuf
13:18 imirkin_: thanks :)
14:54 dj-death: anyone understand the difference between f2f16 and fquantize2f16 NIR opcodes ?
14:54 dj-death: I don't get what quantize does
14:54 pendingchaos: f2f16 converts a float32/float64 to float16
14:55 seanpaul: Lyude: I'm seeing lockdep WARN and NULL deref splat on drm-tip when unplugging an MST branch device on i915, is this on your radar?
14:55 pendingchaos: I think "fquantize2f16" basically does f2f32(f2f16(src0)) or f2f64(f2f16(src0))
14:56 pendingchaos: seems it does that, but also returns -0/0 if src0's magnitude is less than ldexp(1, -14)
14:56 dj-death: pendingchaos: thanks
15:04 dj-death: I'm curious why the spirv spec defines 4 rounding modes for floating point types
15:04 dj-death: but we only handle 2
15:05 dj-death: the CTS doesn't seem to check those either
15:15 imirkin_: nvidia supports 4 rounding modes
15:16 imirkin_: round down, round up, round nearest, round towards zero
15:22 dj-death: by "we" I meant the generic part of the spirv->nir translation
15:22 dj-death: as far as I can tell intel HW supports the same modes
15:22 dj-death: as what you describe for nvidia
15:23 dj-death: and the 4 modes have been in since spirv 1.0 so I'm a bit confused
15:24 imirkin_: ah ok :)
15:26 karolherbst: dj-death: the others are only relevant for extensions and CL
15:28 dj-death: karolherbst: that's what confuses me, if it's in the spirv 1.0 spec, that was before any extension no?
15:28 karolherbst: gl extensions
15:28 dj-death: karolherbst: oh sorry, you're talking about nir stuff? :)
15:29 karolherbst: not everything in spir-v is because of glsl
15:29 karolherbst: glsl itself doesn't know rounding modes
15:29 karolherbst: it was just added because of CL (afaik and the glsl fp16 extension defines something)
15:29 dj-death: right, but what prevents a normal vulkan application from using features available from spirv 1.0?
15:32 bnieuwenhuizen: dj-death: the vulkan spir-v appendix?
15:34 bnieuwenhuizen: dj-death: at least the newer spec has language about not using certain rounding modes unless they're allowed by the corresponding vulkan extension
15:34 karolherbst: "The FPRoundingMode decoration can only be used for the floating-point conversion instructions as described in the SPV_KHR_16bit_storage SPIR-V extension."
15:35 karolherbst: but.. mhh
15:35 karolherbst: it doesn't seem to limit which rounding modes can be used
15:36 karolherbst: bnieuwenhuizen: where is that stated though?
15:37 karolherbst: ohh
15:37 karolherbst: I found it
15:37 karolherbst: "Only the round-to-nearest-even and the round-towards-zero rounding modes can be used for the FPRoundingMode decoration."
15:37 karolherbst: https://vulkan.lunarg.com/doc/view/1.1.130.0/linux/chunked_spec/chap40.html#spirvenv-module-validation
15:39 dj-death: yeah, SPV_KHR_float_controls seems to only talk about RoundingModeRTE & RoundingModeRTZ
15:41 karolherbst: those are exectuion modes though
15:42 karolherbst: I have a branch to fully support all rounding modes for kernels.. need to clean that up and finish it (but constant folding is annoying :( )
15:50 seanpaul: agd5f_: so that MST NULL deref came from the DSC pull, the regression isn't in drm-misc yet. Do you want to send the fix to airlied?
15:50 seanpaul: Lyude: fyi ^^
15:55 Lyude: seanpaul: yep
15:55 Lyude: it's from a patch that I forgot to push but that was the wrong fix anyway as someone pointed out
15:56 agd5f_: seanpaul, yeah, I can send a new PR with that added, assuming it fixes it
15:56 Lyude: going to review/push the fix once I get into the office
15:57 seanpaul: Lyude: probably makes sense to go through agd5f_ for this
15:57 seanpaul: so we don't need to backmerge drm-misc just to pick up a regression
15:57 Lyude: seanpaul: sgtm
15:57 seanpaul: thanks!
15:57 agd5f_: seanpaul, does the fix work?
15:57 seanpaul: agd5f_: will test it, just bisecting the lockdep atm
15:58 seanpaul: it's a separate issue
15:58 agd5f_: ok
15:58 seanpaul: 2 revisions left... the suspense is killing me!
15:59 seanpaul: too bad chamelium doesn't support MST, would have saved everyone a lot of time
16:17 seanpaul: agd5f_: "Avoid NULL pointer dereference" seems to fix the NULL deref, you can add my T-b to that
16:18 seanpaul: agd5f_: lockdep splat is caused by 64e62bdf04ab8529f45ed0a85122c703035dec3a "drm/dp_mst: Remove VCPI while disabling topology mgr"
16:20 seanpaul: just sent the output in a reply to that patch
16:25 agd5f_: seanpaul, done
16:25 agd5f_: I'll send out a new PR this afternoon
16:25 seanpaul: agd5f_: thank you!
16:26 seanpaul: agd5f_: the lockdep issue is in -misc-next, so it can probably just get fixed there and hopefully avoid any more topic pulls
16:27 agd5f_: sounds good
18:15 Lyude: agd5f_: did you pick up wayne lin's fix that we were talking about earlier btw?
19:10 mareko: imirkin_: because radeonsi doesn't unbind sampler states but the function deletes it
19:10 imirkin_: mareko: oh. so it had nothing to do with the ordering of sampler views vs samplers
19:13 imirkin_: hmmm ... that explanation doesn't make sense to me, at least not immediately. i do see that it doesn't unbind the sampler state before deleting it, but that doesn't explain why flipping the order does anything
19:25 sunshavi: anarsoul: glamor is activated on my workstation with mesa-git (compiled today). Are You aware that sometimes some characters repeat twice. It Just happens to me within emacs. when glamor is deactivated that issue goes away
19:26 kisak: that's strange because glamor shouldn't be doing anything wrt to keyboard input
19:28 anarsoul: sunshavi: feel free to file a bug, see https://www.mesa3d.org/bugs.html on how to do that
19:28 sunshavi: Yes. It is weird
19:28 anarsoul: you probably can apitrace Xephyr with emacs in it
19:29 sunshavi: apitrace=debug?
19:29 anarsoul: oh, so it's not rendering issue?
19:29 anarsoul: https://github.com/apitrace/apitrace
19:29 sunshavi: thanks
19:29 pepp: imirkin_: the call to si_set_sampler_views depends on the sampler states (it calls si_set_sampler_view_desc(..., samplers->sampler_states, ...)) so we need to bind the sampler state before setting the sampler view
19:32 imirkin_: pepp: huh ... ok. that's weird. normally they're supposed to be separate ... why is the dependency there?
19:33 sunshavi: it just happens with emacs but not with xemacs (weird)
19:35 pepp: imirkin_: they're almost separate. If the sampler state had been unbound it would work fine (https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/radeonsi/si_descriptors.c#L490)
19:35 imirkin_: so (part) of the problem is that it doesn't unbind the destroyed states at the end, right?
19:36 imirkin_: (it = util_compute_blit)
19:37 pepp: imirkin_: yes. And I'm not sure that we can unbind a sampler state in radeonsi (trying to bind a null state will be ignored by si_bind_sampler_states instead of clearing the existing one)
19:37 imirkin_: huh
19:44 imirkin_: pepp: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state.c#n464
19:44 imirkin_: nvc0 treats a null samplers array as an array of null's
19:51 mareko: imirkin_: setting a sampler view reads the sampler state and vice versa
19:51 imirkin_: someone's gotta go first :)
19:51 mareko: if you bind the sampler view first, it reads the sampler state that's deleted
19:52 mareko: if you bind the sampler state first, it can't read the sampler view, because that's properly unbound
19:53 imirkin_: but why is it impossible to delete the sampler state?
19:53 mareko: the function does it
19:53 mareko: imirkin_: st/mesa doesn't delete them
19:53 mareko: or cso_context
19:53 imirkin_: there's no mechanism for it in GL
19:54 imirkin_: having this implicit ordering is definitely odd.
19:54 mareko: it's incorrect indeed
19:54 imirkin_: afaik all the other drivers handle it
19:55 mareko: I don't disagree
19:56 imirkin_: :)
20:32 agd5f_: Lyude, I haven't sent out a PR yet, so I can still make changes
20:34 Lyude: agd5f_: ah cool :), could you apply https://patchwork.freedesktop.org/patch/349111/ on top of the other mst dsc patches?
20:34 Lyude: that should fix the issues we're seeing with the null deref
20:41 anarsoul: is there any way to convert android's gfxtrace into apitrace?
20:41 pendingchaos: run the gfxtrace replayer under apitrace?
20:41 pendingchaos:knows nothing about gfxtrace
20:42 imirkin_: i'm guessing the issue is that there is no gfxtrace replayer
20:42 imirkin_:also knows nothing about gfxtrace
20:43 anarsoul: there's gapid from google, I'm not sure if it can replay the trace without starting its UI
20:44 anarsoul: I wish they just used apitrace
20:52 Lyude: seanpaul: revert sent for the lockdep splat btw
20:52 seanpaul: Lyude: much appreciated, will review
20:53 seanpaul: Lyude: ship it
20:53 Lyude: seanpaul: on it
20:54 seanpaul: Lyude: also, thanks for finding that alternate fix for the NULL issue
20:54 Lyude: np, it ended up being surprisingly convienent that I forgot to push that patch :P
20:54 seanpaul: haha, well in fairness, you couldn't push it since it's not in -misc
20:55 Lyude: seanpaul: yeah I realized that as well lol
20:56 seanpaul: we should isolate all of our panic-inducing patches to topic branches
20:57 Lyude: yeah, the way the mst msc stuff got handled was kinda confusing, especially since there was a while where I was getting patches for stuff that wasn't even available on drm-tip
21:00 Lyude: seanpaul: pushed
21:01 agd5f_: Lyude, should I apply that patch on top of wayne's or in place of?
21:01 Lyude: agd5f_: in place of wayne's fix for the NULL deref
21:02 seanpaul: Lyude: these topic branches aren't too frequent, so i guess we'll deal with the pain as they come. thanks for the revert, my tree is now fixed... so i can go ahead and break it myself
21:02 Lyude: hehe
21:03 seanpaul: struct drm_drv *drv = (struct drm_drv *)connector;
21:03 seanpaul: oops, wrong window..
21:04 imirkin_: also looks like questionable code ... connector is a drm_drv?
21:04 vsyrjala: meh. close enough
21:06 seanpaul: imirkin_: just my attempt at a bad joke (look up)
21:08 anarsoul: imirkin_: pendingchaos: 'gapit' tool can produce video from gfxtrace and looks like apitrace can make a trace of it
21:19 robclark: mareko: in mesa/st, does blend state get updated when fb state changes? There is a comment about it "depends on update_framebuffer_state" but I'm not seeing where that happens.. background is I'd kinda like to move the special handling for integer and non-alpha formats to mesa/st, so that I can convert blend state to a hw stateobj. (Otherwise I need 4x variants times # of render targets)
21:21 imirkin_: robclark: note that not all hw has the same shortcomings, so unnecessary blend states for everyone would not be welcome
21:26 anholt_: robclark: st already does non-alpha formats for you.
21:26 anholt_: and disabling blend on integer, it looks like
21:30 robclark: imirkin_: that *could* be a pipe cap if necessary.. in practice I'm not really sure it would result in so many more blend states.. but idk
21:31 robclark: airlied: looks like the one remaining special thing we need to do for int formats is to disable the per-MRT logic-op
21:31 robclark: hmm, I didn't see mesa/st using util_blend_dst_alpha_to_one()
21:32 robclark: maybe it open codes that.. if I can get rid of the non-alpha variant, that would be one step in the right direction..
21:32 anholt_: fix_xrgb_alpha
21:33 Kayden: you might need PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND set
21:33 Kayden: because radeonsi and nouveau didn't want that
21:33 robclark: ahh, nice
21:34 Kayden: I don't think I noticed a util function when I wrote that
21:35 robclark: looks like util_blend_dst_alpha_to_one() doesn't handle PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE .. but that is easy enough to fix..
23:01 anarsoul: is there any way to emulate PIPE_FORMAT_R8_UNORM and PIPE_FORMAT_R8G8_UNORM support if hardware supports L8 and L8A8?
23:02 imirkin_: that use-case was probably not considered by st_format, but should be easy in principle
23:02 imirkin_: just add the relevant formats to the fallback list in st_format's mega-table-of-everything
23:02 imirkin_: (presumably you want GL_R8 & co, rather than PIPE_FORMAT_R8_UNORM emulation specifically)
23:03 imirkin_: er, GL_RED obviously
23:03 imirkin_: anarsoul: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_format.c#n515
23:03 imirkin_: just dump L8/LA8 in that list before DEFAULT_RGBA_FORMATS
23:03 imirkin_: should Just Work (tm)
23:04 imirkin_: (there's probably some subtle reason that it won't and will require further fixups... but ... should be close at least)
23:05 anarsoul: imirkin_: IIRC for L8 sampler returns (L,L,L,1) while for R8 it returns (R,0,0,1)
23:05 imirkin_: correct
23:05 imirkin_: however there should be a swizzle auto-applied to a GL_R8 texture
23:06 imirkin_: which should make it all work out
23:06 anarsoul: hm
23:06 imirkin_: i could be misremembering
23:06 imirkin_: it's been known to happen
23:10 anarsoul: imirkin_: I guess it's more difficult with R8G8
23:10 imirkin_: yes...
23:10 imirkin_: maybe...
23:12 imirkin_: anarsoul: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_sampler_view.c#n307
23:13 imirkin_: you could make that code, or surrounding, a little smarter
23:13 anarsoul: thanks
23:13 imirkin_: anarsoul: actually ... it could work
23:13 imirkin_: coz that then goes through swizzle_swizzle()
23:14 imirkin_: although that might be the GL-set swizzle
23:14 imirkin_: it might be tough for rendering though
23:15 imirkin_: since the shader will put stuff into .rg, while you'll be looking in alpha
23:15 imirkin_: (you = the hardware)
23:15 anarsoul: imirkin_: it can render into r8 and r8g8
23:15 imirkin_: dunno if you can set such results per-component, if not, it will require a shader key
23:15 imirkin_: oh ok
23:16 anarsoul: but it can't sample :)
23:16 anarsoul: well, it can, but as A8/L8/I8 for R8 or L8A8 for R8G8
23:16 imirkin_: right
23:17 imirkin_: i think that's common for ES2 hw
23:41 anarsoul: imirkin_: something like https://gist.github.com/anarsoul/3e7008ada51b90ab5a423f47d61d8dee ?
23:42 imirkin_: anarsoul: not quite ... i don't think the lima_format.c changes are necessary
23:42 imirkin_: if you do those, then the st will think it's really got PIPE_FORMAT_R8G8_UNORM
23:43 anarsoul: they're necessary to add support for rendering into R8 and R8G8
23:43 anarsoul: since L8 and L8A8 are not renderable formats
23:43 imirkin_: having renderable-but-not-texturable formats will lead to eternal sadness
23:43 anarsoul: darn
23:44 anarsoul: so just abandon all hope for r/rg? :)
23:44 imirkin_: i mean ... for ES2 ... it's not immensely useful
23:44 imirkin_: it's part of ES3
23:44 imirkin_: but i suspect there are some different tricks you could use to make PIPE_FORMAT_L8_UNORM/L8A8_UNORM renderable
23:45 anarsoul: they aren't renderable by spec :)
23:45 imirkin_: who cares
23:45 imirkin_: you're implementing a gallium driver
23:45 imirkin_: st/mesa handles all the GL details for you
23:45 anarsoul: I wish there was a swizzle in texture descriptor
23:45 imirkin_: there is
23:45 anarsoul: I mean hardware descriptor
23:46 imirkin_: oh yeah. lack of ARB_texture_swizzle support is annoying.
23:46 imirkin_: but common on those earlier GPUs :)
23:46 imirkin_: even r600 managed to get it (slightly) wrong
23:50 mareko: robclark: _NEW_BUFFERS -> st_invalidate_buffers, see that function
23:52 robclark: ahh, ok, thx
23:54 mareko: anarsoul: if you need texture_rg, you can change st/mesa to select rgbx for you
23:56 anarsoul: mareko: I was thinking about native r/rg