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