00:00 imirkin: but you have to used fixed-function things, since i don't think you can mix it with ES2+ things
09:08 MrCooper: eric_engestrom: got a minute to look at https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3087 ?
09:08 MrCooper: hakzsam: ^ you tested that this doesn't break the radv_polaris10_vkcts job, right? Can you reply to my comment accordingly?
09:09 hakzsam: done
09:15 MrCooper: thanks!
09:16 bbrezillon: narmstrong: around?
09:16 bbrezillon: narmstrong: do you plan to apply "drm: Add support for bus-format negotiation" soon?
09:18 bbrezillon: anholt_: Hi, can you have a quick look at "drm/vc4: dsi: Fix bridge chain handling"?
09:21 mlankhorst_: ickle: do you have a new version of nuking execbuf_flags?
09:26 mmind00: mlankhorst_ mripard: not sure if you have seen the question from yesterday, so would it be possible to get a 5.5-rc1 into drm-misc-next for the PHY_MODE_LVDS constant from https://elixir.bootlin.com/linux/v5.5-rc1/source/include/linux/phy/phy.h#L42 ?
09:28 mripard: mlankhorst_: do you have some time to do it? if not, I can do it
09:50 narmstrong: bbrezillon: sure, I can
09:52 narmstrong: bbrezillon: did you have time to look at my "[PATCH v5 0/4] drm: Add support for bus-format negotiation" ?
09:53 bbrezillon: narmstrong: yep, it looks good to me
09:54 narmstrong: bbrezillon: can you ack the seris on the ML so I apply it ASAP ?
09:57 bbrezillon: narmstrong: hm, wait, didn't pinchartl suggested to make the default helpers private?
09:57 bbrezillon: narmstrong: acking my own patches? that sounds weird
10:09 narmstrong: bbrezillon: was not clear
10:09 narmstrong: bbrezillon: just to make sure you're ok with my repost/rework...
10:35 mlankhorst_: mmind00: done :)
10:56 mmind00: mlankhorst_: thanks a lot :-)
11:13 mlankhorst_: np
11:34 shadeslayer: hey, I was wondering if anyone could help me out with the hashtable implementation in the kernel? I'm not really sure I understand how to insert/fetch a key-value pair
13:24 Venemo: jekstrand or Kayden can we get an A-B or R-B on MR 2420, 2323 and 2422? these are all quite short patches and they do look fine to us, but would be nice to get some input from you guys
14:24 danvet: mmind00, just realized we need a backmerge into drm-next first, which I haven't chickened out of yet
14:25 danvet: mmind00, so might want to re-drop the excuse for the backmerge and ping airlied & me
14:26 mmind00: danvet: mlankhorst_ backmerged drm-next into drm-misc-next earlier today
14:27 danvet: oh cool, it all happened alredy
14:27 mmind00: yep all good and I got the PHY_* constant I needed :-D
14:28 danvet: mmind00, oh drm-next is only at -rc2, was that good enough for you?
14:28 mmind00: danvet: yep ... that constant got in during the regular merge-window from the phy tree, so even -rc1 would've been fully ok
14:29 mmind00: just needed that magic 5.5 in front
14:34 narmstrong: bbrezillon: v6 sent :-)
14:37 danvet: mmind00, ah cool
14:38 bbrezillon: narmstrong: and acked :)
15:58 jekstrand: Venemo: done
15:59 Venemo: thanks jekstrand
16:00 jekstrand: yw
16:00 jekstrand: They were all pretty easy
16:00 jekstrand: Venemo: I would like to see the GS patch run through Intel CI though. I'm fairly sure it's a no-op for us but would feel more comfortable if CI agrees.
16:00 Venemo: jekstrand: sure, how do we run it through Intel CI?
16:01 jekstrand: Venemo: craftyguy has to set you up with a branch
16:01 jekstrand: Venemo: I suppose I can run it
16:02 Venemo: jekstrand: I guess it's easier if you run it, but I'm also fine running it myself if you can show me how
16:08 jekstrand: Venemo: I pushed it
16:44 Venemo: jekstrand: what exactly is the Intel CI? doesn't it run automatically with mesa's own CI?
17:01 dcbaker: Venemo: Intel's CI predates the the mesa CI by a long shot, so no, it's not tightly integrated
17:01 dcbaker: or, integrated at all
17:01 Venemo: I see
17:01 Venemo: okay
17:20 Kayden: generally you push branches to https://gitlab.freedesktop.org/Mesa_CI/repos/mesa and results show up at https://mesa-ci.01.org/
17:20 Kayden: runs it on every generation of intel gpu
17:20 Kayden: full deqp/glescts/glcts/webglcts/skqp/vkcts
17:21 Venemo: wow, nice
17:21 Kayden: gitlab wasn't being used at fdo when we started
17:21 imirkin_: nice farm of i740's, i'm sure.
17:21 imirkin_: :p
17:22 Kayden: everything gen4+ and a couple of 945's still kicking around. no 8xx or earlier.
17:22 imirkin_: wise.
17:23 jekstrand: Kayden: We should merge the blorp HiZ patch
17:23 jekstrand: patches
17:23 Kayden: I did
17:23 jekstrand:fetches
17:24 Kayden: jekstrand: we should figure out something for the anv HiZ patch. :) and also land the GCM patches (!597)
17:26 jekstrand: I'm working on the anv HiZ patches now
17:26 Kayden: \o/
17:26 jekstrand: And I wanted to rebase them on top of the others
17:26 jekstrand: Because it cleans up some corner cases
17:26 Kayden: ah, nice
17:27 Kayden: from your comment, I wasn't sure exactly what you didn't like or wanted changed, or else I might've taken a stab at it
17:27 Kayden: but, glad to see it moving forward :)
17:29 jekstrand: Now that my PM blog posts and gamemode patches are in a holding pattern, I'm going to try to tie up some other loose ends.
17:48 dcbaker: hakzsam: let me know when you're ready for me to pull 824bd0830e811a7b6347bbd5c30e0a76bc7daf60 into 19.3
17:50 hakzsam: dcbaker: as long as you pull 17741a0a05722245314e8ce9a3d5191feb63d9bd it's fine to pull 824bd0830e811a7b6347bbd5c30e0a76bc7daf60
17:51 jekstrand: Have we released 19.3 yet?
17:53 kisak: 19.3.1 is out
17:54 hakzsam: Yeah, it's for 19.3.2
17:54 jekstrand: k
17:56 dcbaker: hakzsam: I'm guessing I shouldn't pull the revert of 17741 then?
18:02 kisak: dcbaker: what rever?
18:03 kisak: https://cgit.freedesktop.org/mesa/mesa/commit/?id=973181c06cca3fe232c3a435abde31f2fc1b81ef should have been reverted by https://cgit.freedesktop.org/mesa/mesa/commit/?id=f0ed67b770619b74120444aa3788197eef28597f, then replaced by https://cgit.freedesktop.org/mesa/mesa/commit/?id=17741a0a05722245314e8ce9a3d5191feb63d9bd
18:04 kisak: so 97318... can be skipped in the release branch
18:06 dcbaker: oops, I got those backwards, okay, I'll skip 97318. Thanks
18:08 hakzsam: dcbaker: I'm not in front of my computer atm but I can look in one hour or so
18:09 dcbaker: cool. I think that the staging/19.3 branch is correct at fdo
18:13 hakzsam: dcbaker : staging/19.3 looks good. Thanks!
18:55 jekstrand: Kayden: I think I've got a branch I'm reasonably happy with now.
18:55 jekstrand: I just kicked it Jenkins
19:02 anholt_: Kayden: for the ssbo series, https://mesa-ci.01.org/anholt/builds/16/group/63a9f0ea7bb98050796b649e85481845 any idea why just these boards would regress?
19:09 Kayden: jekstrand: \o/
19:10 Kayden: anholt_: That seems unrelated. Those aren't even using Gallium
19:10 Kayden: well, icl_iris is, but the others are i965
19:10 Kayden: thought that was strange also
19:10 Kayden: the fact that it fails on 4 platforms makes me think it isn't a flake though
19:12 anholt_: Kayden: the series does touch i965
19:12 anholt_: (swaps whether ssbos or atomics come first)
19:12 Kayden: oh, right, it does
19:12 Kayden: I'll try and take a look later today
19:46 krh: tarceri: could you take a look at the top commit in !332
20:38 tarceri: krh: looks good to me
20:45 krh: tarceri: thanks
20:45 Kayden: anholt_: I was going to say...num_abos/ssbos don't seem that useful, because...does it include one? does it include both? what's the max binding? which are which?
20:46 Kayden: anholt_: I was wondering whether it would be useful to add a ssbo_and_abo_bindings bitfield to shader_info
20:47 imirkin_: afaik r600 is the only driver that wants to treat abo/ssbo separately
20:47 Kayden: have num_abos > 0 mean "there are ABOs", and num_ssbos >0 mean "there are SSBOs" and ABOs start at num_ssbos, and you can just look at the bitfield or something...
20:49 anholt_: Kayden: I actually want to just pack the ABOs like we do for SSBOs, then the field will have the right meaning
20:50 Kayden: right, but...st at least needs to know which binding points to map to which section
20:51 Kayden: and maybe it'd be useful for st
20:52 anholt_: right now num_ssbos has the bindings baked in so they're packed, that that seems nice (though maybe causing extra rebinding of the states when programs use different sets of bindings per shader). I just want to do that to ABOs
20:52 anholt_: but working on that was really confusing when trying to understand the glsl-to-tgsi path, and eventually I punted
20:53 Kayden: ok
20:54 imirkin_: it was hard to write too :)
20:54 imirkin_: and if it was hard to write, it should be hard to read :p
20:54 imirkin_: but seriously, GL just does it in a very confusing way
20:54 imirkin_: ssbo's have a remapping thing like ubo's, while abo's don't
20:55 imirkin_: and iirc abo's are consistent across shader stages, while ssbo's have their own bindings per shader stage, essentially (since they have the remap table)
20:58 Kayden: oh... I think I see what's going wrong
21:04 krh: mareko: goodbye tgsi
21:05 krh: mareko: negative diffstat for 2020 so far?
21:08 imirkin_: that'll last for another 5 minutes...
21:09 krh: Kayden: does the fence debug output in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3172#note_370720 make sense to you?
21:15 Kayden: Tapani's? Not at all
21:16 Kayden: 5 fences but only 3 printed? and waiting on a single fence twice?
21:16 Kayden: that sounds really broken
21:17 Kayden: I'm not sure how that could even happen :/
21:20 ickle: iris_fence_create_fd() could be described as too trusting
21:20 ickle: if the FD_TO_HANDLE failed, we would create syncpt with handle=0
21:20 Kayden: oof
21:20 Kayden: good point
21:21 Kayden: that makes me wonder though, is it just certain ioctls getting sandboxed on android/celadon
21:21 Kayden: which would then cause failures, causing that
21:21 Kayden: we had to whitelist a bunch of new ioctls a while back
21:22 Kayden: we should probably improve that function to return a NULL fence for debuggability if nothing else
21:40 krh: Kayden: but it sounds like it's working for a bunch of submits before it fails
22:00 Kayden: hmm, that's a good point