07:22 hakzsam: daniels: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1843510 seems stucked? (sorry to ping you again about CI)
07:26 anarsoul|2: tomeu: ^^
08:01 daniels: hakzsam: np, sorry for letting us know. those devices it's ended up running on seem to have been weird since the power cut last weekend. admins are trying to figure out why but we'll just disable them if we need to. thanks!
08:01 hakzsam: ok
08:10 daniels: & sorry for the inconvenience
08:11 daniels: if it's blocking you, please just push a commit disabling Panfrost and we'll fix it up later
08:24 hakzsam: it's fixed now
08:26 daniels: \o/
08:39 hakzsam: actually not, https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1843509 (some previous MRs got merged though)
08:46 tomeu: hakzsam: if you retry those stuck jobs, I think it should pass now
08:47 tomeu: daniels: though for some reason my last pipeline is stuck: https://gitlab.freedesktop.org/tomeu/mesa/pipelines/116619
08:51 daniels: tomeu: everything is stuck right now - I'm about to upgrade GitLab for a security release, which means pausing all the available runners and draining the job queue
08:51 daniels: just waiting for the last job to finish now
08:55 hakzsam: yeah, error 503, waiting for the upgrade, np :)
09:06 tomeu: nice!
09:20 daniels: tomeu: err, can you please send me the lavacli/lqa yaml config files again?
09:20 daniels: i think someone might have been a bit too thorough in cleaning up after switching runner types, and deleted the VM the LAVA runner was on
09:20 daniels: not sure who that person would be however
09:20 tomeu: cleaning is good!
09:21 daniels: so clean there's literally no trace of it
09:23 tomeu: daniels: sent, I haven't tested it though
09:27 daniels: tomeu: thanks, where does it need to be written to again?
09:28 tomeu: volumes = ["/home/anholt/lava-config/lavacli.yaml:/root/.config/lavacli.yaml", "/cache"]
09:29 tomeu: this job is ready to test it: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/1845264
09:30 daniels: phew, it works
10:14 danvet: pinchartl, more begging for review on my drmm series
10:14 danvet: lots of driver reviews/acks
10:15 danvet: lots of reviews on the core bits&pieces
10:15 danvet: but consistently no one daring to put an r-b or even ack on those parts :-/
10:15 danvet: sravn, tzimmermann ^^ also you folks, ack on the concept would be great
10:16 danvet: I'll want multiple people on this anyway before merging, so you wont be the lone approver of record :-)
10:16 tzimmermann: danvet, i'll take a look this afternoon
10:17 danvet: tzimmermann, no hurry since I'll be on vacations next week, but much appreciated
10:17 tzimmermann: ah, ok
10:17 tzimmermann: enjoy the time off
10:17 danvet: just figured I drop a few pings before heading out
10:18 danvet: j4ni, i915 perspective for drmm would be great too
10:18 danvet: since I'll need acks anyway to stuff this all into drm-misc
10:39 danvet: airlied, I'm on vacations next week so if Linus misses it pls apply "[v4] vgacon: Fix a UAF in vgacon_invert_region"
10:52 danvet: j4ni, drm/drm_displayid.h: Replace zero-length array with flexible-array member <- you're also going to push this?
11:07 danvet: ickle, drm: unbreak the DRM menu, broken by DRM_EXPORT_FOR_TESTS <- you're pushing?
11:08 ickle: compiling and pushing
11:21 ag01: Hi, i'm getting a free(): corrupted unsorted chunks when using MESA 19.1.6 with a gstreamer pipeline that includes a filter plugin. I'm using wayland/egl, and this issue wasn't present in 18.1.9. I'm using the snapdragon 410E SoC (adreno 306), and i've posted some of my finding on the 96boards forum here:
11:21 ag01: https://discuss.96boards.org/t/db410c-20-02-release-gstreamer-camera-pipeline-segmentation-fault/9544 - apologies if this is the wrong channel to post!
11:26 danvet: ickle, thx
13:07 karolherbst: jekstrand: mhh.. that stride bit is a bit more annoying actually: cast -> ptr_as_array -> array -> ptr_as_array and for arrays we get the glsl explicit_stride which eg isn't set for vectors at all
13:07 karolherbst: I am not even convinced nir_deref_instr_ptr_as_array_stride should return 0 even for glsl, but maybe I am also missing something here
13:33 pinchartl: danvet: I'll see what I can do :-)
13:34 pinchartl: it would help if everybody stopped sending patches for a week though :-)
14:36 Venemo_: daniels: script failure on medon-s390x https://gitlab.freedesktop.org/Venemo/mesa/-/jobs/1850004
14:48 Venemo_: meson*
14:49 MrCooper: ugh, first time I see it hitting timeouts on a gstreamer runner
14:52 Venemo_: umm, this is not gstreamer, or is it?
14:56 MrCooper: I made this job use the gstreamer runners because the packet ones kept hitting these timeouts
14:56 jekstrand: karolherbst: We shouldn't have ptr_as_array in GLSL
14:57 karolherbst: jekstrand: the problem is I have array in CL
14:57 karolherbst: but mhh, I thought you can have ptr_as_array in glsl with those fancy extensions
15:01 karolherbst: jekstrand: I need something like this to make it work: https://gist.github.com/karolherbst/088a094feabeb22cc839b8694148528e
15:01 karolherbst: which we obvisouly can't do
15:01 karolherbst: but I am wondering why it's fine for that function to get 0 returned anyway
15:07 MrCooper: Venemo_: have you retried the job? Maybe the runner just happened to be overloaded
15:08 Venemo_: MrCooper: I have no idea. just received an email about the failure
15:09 MrCooper: you have no idea if you've retried the job? :)
15:09 Venemo_: I don't know what retiring it means exactly
15:09 Venemo_: I didn't cancel the job, if that's what you mean
15:10 MrCooper: the "Retry" button at the top right of the job page
15:11 Venemo_: ah. I will try that
15:11 Venemo_: right now my plane is about to take off, so not at the moment
15:11 MrCooper:clicked the button
15:12 Venemo_: usually they work after I hit retry, but I hate these random failures
15:12 MrCooper: I'm afraid you just go unlucky again
15:12 MrCooper: got
15:12 Venemo_: :(
15:13 Venemo_: I guess we could make it into a drinking game
15:14 MrCooper: maybe wait until your plane has arrived
15:14 MrCooper: the job passed now
15:14 Venemo_: cool
15:14 Venemo_: :)
16:19 sravn: danvet: drmm stuff on my todo list for the weekend. You fixed all my major issues with the core stuff from a first look, but I need more time to focus to do a proper review
16:21 sravn: pinchartl: "A no new patches" week would be nice :-) Especially when people keep sending those 50+ series.
16:22 sravn: pinchartl: My next series is a slim ~35 patches with only trivial binding changes. But I may need a bit more time to polish before pestering you and others with the patches.
17:34 danvet: sravn, thx a lot
18:17 lrusak: anyone know how to update the github mirror for drm-tip? https://github.com/freedesktop/drm-tip
20:02 sravn: danvet: static inline int drm_mode_config_init(struct drm_device *dev)
20:02 sravn: danvet: { return drmm_mode_config_init(dev); }
20:03 sravn: danvet: So the wrapper is the old deprecated way.. I will response by mail too
20:05 danvet: sravn, how does __must_check work with your wrapping?
20:09 Lyude: ok-mst regressions should -actually- be fixed now :). and, wow, I think this is the first time I have ever actually seen plugging one MST hub into another already-connected hub actually work correctly on Linux
20:09 Lyude: i think we have done a good job (amd deserves some credit here as well!)
20:09 Lyude: (and sean)
20:09 Lyude: (basically most people I guess)
20:09 sravn: danvet: I did not try to build it. But we have __must_check on drmm_mode_config_init(), so here we are safe. I assumes that we are safe by the "return drm_mode_config()".
20:10 sravn: danvet: Or do the compiler then infer a __must_check also on the inlined drm_mode_config_init() function?
20:10 danvet: sravn, hm yeah might work
20:52 Lyude: hm, this is going to be a hard one to answer but maybe someone in here knows: would the cable length limit for DP still apply to the sum of the distance of each cable leading down to a sink in an MST topology?
20:52 Lyude: or would the MST hubs themselves basically act as repeaters
20:53 imirkin_: speculation: they're repeaters. it's not like an ethernet-style ether where everyone talks on the same wire.
20:54 HdkR: ^ Should be a repeater in MST case. Though I've seen DP KVMs where it isn't a repeater
20:54 imirkin_: right - if it's not active compoennt visible in the topology, then it doesn't count
20:55 Lyude: alright, that's what I assumed
20:56 Lyude: was seeing a sink plugged in like mstb #1 → port #1 → mstb #2 → port #2 → sink flicker every now and then and wondered if that was it, but I think that might have been a glitch in the matrix or I had too many power cables around my displayport cables…
20:56 Lyude: i guess now I know how to make unreasonably long displayport connections
20:57 imirkin_: with fiber?
20:58 Lyude: imirkin_: no, just keep plugging mst hubs into eachother :)
20:58 imirkin_:wonders about latency implications
20:59 Lyude: imirkin_: there are some! honestly I do genuiunely want to try hooking up the max number of daisy chained hubs allowed by the spec to make sure that we actually handle said latency implications right
20:59 imirkin_: quick search reveals a 15m-long DP cable. that's pretty wild.
20:59 Lyude:shudders
20:59 Lyude: maybe that's allowed by the spec but with how sensitive DP seems to be to electrical noise sometimes I'd be amazed if that didn't have problems
21:00 imirkin_: https://www.startech.com/Cables/Audio-Video/DisplayPort/15-m-active-optical-displayport-cable~DP14MM15MAO
21:00 Lyude: oh-it's optical, that's probably OK
21:00 imirkin_: it's such a steal at $284 that it's on backorder!
21:01 Lyude: that's less then a diamond plated DP cable
21:01 imirkin_: well, there are some non-optical ones, but they don't advertise 8k@60
21:03 danvet: imirkin_, maybe the spec's definition of "works" means fallback to 1.62GHz at most
21:03 HdkR: Oculus has a 5m fiber Type-C but it doesn't work as a regular type-c :(
21:06 HdkR: Tried using it for a DP->DP run over type-c and Linux just tries resetting the port
21:08 Lyude: HdkR: link training failure and it needs to try falling back to a lower link rate but doesn't and instead gets stuck in a retraining loop?
21:13 HdkR: Lyude: Maybe? It is rated for 5gbps, even even slower USB devices were failing with it
21:39 austriancoder: whats the best way to test if I can enable PIPE_CAP_SHAREABLE_SHADERS?
21:42 anarsoul|2: just a guess -- enable it and check if anything breaks?
21:49 anholt_: anarsoul|2: not really, it's going to have basically no test coverage.
21:49 anarsoul|2: ouch
21:59 karolherbst: requires CL
21:59 karolherbst: otherwise there is no other user
22:00 karolherbst: ohh wait, mesa actually uses it as well
22:00 karolherbst: actually.. I confuse it with something else
22:00 karolherbst: don't mind me
22:01 imirkin_: anarsoul|2: for historical reasons, shaders are on context rather than screen
22:01 imirkin_: anarsoul|2: if you enable that cap, you're basically saying that the shader cso has no dependency on the pipe_context
22:01 anarsoul|2: guess we should enable this cap in lima
22:02 imirkin_: which also enables st/mesa to not have to recompile the same shader for multiple GL contexts
22:02 imirkin_: otoh if you make use of various other shader keys, it's not as interesting
22:06 anarsoul|2: imirkin_: what shader keys?
22:09 imirkin_: anarsoul|2: a bunch of PIPE_CAP's have been added recently
22:09 imirkin_: to add shader keys to st/mesa
22:10 anarsoul|2: any examples?
22:17 imirkin_: PIPE_CAP_FLATSHADE or something
22:17 anarsoul|2: 0 for lima
22:18 imirkin_: 0 = you get variants
22:19 Lyude: why VESA ever thought that intentional timeouts were ever a smart way to respond to an invalid sideband message in DP MST I will never understand :\
22:31 austriancoder:has created a MR
22:43 anarsoul|2: I wonder if there're any known apps that use shaders created in different ctx
22:44 anarsoul|2: I suspect that q3a can be one since it spends *a lot* time recompiling shaders with gl2 renderer when running on lima
22:44 anarsoul|2: but it's just a guess :)
22:45 karolherbst: anarsoul|2: dolphin does
22:45 imirkin_: anarsoul|2: it's fairly common among more modern software
22:45 anarsoul|2: karolherbst: file manager from plasma?
22:45 karolherbst: the GC emulator
22:45 imirkin_: GC/Wii
22:47 anarsoul|2: requires gl3
22:48 anarsoul|2: => can't run on lima
22:48 imirkin_: it used to semi-work with GLES3 at some point
22:48 karolherbst: that's not the only reason it can't run on lima :p
22:48 imirkin_: i doubt this will be a big deal for lima, tbh
22:48 karolherbst: depends
22:48 imirkin_: but you were asking, so... i felt obliged to provide info :)
22:49 anarsoul|2: imirkin_: no GLES3 either
22:49 karolherbst: what does it use on android then?
22:49 imirkin_: GLES2 presumably
22:49 anarsoul|2: karolherbst: GLES3
22:49 karolherbst: ohh lima can't do GLES3 either.. gotcha
22:49 imirkin_: but it could?
22:49 anarsoul|2: no
22:49 austriancoder: fdo-packet-arm2: fatal: write error: No space left on device
22:50 anarsoul|2: imirkin_: it's GPU from 2008
22:50 imirkin_: anarsoul|2: right, so ... GLES2 on android then?
22:50 imirkin_: anarsoul|2: fwiw G80 is from 2006 and does GL 3.3 :p
22:50 imirkin_: with a _slightly_ different power envelope...
22:50 anarsoul|2: imirkin_: what do you mean? dolphin requires gles3 on android as per wikipedia
22:51 anarsoul|2: mali4x0 supports only gles2
22:51 karolherbst: imirkin_: there are some lower power teslas though
22:51 karolherbst: :p
22:51 imirkin_: either i or you misinterpreted karol's comment
22:51 imirkin_: i interpreted it to mean "how does android do graphics then"
22:51 anarsoul|2: well, I guess it could do gles3 if we did vertex shaders in software
22:51 imirkin_: whereas you interpreted it to mean "how does dolphin run on android"
22:51 karolherbst: wait.. you don't have vps?
22:51 karolherbst: ufff
22:53 anarsoul|2: yet hardware doesn't have MRT support...
22:54 anarsoul|2: *sigh* I wish ARM released docs for utgard... they abandoned it anyway
22:54 imirkin_: does it have everything else though?
22:54 imirkin_: like integers, etc?
22:54 anarsoul|2: imirkin_: nope, we lower integers to floats
22:54 imirkin_: MRT can be faked by doing the render a bunch of times
22:54 anarsoul|2: also no fp32
22:55 imirkin_: heh
22:55 imirkin_: yeah, GLES3 may not be your speed then
22:55 imirkin_: you kinda need to support things like bit ops
22:55 imirkin_: and fancy texture/rt formats
22:56 HdkR: anarsoul|2: feature complete ES 2.0 driver now right? :)
22:56 anarsoul|2: HdkR: well, IIRC deqp pass rate for gles2 is ~96%
22:57 anarsoul|2: we have some issues with gpir compiler (one for vertex shaders)
22:58 imirkin_: that's pretty good
22:58 imirkin_: the final few % are the hardest
22:58 austriancoder: did anyone looked into bordercolor lowering for nir?
22:59 anarsoul|2: austriancoder: are you sure your hw doesn't support it?
22:59 imirkin_: i965 needs it :p
22:59 HdkR: anarsoul|2: Nice
22:59 imirkin_: unfortunately you can't really do it without also reimplementing texturing in the shader on top of like texelFetch.
23:00 austriancoder: anarsoul|2: for the older ones I am 100% sure
23:03 austriancoder: imirkin_: hmmm ... sounds like much work
23:04 imirkin_: yes, a lot easier if your hw just supports it
23:04 imirkin_: fwiw pretty much all DX10 hw gets integer border colors wrong
23:04 anarsoul|2: also that'll likely affect performance and you don't want that on older hw
23:05 anarsoul|2: however I'm not sure how branching is implemented on vivante
23:15 anarsoul|2: hm, something's wrong with gitlab? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4055#note_429801
23:20 anarsoul|2: MR seems to be merged, but gitlab is not aware :\
23:20 anarsoul|2: daniels: ^^
23:25 mattst88: 11:25PM in London, daniels is probably doing better things at the moment than tending to gitlab :)
23:26 anarsoul|2: mattst88: well, he'll probably see it tomorrow
23:26 anarsoul|2: or on Monday
23:26 anarsoul|2: :)
23:26 mattst88: heh
23:26 anarsoul|2: I'm just not sure whom else to ping
23:52 imirkin: should just have an auto-disable for CI on weekends :p
23:55 anarsoul|2: imirkin: I don't have much time to work on lima on workdays :(
23:56 imirkin: that was a tongue in cheek comment