00:21ishitatsuyuki: I've got a Navi card and AMDGPU is giving me fence timeouts a lot (it locks up the whole system). I do a force power reset when it happens. Any way to get a less destructive restart in those cases?
01:05airlied: dcbaker: the latest meson in fedora 32 seems to fail to build mesa
01:06airlied: /usr/bin/ld: src/gallium/state_trackers/dri/libdri.a(dri2.c.o): in function `dri2_interop_export_object':
01:06airlied: /home/airlied/devel/mesa/mesa/build/../src/gallium/state_trackers/dri/dri2.c:1813: undefined reference to `st_finalize_texture'
01:06airlied: /usr/bin/ld: src/gallium/state_trackers/dri/libdri.a(dri_screen.c.o): in function `dri_init_screen_helper':
01:06airlied: /home/airlied/devel/mesa/mesa/build/../src/gallium/state_trackers/dri/dri_screen.c:580: undefined reference to `st_gl_api_create'
01:06airlied: downgrade from 0.53.2 to 0.53.1 seems to fix it
07:45tpalli: fdo gitlab giving 503
07:50tpalli: ok now works again
08:38pq: danvet, I like your definition on the difference of C8 and R8.
10:00danvet: lynchc, pankaj doesn't have commit rights, so can you go ahead and merge "[PATCH 0/5] Cleanup drm_dp_mst_topology_cbs hooks"?
10:07danvet: pq, enough to write a small patch for the drm_fourcc.h header?
10:12danvet: ickle, [PATCH] drm: Clean up unused code, to improve a system! <- I guess you'll apply that one?
10:14danvet: tagr, [PATCH v2 01/17] drm/tegra: remove checks for debugfs functions return value <- just to check, still a-b: you?
10:37pq: danvet, me write a patch? What should it say, given we have no use cases yet AFAIK.
13:51movi: hi. do you guys accept EDID issues as well? :)
14:19imirkin_: movi: what kind of issues?
14:20movi: imirkin_: i have a device which transmits high VIC modes (like 4k60) but sets the max pixelclock in the DTD too low, so they can never be used unless forced. X for example discards them outright
14:25imirkin_: you can fake an edid with drm.edid_something
14:44vsyrjala: movi: do you mean the max tmds clock in the hdmi extension block(s) is too low?
14:46vsyrjala: though i dunno if xorg's edid parser even parses the hdmi 2.0 ext block. if it doesn't that could explain why it drops modes w/ high dotclock. i guess someone should finally tell x not to parse such things from the edid at all
14:49vsyrjala: hmm. looks like there some kind of MaxClock xorg config knob that could override that
15:13MrCooper: ickle: FYI, your dri-devel list subscription got disabled due to megamailservers.eu bouncing list posts for "containing SPAM-like characteristics"
15:13ickle: I love ISPs
15:16ajax: vsyrjala: xserver does know about the hdmi max_tmds_clock field, assuming it's not changed much since 2010 or so. if hdmi 2.0 defined something newer then it's news to xserver.
15:17ajax: but i don't think it did, at least if i'm reading drm_edid.c correctly
15:25vsyrjala: hdmi 2.0 introduced a new ext block
15:28vsyrjala: see drm_parse_hdmi_forum_vsdb()
15:41movi: imirkin_: already did. i actually "patched" it to work ok
15:41imirkin_: movi: i think there's a table somewhere of edid quirks
15:42imirkin_: if you can make it work with that, i expect it'd be accepted upstream
15:42movi: imirkin_: it works for me, but i'd like the edid parsing to either make a quir or ignore dtd's altogether. windows seems to do, and i remember a patch floating around that did just that
15:42movi: you can look at the dumb edid here, it's the yamaha one https://bugs.freedesktop.org/show_bug.cgi?id=87508
15:43movi: oh sorry, wrong bug
15:46movi: https://bugzilla.kernel.org/show_bug.cgi?id=206833 that's the one. look at the yamaha edid
15:46imirkin_: right, so if you can extend the quirking mechanism to account for your use-case, i'm sure it'd be accepted
15:46movi: can you show me the whereabouts of the code that lives?
15:49movi: thanks, i'll take a look, however, from what i see you take a patch-specific-device approach. would a ignore-max-clock-if-there-are-higher-vics approach be considered?
15:49movi: as this is what other devices seem to do. windows sets the default resolution according to dmt, but allows for higher modes. the ps4 ignores the dmt outright
15:57imirkin_: vsyrjala: opinion on --^ ?
15:58vsyrjala: i don't see any kernel issue there. the avr seems to remove the 4k@60 preferred mode for some reason, but there are still 4k@60 modes coming via the vics
16:01jekstrand: daniels: So... EGL_image_explicit_sync_control.... Is it implemented anywhere?
16:01jekstrand: daniels: The extension says it was written by this Daniel Stone guy so I thought maybe you would know. :-P
16:03imirkin_: vsyrjala: sounds like modes are being rejected due to some max clk in the edid
16:04vsyrjala: by the xserver i think. though i don't quite understand why the change in behaviour. the max tmds clock declared in the edid is the same either way
16:06daniels: jekstrand: it never ended up getting reviewed on the Mesa side, and I never ended up pushing it too hard because it's really annoying to use in Wayland as it stands
16:07daniels: (you have to import an EGLImage whenever a client creates a dmabuf wl_buffer so you know whether or not it's acceptable to the GPU - but you don't know whether or not to pass the implicit_sync_control token to EGLImage creation because the implicit-sync extension is per-surface rather than per-buffer ...)
16:07daniels: so I'd be quite tempted to rev the implicit-sync extension to be purely additive to the dmabuf creation phase, ignoring surfaces
16:08jekstrand: It's just that right now we're still getting some implicit sync even with explicit sync_files being passed around
16:08daniels: yeah, I do remember what the extension was about :P
16:09jekstrand: Not that the implicit sync will work, mind you. Vulkan smacks every buffer with EXEC_OBJECT_ASYNC so the fence isn't getting set, it's just that the server is trying to wait on it.
16:09jekstrand: So I don't think it's an actual problem, at least not today.
16:09jekstrand: It just annoys me to no end. :-P
16:24movi: vsyrjala: indeed by the xserver. i haven't tried it on a pure gmb app, like kodi though
16:25Venemo: hey jekstrand do you have a moment? how would you feel about adding I/O masks to shader_info? something along the lines of what get_variable_io_mask would return? we have something similar in ACO, but we'd like to expand that. would such a thing be useful to you?
17:01dcbaker: airlied: Okay, I'll look into it
17:27shadeslayer: tomeu: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4162 is ready to be merged now :)
17:46robclark: does shader->info.name correspond to the .shader_test files that mesa dumps (ie. MESA_SHADER_CAPTURE_PATH)? I'm wondering if I could stash that in a CP_NOP packet and use that to map back to shader I see in cmdstream where things crash?
19:24jekstrand: Venemo: I thought we had I/O masks. We have inputs_read and outputs_written. What else were you thinking?
19:24jekstrand: Venemo: Sorry. Was buying groceries and getting lunch.
19:40Venemo: jekstrand: no problem. we need slightly more than inputs_read and outputs_written.
19:42jekstrand: Venemo: What more do you need?
19:42Venemo: jekstrand: we have this currently: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/compiler/aco_instruction_selection_setup.cpp#L903 this is useful because it allows us to set up the driver location for our variables in a very efficient manner.
19:43jekstrand: Venemo: Pardon my confusion but that looks a lot like inputs_read and outputs_written to me.
19:44Venemo: jekstrand: I think this is closer to what it is closer to what get_variable_io_mask does in nir_linking_helpers
19:44Venemo: isn't it?
19:45Venemo: maybe I'm missing something
19:45jekstrand: I'm not sure
19:45jekstrand: One of us is missing something.
19:45jekstrand: set_io_mask in nir_gather_info seems pretty complete to me
19:45Venemo: let me take a look
19:45jekstrand: The one thing that the ACO patch does which NIR doesn't that I can see immediately is that it combines stages
19:46jekstrand: But that's not really something nir_gather_info can do
19:49Venemo: I'm pretty sure there is a reason why we have that instead of just bitwise ORing the inputs_read and outputs_written of each stage
19:49pendingchaos: I can't remember for certain why we don't use nir_gather_info's masks
19:49pendingchaos: ACO also marks whole variables while nir_gather_info marks accesses though
19:50pendingchaos: which might make it more useful for assigning locations to variables
19:50Venemo: there is a mark_whole_variable in nir_gather_info
19:50pendingchaos: Venemo: that's only done if it can't partially mark the variable
19:50Venemo: I see
19:51pendingchaos: probably why it wasn't used, I think it could mess up arrays
19:52Venemo: so AFAIU the difference between what's in NIR and what's in ACO is the distinction between accesses of variables, and the existence of variables
19:52pendingchaos: I think so
19:53pendingchaos: var0 (float) gets driver_location 0, var1 gets driver_location 1 (because only element 1 of var0 is written), nir_lower_io creates a write at driver_location 1 for var0
19:53jekstrand: On Intel, we don't do indirects on most things so it's a non-issue.
19:53jekstrand: We could allow it on inputs, in theory, but it's a lot of work.
19:54Venemo: for us, it's not an issue either, but rather a missed opportunity for optimization
19:56Venemo: would it make sense to add some kind of toggle to nir_gather_info to collect what we need? or maybe have separate fields in shader_info?
19:56jekstrand: Venemo: We could add a toggle, I suppose.
19:57Venemo: in fact, we care about both things
19:58Venemo: so I think best would be separate fields
19:58Venemo: not sure how to call them
20:01Venemo: maybe inputs_existing and outputs_existing? would that make sense?
20:02Venemo: or we could keep calling it io_mask, since that's what nir_linking_helpers already calls it
20:02Venemo: that makes sense too
20:04Venemo: in fact, could this be filled by nir_linking_helpers rather than nir_gather_info? since these fields would be mostly useful with the knowledge of what the previous and next stages are like
20:05Venemo: jekstrand: one possible example is a TCS which writes 3 outputs, and a TES which reads only 1 of those. we need the new field so that we can allocate the correct driver location to both of them.
20:07jekstrand: Venemo: You know, you can do things in the driver compiler. It's ok to do that. :-P
20:08jekstrand: More seriously, I'd be fine with having an `inputs` or `input_locations` mask if it's useful to someone.
20:11Venemo: jekstrand: we currently do this within ACO, but ACO doesn't have knowledge of any stage other than what it currently compiles. so we have to move it either to RADV, or to NIR. since NIR already almost does what we need, I think it's make sense to add it there, just in case it is useful to other people
20:11jekstrand: In our driver, we put that stuff in a vue_map data structure which is generated by the driver and passed into the back-end compiler
20:12jekstrand: That data structure also contains a bit more than just masks
20:14Venemo: we could squeeze it into RADV as well, if we wanted to
20:16jekstrand: I'm fine with having stuff in NIR if it's useful
20:16jekstrand: Also, you can modify those fields in RADV if you want
20:16jekstrand: Just be careful if you do
20:16Venemo: I'll think about it a bit more
20:19Venemo: jekstrand: different topic. I made a NIR patch which adds a field called tcs_reads_only_vertices_of_invocation_id. I was not sure where to add it though. do you think this is an okay approach? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4165/diffs?commit_id=71e2cfa62a2ad36948420d6dfa9484a8c9b0cf93
20:20jekstrand: Venemo: Seems like a reasonable thing to have
20:21Venemo: cool, thanks :)
20:21jekstrand: Personally, I think I'd make the boolean go the other direction: "does this read cross-invocation?"
20:21Venemo: can edit it like that if that's preferred
20:21jekstrand: Maybe tcs_reads_other_invocation_vertices?
20:21jekstrand: naming is hard. :(
20:22jekstrand: I'm not in love with that name either TBH but it at least seems a bit clearer to me.
20:26Venemo: yeah, maybe
20:27Venemo: I can rename
21:18Venemo: jekstrand: how about tcs_reads_cross_invocation_vertices ?
21:21jekstrand: Venemo: sounds good
21:28Venemo: ok, thx
22:34jekstrand: marcheu, krh: Any objections from Chrome if I make syncobj a hard requirement for ANV? I don't know what kernels you're running these days. It might end up meaning a forward-port of the kernel feature but it should be an easy port.
22:35jekstrand: We've got 7 implementations of VkSemaphore right now and dj-death has patches for an 8th. I'd like to delete some of them. :-)
22:36jekstrand: If Chrome was ok with requiring syncobj, I could at least delete the non-syncobj sync_file path
22:37jekstrand: Hrm... Actually, it's only 6. I miscounted.
22:38imirkin_: don't worry, it'll be 7 soon
22:39jekstrand: tjaalton: Any thoughts on the above? Probably best to wait for Ubuntu 20.04 before droppting 18.04 support from ANV.
22:39jekstrand: imirkin_: Yeah... Rev'ing kernel APIs sucks....
22:39imirkin_: should have gone the openbsd way -- kernel + userspace are locked together
22:40jekstrand: imirkin_: And maintain 17 stable branches of Mesa? I'd rather not.
22:40imirkin_:needs to stop forgetting <sarcasm> markers...
22:41imirkin_: otoh, it should just be implied around anything i say
22:41jekstrand: imirkin_: My brain inserts them automatically
22:41imirkin_: very good.
22:41marcheu: jekstrand: what kernel version is that? worst case we can disable vk on older platforms
22:45jekstrand: But, like I said, it's an easy back-port if that's needed.
22:45marcheu: I think kernel < 4.14 aren't very stable for vk anyway
22:45airlied: let's just pull mesa into the kernel tree :-P
22:46jekstrand: airlied: No, we need to pull the kernel into the mesa tree. Microkernels all the way!
22:46jekstrand: userspace DRM. What could go wrong?
22:47airlied: just need one super priveldged process, let's call it X
22:47jekstrand: Oh, wait, I think we did that once... We called it Q? or was it Y? Oh, no, it was X
22:47airlied: hehe snap :-P
22:48imirkin_: should just call it kthread and be done with it...
22:48imirkin_: no one will know.