00:21 zf: bnieuwenhuizen, sorry to bother, but I cannot for the life of me find the flag you mentioned for querying planar YUV RTV support?
00:39 bnieuwenhuizen: zf: You got VK_IMAGE_CREATE_EXTENDED_USAGE_BIT_KHR?
00:39 bnieuwenhuizen: "For images created with VK_IMAGE_CREATE_EXTENDED_USAGE_BIT a usage bit is valid if it is supported for at least one of the formats a VkImageView created from the image can have (see Image Views for more detail)."
00:44 bnieuwenhuizen: so if you enable that flag you should be able to set the color attachment usage bit on image creation (and that should be allowed by vkGetPhysicalDeviceImageFormatProperties if you set the flag there too)
00:45 bnieuwenhuizen: and then for the image view you can just query support through vkGetPhysicalDeviceFormatProperties of the plane format
01:24 DavidHeidelberg: eric_engestrom: we could save one build at pre-merge I think. We do debian-release, but I just turned on Debian tests on nightly repository, so maybe we could skip that one, as it's covered by nightly builds against latest Debian
01:27 DavidHeidelberg: Unpaid advertisement: If you're running Debian unstable/testing (Trixie), don't forget we have nightly builds available. You can test and experience both the advantages and challenges of nightly Mesa builds!
01:29 DavidHeidelberg: When something goes wrong, you can also do "binary bisect", as we keep previous builds :)
02:12 soreau: daniels: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725
02:13 soreau: This seems to fix the problem (#12309) and works well for modifier-less but not sure about everywhere else
02:14 soreau: it doesn't seem like I can add labels to the MR but I will cc you there as well
03:54 Lynne: wow, managed to freeze glslang
06:47 daniels: soreau: that commit needs far more description - it fails a BO creation request if modifiers are specified that do include linear, and allows it to succeed only if the user explicitly specified that linear is not ok?
09:28 glehmann: airlied: given that this is red hat related, do you know someone who can review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31656 ?
09:29 MrCooper: karolherbst: FYI, rusticl with zink on RADV fails piglit program@execute@amdgcn.sign_extend_inreg (passes with radeonsi), looks like it either doesn't sign-extend or cuts off the most significant 32 bits
09:33 glehmann: MrCooper: does it work with RADV_DEBUG=llvm?
09:34 MrCooper: yes, it does
09:36 MrCooper: also fails with radeonsi and AMD_DEBUG=useaco
09:36 MrCooper: the plot thickens for ACO
09:41 glehmann: I never used rusticl before, but if you can narrow it down to the specific sub test and open a mesa issue with the outputs of `RADV_DEBUG=shaders,llvm` and `RADV_DEBUG=shaders` maybe I can figure it out
09:56 glehmann: MrCooper: I think I found the bug by porting the kernels to glsl
09:56 glehmann: aco's 64bit extract_i8 is broken
09:56 MrCooper: cool, thanks, sorry was already looking into something else :)
10:14 Lynne: is there a way to ask the driver to automatically cache the generated binary via the vulkan API?
10:37 glehmann: MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31734
10:39 glehmann: Lynne: afaik all the desktop drivers have an automatic cache, but applications can't control whether it's used
10:39 MrCooper: thanks
10:49 Company: I've wondered if I should use the custom VkPipelineCache I'm keeping around
10:49 Company: if drivers have their own cache anyway that's probably working way better than mine anyway
10:50 Company: plus with 2 caches it's all duplicated work
10:52 glehmann: unless you ship on mobile, or you know that you need your own cache for some reason, I would just rely on the driver to do it
10:52 glehmann: dxvk deleted its own VkPipelineCache code years ago for the same reason
10:56 notmeatforyou: So you realized probably the combinations vs collisions theory by now, my invention was fine of course, but it actually is all designed so, due to powers of two's is genius way of representing info. However it's that i no longer have time to educate you. Education is just so fairly important to get abusers to change their attitude, i believe i chose the correct path. Me myself am not that educated in physics i knew that fft was not the thing we af
10:56 Lynne: glehmann: radv, anv and nvidia, none of the desktop vendors cache
10:57 Lynne: it takes 20 seconds to compile which isn't great
10:57 Lynne: compute-only, if it matters
10:58 glehmann: that sounds wrong? these are drivers that for sure have their own cache, and everyone relies on it
10:59 Company: I remember things got way faster when I added the pipeline cache
10:59 Company:git log when that was
10:59 Company: 06 2023
11:00 Company: so, dunno?
11:02 dj-death: sure you're not inserting some timestamp or something in your spirv?
11:02 dj-death: we had a customer doing that and complaining that compile time was slow
11:03 dj-death: but every single shader was different with only an unused constant changing
11:04 Company: how does that work with specilization constants btw?
11:04 dj-death: the current common pipeline code adds them to the hash
11:04 dj-death: so it's effectively different if you change the specilization constants
11:04 Company: so you cache after applying the constants
11:05 dj-death: yeah
11:05 dj-death: if I'm correct, all the mesa drivers do that I think
11:05 Company: it makes sense - and it means the cache might blow up if I create too many variations
11:06 dj-death: yeah
11:06 dj-death: this could be changed, but at least for us we would need some analysis
11:06 dj-death: because if the constant is used to size an array, it might be changed the final shader quite a bit
11:07 dj-death: s/be changed/be changing/
11:07 Company: I'm never quite sure if I want specialization constants or just pass vertex attributes
11:07 Company: is there a good rule of thumb?
11:07 dj-death: push constants is the best I think for us
11:08 dj-death: vertex attribute also works for 3D
11:08 dj-death: obviously not for compute :)
11:08 dj-death: or ray tracing or mesh/task shaders
11:08 emersion: daniels: i think this is buggy https://gitlab.freedesktop.org/mesa/mesa/-/commit/361f3622587e5bc452a62dbd671969b713273b79#72f2ccebfee5f52862cfdca8fd9199d25abb211f_1168_1173
11:09 emersion: querying modifiers will then return INVALID
11:09 emersion: also not sure why there is a special case for "count == 1 && modifiers[0] == DRM_FORMAT_MOD_INVALID"
11:10 emersion: IOW: this commit does more than just unify these two functions, it also changes behavior
11:12 Company: aren't there hacks somewhere that allow passing INVALID as a modifier in places where modifiers are mandatory?
11:12 Company: in the EGL APIs?
11:12 emersion: some APIs do, some APIs don't
11:12 emersion: but here it doesn't make sense to me
11:13 emersion: because INVALID doesn't mean "implicit", it's ignored
11:13 notmeatforyou: I have not really googled the name of binary format inventor, i knew george bool, but i am aware that british Americans were the ones who took the computers to next level predominantly, so they have such conferences where the brightest heads participate, wikipedia names it shannon's format. Hence there are no mistakes done in that science.
11:13 emersion: in other words
11:13 emersion: if a driver gets a list with INVALID somewhere, it will ignore it
11:14 emersion: doing some special casing in the frontends just makes everything harder to reason about
11:15 emersion: we should either plumb the INVALID semantics everywhere in the GBM stack, or leave it
11:16 glehmann: Company: if the constant disables an entire code path or controls loop iteration count, spec constants can be useful for performance. otherwise, use push constant / ubo. vertex attribute isn't uniform, so it's worse
11:18 Company: vertex attributes have the benefit that I can use a singe DrawArrays() call
11:18 Company: if I need to change buffers, that doesn't work
11:20 Company: that said, if I need to change pipelines due to spec constants, that doesn't work anyway
11:20 daniels: emersion: iswym
11:21 daniels: I don't like the list == {INVALID} check either, but istr I was carrying that over from existing frontend semantics, rather than creating new ones
11:21 emersion: i don't see that in the diff
11:22 emersion: these two special cases seem like new logic
11:22 daniels: as for the LINEAR one, you're right: I think if we get a list containing LINEAR _anywhere_ in the acceptable list, and we're working on a driver which doesn't support modifiers, we should force INVALID, rather than the special-case of a list which contains only linear
11:22 notmeatforyou: Now the rest of info is not anymore so say relevant , it's my anger in life that i try to shut down that i did not get proper devices on time to work with, motivation to push the methods to public domain was decided over i do not want others like me to suffer under the same effect.
11:22 emersion: daniels: no, we should fail
11:23 emersion: if we get a list of modifiers, we should never return a BO with INVALID
11:23 daniels: yeah, I agree that we should either not create a BO, or create a BO which returns LINEAR
11:23 daniels: I don't have a strong preference for which
11:23 daniels: provided we're not breaking existing users
11:23 emersion: if a list contains LINEAR anywhere and some other stuff, returning a LINEAR BO may be sub-optimal
11:23 daniels: and yeah, I'm not able to dig into it right now, but I'm _sure_ that the INVALID thing came from pre-existing frontend code which I carried over
11:24 daniels: right, LINEAR might be suboptimal compared to other modifiers, but note that it's conditional on the driver not implementing modifiers at all, so it's the choice between linear or nothing
11:24 notmeatforyou: the relevant bits are that computer engineers did not design systems to have to go to trashbin short after purchase where they could if someone is so uneducated, because after all history saw the best heads to work at it, so from this the results were also guaranteed to come out.
11:24 emersion: daniels: INVALID may mean something better than LINEAR
11:35 notmeatforyou: now the issue behind ddos is some tables need to be put to new paradigm, which i decided not to describe but i thought about it and it just would not even hurt if i did, cause the hash can be composed that if you do not accept the terms all output depends on each other in a rolled out fashion, if one bit goes wrong nothing is anymore working no service hence possible.
11:37 daniels: emersion: that's true - I don't mind preferring INVALID, but then like you say we would be returning INVALID for the query, which seems to be problematic for wlr?
11:37 daniels: (is this the cursors-are-broken bug?)
11:37 emersion: there are two bugs
11:37 notmeatforyou: it's somewhat private illness , to show that identity fraud/theft is wrong and hence not welcome, starts from abuse and goes worst every day, better to block it right from the start.
11:37 emersion: first one is that gbm_bo_create_with_modifiers({LINEAR}) returns a BO with gbm_bo_get_modifier() = INVALID
11:37 daniels: emersion: only two? :)
11:37 emersion: lol
11:37 daniels: (yes, the first is unequivocally a bug)
11:39 emersion: second bug is that gbm_bo_create_with_modifiers({INVALID,FOO}) has different behavior from, gbm_bo_create_with_modifiers({FOO})
11:40 emersion: but only if the driver doesn't support modifiers
11:40 emersion: if the driver supports modifiers, and FOO is not supported, it'll fail, it'll never return a BO with INVALID
11:41 emersion: if the driver doesn't support modifiers, it'll succeed with a BO with INVALID
11:41 emersion: and then there's the case where LINEAR is in the list
11:41 daniels: I agree the divergence is a bug too, and we should try an implicit alloc if the user has signalled that implicit is OK via INVALID
11:41 emersion: GBM doesn't have the semnatics that INVALID means implicit
11:42 emersion: with GBM, INVALID values are ignored - until your patch
11:42 emersion: changing this is a breaking API change
11:42 daniels: so instead of allowing INVALID -> implicit when the driver supplies modifiers, you'd rather always ignore INVALID i.e. always fail when the driver doesn't support modifiers?
11:43 emersion: simple: if the user supplies modifiers and the driver doesn't support these, fail just like before
11:43 daniels: akc
11:43 daniels: *ack
11:44 emersion: if (!pscreen->resource_create_with_modifiers && count > 0) { return false; }
11:44 emersion: i'm open to discussing changing this behavior, but, it would be a breaking change
11:44 emersion: and we need to make sure it's consistent
11:44 emersion: and it probably requires updating all driver's resource_create_with_modifiers
11:45 emersion: fwiw, "INVALID means implicit" is a Wayland-only thing
11:45 daniels: I've just looked at GBM from a random 2022-era branch I had lying around, and sure enough we fail on non-modifier drivers if count > 0, so yeah, what you're doing seems correct to restore that behaviour, and I no longer have any idea why I'd tried to implement something different
11:45 emersion: KMS, GBM, EGL -- none of these have this behavior
11:46 emersion: i do believe the wayland behavior is nicer because it allows a single codepath for both cases (modifiers supported or not)
11:47 emersion: but it really requires some serious thought to convert an API from the old model to the new one
11:47 daniels: yeah, me too, but changing API seems kinda silly, especially when the API is already this terribly fragile :)
11:47 daniels: yeah
11:47 notmeatforyou: alyssa: don't say to me you got insulted by me, I did the reverse, if i was so intelligent at 22 i would not be worthless today. But it indeed looks like krh hacked things pretty deep, and i might as well add the needed code, but better you do, cause you might get paid on it.
11:51 androidui: hi
11:56 notmeatforyou: there is no technical issues with self-driving cars, proper contructed ai can do that very well with low-power and huge performance, it's just that this is scifi field and all the testings take inherently long time, people who do that have to get paid too.
12:03 notmeatforyou: it seems i am a bit nerve wreck guy, that is why i am alone spending my time, cause i can not go to conflict i dislike conflicts and wars and such things, became little bit too soft , it's toxic to me, i am classified as someone who does not like to go there, if that is alien attitude like whatever but that is the way it is with me.
12:04 immibis: self-driving cars are held to a high standard because if they fail then random people die. so far they are not reliiable enough to meet the high standard. people have long argued there should not be a high standard, since human drivers also kill random people when they fail.
12:05 immibis: and... this is not the self driving car channel
12:05 daniels: immibis: please don't engage
12:09 notmeatforyou: so that is what i am talking , so how much of such conflicts is the result of short of understanding how systems work and are designed, it is the only thought that circulates in my head, cause i can not see the problems you see?
12:10 kode54: Company: too many variations? see A Hat In Time and its 16GB shader cache that's larger than the game itself
12:12 immibis: daniels: why would you say that instead of banning spammers
12:13 Company: kode54: it's good to know that whatever dumb thing I do, some game did it before me and Mesa has fixed that cae already
12:13 llyyr: immibis: this spammer has singlehandedly caused ipv4 exhaustion, banning doesn't do anything
12:13 kennylevinsen: kode54: a 16 GB shader cache would definitely count as having blown up in ways one *doesn't* want to copy :)
12:15 notmeatforyou: again you do not know how cidr and time derivatives work and cidar encodings, ipv4 addresses can never run out, and you have no idea how big time a telescope would zoom in , so if you are afraid of gps crashing your car, its many times more likely that the driver would do that, with security enhancements
12:17 immibis: llyyr: hmm, the last time i notified other members of a channel about something similar to this, channel operators banned me for a week
12:18 kode54: immibis: do you have the will to employ an infinite proxy supply to evade bans until literally the heat death of the universe?
12:18 kode54: because this person sure does
12:19 kennylevinsen: back to topic please
12:19 kode54: yes
12:19 kode54: soreau, see above, your modifier issue was mentioned
12:20 kode54: kennylevinsen: the best part about that 16GB shader cache, is that for quite some *years*, steam was forcing full shader cache validation on every day cycle
12:20 notmeatforyou: and by the way there is a concept of a remote driver , which is lagging due to elmo engineers do not figure out how powers of two's work, they hook this remote driving procedure to the 4g networks where they transfer data in excess of many gigabytes in minutes , sure it ain't gonna carry out this way
12:21 notmeatforyou: you need a proper filesystem and wire protocol to do that
12:27 notmeatforyou: it's that yeah doing driver licenses, and i am not concerned about my injury or that i am incapable of driving the car in my cripple rythm, it's just that i know what is being targeted with this event, romeo must die form, i know how dirty these people play.
12:30 notmeatforyou: and it's not like i am not sick, i am , but incurably sick in that sense cause i am moderating way more toxic people than you do, and to study their moves , yes i became very sick to understand those ways, cause i am not like that
13:12 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31736
13:19 Company: DavidHeidelberg: I enjoyed your XDC talk
13:19 Company: I like it when my software is useful to developers
13:51 soreau: daniels: I've updated the commit message in an attemp to make it clearer what the commit is doing/fixing
13:51 daniels: soreau: thanks
13:52 soreau: yw, please let me know if it should be tweaked further
13:52 daniels: DavidHeidelberg: I think we really need to punt LTO back to nightly - I'm seeing fedora-release regularly take 19-20min, and since it only starts after the entire build-for-tests stage finishes, it can be the long pole that pipelines end up waiting for
13:55 daniels: DavidHeidelberg: if we can make it run quickly then cool, but in a bunch of MRs I picked from yesterday, the runtime varies from ~18-22min - https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65243914 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65130261 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/64375116 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65236004 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65230900
13:55 daniels: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65226888 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65221316 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65219636 https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65217672
13:55 kode54: how many arches is that 18-20 minutes building for?
13:56 daniels: one
13:56 zmike: would splitting it into multiple lto jobs be useful?
13:56 kode54: oh
13:56 kode54: oh right, LTO
13:57 kode54: I don't know how long my system would take to build with LTO enabled
13:57 kode54: not that that's a useful metric
13:57 zmike: your system wouldn't build every possible driver anyway, which is the reason the job takes so long
13:57 kode54: I'm only building the defaults for arch package
13:59 kode54: _dri_drivers="i915,i965,r100,r200,nouveau" _gallium_drivers="r300,r600,radeonsi,nouveau,svga,llvmpipe,softpipe,virgl,iris,zink,crocus,i915" _vulkan_drivers="amd,intel,intel_hasvk,swrast,nouveau" _codecs="vc1dec,h264dec,h264enc,h265dec,h265enc,av1dec,av1enc,vp9dec"
13:59 kode54: so not a full comprehensive set by any means
14:01 kode54: didn't someone say the build containers are also 8 threads?
14:01 kode54: not that bumping that would help anything, you'd have less to go around for other jobs
14:02 kode54: zmike: done any magic lately? (coding wise)
14:02 kode54: I should see if you've posted anything
14:03 zmike: I took a really solid nap the other day
14:03 kode54: oh fug, I saw you got con crud
14:04 zmike: too much unprotected wayland discussion
14:22 soreau: it only counts for a 'coding wise' accomplishment if you've solved a problem while napping
15:24 zmike: someone want to ack https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/964
15:32 DavidHeidelberg: Company: thank you 🤩
15:33 DavidHeidelberg: daniels: hehe, I wanted, just the warnings (threated as errors) by non-LTO build are different, so it's slightly annoying
15:37 DavidHeidelberg: I added some into gitlab-ci.yml, but another batch showed up, so I moved to other stuff and kept LTO on it
15:42 MrCooper: DavidHeidelberg: do you have a fedora-release log with LTO disabled by any chance?
15:46 DavidHeidelberg: MrCooper: generating one now
15:59 DavidHeidelberg: MrCooper: https://gitlab.freedesktop.org/dh/mesa/-/jobs/65303723
16:02 MrCooper: that rings a bell, there might already be an MR which fixes it
16:02 daniels: DavidHeidelberg: yeah, I can see why you'd want it, but 20min is just way too high for builds tbh ... if there's some amazing new version of mold or some optimisation tuning we can do to cut it in half then cool, else it'll have to just stay in nightly for now
16:04 daniels: ah, iswym, non-LTO builds currently error where LTO don't, awesome
16:07 DavidHeidelberg: yup.. yup..
16:08 DavidHeidelberg: daniels: nah, I was just lazy to iterate over weird errors not seen with LTO...
16:08 DavidHeidelberg: I'm happy when you ack https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31616
16:08 DavidHeidelberg: that would be nice to have nightly with full-LTO everywhere
16:11 daniels: DavidHeidelberg: sort of - I don't mind enabling LTO if it actually helps us do stuff, but it seems to have been broken for ages now without anyone putting systemic effort into root-causing the failures and fixing the drivers - if it just means that the nightly builds have random failures which don't correlate to pre-merge which never get fixed by anyone, then I don't think it makes sense tbh
16:13 DavidHeidelberg: daniels: right, I believe thou there would be people looking into it, there is just no way how to reproduce.. where the CI would give us artifacts with debug + testing suite. So when magically in one nightly tests fails, someone can diff the binaries and look what changed
16:13 DavidHeidelberg: I believe that could be much better than having some random complex workload on distro compiled kernel
16:14 DavidHeidelberg: plus, for the binaries used for tests on embedded HW, it may (maybe, I would have to check), run the 3h suite faster in exchange for 5 minutes at build time
16:15 daniels: yeah, that would definitely be awesome if someone was working on root-causing and fixing it
16:16 daniels: I just worry it won't happen and nightly drifts away as some kind of weird unreliable noise
16:16 daniels: (more than it is currently)
16:16 daniels: I'm happy to take majority opinion though, hence why I was also sitting out the MR :)
16:19 MrCooper: FWIW, my idea for testing LTO build in CI was that otherwise more stuff will keep breaking with LTO, making it harder to investigate its boss problem(s)
16:21 DavidHeidelberg: yeah the noise is risky. But if there would be issue with some particular build generating stable-crash/fail (because that's what usually LTO causes and get reported). At some nightly I would hope, it generate mesa code which crash in some small dEQP test (or trace) and can be debugged
16:23 DavidHeidelberg: MrCooper: for the warning, since LTO probably knows this won't happen, it won't fire it, maybe more recent compiler (Fedora) would help?
16:26 MrCooper: your guess is as good as mine :)
16:27 MrCooper: to put it differently, without testing the LTO build in CI, we'll likely keep drifting further away from the end goal of Mesa actually working reliably with LTO
16:32 emersion: MrCooper: did my dri-devel reply make sense to you?
16:32 emersion: or not?
16:32 MrCooper: I was hoping to get an opinion from others as well
16:32 emersion: same...
16:33 emersion: do you know who else I could ping?
16:33 MrCooper: personally I don't see how we can avoid handling this via Wayland protocol
16:33 emersion: even if it doesn't pin?
16:33 MrCooper: you'd have to describe in more detail what you mean by that
16:34 MrCooper: (in the thread, not here)
16:34 emersion: you mean the dynamic importer thing?
16:34 MrCooper: whatever you mean by that
16:34 emersion: your concern was pinning to system memory right?
16:35 MrCooper: mainly that no kernel mechanism allows the compositor to know the client's intent
16:35 emersion: dynamic importers are a kernel api thing
16:35 emersion: internal dmabuf api
16:35 MrCooper: I know that, just not how you envision that solving all the issues
16:36 emersion: why is knowing the intent necessary?
16:36 emersion: well, with dynamic imports, there's no pinning to system memory
16:36 emersion: afaiu
16:36 MrCooper: I'm sorry but I don't have time for this right now, please follow up in the thread
16:37 emersion: okay... it would be helpful if you could sent your questions there
16:37 emersion: send*
16:37 emersion: I'm nor sure what to explain
16:37 emersion: not*
16:37 MrCooper: it's just the above, I'm not sure how you envision "not pinning" solving all the issues
16:37 emersion: I'm not sure what the rest of the issues are
16:38 emersion: I saw only one issue, pinning
16:38 MrCooper: e.g. knowing which device the buffer is (intended) for
16:38 emersion: this isn't necessary
16:38 emersion: compositor just tries
16:40 emersion: the more I think about it the less I'm excited about wl protocol changes
16:40 MrCooper: importing to a device may work without pinning, but not be optimal for the client's intent
16:40 emersion: the compositor knows where it needs to paint the buffer
16:43 emersion: so, your concern is maybe, device where the buffer will be painted cannot import the buffer, there are 2 other devices where the buffer can be imported, what's the most optimal?
16:43 emersion: does this really happen?
16:43 emersion: what's an example of this?
16:50 zamundaaa[m]: emersion: an example would be a laptop with iGPU, dGPU + an external GPU
16:51 emersion: zamundaaa[m]: these devices cannot import each others buffers without moving
16:51 zamundaaa[m]: If a buffer from the eGPU needs to be presented on the dGPU, but direct import doesn't work, then the compositor could either blit to a compatible buffer on the eGPU and then copy that over, or it could first copy to system memory and then to the dGPU
16:51 MrCooper: DavidHeidelberg: I'm quite skeptical about getting any progress on the LTO boss problem(s) just from CI, given how random they've been
16:52 MrCooper: emersion: "not pinning" doesn't help for the case I described, where the buffer already resides in system RAM
16:52 emersion: MrCooper: why not?
16:52 MrCooper: being in system RAM is bad even if not pinned
16:53 emersion: being in system ram is not a consequence of the import
16:53 emersion: something else triggered it
16:53 zamundaaa[m]: emersion: both iGPU and eGPU can access the buffer directly, but only one of them is efficient
16:54 MrCooper: it could still mean the importing GPU can only access it in system RAM, in which case there would be migration ping-pong between the exporting GPU's VRAM and system RAM
16:55 zamundaaa[m]: Even if the kernel could tell us which import would be more efficient, the protocol changes are still useful
16:55 zamundaaa[m]: To tell the client which devices it can expect the compositor to handle
16:56 zamundaaa[m]: And which GPUs are preferred over others
16:56 emersion: I need to run, will reply later
16:57 MrCooper: I tell you I don't have time right now, you drag me into it anyway, then you need to run? Great ;)
16:58 DavidHeidelberg: :D
17:00 MrCooper: that might have been too harsh depending on the reason for needing to run, in which case I'm sorry
17:19 DemiMarie: Why would the protocol and the kernel change be mutually exclusive?
17:19 zamundaaa[m]: They're not
17:20 zamundaaa[m]: We definitely want both
17:29 soreau: eric_engestrom: daniels: who would be good to ping about review for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725 ?
17:57 zf: bnieuwenhuizen: thanks. of course it tripped me up because that flag is never mentioned in VUIDs, which effectively contradict the relevant parts of the spec
17:57 zf: love vulkan :-)
18:46 zmike: I just fixed some related parts of the spec recently around whether creating planar views was even legal (obviously it is), so it's not surprising there are other bugs in the same area
20:19 DavidHeidelberg: karolherbst: I see rusticl now reports CL_DEVICE_IMAGE_SUPPORT: CL_TRUE, but CL_DEVICE_MAX_READ_IMAGE_ARGS: failed, expected at least 128, got 16
20:19 DavidHeidelberg: by spec, when CL support image, it needs to report 128
20:24 DavidHeidelberg: while rusticl reads PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS and pass it
21:02 karolherbst: you don't need 128 with the embedded profile
21:02 karolherbst: DavidHeidelberg: piglit is just unreliable with everything in regards to those caps, because it just hardcoded against clover + r600
22:05 DavidHeidelberg: The spec say "Max number of image objects arguments of a kernel declared with the read_only qualifier. The minimum value is 128 if CL_DEVICE_IMAGE_SUPPORT is CL_TRUE, the value is 0 otherwise."
22:05 DavidHeidelberg: which seems pretty explicit. Maybe I'm missing some extension adjusting this paragraph?
22:06 DavidHeidelberg: (in https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/clGetDeviceInfo.html )
22:09 DemiMarie: What are the plans for long running compute on Asahi? My understanding is that that will require long-term pinning of memory, but I think that it is better to have that as an option than to not offer it at all.