01:37 airlied: karolherbst: just rebasing the spirv-llvm-translator to later branches shouldn't be har
01:37 airlied: hard
02:55 airlied: karolherbst: bumped to latest 160 branches
08:45 karolherbst: cool, thanks!
08:45 karolherbst: not sure what to do with the other problems though :/
08:46 karolherbst: that bump alone only fixes a handful of bugs, like `isnormal` and other operations. The opaque pointer stuff is a bit more invovled _though_ that only matters with generated spirvs with weird tooling
11:15 Fr0stBit: Hello!
11:16 Fr0stBit: Has anybody tested chromium with hevc playback on AMD cards?
11:16 Fr0stBit: This sample video: https://test-videos.co.uk/vids/bigbuckbunny/mp4/h265/1080/Big_Buck_Bunny_1080_10s_30MB.mp4 plays in chromium on my Intel laptop but not on my Ryzen laptop and I'm trying to figure out if its a chromium or a mesa issue
11:56 karolherbst: Kayden: mind taking a look at this commit to implement CL subgroups? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893/diffs?commit_id=79eb02a4423283d6bad8569619a01e699a035887
11:56 karolherbst: though I wonder if I could ask iris to precompile everything and make some of that stuff less messy
11:57 karolherbst: for CL we kinda want that to happen before `launch_grid` anyway
12:23 CounterPillow: Kind of weird DRM question: where on the sliding scale from single LED to 8K display do we make the cutoff of what a DRM panel is?
12:24 CounterPillow: is an addressable RGB LED strip that's controlled over SPI a potential 1xn DRM display, or should the LED subsystem handle that?
12:26 pq: hmm... would there be a "card" for it? What would be the DRM device for a led strip?
12:26 CounterPillow: I assume it'd work like SPI LCDs work currently
12:26 pq: Would you expect the led strip to used by programs that use KMS?
12:27 CounterPillow: Good point. We probably don't want to display a kernel framebuffer console on it, but we do kind of want to just throw pixel data at it instead of fiddling with individual LEDs through sysfs.
12:27 pq: good questions, and my guess is it depends on what userspace you expect to be able to run for it
12:28 pq: also, how awkward would the LED API be? I'm not familiar with it.
12:29 CounterPillow: Very awkward, you'd be opening multiple file descriptors through sysfs per LED
12:29 CounterPillow: I've sent a mail to the linux-leds mailing list to propose a new API for this awkward inbetween of "more than one LED, not a display". What speaks for making this not DRM is that pixel formats map badly to it https://lore.kernel.org/linux-leds/5324811.I0CZgJUjXn@archbook/T/
12:30 CounterPillow: What speaks for making it DRM is that a LED matrix is basically a display and any LED strip can be a LED matrix if you run it back and forth in strips
12:31 pq: what are those "wacky multi-colour" things, how do you drive them?
12:32 CounterPillow: Basically multi-colour LEDs that are not R/G/B but something like RGBW or Violet/Green or what have you
12:33 pq: more than 3 channels would be a problem for DRM pixel formats indeed
12:33 pq: but new pixel formats can be invented
12:34 pq: OTOH, if it's like 2-channel violet/green, you could use any 2-channel or palette pixel formats.
12:36 javierm: CounterPillow: https://cdn-shop.adafruit.com/product-files/2239/alt%20sk9822%20datasheet.pdf is the chip of the strip you shared, right ?
12:36 linkmauve: CounterPillow, I’ve seen people place LED strips on their ceiling, locate each LED, and then draw things using that.
12:36 CounterPillow: javierm: correct
12:37 CounterPillow: 8bpc RGB almost maps nicely to pixel formats except for the 5-bit brightness which is per LED and not globally for all LEDs so modelling that brightness as a backlight would be a disservice to the capabilities
12:38 javierm: CounterPillow: the brightness could be handled by a separate backlight device IMO
12:39 CounterPillow: You could also use a driver chip like this and arrange its output LEDs in a matrix, as another example of how multi-LED devices work in practise https://www.ti.com/product/LP5036
12:40 CounterPillow: but a 6x6 12-bit-per-channel DRM panel feels a little silly
12:42 javierm: CounterPillow: there's https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L146 :)
12:43 javierm: but I don't see why a LED strip couldn't have a DRM driver, it's not that different than small RGB or monochrome OLED panels
12:45 MrCooper: zmike: FYI, gitlab comments support a /duplicate quick action which marks the issue as a duplicate of and related to another issue (and closes it, if it's still open)
12:45 zmike: 🤔
12:49 pq: huh, I could have sworn I've seen a RGB999E5 or another common-scale pixel format before
12:50 pq: that would match nicely the 5-bit brightness
12:50 DavidHeidelberg[m]: finishing for Ack/Rb for switching radeonsi jobs to Wayland (noticable CI speedup on jobs which are usually the last one running): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23964
12:50 DavidHeidelberg[m]: *fishing
12:56 robmur01: CounterPillow: sounds similar to the debates around 7-segment displays that are a bit beyond the LEDs API but not really capable enough to fit into auxdisplay
12:58 jannau: DavidHeidelberg[m]: you did not run into https://gitlab.freedesktop.org/mesa/mesa/-/issues/9276 yet?
12:59 DavidHeidelberg[m]: it's already in fails or not yet
13:00 robmur01: you kinda want the equivalent for pixel data of what auxdisplay is for character data
13:05 javierm: CounterPillow: looking at https://www.adafruit.com/product/2239, the "pixel" format is just 24 bpp RGB https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L189
13:06 CounterPillow: Yeah, if you ignore the brightness across all three channels that can vary for each pixel which you might want to do for contrast reasons :)
13:07 CounterPillow: I think I should just get some of these devices and write some drivers for them and see how terribly it goes, if there's a need for a new abstraction it will reveal itself
13:08 javierm: CounterPillow: right, but you can then take each channel 8-bit color value and combine with the backlight configuration (5-bit / 32 levels) and write that to the IC
13:08 javierm: there's no need for the latter to be encoded in the pixel format
13:08 javierm: it's less flexible yes, but it will operate as a normal panel
13:08 CounterPillow: Hmmm, yeah
13:09 javierm: doing it that way it means that you could use any user-space application, even fbdev user-space using the DRM fbdev emulation
13:10 javierm: because you could just expose a DRM_FORMAT_XRGB8888 format
13:11 javierm: you wouldn't be able to chose the brightness for individual pixels / RGB led colors, do I wonder how useful that is in practice
13:14 CounterPillow: And I guess for the LED driver with 36x12bitsx3channels I could either implement a cursed new pixel format or use XRGB161616 and scale the values
13:15 CounterPillow: oh nvm it's actually 36x12bits, I overestimated the channels by a factor of 3
13:17 javierm: CounterPillow: yeah, if I read correctly is just https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L146 ?
13:18 CounterPillow: Yeah
13:18 javierm: CounterPillow: if the adafruit strip was cheaper, I would had buy one too :)
13:20 javierm: but would be great to have a driver for that, specially now that is harder to define spidev nodes in DT
13:35 zmike: can I get an ack on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23971
13:38 gfxstrand: karolherbst: Not sure what you mean. I don't see any arrays there.
13:39 karolherbst: gfxstrand: soo.. with opaque pointers disabled, you have a direct chain from the printf call to the variable being a fixed size array
13:39 karolherbst: with opaque pointers enabled you have this bitcast in the middle dropping the size information
13:40 gfxstrand: Oh, well that's annoying.
13:40 gfxstrand: karolherbst: So how does that show up in the back-end? Is it getting an SSBO array length intrinsic or something?
13:41 austriancoder: has anyone ever tried to emulate OES_texture_float (PIPE_FORMAT_R32G32B32A32_FLOAT) with OES_texture_half_float (PIPE_FORMAT_R16G16B16A16_FLOAT)?
13:42 karolherbst: gfxstrand: the back-end doesn't really care, we just need the size information to extract the printf info
13:42 karolherbst: because it's pointing to a static array with the string as a constant
13:48 gfxstrand: karolherbst: Is there a bug about this? Or is printf doing something weird? How are we handling this case right now?
13:49 karolherbst: it's some fallout from moving to llvm-16
13:50 karolherbst: so libclc is built with opaque pointers enabled and it messes up a lot of those things
13:50 gfxstrand: :rolling_eyes:
13:50 karolherbst: because... LLVM implicitly upgrades to opaque pointers
13:50 gfxstrand: woo
13:50 karolherbst: and libclc is built like this: clang -> llvm-link -> opt -> llvm-spirv
13:50 karolherbst: so if clang emits with opaque pointers disabled, llvm-link converts it to opaque pointers enabled :D
13:51 karolherbst: gfxstrand: my "fix": https://github.com/karolherbst/llvm-project/commit/9193f678e8ae8bcff09b76531401eefd9970f902
13:51 karolherbst: that gives me a libclc like we get it with llvm-15
13:51 karolherbst: but I think we have to follow more closely how that stuff will look like once opaque pointers are more matured
13:52 gfxstrand: I mean, if the libclc being produced is busted, then patching it in LLVM seems like the right choice.
13:52 karolherbst: the translator has weird hacks to follow back pointer chains and stuff
13:52 karolherbst: it's just not always working
13:52 karolherbst: yeah...
13:52 karolherbst: _but_
13:52 karolherbst: the printf is actually still legal
13:52 karolherbst: and there is work on making the string dynamic as well
13:52 karolherbst: in any case, what we do is a bit too strict and getting a random pointer to constant memory without the size information is _legal_
13:53 gfxstrand: karolherbst: Ugh...
13:53 gfxstrand: karolherbst: How's that supposed to work?
13:54 karolherbst: you encode which string it points to?
13:54 karolherbst: it still has to point to uniform constant memory
13:54 gfxstrand: But we're supposed to be able to parse the string from the SPIR-V parser.
13:54 karolherbst: just it might come from a phi source
13:55 karolherbst: from the opencl spirv extension thing: "format must be a pointer(constant) to i8."
13:57 gfxstrand: Yeah, just dug that up.
13:57 gfxstrand: We should file a bug and tell them not to do that.
13:57 karolherbst: gfxstrand: for now I think it's fine to follow the pointer chain and see if we hit a variable of static size and bail otherwise, because that's what OpenCL C without extensions only allows anyway
13:57 gfxstrand: I really doubt anyone is emitting fully generic printf code in kernels.
13:57 karolherbst: _but_ spirvs can do whatever they want anyway.
13:57 karolherbst: uhhhh
13:57 karolherbst: there are extensions for that
13:57 gfxstrand: fuuuuuuuu
13:57 karolherbst: not sure they are public yet :D
13:58 gfxstrand: Why?!? Why are we string processing in kernels?!?
13:58 gfxstrand: But also if there are extensions for that then people don't expect it to work today.
13:59 gfxstrand: http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/POCL/SPV_EXT_relaxed_printf_string_address_space.html
14:00 karolherbst: ahh
14:00 karolherbst: there it is :D
14:00 karolherbst: `404: Not Found` :D
14:00 gfxstrand: http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/EXT/SPV_EXT_relaxed_printf_string_address_space.html
14:00 karolherbst: yeah.. it's nuts
14:01 karolherbst: building the string inside the kernel is way too much work
14:01 karolherbst: however
14:01 karolherbst: selecting the string based on some condition is I think fine, and which we don't support atm
14:01 karolherbst: it's still.... bad but not as terrible
14:01 gfxstrand: :rolls_eyes:
14:02 karolherbst: but it is allowed do that already with spirv
14:02 gfxstrand: I mean, maybe? I guess we could select on string instead of parsing it.
14:02 karolherbst: we already encode the string as a constant, no?
14:02 karolherbst: so instead of emiting a constant, we emit a variable
14:02 karolherbst: wouldn't really change much
14:02 gfxstrand: I mean, maybe it could be okay.
14:03 karolherbst: we already encode it in the buffer we write to
14:03 gfxstrand: We would need to change the printf buffer format.
14:03 karolherbst: why?
14:03 karolherbst: it's already there
14:03 karolherbst: we just have to write a variable instead of a constant on the lowering side
14:04 gfxstrand: Right now, printf has a static list of strings, known at compile-time. What gets dumpped in the buffer is just the arguments.
14:04 karolherbst: and the string id
14:04 gfxstrand: Yes
14:04 gfxstrand: And we could support the current thing by just making the string id the pointer or something.
14:04 karolherbst: that's the only change, string id constant to string id variable (with current spec behavior)
14:04 gfxstrand: But if we want the generic thing, we can no longer pull strings out at compile time. We have to dump them into the buffer.
14:04 karolherbst: yeah.. I'd ignore the generic thing
14:04 gfxstrand: Because it might come from random global memory
14:05 karolherbst: that's a problem for future us
14:05 karolherbst: I have a stupid idea...
14:05 karolherbst: we kinda lower those printf strings like we lower images....
14:05 karolherbst: and it's just an index..
14:06 karolherbst: it kinda sucks, but...
14:06 karolherbst: dunno.. the first step would be to just follow back the chain and find the constant string and use that for now.. dunno
14:06 karolherbst: could also fix it properly
14:18 Venemo: hi guys
14:18 Venemo: is it possible to write an algebraic patten in which there are certain rules between constants?
14:19 Venemo: for example, I'd like a pattern such as this: (('ubfe', ('ubfe', a, '#b', '#c'), '#d', '#e'), ('ubfe', a, b - d, c - e))
14:20 Venemo: but obviously this doesn't work
14:20 gfxstrand: No, not currently.
14:20 Venemo: and it is only feasible when b > d and c > e
14:20 Venemo: gfxstrand: what would you recommend to do for this pattern then?
14:20 gfxstrand: I've thought about how one might be able to do that but it's tricky.
14:20 gfxstrand: You'd need to implement the op in C
14:21 Venemo: I mean I guess I could write a loop and emit them one by one, but I feel that would be quite ugly
14:21 gfxstrand: And maybe just bail if there's a swizzle in between.
14:21 Venemo: I don't know what you mean by a swizzle here
14:21 gfxstrand: You have one ubfe reading another. If it swizzles between them, you'd need to account for that.
14:21 gfxstrand: Or just bail
14:22 Venemo: what does it mean, "it swizzles between them"
14:23 gfxstrand: If you have ubfe(ubfe(a, b, c).zyx, d, e)
14:23 gfxstrand: IDK if that syntax makes sense.
14:24 gfxstrand: One of the cool things about opt_algebraic is that it knows how swizzles work so it can produce ubfe(a.zyx, b-d, c-e)
14:24 gfxstrand: But if you're writing an opt in C, you either need to handle that yourself or just bail whenever you see a non-trivial swizzle.
14:24 Venemo: sorry, I've never dealt with swizzles ever, so I'm not sure
14:24 gfxstrand: Be thankful!
14:24 Venemo: I don't want to write it in C, though. would rather shoehorn it into opt_algebraic if possible
14:26 zzxyb[m]: Excuse me, I will import the gbm_bo on one drm device to the second drm device through gbm_bo_import, how can I convert it into a picture and save it on the disk through gbm_bo_map, i used code like this : gbm_bo_map(m_bo, 0, 0, m_width, m_height, GBM_BO_TRANSFER_READ, &m_stride, &m_map_data) ,result is empty,is it because I should not be GBM_BO_TRANSFER_READ this flag?
14:30 gfxstrand: Venemo: We could loop, in the python but that's a LOT of new rules.
14:33 pq: zzxyb[m], by "empty" do you mean you can access the pixels but they are all zeros?
14:33 Venemo: gfxstrand: I suppose this would work too: (('ubfe', ('ubfe', a, '#b', '#c'), '#d', '#e'), ('ubfe', a, ('isub', b, d), ('isub', c, e))) <-- this would be constant folded, right? but I'm not sure how to express the constraint of b > d and c > e
14:33 gfxstrand: Yes, that would work if we can work out the constraints
14:34 pq: zzxyb[m], are you checking for failures at every step?
14:34 Venemo: I can't find in the current syntax how to do this :(
14:34 gfxstrand: We don't have a constraint syntax that lets you compare constants right nowl
14:34 karolherbst: just add new syntax: '#b(>d)' :D
14:34 pq: zzxyb[m], are you sure the image you are expecting has finished being drawn into the bo in the first place?
14:35 karolherbst: ehh wait..
14:35 karolherbst: those are just helper functions, right?
14:35 pq: that's all I can say now, I'll be back tomorrow
14:35 gfxstrand: Yeah, you can do `#b(greater_than_3) but not `#b(greater_than_d)`
14:36 karolherbst: mhhh
14:36 karolherbst: could support optional arguments to the helpers? mhh
14:36 karolherbst: could be messy
14:37 zzxyb[m]: pq: i mean return null pointer
14:39 zzxyb[m]: pq: i'm sure, because I used mmap to dump the image in bo to disk and checked
14:39 zzxyb[m]:uploaded an image: (589KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/iNzINxUVKIELExQvwatEfBCB/image.png >
14:41 zzxyb[m]: because this image was sent to the display a little abnormally at the end, so I am troubleshooting,my working scenario is to complete the rendering on the first drm device, and then gbm_bo_import to the second drm device for display
14:44 zzxyb[m]: i'm sure drmModeAddFB is successful and has the correct framebufferid,no errors
14:46 emersion: null pointer would mean a map error
14:46 emersion: i don't think mapping will be supported with a "foreign" DMA-BUF
14:51 gfxstrand: Yeah, map + dma-buf is tricky
14:59 zzxyb[m]: the strange thing is that the same code can mmap on an arm device, the graphics card is mali, and the image is correct, but mmap reports an error (returns a null pointer) on X86, so i seek to use gbm_bo_map
15:00 emersion: one shouldn't mmap directly a DMA-BUF
15:01 emersion: this will mess up synchronization at the very least
15:03 zzxyb[m]: <zzxyb[m]> "image.png" <- I just want to verify the correctness of the image, after all, the display is abnormal after my pageflig.
15:09 zzxyb[m]: <emersion> "this will mess up synchronizatio..." <- then how do I verify that using gbm_bo_import on different drm devices is successful without any error,after all, my work scene is that the monitor connected to the second drm device is actually rendered and processed by the first drm device, and I just want to display the rendering result gbm_bo on the second monitor.i am using gbm_bo_import + drmModeAddFB + drmPageflip.the result ends up
15:09 zzxyb[m]: being displayed as a pattern of bars.it seems that there is no alignment, such as stride, size and other information
15:13 zmike: DavidHeidelberg[m]: the shader-db part of CI could be made more clear about what exactly the failure is, e.g., https://gitlab.freedesktop.org/zmike/mesa/-/jobs/44845799
15:15 zzxyb[m]: i will double check the gbm_bo information returned by gbm_bo_import tomorrow to see if the width and height are correct
15:15 DavidHeidelberg[m]: zmike: hmm, it doesn't print the failing shaders, right? (From what I see)
15:15 zmike: yeah
15:16 DavidHeidelberg[m]: I'm putting on my to do :)
18:45 austriancoder: how bad is the idea that a nir phi would have a swizzle? I have some cases where nir_shrink_vectors could help.
19:14 jenatali: I think alyssa would have strong opinions on that
19:45 pendingchaos: couldn't you use a nir_op_mov?
19:55 austriancoder: pendingchaos: need to check it but from quickly scanning over it I would say no :) oh.. important note.. I am in vec4 world. I have an undef that gets lowered to vec3 of 0.0f. and the pi uses it. But I would be smarter to to only have ssa_12.xxx instead of ssa_12. Will talk to Alyssa :)