00:43mareko: there is also softpipe ;)
05:58airlied: jani: I think I just baked the xe WA collision into drm-next :(
06:01airlied: zmike: any idea how mesh shaders interact with gl point size?
06:02airlied: since I think st_point_size_per_vertex might be wrong
06:07airlied: (not the bug I'm chasing, but I think it's another one)
08:19linkmauve: 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:31soreau: 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:32linkmauve: Likely flipper or something like that.
08:32jani: airlied: auch, you got it figured out?
08:33jani: looks like
09:15dj-death: is gitlab a bit down?
09:15dj-death: can't push or load mrs
09:16pq: yes
09:18airlied: jani: well I think we need to backmerge something somewhere to fix it, but not sure where
09:21jani: airlied: drm-next -> drm-xe-next
09:21jani: I've already pinged the xe maintainers
09:45pixelcluster: 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:00mlankhorst: pixelcluster: yeah will do so
10:01mlankhorst: pixelcluster: still following the entire discussion btw :)
10:01pixelcluster: nice, thanks :)
10:01pixelcluster: I suppose I might be getting a bit impatient :P
11:31mlankhorst: pixelcluster: Yeah I've been busy trying to get reviews on PREEMPT_RT, getting intel display code merged takes even more patience. :-)
11:43mlankhorst: 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:59zmike: airlied: maybe Venemo remembers more immediately about the gl_PointSize and mesh shader interaction
12:04Venemo: 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:08Venemo: 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:02zmike: can we just delete virgl ?
14:03zmike: I ask this every year, and every year I hope the answer is different
14:10kisak: 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:11kisak: (I'm not asking for things to go away)
14:12zmike: it's almost always the odd driver out in ci fuckups and it's always annoying to debug
14:50glehmann: can we make virgl use spirv by using zink's backend and spirv-cross on the server side?
14:54zmike: mareko: I finally finished it https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40462 17:55zmike: airlied: confirmed, the only 4.6 llvmpipe fails from cts-runner are the fbfetch one from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40437 and the two mesh ones you looked at
17:57zmike: if you're considering a conformance submission, I changed the rules a couple years ago so you could use this script to create your package in parallel https://gist.github.com/zmike/e8eec8fdb6eb1d264828b2affede993b 17:57zmike: which should allow it to complete in like 30-40 mins on a reasonably fast machine
18:00HdkR: zmike: But will it be conformant on non-x86? :P
18:01zmike: HdkR: https://i.imgur.com/xIVSeSQ.gifv 18:01HdkR: I /do/ have a wacking huge ARM device that I could do a run on to check.
18:02zmike: that's up to you, but conformance for software implementations is by architecture/platform
18:05HdkR: zmike: Interesting, so a Radeon RX 9070 would need conformance submissions on x86 and arm64 even though it is the same card?
18:05HdkR: What a curious system.
18:06jannau: not a software implementation (ignoring the driver)
18:07zmike: ^
18:07HdkR: ic
18:25mareko: if you want to compile your own GLSL shader in VK, what do you use? (I'm missing something like shader_runner)
18:27zmike: glslang ?
18:27mattst88: mareko: https://gitlab.freedesktop.org/mesa/vkrunner sounds like what you want
18:54Company: mareko: if you figure it out, tell me - I'm looking for something to use in GTK
18:55Company: so far I'm indeed looking at glslang
19:05Company: question: if I eglExportDMABUFImageMESA() and get 1 fd but eglExportDMABUFImageQueryMESA() tells me there are >1 planes, is that valid?
19:05Company: Do I now have a dmabuf with planes without fd?
19:06Company: and when importing that dmabuf in other places (ie Vulkan), are the drivers expected to deal with me passing them -1 fds?
19:09Company: I'm trying to figure out if I should (1) reject that, (2) just use the fd for all planes, (3) pretend there's only 1 place, (4) use -1 as the fd for those planes or (5) decide on a case-by-case basis because all of this stuff is a mess
19:14mareko: different planes have a different offset, but should have the same fd IIRC
19:16zmike: yeah you can have a dmabuf that has multiple planes
19:17Company: I think so far my assumption was that each plane has an fd
19:17Company: but the same fd can be used for multiple planes
19:18Company: but I got a report now that only the first plane returns an fd
19:18Company: on 26.0 with radeonsi
19:19Company: actually, my Vulkan code only supports 1 fd anyways, so that code is fine
19:21Company: so the question is relevant for importing with eglCreateImageKHR
19:22Company: I suppose I just omit EGL_DMA_BUF_PLANE1_FD_EXT in that case?
19:22Company: but specify EGL_DMA_BUF_PLANE1_PITCH_EXT and EGL_DMA_BUF_PLANE1_OFFSET_EXT?
19:55airlied: zmike, Venemo : if pointsize works like vertex shaders, then GL_EXT_mesh_shader support is buggy in the state tracker and CTS has a hole where it only tests 1.0 pointsizes
19:55zmike: that's extremely likely
19:59zmike: glcts definitely a very strong case for utilizing AI to write tests since the coverage is bad and nobody works on it
20:11dj-death: is there a way to get deqp-runner to just generate the testcase files without running the tests? :)
20:14cmarcelo: dj-death: maybe --deqp-runmode=txt-caselist ? (there are other run modes too)
20:21airlied: zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40475 20:23zmike: good find
20:27zmike: I filed a coverage ticket that'll never get filled
21:25dj-death: cmarcelo: thanks, but it's not helping
21:27cmarcelo: dj-death: what you mean by testcase files?
21:28Sachiel: I assume the way that deqp-runner takes the caselist and randomizes and splits in groups
21:28cmarcelo: oh, I confused deqp with deqp-runner..
21:30cmarcelo: you could try to make a script to pass as --deqp instead of the real deqp-vk, that will collect what each split list looks like.
21:31cmarcelo: (if I'm understanding this right...)
21:32Sachiel: there's also the really dumb way of making the driver crash on init and collect the lists it leaves behind of failed tests
22:09Venemo: airlied: I'm not familiar with that code. what's the bug?
22:16anholt: daniels: question on how the s3 buckets work: fdo-opa/artifacts/<user>/<repo> has per-pipeline/per-job stuff under it. how long does stuff in that bucket last? could I have things under user/repo/ that don't fit the pipeline/job schema? Because, for working on stabilizing a trace set, it would be nice to have the trace replay hash.pngs stored somewhere between jobs, so you can see and understand flakes and things (or see differences
22:16anholt: between drivers when setting up traces for multiple drivers)
22:17anholt: (dxvk replay is now working on lvp https://anholt.pages.freedesktop.org/-/mesa/-/jobs/95493273/artifacts/results/index.html) 22:27glehmann: why are the non-merge pipelines here missing so many jobs? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33002 22:27glehmann: for example, everything anv
22:55valentine: glehmann: your branch is in the middle of the farm maintenance yesterday, rebase and they will show up