09:05 pq: vsyrjala, the kernel cannot degrade other connectors harder unless their CRTCs were added to the commit, right?
09:35 mlankhorst: sima airlied: https://patchwork.freedesktop.org/patch/716063/?series=164264&rev=1 should this be drm-next or drm-xe-next?
09:36 sima: mlankhorst, if you have the backmerge already in drm-xe-next then I think best to apply it there (since that's where most xe testing/bisecting happens) and then feed it into drm-next through the usual pr train
09:37 sima: also I guess since this looks eerily like the one I've screwed up already, but once again, make sure it's extra highlighted in the pr mail so we don't screw up a 3rd time
09:38 sima: or is this a new one and somehow the xe wa table is just extremely prone to mismerges by airlied&me?
09:38 sima:a bit confused
09:40 mlankhorst: hm I thought it was a new failure, let me find the original kernel builds
09:44 mlankhorst: Yeah the most recent failure broke on 30 march 18:44 and 19:20, not sure why exactly.
09:44 mlankhorst: Also uncertain what timezone
09:46 mlankhorst: Around the time drm-xe-next was merged into drm-next
09:53 mlankhorst: Yeah looks like drm-xe-next is the correct place now
10:00 vsyrjala: pq: it can with allow_modeset=true
10:23 pq: vsyrjala, huh? That's new.
10:25 vsyrjala: been like that forever
10:25 pq: vsyrjala, that means that userspace needs to inspect the feedback properties of everything on the modeset of anything.
10:25 vsyrjala: i suppose
10:26 pq: I find that unexpected.
10:27 pq: even more reason to get pairs of setting/feedback properties for everything that drivers choose automatically.
10:28 vsyrjala: just a small matter of convicing someone to write the code
10:29 pq: yeah, this half a piece at a time doesn't seem to work too well
11:41 karolherbst: glehmann: well libclc comes with software emulation for fma, so that's not necessarily a problem
11:41 karolherbst: just makes things very slow :)
11:42 karolherbst: which also means we could emulate fma for games that really really will require it
11:42 karolherbst: anyway.. I really should do the proper fma work, because I need it for CL, because atm zink gets the emulated fma :')
11:49 glehmann: same for radeonsi before rdna2
12:04 zmike: in zink you'd have to hook up the extension anyway
12:13 karolherbst: yeah...
12:13 karolherbst: it's on my todo list...
12:13 karolherbst: glehmann: got fma added that late? I thought there was slow fma before that
12:14 karolherbst: gfx6 seems to have fma, but not sure what RDNA that is
12:15 karolherbst: ohh looks like that GCN so yeah.. even with 1/4 of the speed of fmad, this is still faster than emulated ffma :)
12:16 karolherbst: anyway, there is a plan to properly model all of this
12:42 glehmann: fma is full rate since gfx9, but since we had mad too, it was judt easiert to use that
12:42 glehmann: rdna2 removed mad
13:08 anonymix007[m]: Am I supposed to export sync files from DMA buffers when importing into Vulkan? I tried not to and there clearly is tearing. I also tried to do so and the Vulkan driver hangs in drmSyncobjTimelineWait
15:01 karolherbst: glehmann: right, the point is just that using ffma on the older hw is better than the emulation, and with the plan I was discussing with gfxstrand we do have a way that drivers can make the correct choices