02:02 DemiMarie: karolherbst: nope, it isn’t purely cosmetic as users can turn off overcommit
02:03 DemiMarie: karolherbst: using caller-specified GPU VA is necessary for virtGPU native contexts anyway
02:05 DemiMarie: Is there a reason for not supporting Xe on platforms that support i915, even though Xe offers new features like VM_BIND and (hopefully someday) virtGPU native contexts? Qubes OS may use virtGPU native contexts in the future, and Spectrum OS almost certainly will.
03:37 HdkR: t/14
07:32 dj-death: gfxstrand: I'm trying to get EXT_attachment_feedback_loop working in Anv
07:32 dj-death: gfxstrand: and I think I'm at the point where some of the changes made to the runtime are not working for us
07:33 dj-death: gfxstrand: in particular "vulkan,anv,dozen: Use VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT"
07:33 dj-death: gfxstrand: the assumption is that feedback loop is equivalent to the old VK_IMAGE_LAYOUT_SUBPASS_SELF_DEPENDENCY_MESA
07:33 dj-death: gfxstrand: but that's break a bunch of cases for us, because we have to disable compression for VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT
07:34 dj-death: gfxstrand: so with the runtime change, it's disabling compression for a lot more cases than we need to
07:34 dj-death: gfxstrand: and also there is a disconnect between the layouts inserted by the runtime and what the app is using
07:35 dj-death: so we get inconsistent layout transitions from the runtime/app
09:26 karolherbst: DemiMarie: turning off overcommit breaks things, soo....
09:27 karolherbst: but anyway
09:27 karolherbst: it's still cosmetic as _nobody_ handles OOM correctly
09:28 karolherbst: it's almost impossible to do so correctly
09:28 karolherbst: it's not worth the effort unless your job is to run on embedded platforms with no RAM
09:30 javierm: DemiMarie: for Qubes OS wouldn't something like virtio-wayland be more suitable?
09:30 javierm: that is, just make whatever is composited in the VM a wayland client ?
09:31 karolherbst: DemiMarie: developers time?
09:31 karolherbst: also sometimes it's better to have clear cut inside drivers if hw design changes too much
09:31 karolherbst: and xe does look like such a point
09:37 qyliss: javierm: wayland clients still want GPU access sometimes
09:37 qyliss: native contexts are the most promising way to do that
09:51 MrCooper: DemiMarie: if you're talking, your messages aren't getting through to IRC
09:55 dottedmag: javierm: Qubes in X provides tighter integration than just "show a VM in a box": you can have windows from different VMs overlapping and stacked on top of each other
09:59 qyliss: dottedmag: that's what virtio-wayland is for
10:00 qyliss: (although virtio wayland is on the way out, in favour of wayland virtio-gpu contexts, which despite the name do not necessarily involve a GPU)
10:08 javierm: qyliss: yeah, is called virtio-gpu because the QEMU device backend is virtio-gpu even if you want to use it only for KMS :)
10:09 qyliss: I think we're still talking about slightly different things
10:09 qyliss: as with Wayland contexts there's no guest KMS involved
10:09 qyliss: (and QEMU so far doesn't support it, only crosvm)
10:11 javierm: qyliss: I know. I was referring to name of the (not yet existent) virtio-gpu wayland context and the fact that would be gpu in the name
10:12 javierm: because in that case the virtio-gpu device in the guest would be used as a transport to send the wayland data
10:14 javierm: instead of the /dev/wl0 or whatever is called the devnode that is used in the Android/ChromiumOS guest kernels
10:14 qyliss: wdym not yet existent?
10:14 qyliss: it does exist
10:15 qyliss: just not existent in QEMU?
10:15 javierm: qyliss: really? I didn't know that crosvm supported wayland over virtio-gpu contexts
10:15 qyliss: it has done for a long time
10:15 qyliss: I don't think it's the default on Chrome OS yet
10:17 javierm: interesting, so they will be able to drop that downstream chardev driver
10:17 qyliss: at some point, yeah
10:17 qyliss: it's also on its way into QEMU
10:18 qyliss: https://lore.kernel.org/qemu-devel/20230421011223.718-1-gurchetansingh@chromium.org/
10:19 DavidHeidelberg[m]: bumpin Alpine to 3.18 (llvm15 -> 16), did some stresstesting, any objections? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23359
10:20 javierm: qyliss: cool, thanks a lot for the reference
10:20 javierm: I know that there were plans to replace the downstream solution using virtio-gpu contexts but didn't know that were implemented yet
10:21 javierm: qyliss: and yeah, it would be great for qemu to have feature parity with crosvm w.r.t virtio-gpu {native,wayland} contexts
10:25 DavidHeidelberg[m]: There is follow big MR for rename (x86 and amd64 to x86_64, armhf to arm32, and i386 to x86_32 ) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23282 Please A-b, R-b (generally it gets tested as it builds, the Alpine MR is required for this change)
10:56 DavidHeidelberg[m]: MrCooper: ccache seems to have some effect, +- 8 min -> 3 min https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23362
12:27 dolphin: airlied, sima: no full CI results yet, but one fix appeared, shall I still send a PR or next week?
12:28 sima: dolphin, I guess if it's just a minor thing you can skip
12:30 dolphin: it's one with real impact to OA API, that's why I tried to get the CI results still
12:30 dolphin: maybe I send it and you'll check the results before pulling trigger?
12:30 dolphin: BAT looks good (or it looks as bad as previous, not worse) for it
13:44 karolherbst: dcbaker: sorry to be a pain with this, but you forgot to look into https://github.com/mesonbuild/meson/pull/11733 or would it be better if I ping somebody else with it?
14:29 dcbaker: karolherbst: … I’m sorry. I’m being the pain here. First thing when I get into work
14:29 dcbaker: Sorry
14:31 DemiMarie: karolherbst: libxml2, libcurl, systemd, ffmpeg, SQLite, wlroots, and BoringSSL *do* handle OOM correctly, and at least libxml2, wlroots, BoringSSL, and SQLite have testing to make sure they do.
14:35 DemiMarie: karolherbst: my understanding was that Xe supports all Xe-architecture GPUs, which is gen11+ IIUC. Feel free to correct me if I am wrong.
14:35 karolherbst: yeah, which is like way less than what i915 supports
14:35 DemiMarie: I know
14:35 karolherbst: ohh wait, the question was the other way around
14:35 karolherbst: supporting xe inside i915
14:36 DemiMarie: No
14:36 DemiMarie: At least that was not my intent
14:36 karolherbst: then I think it's hard to understand the question
14:36 DemiMarie: My intent was to ask why Xe will not replace i915 on the architectures both support.
14:36 karolherbst: ahh
14:36 karolherbst: well.. amdgpu has the same situation
14:37 karolherbst: it's usually done when there is some transition happening
14:37 karolherbst: but there will be only one default driver for a speciic set of hardware
14:37 DemiMarie: Why not make Xe the default on newer kernels?
14:38 DemiMarie: It is (presumably) much less code and so less attack surface.
14:39 karolherbst: that might or might not happen
14:41 karolherbst: DemiMarie: I am sure it's all broken
14:41 karolherbst: it might work in some best case OOM situation
14:41 karolherbst: but it won't work in all OOM situations
14:42 karolherbst: unless you seriously know what you are doing
14:42 karolherbst: sure.. some projects might know that, but that's just a handful of things and even then you get cases it just won't work reliable
14:43 karolherbst: but for libs it's easier, just return an error and don't log anything, job done
14:43 karolherbst: and then the application ooms/crashes, because it logs the oom error
14:43 DemiMarie: karolherbst: my PoV is that crashing on OOM is not a library’s decision to make.
14:44 karolherbst: yeah and we try our best to return the error
14:44 DemiMarie: Especially for a lib like Mesa that one cannot avoid using.
14:44 karolherbst: it's still all cosmetic
14:44 karolherbst: and just "because we have to do it"
14:44 DemiMarie: On desktop, probably. On embedded, no.
14:45 karolherbst: I'm not saying we shouldn't do it, just that it's all best effort and not really worth the effort doing more than just return the error
14:50 pq: DemiMarie, you mean they handle malloc returning NULL correctly? I suppose one could also fail to find a page to back a growing stack.
14:52 pq: handling already established mmaps hitting OOM is a whole another... *cough*
14:53 karolherbst: pq: well that's not a problem if you disable overcommit, no?
14:53 karolherbst: but yeah...
14:53 daniels: libwayland-server and libwayland-client don't handle OOM, because we don't expect that every single Wayland call will be bracketed with a check for OOM and safe recovery if you are OOM
14:53 karolherbst: I'm not convinced any project handles OOM correctly
14:53 pq: is it? oh yeah, then brk() returns NULL and glibc... does what?
14:54 daniels: (bearing in mind that safe recovery is basically impossible, because you're not going to be able to call anything useful to help you recover. want to save your file you were working on? good luck.)
14:54 karolherbst: it crashes?
14:54 karolherbst: might return an error and sets errno?
14:55 pq: karolherbst, I mean doesn't glibc call brk() to extend stack? wait, how does that work...
14:55 karolherbst: I'm sure the error just gets passed to the caller
14:55 pq: what caller?
14:55 karolherbst: of glibc
14:56 DemiMarie: daniels: do you mean that both abort?
14:56 pq: but I was just calling my own functions and suddenly they need more stack space
14:56 karolherbst: mhh
14:56 karolherbst: guess you crash then
14:57 karolherbst: just disable all stack memory
14:57 pq: or was there a default size for stack instead of growing it on-the-spot...
14:57 karolherbst: you still need one on function calls if the function needs stack mem, no?
14:57 karolherbst: but maybe you have a page of stack by default
14:57 karolherbst: or something
14:57 karolherbst: there was something for that
14:57 pq: every function call more or less needs stack, you need the return address somewhere :-)
14:58 karolherbst: right.. but you can reuse the same allocation until you need to grow
14:58 karolherbst: the default is.. 256 bytes?
14:58 pq: right, so how does the growing part work?
14:58 karolherbst: or something?
14:58 daniels: emiyes, both abort
14:58 karolherbst: pq: yeah.. so the compiler inserts stuff to increase it ... :)
15:00 karolherbst: but if you really care you can also just incrase it to something you are sure you won't need more
15:00 pq: maybe... or maybe there is just a huge mmap that the kernel populates on demand?
15:00 karolherbst: well.. how would the kernel know you need more stack mem
15:00 pq: page fault
15:00 karolherbst: mhhh
15:00 pq: the same way all backing pages come into play
15:00 karolherbst: right...
15:01 pq: maybe disabling overcommit means that all stack area is populated by real memory from the start?
15:01 karolherbst: yeah, should be
15:01 karolherbst: but on an incrase you still need to allocate more memory
15:01 pq: sounds like a big waste :-D
15:01 karolherbst: it's just 4k
15:02 karolherbst: "some" kernel drivers need more for a single function :P
15:02 karolherbst: but you can disable automatic stack incrase and handle it all manually
15:03 karolherbst: but then figuring out when to incrase it is just pure pain
15:03 karolherbst: and then it crashes if you run out of it
15:03 karolherbst: so you just don't use stack memory
15:04 pq: so... if you mmap e.g. 16 MB initially for the stack, populate only the first page, isn't that overcommit? or is that "mmap" completely implicit, so it doesn't count for overcommit but the kernel still populates more pages as needed?
15:04 karolherbst: and malloc _everything_
15:04 pq: I'm talking about userspace stack, not kernel stack, btw.
15:04 pq: they're different I believe
15:04 karolherbst: if you don't use it, it's not allocated by default, yes
15:05 pq: userspace can easily eat mega and gigabytes of stack
15:05 karolherbst: yeah
15:05 karolherbst: but the point is.. systems who care, disable overcommit and handle it manually
15:05 karolherbst: and then to stay sane they also can't use the stack, because... of those issues
15:05 emersion: pq, it seems like there's MAP_GROWSDOWN, and the kernel automatically allocates
15:06 pq: emersion, thanks! That sounds like the logical choice.
15:07 pq: so code eats stack om nom nom, page fault, kernel fails to find a free page for more stack, what do you do? SIGSEGV.
15:07 karolherbst: correct
15:07 karolherbst: could install a signal handler :)
15:07 karolherbst: and do the wrong thing
15:08 karolherbst: could try to free some caches and hope for the best
15:08 pq: yes, with a preallocated alternate stack, and...
15:08 karolherbst: yeah....
15:08 pq: but you can't return from SEGV handler to re-try, can you?
15:08 karolherbst: fun thing.. how would libraries report their stack use?
15:09 karolherbst: uhm...
15:09 karolherbst: I think you can
15:09 karolherbst: only SIGKILL is fatal
15:09 karolherbst: though you'd SIGSEGV again if you didn't fix it
15:09 emersion: pq, you can
15:10 pq: I'm shocked - and it actually re-tries the faulting instruction?
15:10 karolherbst: sure
15:10 karolherbst: and then you end up in a signal handler loop :)
15:10 emersion: i've only ever used it with longjmp in the handler
15:10 emersion: to implement a safe{} block for C of course
15:10 emersion: which is the contrary of Rust's unsafe{} ;)
15:11 karolherbst: sounds cursed
15:11 emersion: that's the whole point :P
15:11 hwentlan_: emersion, melissawen, I don't know if you've had time to look at the color pipeline KMS uAPI... I've been working on a patchset for it, but will probably still take a couple weeks or so before I can post a first iteration (using VKMS) for RFC
15:11 pq: siglongjmp doesn't work, you don't know where to jump to, if a random piece of code in a random lib exceeds your stack allocation? or can you fecth the faulting code address, and...
15:12 karolherbst: welll...
15:12 karolherbst: you can parse the stack....
15:12 karolherbst: (if you have proper stack pointers)
15:13 pq: hwentlan_, btw. did you get that IRC discussion I pinged you on err... some weeks ago but after the hackfest?
15:13 emersion: there are also libcs which use a fixed stack size, like musl
15:13 karolherbst: anyway.. my point was: nobody gets it all correct
15:14 emersion: hwentlan_: oh, so you're going to implement each color block in VKMS?
15:14 pq: hwentlan_, about the new generic KMS color pipeline design
15:14 hwentlan_: pq, I don't remember. Got a link by any chance?
15:14 pq: lemme see... did emersion bookmark it while on holidays?
15:15 hwentlan_: emersion, not each color block necessarily but it's a good vehicle to iterate quickly on a qemu VM while working on new KMS API
15:15 pq: hwentlan_, https://oftc.irclog.whitequark.org/dri-devel/2023-05-17
15:15 emersion: i read the discussion but don't remember anything about it now
15:16 hwentlan_: but might implement one or two useful blocks in VKMS if they're easy to implement... like an sRGB EOTF and inv_EOTF, and maybe a matrix... could even do a custom 1D LUT...
15:16 hwentlan_: reading
15:16 pq: I don't remember the contents either, but I remember thinking you wanted to see it. :-)
15:17 pq: *you should see it
15:17 pq: maybe it's nothing new now
15:19 pq: hwentlan_, if you do a custom 1D LUT in VKMS with selectable tap distribution, you could implement any enumerated TF with const tables.
15:19 pq: as an implementation detail of enumerated TFs
15:20 pq: and implementing inverse would be as easy as swapping the tap distribution array with the LUT value array
15:21 pq: till tomorrow .o/
16:03 gfxstrand: dj-death: See also the discussion with cwabbott I've been having the last couple weeks. I think turnip wants something split too.
16:03 gfxstrand: dj-death: That said, I fear not disabling compression for subpass self-dependencies is also broken, we're just not seeing it in CTS tests. We definitely disable it in those cases on iris and i965.
16:06 dj-death: gfxstrand: thanks
16:07 dj-death: gfxstrand: seems to match the testing I did with not disabling compression and having all the feedback loop tests pass :/
16:08 dj-death: gfxstrand: then what's left is the missing transition I guess
16:08 dj-death: I'm not sure how we can deal with this
16:09 dj-death: would need to look at all the barriers, and check if we're in a render pass, then put the source layout back to what the runtime picked
16:16 zmike: sounds like more cts coverage is needed
16:18 gfxstrand: dj-death: IDK what you mean.
16:18 gfxstrand: You should be able to disable compression just based on the layout. The FEEDBACK_LOOP layout disables compression. The only bits you need to flip on and off per-pipeline is the bits about early depth tests.
16:19 dj-death: gfxstrand: there is some kind of explanation in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23372
16:20 dj-death: wrong change apparently
16:20 dj-death: but it shows the inconsistent layout transitions
16:22 gfxstrand: dj-death: Oh, well that's a bug...
16:22 gfxstrand: I'm surprised we haven't seen that before
16:22 gfxstrand: I doubt your patch fixes it, though.
16:22 dj-death: it leaves the initial app layout
16:23 gfxstrand: Which is to say that we could see that with any combination of an initial/final layout that don't match subpass layout
16:23 dj-death: so they're consistent at least in the tests
16:23 dj-death: I think in this case the app is doing a barrier in the render pass
16:24 dj-death: maybe we mark image compressed incorrectly
16:24 gfxstrand: They can't do a layout transition mid-render-pass
16:25 gfxstrand: Oh, but they are doing a barrier to let them do back-to-back subpass draws.
16:25 gfxstrand: And that one they're passing GENERAL->GENERAL.
16:25 dj-death: yeah
16:26 gfxstrand: Yeah, short of intercepting vkCmdBarrier(), there's no way we can fix that in the runtime.
16:26 dj-death: yeah
16:26 gfxstrand: As long as the driver ignores the layout portion of any barrier with identical initial and final layouts, it should be okay.
16:26 dj-death: I guess I'll get on that tomorrow :)
16:27 dj-death: it has to be in the runtime I think
16:27 dj-death: the driver can guess what the runtime did, but if that changes :|
16:27 gfxstrand: We should at the very least document that corner.
16:28 gfxstrand: Yeah, that's the limitation of the runtime being a toolbox and not actually hooking everything.
16:28 gfxstrand: Some days, I question that choice.
16:29 gfxstrand: We may eventually want to move to a more gallium-like thing where everything goes into the runtime and the runtime calls into drivers instead of the other way around.
16:29 gfxstrand: Vulkan isn't as thin as it once was.
16:42 karolherbst: a new gallium? funky
16:43 karolherbst: well.. it would help implementing CL in a more modern environment
16:43 karolherbst: given it has a command buffer extension...
16:43 karolherbst: so something like gallium, just more lower level + explicit command buffer control _might_ be something which _might_ work out
16:44 karolherbst: but maybe layering it on top of vulkan is possible, but I'm reluctant using zink, because the gallium API is a nightmare for it long term
16:52 gfxstrand: I don't think it would be the pluggable mess that gallium is.
16:52 gfxstrand: Like, it wouldn't be trying to abstract across state trackers.
16:52 gfxstrand: Just make the layering more clear.
17:01 karolherbst: yeah.... probably. I mean, we have way more experience with that stuff now anyway :)
17:27 deathmist1: hey, trying to bisect AMD RX6600 OGL graphical artifacting where 23.1.x is bad and 23.0.x is good, but 23.0-branchpoint also is bad; what should I try now?
17:29 psykose: does 23.1 branch from somewhere in 23.x.y? it's possible for a fix to have been picked to 23.0.x but not 23.1 (had that happen before)
17:30 psykose: so 23.0-branch would be bad but 23.0.something wouldn't be, and 23.1 would also be bad
17:30 deathmist1: I tested 23.0.0 as good fwiw
17:30 psykose: hm, not sure then
17:31 eric_engestrom: deathmist1: if you can bisect on the commits in `main` that's probably going to work better :)
17:32 kisak: You can do a reverse bisect for what fixed the issue between 23.0-branchpoint and 23.0.0. in a reverse bisect, you're trying to find the commit that fixed the issue, good = bad and bad = good in the git commands
17:33 kisak: after that, you can cherry pick the commit you find until you're testing newer than that commit in git main.
17:36 eric_engestrom: deathmist1: kisak's idea is also good, and less work than what I suggested :P
17:36 eric_engestrom: deathmist1: when you find the commit that fixes the issue for you in the 23.0.x branch, ping me so that I can make sure 23.1.x include the fix as well
17:36 kisak: otherwise, you could finish the reverse bisect, then follow the (cherry picked from commit...) to try to be the known good reference point.
17:39 kisak: watch it be ... https://cgit.freedesktop.org/mesa/mesa/commit/?h=23.0&id=796af8e799a4417e7e3854918b1c9c82bdc79a3e
17:50 deathmist1: kisak: you might be onto something, I see that was in 23.0.0-rc5 and tried 23.0.0-rc1 -> same artifacting I see on 23.1.x, gonna test adding that on top of rc1 now before going further
17:51 Newbyte: deathmist1: what if you just manually enable/disable glthread?
17:51 Newbyte: like, without rebuilding. that's possible right?
17:55 eric_engestrom: yeah, if I'm not mistaken deathmist1 you can disable it by running `mesa_glthread=false your_app`
17:56 eric_engestrom: go to any known-bad version and run that to see if it fixes it
17:56 deathmist1: well I rebuilt anyway and yep looks like that was it, going back to 23.1.1 and trying that as well
17:59 psykose: wonder why i don't see any issues with the same gpu and versions
18:00 kisak: At least that tells you it's not really a regression. glthread got enabled by default on radeonsi, but there was too much feedback that came in that it made sense to push that back another 3 months to nail down the rough edges. The issue was there in the older mesa versions, but it was hidden away.
18:01 Newbyte: psykose: well, are you testing teh same thing as deathmist?
18:02 kisak: The right answer here is to file a bug report so that the radeonsi devs have something to ponder, and disable glthread of that one game until there's a fix to test.
18:07 psykose: Newbyte: good point, i keep forgetting i run the compositor in vulkan which isn't the same
18:14 CounterPillow: Is there a corresponding get call hidden in one of the function(s) called before that makes this put necessary? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c#n50
18:16 CounterPillow: I don't see one in drm_crtc_send_vblank_event so this code seems at least wrong in so far as it doesn't balance the put in all cases, unless I'm grossly misunderstanding the code here
18:21 CounterPillow: Ok apparently the corresponding gets are in a different file somewhere
18:50 deathmist1: kisak: thanks for the pointer to the culprit :) I've filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/9141 (RadeonSI: glthread causes various graphical glitching)
18:51 deathmist1: eric_engestrom: fwiw "mesa_glthread=false epiphany" in my case didn't seem to make a difference with the busted mesa
18:51 deathmist1: it did print the ATTENTION override messages at least but was ineffective in the end
18:55 jenatali: anholt: FYI that first patch doesn't compile
19:04 anholt: fixed
19:05 airlied: robclark, Kayden : could you quick ack the patches in 23291?
19:07 anholt: did you audit every driver for needing to report 0 for these?
19:07 airlied: anholt: yup that's why there's patches in it
19:07 anholt: I guess since you have svga in there then it's not just driven by CI fails
19:08 anholt: ack for fd/crocus/iris
19:09 jenatali: anholt: Looks like I'm seeing a draw with just a VS/FS where the VS outputs all 0s for position
19:09 jenatali: Seems like this is supposed to be doing a read from a buffer in the FS but since it's not, it's leaving wrong data in the output
19:09 jenatali: I can keep debugging, just figured I'd throw that out in case it rings a bell
19:09 anholt: the GS isn't bound?
19:09 jenatali: Not at the D3D level according to PIX
19:10 anholt: well, that's certainly information!
19:10 jenatali: Lemme see if I can find a more scoped down test for easier debugging, this one loops so much it'd be had to break on the right spot...
19:18 anholt: oh, it's not going to be in the GS, because we have failures on non-layered targets. so it's actually the st->pbo.layers being set that's getting us.
19:22 jenatali: Oh, I see what's going on
19:22 jenatali: The VS is overwriting position with 0s
19:23 jenatali: That nir_store_var with a writemask of (1 << 2) seems to be not behaving appropriately
19:24 jenatali: Our compiler backend assumes that I/O has been lowered to temps, i.e. each output is only written by one store, where the data is accumulated into a temp first
19:25 jenatali: For CL/VK we run the appropriate passes, but for GL we just rely on mesa/st doing that for us, but this PBO VS doesn't have all the same lowering done on it that app shaders do
19:25 jenatali: Of course we could also just implement PIPE_CAP_VS_LAYER_VIEWPORT...
19:26 anholt: and with that hint, I see the error in v3d as well :)
19:27 jenatali: Yeah, it's already implemented in the compiler, just a one-liner to add the pipe cap fixes the test for me :P
19:42 anholt: I'm going to just make that VS less surprising for backends.
19:43 jenatali: Yeah, good idea. I'm push that cap anyway, 'cause why not
19:43 jenatali: pushing*
21:34 Kayden: airlied: iris/crocus patches gets my ack as well
21:34 Kayden: airlied: you're adding task/mesh in gallium...?
21:35 airlied: Kayden: just enough bits to bridge lavapipe/llvmpipe
21:35 jenatali: For lavapipe
21:35 DavidHeidelberg[m]: I plan to merge tomorrow (since risk of breaking due to rebases, please if you see some serious issue, speak about renaming now): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23282
21:35 airlied: someday I'll have to consider removing that bridge I suspect
21:35 airlied: just feels like a daunting challenge
21:36 Kayden: ahh
21:36 airlied: though there is a GL ext if someone wanted to waste their life :-P
21:37 airlied: https://registry.khronos.org/OpenGL/extensions/NV/NV_mesh_shader.txt
21:37 airlied: zmike: snipe
21:37 zmike: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7192
21:38 jenatali: I misread and that was a merge request for a second
21:38 jenatali: Man I can't type today... I thought that was a merge request
21:39 zmike: call me nvidia cuz I knew what you meant to do even if you gave me garbage input
21:39 kisak: That's how driver development works, right? Snap your fingers and zmike-GPT generates a merge request.
21:39 psykose: i feel like i've read this entire conversation before word for word
21:39 zmike: 😬
23:45 DavidHeidelberg[m]: anholt: do you want to squeeze Fixes tag into https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23379 before Marge picks it up?