10:51 daniels: mlankhorst: I'm applying a fix commit to drm-misc for a commit which is in drm-misc-next (as well as the PR airlied sent to Linus for 6.17) and has been applied there, but is not in drm-misc-fixes as that hasn't had a backmerge yet. am I right to think that I should be pushing it to drm-misc-next-fixes, so the next fixes-for-6.17 pull req includes it?
10:59 mlankhorst: daniels: That's the correct place!
10:59 mlankhorst: Or if it can wait until monday I'd put it in rc1
10:59 daniels: \o/
10:59 daniels: it's not super-urgent, so happy to do whatever's easiest for you, as long as it gets into 6.17 at some stage
11:01 mlankhorst: just put it in next-fixes, I don't think it has been pulled in yet so it doesn't matter in either case
11:03 daniels: sweet
11:05 daniels: thanks!
12:09 zmike: mareko: what are we waiting for on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36296 ? just me to investigate that random game or ?
17:29 mareko: zmike: an explanation how the multi-context buffer release works
17:29 mareko: there should be a large comment somewhere for any non-trivial stuff
19:05 zmike: mareko: I did explain it some, and I can add more comments, but in general are we good to go? if so I'll start reorganizing things into commits that might actually be merge-able
19:33 mareko: zmike: in general yes, but I still need to review the multi-context stuff
20:04 mareko: what is the different between load_global, load_global_constant, and load_constant?
20:06 mareko: nevermind load_constant, but what about load_global_constant?
20:22 glehmann: I think there isn't really a difference, at least if the load_global is flaged as ACCESS_CAN_REORDER
20:22 glehmann: so load_global_constant should probably be removed at some point
20:30 karolherbst: mareko: load_global_constant is considered to load from a constant buffer that never changes
20:30 karolherbst: or at least not while the shader is executing
20:33 austriancoder: I want to "transport" the action (begin, pause, resume, end) of transform feedback down into the gallium driver. At the moment I have some wild logic in the gallium driver to guess the action based on pipe->set_stream_output_targets(..) calls. My HW has one register which wants the current xfb state: enabled, paused/stopped or resumed.
20:34 austriancoder: shall I extend set_stream_output_targets(..) with a hint argument?
20:44 austriancoder: or maybe add a new set_stream_output_state(..)