02:48 tarceri: MrCooper: thanks. I think I'll put any further fix attempts on hold until rob merges his series, I think we will want the bigendian users testing his series before it lands to avoid regressing further and we can try put the final pieces together after
03:13 robclark: tarceri: gee, thanks for introducing my MR to b/e quagmire ;-)
03:15 robclark: that said, I think my MR removes any of the "endian aliased" pipe formats other than __DRI_IMAGE_FOURCC_SARGB8888 (and idk what b/e cases that might effect) so I guess at least closer to not sucking
03:19 tarceri: lol
03:35 tarceri: robclark: I'll review what I can to keep things moving along ;)
03:35 tarceri: it shouldn't hold up your series as long a it doesn't completely break the driver loading again
03:41 robclark: tarceri: I had been trying to preserve current breakage carefully... but pls have a look at my rebase to double check my work
03:41 robclark: (the format things are headache inducing ;-))
03:44 tarceri: I have a feeling the color may flip like they did with the mr I closed (unless you mr fixes something else) but that can probably be dealt with later. It seem like dri and pipe don't always act the same way where they are used but we might just need to fix the use locations rather than the definitions
03:45 robclark: maybe there are other hidden bugs... but IMO we should just have drm and pipe formats
03:46 tarceri: and yeah its confusing stuff but by the time its all cleaned u it will be much better than the way it was a few year ago with magic numbers mapped together everywhere. It not surprising it all fell apart
03:46 robclark: if we map drm to pipe faithfully then rest is for things with b/e hw to find the bugs
03:47 robclark: (and by things I mean ppl.. sry ofc)
03:49 tarceri: haha, I'm one of those thin... err people now.
03:50 tarceri: I think there are openpowerpc things it the works too so I'm sure this would all come back one day even if all the old hardware was to melt at once
03:52 robclark: some arm things are bi-endian too... but I think nv had the right idea when they convinced power to give in and go l/e.. it's just too big a windmill to tilt against
03:53 tarceri: yeah
03:56 tarceri: I discovered a powerpc linux facebook group with around 3000 members the other day should I direct them to your MR? :-P
03:56 robclark: pls don't :-)
03:57 tarceri: j/k
03:59 hazard_hitman: haha
04:03 robclark: direct them to piglit or whatever way we can reproducibly test their use-case in ci.. and then leave it up to the ci maintainers to balance ci resources vs benefit to community.. but if there aren't ci tests proving something is broken, then it isn't
04:05 airlied: not sure anyone wants to run a BE GPU CI machine :-)
04:05 airlied: keeping the s390 stuff in is enough of a fight
04:06 tarceri: is there r300 ci now?
04:09 robclark: if no one cares enough to keep lights on in Ci then no one cares enough if an MR breaks them
04:10 robclark: I mean CI isn't the end of the day for "working" but it is the bare minimum
04:10 airlied: I don't think you can ask someone to run CI for community stuff really, it's not sustainable
04:11 airlied: like we can barely get enough functional hardware in one place to sustain what we do have
04:11 airlied: I can't imagine anyone getting a G5 + gpu combo into a stable enough state to run on, it'll always be finding regressions and fixing it
04:12 airlied: or we declare we only care about s390 + llvmpipe and burn anything else down, and tell them to stick to old mesa
04:14 robclark: without CI we are just hoping changes don't break things... beyond that it is up to folks who care to step up
04:15 robclark: not trying to break things intentionally.. just saying it is hard to repro issures otherwise
04:17 tarceri: robclark: if they test your series and the worst thing that happens is the colours flip I'm happy for you to push those first 3 patches and I'll plug away at fixes eventually
04:19 tarceri: i added my rb
04:20 robclark: thx
04:21 robclark: at least everyone agrees on getting rid on dri formats :-P
07:12 MrCooper: zamundaaa[m]: e.g. when the commit became ready to program to HW, and when the deadline for that was
10:31 daniels: tarceri: which hw are you on ooi?
10:32 daniels: I have seen the MRs but this heatwave has been doing bad things to my brain; hopefully it settles down tomorrow and I can do things which aren't just completely mindless
10:36 tarceri: daniels: you've gone full native. Handling the heat like a true brit :-P
10:36 daniels: genuinely part of the reason I left!
10:36 daniels: but also ... everywhere in this place is designed to capture as much heat as possible and never let it escape. which works well most of the year tbf
10:38 tarceri: I could use a bit of that right now
10:40 tarceri: I got an old G5 with an r300 although most fixes have been for r600 thus far
11:29 pinchartl: vsyrjala: it would be nice if you could CC the cover letter to everybody when you send a series. I always have to look it up
14:48 daniels: tarceri: you'll be glad to hear my British internet has also decided it's too hot to work
15:29 zmike: jenatali: I see in mediafoundation you're using set_fence_timeline_wait, but it's not obvious to me where that frontend is calling sync/signal
15:31 jenatali: Looking
15:34 jenatali: zmike: I'm not finding that function name - what's the function you're talking about?
15:34 zmike: it's a pipe_screen method
15:34 jenatali: Just trying to find the context of where in the stack the problem is
15:34 jenatali: Ah, value, not wait
15:36 jenatali: zmike: The fence is passed as a pointer into a bunch of video methods which implicitly signal/wait on it
15:36 zmike: can you elaborate on that?
15:37 zmike: I'm fixing the timeline semaphore implementation because it's broken, and it's not clear how to fix things here
15:37 jenatali: What's broken? :)
15:37 zmike: by spec, you can set the timeline value, wait, set the timeline value again, signal
15:37 zmike: and this is fine
15:37 zmike: but the current implementation has the value as a separate screen method without any synchronization
15:38 zmike: so you will flush on the signal and use the second value for both the wait and signal
15:38 jenatali: The wait should also flush?
15:38 zmike: that isn't a requirement
15:38 zmike: the value should have been passed to the sync/signal methods
15:38 zmike: and not be a separate method
15:38 zmike: so I'm fixing that
15:39 jenatali: Sure. IIRC I had talked about doing that but it was a ton of churn for a low-value thing
15:39 zmike: yes I'm not a fan of the churn
15:39 zmike: but the current implementation is broken
15:39 zmike: so
15:40 zmike: another day, another full-tree refactor
15:40 jenatali: So I see a pipe_fence_handle in pipe_vpp_desc, as well as pipe_picture_desc
15:41 jenatali: But if you're going to put values to go along with fence handles, then you also need them in every place where a fence is created, don't you?
15:41 zmike: how about I'll put up the MR and you can tell me what to fix
15:41 jenatali: Sure, I'll take a look at it
16:00 robclark: karolherbst: shouldn't rusticl be returning an error if app ignores pipe_compute_state_object_info::max_threads ?
16:02 karolherbst: probably?
16:02 karolherbst: if you check clEnqueueNDRangeKernel there are many error codes I haven't bothered to implement yet
16:02 karolherbst: mhhh
16:03 karolherbst: robclark: it seems like I have added a check for it?
16:03 karolherbst: "if threads != 0 && threads > k.max_threads_per_block(q.device) {" that one, no?
16:04 robclark: that is the device limit, not the kernel limit, I guess?
16:04 karolherbst: nah, that's the kernel limit
16:04 karolherbst: what are the concrete values you are seeing there?
16:06 robclark: not sure there, I'm still debugging.. but what we return in pipe_compute_state_object_info is half of what we feed to the hw
16:08 karolherbst: mhh
16:09 karolherbst: robclark: you do support sharable shaders, right?
16:09 robclark: oh, I see the problem btw... 0 *= 1billion == 0
16:10 robclark: and yes
16:10 karolherbst: ohh shoo
16:10 karolherbst: "threads = 1"?
16:10 robclark: :-P
16:10 robclark: yup
16:10 karolherbst: *Sigh*
16:10 robclark: I'll send an MR in a few
16:11 karolherbst: why isn't rustc or clippy warning me about that :D
16:11 karolherbst: but yeah.. the CL CTS lacks a lot of negative tests checking those errors...
16:11 karolherbst: they get added over time so that's great...
16:13 robclark: yup, that fixed it
16:14 karolherbst: nice..
16:14 karolherbst: I was sure to have debugged this code at some point...
16:15 karolherbst: robclark: eca4f0f632b1 broke it 🙃
16:15 karolherbst: or well..
16:15 karolherbst: was the commit I added that check
16:16 robclark: ahh, thx, saves me finding the fixes tag :-)
16:17 robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35864
16:18 karolherbst: oops.. replied with the wrong account at first 🙃
16:21 karolherbst: oh that reminds me, I should use the approve button, because marge handles that now, no?
16:23 robclark: hmm, the approve button became actually useful?
16:25 karolherbst: yeah... I think there was something...
16:25 karolherbst: but I forgot the details
16:37 jenatali: Yeah I think Marge adds the reviewed-by tags to the commits for approvers
16:39 robclark: oh, nice
16:39 pendingchaos: I think that was removed: https://gitlab.freedesktop.org/freedesktop/fdo-bots/-/commit/13e5b40c65e599f166f6df6ff1334cc870c4a466
16:50 zmike: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35866
16:51 jenatali: Looking
16:58 zmike: I left the original call intact so you can see
16:59 jenatali: zmike: So the problem is, all pipe_fence_handles for us are timeline semaphores under the covers. So far they've just had an implicit value associated with them
17:00 zmike: hm
17:00 zmike: I'm not sure how that affects this
17:01 jenatali: So passing a value just for the server sync/signal is kinda broken
17:01 jenatali: Since then you've basically got 2 values - one that's embedded in the pipe_fence_handle as a single point in time, and another one that treats the pipe_fence_handle has a full timeline
17:01 zmike: oh, you mean you're setting a timeline value on a regular fence?
17:02 jenatali: I guess what I'm trying to say is, it seems like the right way to go about this is to make it so that you create a fence with a new driver object that represents a timeline semaphore, and then a timeline value
17:02 jenatali: If you want the fence to be immutable / not have the sync issues you were talking about
17:02 zmike: yes that's how it currently works with this MR
17:02 jenatali: Having a fence both represent a point in time and a timeline is broken
17:02 zmike: I think you were misusing the api before
17:03 zmike: the fence create api does have that enum so that the driver is aware it is creating a timeline semaphore
17:04 zmike: but because mesa uses threads internally, you definitely cannot use a screen method to modify a context object
17:04 jenatali: So maybe the solution is to just move the setter to a context?
17:04 zmike: that doesn't make any sense though
17:05 zmike: timeline values are only valid for timeline semaphores
17:05 daniels: robclark: sooooo yeah, we are missing some tests for sure - that’s part of the reason I’m so hesitant to introduce something which will likely change behaviour without making it more structurally sound
17:05 daniels: I mean that entire path is a nightmare
17:05 zmike: and you can't wait on those the same way you wait on normal fences
17:05 daniels: but we’re a) doing a bunch of piglit for it and b) also doing YUV target, so hopefully that will all change
17:06 jenatali: It really seems like a timeline semaphore should be a different kind of driver object entirely then
17:06 zmike: functionally it is since there is an enum for creating it
17:06 zmike: if you haven't been adhering to that divide then that's a you problem
17:06 daniels: so lemme merge the useful cleanups first, have a bash at getting the mapping persisted, and then we can see what else shakes out?
17:06 jenatali: Hm I see what you're saying
17:07 robclark: ok.. but I really do need to add some fourcc's to the table sometime before EXT_YUV_target ;-)
17:07 daniels: robclark: for sure
17:07 robclark: and do kinda think that whatever we do can't suck much more than what's already there ;-)
17:09 daniels: yes except some idiot has to fix it :P
17:09 jenatali: zmike: Ack, I'm following now. Just to confirm, you can't do client waits on timeline semaphores, right? Only server wait/signal?
17:09 daniels: let’s see where I get to before I lose the will to live (again)
17:09 zmike: jenatali: yes
17:09 zmike: it must go through the interop/externalobjects api
17:09 zmike: (in GL terms)
17:10 jenatali: Ok so then I just need to update our driver to store the fence type (if we're not already) and use the internal value for wait/signal unless it's a timeline semaphore, then use the external value
17:10 zmike: sounds right
17:10 zmike: also mediafoundation needs to be updated somehow
17:10 jenatali: And then the places where there's a pipe_fence_handle in the video args should be updated to also take a value, since there's implied server syncs associated there
17:10 zmike: feel free to push directly to the MR
17:11 jenatali: Thanks, I think I can get to this later todya
17:11 zmike: cool
17:11 jenatali: I thought this conversation felt familiar: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17446#note_1463044 :P
17:11 robclark: daniels: I think I'm still leaning towards "removing dri_format probably at least fixes more things than it breaks" ;-)
17:12 robclark: (yeah, I missed the fourcc attrib usage in gbm and egl)
17:13 jenatali: zmike: Can you elaborate on "functionally this is the same as other types of timeline semaphores, but it is not actually the same as other types of timeline semaphores" ?
17:13 zmike: jenatali: the mechanics are not the same
17:14 jenatali: Oh it's just which extension it came through?
17:14 zmike: like in vulkan terms a vk timeline semaphore is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_OPAQUE_FD_BIT and a d3d12 semaphore is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_D3D12_FENCE_BIT
17:14 zmike: but a vk timeline semaphore can be used on windows, so a build-time define is not sufficient
17:15 jenatali: Ok, not a big deal, just didn't quite understand
17:15 zmike: it's a very minor and stupid detail but still I had to do a full-tree rename
17:21 daniels: robclark: if any of this could be reasoned about in any consistent way I'd be with you on that
17:24 robclark: I mean, we're going to have to deal with the fallout of dedup _eventually_
17:58 jenatali: zmike: Just to make sure I'm remembering: there's no way for GL to create a timeline semaphore, only import, right?
17:58 zmike: jenatali: not sure what you mean? it's only available in functions taking pipe_fd_type
17:59 jenatali: Right, which also take external handles for importing
17:59 zmike: create_fence_fd, for example
18:48 austriancoder: glehmann: I am looking into your comment https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34755#note_2890168 and I am not 100% sure what I should return from the callback for non fdot's. as I am on a vec4 architecture maybe 4?
18:55 glehmann: if 4 is the maximum width that you can support, then yes (or maybe for e.g. iadd 4 if 32bit and 8 if 16bit, depends on your kind of vec4)
18:55 glehmann: You can return 0 if you just want to leave an instruction as is, but that opens the question: if you don't want to lower fdot and you don't want to lower the width of other alu, why are you calling the pass?
19:02 austriancoder: glehmann: nir_lower_alu_width(..) lowers nir_op_pack/nir_op_unpack ALU Instructions - thats why I am using it in the first place
19:03 glehmann: if you are just interested in that, then you can return 1 for those and 0 for everything else
19:04 austriancoder: glehmann: I will give it a try
19:06 glehmann: btw, is it inappropriate to say I pity you for having to work with vec4 in 2025?
19:06 glehmann: :D
19:14 alyssa: glehmann: my first shader compiler targeted vec16 hardware, if you were wondering how I got this way.
19:14 alyssa: (i8vec16, I mean)
19:14 alyssa: (it.. supported vec16 swizzles...)
20:09 robclark: so mali is to blame for cl having vec16?
20:14 karolherbst: heh...
20:14 karolherbst: did mali even exist when CL was created? :P
20:15 robclark: I think mali-400 existed?
20:16 karolherbst: mhhh
20:17 karolherbst: seems to check out