00:43 mareko: there is also softpipe ;)
05:58 airlied: jani: I think I just baked the xe WA collision into drm-next :(
06:01 airlied: zmike: any idea how mesh shaders interact with gl point size?
06:02 airlied: since I think st_point_size_per_vertex might be wrong
06:07 airlied: (not the bug I'm chasing, but I think it's another one)
08:19 linkmauve: Lyude, thanks! I’ll refrain from starting my driver until then then, but feel free to Cc me so that I’ll review your abstractions while writing my driver.
08:31 soreau: linkmauve: have you decided on a name yet? I propose that you call it 'driver', then it will be known as the driver driver ;)
08:32 linkmauve: Likely flipper or something like that.
08:32 jani: airlied: auch, you got it figured out?
08:33 jani: looks like
09:15 dj-death: is gitlab a bit down?
09:15 dj-death: can't push or load mrs
09:16 pq: yes
09:18 airlied: jani: well I think we need to backmerge something somewhere to fix it, but not sure where
09:21 jani: airlied: drm-next -> drm-xe-next
09:21 jani: I've already pinged the xe maintainers
09:45 pixelcluster: mlankhorst: do you mind/have the time to take a look at https://patchwork.freedesktop.org/series/163183/ ? a lot of the patches already got review, but the cgroup/dmem parts need someone to look at them
10:00 mlankhorst: pixelcluster: yeah will do so
10:01 mlankhorst: pixelcluster: still following the entire discussion btw :)
10:01 pixelcluster: nice, thanks :)
10:01 pixelcluster: I suppose I might be getting a bit impatient :P
11:31 mlankhorst: pixelcluster: Yeah I've been busy trying to get reviews on PREEMPT_RT, getting intel display code merged takes even more patience. :-)
11:43 mlankhorst: It's fun though, PREEMPT_RT tries to make everything preemptible, but display programming has to run in a certain amount of bound time or it fails. Since taking any locks would sleep, to make PREEMPT_RT work all lock acquisition has to happen before programming HW, including some that are used to signal completion.
11:59 zmike: airlied: maybe Venemo remembers more immediately about the gl_PointSize and mesh shader interaction
12:04 Venemo: zmike, airlied, as far as I remember, in general the point size should work the same way for mesh shaders as it does for other types of shaders in that it only matters when the output primitive type is points. what is non-intuitive is that it's defined as a per-vertex output (when intuitively it should be a per-primitive one), and it's write-only in mesh shaders. I hope that answers your question
12:08 Venemo: I suppose in the case when the output primitive type is points, per-vertex and per-primitive doesn't make any difference, so the authors of the spec didn't want to change it
14:02 zmike: can we just delete virgl ?
14:03 zmike: I ask this every year, and every year I hope the answer is different
14:10 kisak: Where on this diagram did virgl hurt you? Can you say? That's like me asking for OpenCL to be deleted from my many packaging splinters.
14:11 kisak: (I'm not asking for things to go away)
14:12 zmike: it's almost always the odd driver out in ci fuckups and it's always annoying to debug
14:50 glehmann: can we make virgl use spirv by using zink's backend and spirv-cross on the server side?
14:54 zmike: mareko: I finally finished it https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40462