07:15 Daanct12: i just submitted a one line patch: https://lore.kernel.org/phone-devel/20240722-bf060y8m-aj0-prepare-prev-v1-1-0e51c0f59d22@riseup.net/
07:15 Daanct12: would like a review
08:26 ManDay: Is intel clc mandatory when building mesa with support for intel?
08:37 karolherbst: ManDay: yes
08:50 ManDay: thanks karolherbst
10:57 karolherbst: pendingchaos: fyi, please use the "do not litter" emoji to mark spam comments as I've done with the one you reported
10:59 pendingchaos: is this is to make it obvious it's spam to readers, or some kind of replacement for the report button?
10:59 karolherbst: replacement, the bot will deal with the spam then
10:59 karolherbst: (and delete the account)
10:59 karolherbst: but it might fail
11:00 karolherbst: anyway, if you report, then somebody else needs to deal with it
11:00 pendingchaos: ok
11:00 pendingchaos: I'll use that instead of report
11:00 karolherbst: and it's way faster as the comment are generally removed a few seconds after marking them
11:01 karolherbst: thanks :)
11:01 pendingchaos: I assume the bot checks a person's project role before doing this?
11:01 karolherbst: it has a few checks in place, but I don't know what checks exactly
11:02 karolherbst: bentiss or daniels might know
11:02 karolherbst: but I've seen it fail to detect spam, and then it comments to tell to report it instead
11:03 daniels: https://gitlab.freedesktop.org/freedesktop/damspam/-/tree/main
11:05 daniels: it looks like the main check is whether or not the account is 6 months old
11:05 daniels: and by 'main', I mean only
11:06 karolherbst: mhhh...
11:08 karolherbst: though I've seen other comments from the bot
12:00 karolherbst: in gallium, what's the best approach to copy data between buffers and images? Is that something expected of `resource_copy_region` or would I need to write a custom copy shader for those cases?
12:22 zmike: some drivers can do it with resource_copy_region
12:22 zmike: others probably need a compute shader
12:25 karolherbst: right, but if not all can do that it's not really useful. Do we have a cap or something to indicate that a specific driver can do it?
12:26 karolherbst: well.. some drivers will just use a shader inside resource_copy_region anyway, I'm mostly interested if resource_copy_region is supposed to copy between buffers and images/textures or if it's valid for drivers to just crash/assert/whatever there?
12:32 mareko: karolherbst: can you see the messages I sent ~5 minutes ago?
12:32 karolherbst: mareko: I can't
12:33 mareko: karolherbst: resource_copy_region can only memcpy between 2 buffers and between 2 textures where the formats are equal
12:34 mareko: karolherbst: for copies between buffers and textures, it's missing the stride parameter at least
12:34 karolherbst: oh right...
12:37 karolherbst: though in CL the APIs for Buffer -> Image and Image -> Buffer copies use implicit strides.... but I need a custom copy shader for copy operations with custom strides (which CL also has) anyway... I know that some hardware (e.g. nvidia) could do all of this via their copy engine, but I need the shader for other hardware anyway.
12:37 karolherbst: maybe something for later, not that it matters much I guess...
12:39 mareko: if Vulkan can copy between buffers and images, it would be worth adding a pipe_context function for it because it's pretty unlikely that shaders in common code would be fast on AMD
12:40 karolherbst: it can
12:41 karolherbst: there is vkCmdCopyBufferToImage and vkCmdCopyImageToBuffer
12:41 mareko: karolherbst: the dedicated copy engine is usually slow and only useful for transfers over PCIe where the bandwidth is low; if you want to utilize all VRAM bandwidth (or even infinity cache bandwidth), it's very likely you have to use compute shaders
12:42 karolherbst: right.. but drivers like radeonsi would choose to do that internally if they care about performance here, no?
12:42 mareko: yes
12:42 karolherbst: but I think I'd start with a custom shader for now
12:43 mareko: karolherbst: radeonsi wouldn't even use the copy engine because it's a separate queue and there is noticable CPU overhead of submitting a command buffer to any queue that isn't gfx
12:44 mareko: because the gfx queue doesn't have to submit/flush
12:44 mareko: usually
12:45 karolherbst: I see
12:54 karolherbst: mareko: I was just looking at si_buffer_subdata and it looks almost identical to u_default_buffer_subdata except it doesn't set PIPE_MAP_DISCARD_WHOLE_RESOURCE when applicable. Is that on purpose or is that just a left over function which could be replaced with u_default_buffer_subdata?
14:30 Company: MESA_VK_DEVICE_SELECT=10005:0 to force llvmpipe - does that work everywhere or does that magic device number change?
14:31 Company:wondering if he can dump that into issues when asking users to reproduce something
14:32 gfxstrand: That should be stable
14:32 gfxstrand: It's hard-coded into lvp_device.c
14:32 Company: sweet
14:33 gfxstrand: Well, the 0 is. The 0x10005 is hard-coded into the Vulkan spec
14:40 mareko: karolherbst: radeonsi promotes DISCARD_RANGE to DISCARD_WHOLE_RESOURCE automatically, the reason si_buffer_subdata exists is to inline the map/unmap calls
15:04 karolherbst: so mainly a CPU optimization here
18:30 marex: I was just running $ dim push-branch drm-misc-next
18:31 marex: and ran intoMerging drm-xe/drm-xe-next... dim:
18:31 marex: dim: FAILURE: Could not merge drm-xe/drm-xe-next
18:31 marex: dim: See the section "Resolving Conflicts when Rebuilding drm-tip"
18:31 marex: dim: in the drm-tip.rst documentation for how to handle this situation.
18:37 marex: it seems the conflict is in drivers/gpu/drm/xe/xe_device.c and drivers/gpu/drm/xe/xe_device_types.h , i.e. not related to drm-misc , uh
18:41 marex: mbrost: hey ...uh ^
18:43 mbrost: marex: I thought i resolved that... it looks like my setup doesn't update drm-tip for some reason, let me ping a team member
18:44 marex: mbrost: thank you, I will un-heart-attack myself in the meantime, sorry for the inconvenience
18:44 mbrost: it is my bad, unsure why my changes don't propagate to drm-tip
18:46 marex: mbrost: no worries
18:46 marex: I won't touch anything for a bit, so I won't mess this up any further
18:47 mbrost: my maintainers are offline, but pinged them to rebuild drm-tip... hopefully they get back online soon
18:48 mbrost: i'll respond on here when it is resolved
18:48 marex: mbrost: thanks, much appreciated
19:19 Lyude: mbrost: fwiw it's fine, i've fixed conflicts from other people beforehand - it just kinda happens sometimes
19:19 Lyude: s/beforehand/before/
19:20 mbrost: thanks, having a bad day across the board, kernel test robot has disliked 2 of my recent patches today too
19:31 marex: mbrost: sorry that I added one more downer on your plate
19:49 Lyude: oh it looks like i hit the same conflict, I'll see if I can fix it
20:03 Lyude: mbrost: fwiw I think I fixed it, building now to double check before I push anything
20:04 mbrost: Lyude: I just fixed it
20:04 Lyude: oh cool
20:04 mbrost: figured out what my problem was pushing, gave it bad login info but dim doesn't appear to complain
20:05 mbrost: marex: should be fixed
20:05 mbrost: hold on 1 sec, different issue now
20:09 mbrost: we have different silent conflict in Xe that popped up, Lucas is fixing it now
20:39 mbrost: marex, Lyude: now everything is fixed
21:30 marex: mbrost: thank you !
22:05 Lynne: you know no one but you has written cooperative_matrix code when for the simplest test you get a crash in radv_shader_spirv_to_nir
22:10 airlied: not true I wrote some as well :-) or at least ported someone elses fork of it
22:10 airlied: https://github.com/airlied/vk_cooperative_matrix_perf
22:14 Lynne: what happened was that shaderc had an error, didn't compile anything, but didn't return an error, so the driver got a 0-byte spv, which somehow made it as far as radv
22:15 Lynne: I don't think the driver should segfault on bad shaders, an assert would be a good idea
22:22 airlied: Lynne: you were of course running with validation layers :-P
22:27 Lynne: I'm the type to remove batteries from smoke detectors :)
22:28 HdkR: Sounds like a good place to enjoy segfaults :)
22:28 Lynne: and shut off validation layers if they blatantly lie
23:05 Lynne: glslang simply gives up and errors if it cannot optimize a piece of code, further cementing its status as the third worst piece of software in history
23:29 Lynne: the validation layers don't support coop matrices, and will error out if they encounter them too
23:34 Company: why has nobody written a better glsl compiler yet actually?
23:34 Company: because I'm slowly running out of appreciation for spirv and the idea of precompiling my shaders and need a runtime spirv generator
23:35 Company: and there doesn't seem to be a good option other than glslang (or various wrappers around it)
23:35 Lynne: but they did, they're called the mesa project, I hear they're using it for something called zink
23:35 Company: can I use it?
23:36 Company: or do I have to fork Mesa for that?
23:36 Lynne: sure, just rip out all the shader code out of mesa, from glsl, to nir, to spirv
23:37 Company: the sad part is that I am seriously considering that option
23:38 Lynne: so do I, and haasn
23:38 Lynne: but /time
23:39 Lynne: also pretty sure the glsl mesa frontend doesn't support vulkan syntax
23:40 Company: oof, right
23:40 Lynne: probably not difficult to add, but its something mesa has no use for
23:41 Company: but I need to compile cicp colorspace converters, and if I put those in the same spirv, it gets huge
23:41 Company: whn in GL I can just strcat() the 15 lines I need
23:43 Company: and if I don't compile the converter with constants and try to use vertex attribs or uniforms or whatever, it gets too slow
23:43 Company: I should check how mpv deals with that
23:44 jenatali: Company: We use Mesa for cross-compiling to DXIL as a standalone tool so we don't have to go back to shader source code
23:44 jenatali: I don't see why you couldn't use it as a standalone GLSL -> SPIR-V compiler
23:45 Company: I think what I really want is a proper linker for spirv
23:45 jenatali: SPIRV-Tools isn't good enough?
23:46 Company: at runtime
23:46 Company: but I haven't check what spirv-tools can do
23:47 jenatali: You can link spirv-tools into an app
23:47 jenatali: That's how CLOn12 and rusticl do CL kernel linking
23:48 Company: I will check it out
23:50 Lynne: isn't all that just a glslang wrapper?
23:51 Company: don't lower my mood again
23:56 Company: it looks like it just works with spirv, but it might have a glslang-based compiler in there somewhere
23:57 jenatali: Spirv-tools? It's got nothing to do with glslang
23:58 Company: but this definitely goes on my todo list for next cycle
23:59 Lynne: why would khronos write not one but two (glsl) to spirv implementations?
23:59 jenatali: Spirv-tools doesn't touch GLSL. It only transforms SPIR-V
23:59 jenatali: It's got things like an optimizer, linker, and validator