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