00:27 mareko: craftyguy: how long does it take for CI results to show up after the Failure email?
00:39 mareko: is this a flaky test? https://mesa-ci.01.org/mareko/builds/11/results/18181190
00:50 craftyguy: mareko: seems like it might be flaky
00:51 craftyguy: mareko: it's typically ~5min, sometimes more if the system is under load (e.g. more CI jobs finishing)
02:41 airlied: ickle: not sure if it was moving to 5.6-rc kernels or the latency fix, but my machines seems much happier, I'd almost request j4ni to add that cond resched to fixes
05:05 cheakoirccloud: Hello, I have two suggestions for improving development under Vulkan. I'm not sure where to post them.
05:07 cheakoirccloud: I spoke here previously about a SaftyNet Layer that would prevent if not illuminate crashes and lockups. For example not ending a command buffer or bindings for vertex buffers.
05:10 cheakoirccloud: Today I discovered that validation layers were not working on my project. I was told that this is common under other OSes. Nevertheless I believe that it would be important to add a feature where validation layers could be told to say hello so that I would be informed (by absence of these msgs) that I don't have validation.
05:11 cheakoirccloud: These issues should be seen as important enough to gather community support.
05:11 anholt_: the validation layer is open source, I would recommend going and working on it.
05:13 cheakoirccloud: Thanks, I just mit.
06:26 suprothunderbolt: not sure if this is the right channel but I'm attempting to work out how to give parameters to libinput so I can disable keyboard in an app but I can't find much about how libinput works...
07:39 j4ni: ickle: please let me know if you think the stuff airlied mentions should be backported to fixes, and which commits
07:42 j4ni: danvet: re "gitlab.fd.o financial situation and impact on services" - can we have a breakdown of which projects consume the most bandwidth? is it a wide issue, or an issue related to a few popular projects? or do we not want to point at specific projects?
07:48 danvet: j4ni, that breakdown is quite some serious amounts of scripting
07:49 danvet: the big chunk of traffic goes directly to cloud storage (bypassing gitlab frontend) for build artifacts and all that
07:55 bbrezillon: pinchartl: any input regarding the 'lvds-codec: data-mapping vs bus-width' discussion?
08:01 ickle: j4ni: deeee411a97559096523f97655ff16da34cf0573 is safe for fixes
13:00 imirkin_: airlied: what's missing from GL4.5 for llvmpipe? seems to be nearly done
13:07 FireBurn: Hi I'm currently seeing a build faulure in radv_device.c https://pastebin.com/wzafjzuA
13:10 FireBurn: Gentoo does the 32bit build first before doing the 64bit one, maybe this was missed on 32bit?
13:11 FireBurn: I'm guessing it was https://gitlab.freedesktop.org/mesa/mesa/-/commit/94099ee64296c60fdd5c3b237eedea0ff6651ea4
13:11 melissawen: agd5f_, I want to send a patch and I am using this repo https://cgit.freedesktop.org/~agd5f/linux . So, I would like to know what branch I should use for amd
13:14 imirkin_: hakzsam: see FireBurn's comment, looks like your commit
13:17 hakzsam: FireBurn: https://hastebin.com/raw/faruhetamo ?
13:21 hakzsam: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3996
13:21 hakzsam: should fix it
13:24 FireBurn: Testing now
13:27 kisak: is there a CI coverage issue there too?
13:27 FireBurn: I'm now seing a differnt failure https://pastebin.com/ba8J2VWN
13:28 hakzsam: kisak: CI apparently doesn't build radv for 32-bit systems
13:29 hakzsam: FireBurn: oh
13:29 FireBurn: There's lots of warnings too but might be not related
13:29 FireBurn: Let me see if I can pop the whole log somewhere
13:32 pinchartl: bbrezillon: hqven't looked at it yet I'm afraid. still in my inbox :-)
13:33 FireBurn: I've put the whole log into https://gitlab.freedesktop.org/mesa/mesa/issues/2578
13:33 gitbot: Mesa issue 2578 in mesa "Mesa build fails on 32 bit architecture" [Opened]
13:43 hakzsam: FireBurn: try https://hastebin.com/raw/exotereven ?
13:46 karolherbst: heh since when do we have reCAPTCHA on gitlab?
13:46 karolherbst: hakzsam: wouldn't be the proper fix to replace NULL by 0?
13:47 karolherbst: s/by/with/
13:47 hakzsam: VK_NULL_HANDLE is 0
13:47 FireBurn: Got a patch failure
13:47 karolherbst: hakzsam: but the error shows "NULL", no?
13:48 hakzsam: yes
13:48 karolherbst: could also be replaced by VK_NULL_HANDLE I guess
13:48 hakzsam: #define VK_NULL_HANDLE 0
13:48 karolherbst: hakzsam: maybe you shared the wrong patch then?
13:48 karolherbst: because your patch seems odd in relation to the build error
13:49 hakzsam: there is two build failures
13:49 karolherbst: ahh, ohhh.. now I get it
13:49 hakzsam: FireBurn: patch failure?
13:49 karolherbst: okay.. sorry for the noise then
13:49 hakzsam: np
13:49 FireBurn: It didn't apply, 3/3 failed
13:50 hakzsam: let me push that fix to the MR then
13:51 FireBurn: http://dpaste.com/17W3BNR
13:51 FireBurn: Is me doing it manually
13:52 hakzsam: does it build now?
13:53 FireBurn: Testing
13:53 karolherbst: ehhh.. upgraded llvm, now I get this: "1:10: fatal error: 'opencl-c.h' file not found" ... ufff
13:54 FireBurn: nope
13:55 hakzsam: FireBurn: logs?
13:55 karolherbst: pmoreau: we need a different solution here :/
13:56 karolherbst: essentially, if llvm gets updated from 9.0.0 to 9.0.1 clover breaks as CLANG_RESOURCE_DIR needs to change
13:57 karolherbst: ehhh
13:57 karolherbst: and meson doesn't update this value
14:00 FireBurn: The error is https://pastebin.com/S2dze8Zv
14:04 daniels: karolherbst: since the very beginning
14:05 karolherbst: yeah... but I think there is a flag to tell clang to just include the default CL stuff... I might take a look at this very annoying issue
14:34 hakzsam: FireBurn: please pull the previous MR, should work now
14:37 karolherbst: mhhhh
14:38 karolherbst: we need to change set_global_binding to have an array of uint64_t not uint32_t
14:39 karolherbst: but lucky that only clover uses this...
14:53 FireBurn: Trying now
16:17 FireBurn: Sorry was in a meeting, I replied back on the MR, works great ta, feel free to add my tested by
16:35 alyssa: Thinking ahead here, but - does anyone's hardware support "partial" vectorization?
16:36 alyssa: In particular, fp32 is scalar, but fp16 can do vec2? and int8 can do vec4?
16:36 alyssa: robclark: ^^ ISTR ir3 was like that maybe?
16:36 alyssa: and if so, what are people planning in terms of nir_lower_alu_to_scalar and nir_opt_vectorize?
16:37 robclark: alyssa: ir3 is scalar.. a2xx had this vec4+scalar co-dispatch thing
16:37 alyssa: Ah, maybe that's what I was confused by
16:38 pendingchaos: AMD (GCN/RDNA) hardware can do some vec2 fp16 but fp32 is scalar
16:38 alyssa: (Obviously mediump is a win for thread count/spilling, but potentially it's also 2x the ALU throughout on some hardware)
16:39 pendingchaos: and some int8 vec4 bitwise operations (and/or/etc) could be implemented using 32-bit operations
16:39 alyssa: pendingchaos: I think that latter one might be cheating ;)
16:42 pendingchaos: it also has some vec2 int16/uint16
16:42 alyssa: Yeah, that's the sort of thing I'm interested in
16:43 alyssa: Maybe lower_alu_scalar needs to support filtering so backends with weird lowering requirements (only these ops, or...) can make those decisions?
16:55 romangg: On AMD I am trying to put a cursor image on a cursor plane via atomic mode setting. Test commit succeeds but the image is scrambled. Kernel log says:
16:55 romangg: [drm:hubp1_get_cursor_pitch [amdgpu]] *ERROR* Invalid cursor pitch of 48. Only 64/128/256 is supported on DCN
16:56 romangg: Normally I would say the buffer I provided is broken. But shouldn't the test commit fail in this case?
17:00 MrCooper: romangg: I agree that it should; kazlaus hwentlan ^
17:01 kazlaus: yeah
17:02 kazlaus: i don't know why we don't have the checks for pitch in atomic check
17:02 kazlaus: hopefully no userspace relies on it being broken though
17:33 romangg: MrCooper, kazlaus: Looking at the dma-buf it's even weirder. The drmModeAddFB2 call for the cursor image has: width: 48 height: 48 handle: 6 stride: 256 offset: 0 format: DRM_FORMAT_ARGB8888
17:33 romangg: pitch 256, so why is it 48?
17:34 kazlaus: well we can crop within the buffer
17:34 kazlaus: to 48/48
17:34 kazlaus: or whatever it actually needs to be
17:34 kazlaus: the pitch is valid
17:34 kazlaus: the hardware only supports cursor with pitch 64, 128 or 256
17:35 kazlaus: so technically we should be validating the pitch, not dimensions
17:35 romangg: hmm, is this cropping then an optimization in the driver if the pitch > height that in the end leads to failed state although it shouldn't?
17:39 imirkin_: hardware tends to be picky about cursors
17:39 imirkin_: you can't have a 64-wide cursor with a pitch of 2048
17:39 imirkin_: (well, maybe on some how you can, but i don't think that'd be common)
17:40 imirkin_: sounds like not all restrictions are implemented in the check phase...
17:43 romangg: Or the restrictions are allright but what the driver later on does with the buffer is not. Because how I understood it now here the pitch (256) was generally compatible with the cursor as it was sent from user space and only after the driver did some cropping the buffer became invalid.
17:49 imirkin_: generally compatible ... but probably only if width is 64
17:56 romangg: ok, I will try to increase the size to that and see if it then works. although to always check what's the minimum pitch size in the driver and then blow a buffer up to that in case it's smaller seems wrong (and I don't know if it's possible in a generic way).
17:57 imirkin_: my guess is that only certain combinations work
17:57 imirkin_: i.e. tightly packed, width/height 64/128/256
19:48 airlied: imirkin_: not much, gpu_shader5 needs finishing, most other things are multisample related so hacks for those, and possibly implement some sort of mulitsample
19:55 imirkin_: oh yeah, MSAA... annoying.
19:55 imirkin_: fake it 'til you make it?
19:58 agd5f: melissawen, drm-next
20:05 airlied: imirkin_: it's faked enough, but for vulkan I'd kinda like to have it to pass CTS
20:05 imirkin_: and vk presumably requires it?
20:15 airlied: imirkin_: yes
21:01 mdnavare: vsyrjala: Looking at your review comments for the drm helper to get adaptive sync limits from vrr monitor: https://patchwork.freedesktop.org/series/68489/
21:01 mdnavare: vsyrjala: you suggested using for_each_detailed_block instead of for (i=0;i <4;i++), do you want me to create a new macro for parsing each detailed block?
21:57 mdnavare: vsyrjala: airlied: I need to define drm_edid_get_vrr_range() similar to where i call drm_for_each_detailed_block((u8 * )edid, get_vrr_range, &vrr_min, &vrr_max) but i need to access range = &data->data.range; where data = &timing->data.other_data; inside get_vrr_range() how can I access range? any thoughts?
22:42 ascent12: Is the page flip DRM event defined to happen on the first pixel out? i.e. before the hardware has necessarily finished scanning everything out.
22:46 vsyrjala: the event typically fires around start of vblank. the timestamp is supposed to correspond to the first active pixel of the next frame
22:51 ascent12: When is the vblank event defined to be sent then, compared to that?
22:59 vsyrjala: same time
23:00 ascent12: The timestamp, or the actual sending of the event?
23:00 vsyrjala: well, i guess some driver/hw might for whatever reason send them out at different times
23:00 vsyrjala: the time when the event is sent isn't really specified. depends on hw/driver
23:05 ascent12: Ok. I was wondering what the earliest possible moment to was safe to reuse a buffer, and directly after the page flip event seems too soon (tears on intel). Holding onto the buffer until the next page flip works fine, but I was just wondering if it was 100% necessary, but seems like it is.
23:32 vsyrjala: the buffer is no longer in use when the event fires
23:42 danvet: ascent12, also note that most drivers suck and dont give you a high-fidelity timestamp
23:42 danvet: most by number, all the big x86 gpu drivers don't suck :-)
23:48 ascent12: Hmm, I really need to take a close look at the precise timing when I'm committing, getting events, and releasing buffers.
23:48 ascent12: danvet: Yeah I'm heard that can cause issues with people trying to do low-latency stuff and do their atomic commits as late as possible.