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