01:43 Net147: What is the best way to get a callback in user space when DRM connector status changes (e.g. cable is plugged/unplugged)?
07:30 emersion: Net147: hotplug uevents
07:31 Net147: emerson: udev monitoring of card device?
07:33 emersion: yes
07:35 emersion: an ACTION=change uevent will be sent
07:35 emersion: with HOTPLUG=1 iirc
07:37 Net147: emersion: thanks
09:20 ishitatsuyuki: Is Vulkan pQueuePriorities respected by Mesa? I know that VK_EXT_global_priority is explcitly implemented but not sure about this one
13:45 EdB: karolherbst: It make it clear what are fixes and what are missing 1.2 implemetation
13:45 karolherbst: ahh, I see
13:45 EdB: and yeah, dimension checking is better that way
13:50 EdB: not sure about making it pure virtual. IMAGE 1D ARRAY / BUFFER should inherited from image class and they will report dimension 1
13:52 kisak: ishitatsuyuki: if I understand it correctly, you need to setcap CAP_SYS_NICE=eip on the executable to give it permission to use high priority queues with radv, don't know about anv
16:26 EdB: :/
16:26 EdB: there is bug at image creation
16:27 EdB: the buffer used seems to be the one from the previous call
18:09 karolherbst: EdB: are you using my set_shader_images patch or stock?
18:09 EdB: error with both
18:09 EdB: but I've find the problem
18:09 EdB: 2 more commit to come into my branch
18:10 EdB: at least
18:13 EdB: *found
18:26 karolherbst: EdB: btw, pushed the dimension change into my branch
18:27 karolherbst: ehh.. should drop the dop commit
18:30 EdB: I'm checking build and will oush the two other commit on my branch
18:32 EdB: done
18:33 karolherbst: ohh, cool
18:33 karolherbst: which test does the pitch one fix?
18:34 EdB: the clEnqueueFillImage piglit one
18:34 EdB: I'm testing if it improve CTS too
18:34 EdB: probably npt
18:38 karolherbst: okay, pushed them as well (with minor adjustments due to merge conflicts)
18:39 EdB: how sad, it didn't change the segfault I have on CTS
18:39 karolherbst: :/
18:39 karolherbst: probably something else then
18:39 EdB: yeah
18:39 EdB: it lok like a format thing
18:39 karolherbst: will try to fix inline samplers tomorrow and then look into remaining CTS problems
18:39 karolherbst: inline samplers are annoying as hell :/
18:40 EdB: :)
18:42 karolherbst: ohh.. and I should enable CL images for llvmpipe for CI testing :)
18:49 EdB: so it segfault after create_image (context=0x4a7e28, queue=0x4a3d88, data=..., imageInfo=0x7fffffffcf00, error=0x7fffffffc39c) at ../test_conformance/images/clFillImage/test_fill_generic.cpp:215
18:49 EdB: in __memcpy_ssse3 () from /lib64/libc.so.6
18:49 karolherbst: mhhh
18:50 karolherbst: which test?
18:50 EdB: so I gues a mapping is not working
18:50 EdB: memcpy( dst, src, imageInfo->width * get_pixel_size(imageInfo->format) );
18:51 karolherbst: maybe
18:51 EdB: I think that mesa and the CTS don't have the same data element size
18:51 karolherbst: uhhh
18:51 karolherbst: that would be annoying
18:52 karolherbst: but also very weird
18:52 karolherbst: what format is this about?
18:52 EdB: CL_R CL_SIGNED_INT16 according the last log
18:53 karolherbst: mhh, let's see if this also happens for me
18:53 EdB: hope it's the current, and not the prev
18:53 karolherbst: this is clFillImage, right?
18:53 EdB: yes
18:58 karolherbst: ehh.. I broke my build locally somewhere
18:58 EdB: ah, strange. it's CL_R CL_SIGNED_INT8 without gdb
18:59 EdB: and CL_R CL_SIGNED_INT16 with gdb
18:59 karolherbst: sounds like memory corruption
19:00 EdB: I've also got
19:00 EdB: Shader Stats: SGPRS: 32 VGPRS: 8 Code Size: 128 LDS: 0 Scratch: 0 Max Waves: 10 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
19:00 EdB: Shader Stats: SGPRS: 24 VGPRS: 8 Code Size: 96 LDS: 0 Scratch: 0 Max Waves: 10 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
19:00 EdB: and a
19:00 EdB: ERROR: Scanline 0 did not verify for image size 652,692,1 pitch 652 (extra 0 bytes)
19:00 karolherbst: mhh
19:00 karolherbst: mhhh
19:01 karolherbst: I think the blitter is not enabled for radeonsi if doing only compute
19:01 karolherbst: that might break that stuff
19:01 karolherbst: but maybe it also doesn't matter... dunno
19:01 karolherbst: I'd check with libasan or valgrind
19:02 EdB: I have "clover: Don't create a compute-only context if image support is enabled"
19:02 karolherbst: I see
19:02 EdB: I think that remove the compute only stuff
19:03 EdB: yeaj awarty msg is adeonsi doesn't create a blitter context if compute-only is specified.
19:03 EdB: so I hope that I have one :)
19:13 EdB: I would really like an icd loader that debug print each calls and args
19:18 karolherbst: I get the crash as well
19:18 karolherbst: ahh yeah..
19:18 karolherbst: dst is invalid memory
19:18 EdB: what Oo
19:18 karolherbst: mhhhh
19:18 karolherbst: dst += mappedSlicePad;
19:19 karolherbst: mappedSlicePad = 0x466470
19:19 karolherbst: so yeah..
19:19 karolherbst: the CTS loops with that and I see how it can run out of bounds real quick
19:19 EdB: I was looking here to
19:19 karolherbst: heh.. waht is the CTS doing...
19:19 EdB: but why does it does that
19:20 karolherbst: (BufferOwningPtr<char> &) @0x7fffffffbce0: {ptr = 0x4d2dd0, map = 0x0, mapsize = 0, allocsize = 451184, aligned = true}
19:20 karolherbst: that's the original pointer
19:20 karolherbst: so it is really small
19:20 karolherbst: ohhhh
19:20 karolherbst: I see :)
19:20 karolherbst: size_t mappedSlicePad = mappedSlice - (mappedRow * height)
19:20 karolherbst: mappedSlice = 4530192
19:20 karolherbst: mappedRow = 0xffffffffffffff88
19:21 karolherbst: :)
19:21 karolherbst: so this is just busted
19:21 karolherbst: mappedRow gets set from clEnqueueMapImage
19:21 karolherbst: it's the row_pitch arg
19:22 EdB: ah
19:22 karolherbst: and we never write to it :)
19:22 karolherbst: I probably won't do anything today besides some basic debugging :p wanna look into it? Otherwise I fix it tomorrow
19:22 karolherbst: "image_row_pitch returns the scan-line pitch in bytes for the mapped region. This must be a non-NULL value."
19:23 EdB: yeah I will have a llok
19:24 EdB: now that we are able to caclulate it :)
19:25 EdB: I think awarty also found the bug according the broken commit merge he add on his branch
19:25 karolherbst: heh
19:25 karolherbst: guess my MR does indeed cause no regressions: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4953902
19:25 karolherbst: a few fixes even
19:25 EdB: :)
19:27 EdB: I'm really no fan of the all into one commit "WIP: clover: clGetImageInfo CTS fixes"
19:27 karolherbst: yeah...
19:27 karolherbst: I guess we can split it up
19:28 karolherbst: but it already got a bit better
19:30 EdB: that why I make those commits on my branch :)
19:31 karolherbst: EdB: sure, but it misses attribution, so that's a bit messy then. I have no problem splitting up the original one, just need to be a bit careful on where to split it and not to forget setting the proper author :p
19:31 EdB: weel I do made those commit by my self based on my piglit test :p
19:32 karolherbst: you probably saw the original commit already though :p
19:32 EdB: run it till they do fails anymore
19:32 EdB: :p
19:32 EdB: sure
19:33 EdB: speacking of that it seems that clEnqueueMapImage was not correct enought
19:33 EdB: some time I have hard time to understand what shoulf be checks by reading the specs
19:35 karolherbst: yeah...
19:35 karolherbst: the spec is quite strict
19:36 karolherbst: but reading the error list is usually good enough to understand what error needs to be returned
19:37 EdB: that why I prefer to have piglit test here, because CTS just checks if it work and don't validate that the api call follow the specs
19:37 EdB: it didn't bother to valide that why correctly fill data back
19:38 EdB: *we
19:38 EdB: a crash is not really a check
19:41 karolherbst: EdB: pushed splitting up the commit :)
19:42 karolherbst: mhhh
19:42 karolherbst: I think the CTS has tests for it somewhere
19:42 karolherbst: yeah.. api
19:42 karolherbst: but it doesn't test everything
19:43 karolherbst: "ERROR: Reported max read image arg count is less than required! (32)" :/
19:43 karolherbst: what the... :(
19:43 karolherbst: ohh _read_
19:43 karolherbst: oh well
19:43 karolherbst: we need to report the texture count here, not images
19:46 EdB: ha I know why the piglit clEnqueueMapImage was bot working. I didn't finish at that time and now is is gone :D
19:46 EdB: It doesn't help to keep tinking about test when you don't have image support
19:46 EdB: :p
20:18 EdB: test still don't pass, but they don't carch anymore
20:19 EdB: nice copy image don't crash anymor
20:19 EdB: nice copy image don't crash anymore
20:24 EdB: karolherbst: fix available at the usale place
20:27 karolherbst: EdB: has_slice = img.slice_pitch();
20:27 karolherbst: mhh..
20:28 karolherbst: maybe something like this: size_t _slice_pitch = img.slice_pitch(); if (_slice_pitch && !slice_pitch) throw error(CL_INVALID_VALUE); *slice_pitch = _slice_pitch();
20:28 karolherbst: or...
20:29 karolherbst: if (img.slice_pitch() && !slice_pitch) throw error(CL_INVALID_VALUE); *slice_pitch = _slice_pitch();
20:29 karolherbst: mhh
20:29 karolherbst: I doubt the pitch can be 0 for those requiring to have one
20:29 EdB: you may have to put 0 if provided
20:29 karolherbst: yeah, which my code does
20:30 karolherbst: ohh wait...
20:30 karolherbst: no, the if has to be there
20:30 karolherbst: you are right
20:30 karolherbst: but we could make the has_slice thing a bit simplier.. but leaving it as is would also be fine
20:31 karolherbst: I just don't like that in C you have to do stuff like this like that :/
20:32 karolherbst: img.type() in { CL_MEM_OBJECT_IMAGE1D_ARRAY, CL_MEM_OBJECT_IMAGE2D_ARRAY, CL_MEM_OBJECT_IMAGE3D } would be so much cooler :D
20:32 EdB: yeah
20:33 karolherbst: or maybe we want to have a static bool image::type_has_slices(type...)
20:33 EdB: sometimes I find myself starting to writing C code like that because I also to SQL :)
20:33 EdB: *do
20:33 karolherbst: EdB: I was also thinking of making clover::image a template with two args
20:33 karolherbst: dimensions and cl_mem_object_type
20:34 karolherbst: would allow us to remove those virtual methods
20:35 karolherbst: and then we could do it like this: class image1d : image<1, CL_MEM_OBJECT_IMAGE1D> { ... };
20:35 EdB: indeed. Whould this still work with all the obj(cl_mem) checks
20:36 karolherbst: but we were also thinking about rewriting clover in rust :D no clue
20:36 karolherbst: EdB: no idea
20:36 karolherbst: main reason I don't try it out as I assume a lot of places break in some ways
20:36 EdB: ah that what the Rust ML meesage are for ;p
20:38 karolherbst: no, I think this was unrelated :p
20:39 karolherbst: we talked about clover in rust maybe 2 or 3 days ago?
20:40 EdB: on the IRC ?
20:40 karolherbst: but clover would be an ideal starting point. It's not as much code and most of the work is done in the compiler bits anyway, which is mostly done
20:40 karolherbst: yeah
20:40 karolherbst: anyway.. that's just the main reason I am a bit reluctant of refactoring stuff
20:41 EdB: clover is a nice piece of c++ :(
20:42 airlied: i doubt a rust version woild land before a cl 3.0 compliant clover
20:42 karolherbst: yeah, I doubt that as well
20:43 karolherbst: and maybe it makes sense to start with something which is under less development
20:43 karolherbst: like va or vdpau :p
20:43 airlied: so refactor away if it makes it less ugly
20:43 EdB: if we keep the same spped as for 1.2 there is plenty of time :D :D :D
20:43 karolherbst: well.....
20:43 karolherbst: 3.0 is already mostly done :p
20:43 karolherbst: airlied: or how much is missing?
20:44 airlied: karolherbst: only 2 bits I think
20:44 karolherbst: cool
20:44 airlied: maybe 3 need to look at clang a bit closer
20:44 karolherbst: EdB: CL 3.0 is really just an API cleanup than adding features
20:44 karolherbst: with CL 3.0 the default language is even CL 1.2
20:44 EdB: yeah I know
20:44 karolherbst: not 2.0 or even 3.0 :p
20:44 EdB: I was justr joking
20:44 karolherbst: ahh
20:44 karolherbst: airlied: cool
20:45 karolherbst: anyway, I think rust should be started by rewriting va and vdpau :p
20:45 karolherbst: not sure which frontends have even less changes
20:45 EdB: my plan was to do 3.0 once 1.2 was done since it's can be just the same with few api
20:45 EdB: few more
20:45 karolherbst: I think airlied was faster :p
20:46 EdB: I like to do in order
20:46 airlied: isnt 1.2 printf?
20:46 EdB: liek for the moment I restrain myself because printf doesn't land yet
20:46 karolherbst: yeah.. printf :/
20:46 karolherbst: is printf still required in 3.0?
20:46 airlied: yes
20:46 EdB: I have a working printf :D
20:47 karolherbst: uhh
20:47 airlied: i just didnt want any 3.0 surprises
20:47 karolherbst: they clean the API up and forget to remove the most annoying bit :p
20:47 EdB: I hope tstellar will land the libclc part soon
20:47 airlied: he went on oarental leave
20:47 EdB: I've heard
20:48 airlied: might need to bother other clc committer
20:48 airlied: maybe arsenm still has commit
20:48 EdB: for 8 weeks IIRW
20:48 airlied: EdB: is that amd only printf?
20:48 EdB: but that was weeks age :)
20:48 EdB: airlied: yes it's
20:49 airlied: need to respin my amd use nir patches
20:49 karolherbst: mhhhhh
20:49 airlied: ohwe also have il api to land
20:49 EdB: in that case I may be intersed to make it for nir :)
20:49 karolherbst: yeah, but that's mainly done
20:50 karolherbst: EdB: well, the idea of moving AMD over to nir would be to get rid of the entire llvm backend as well.. but not sure if we want to be that drastic
20:50 karolherbst: but it would make clover generic
20:50 airlied: yeah i just dislike long lived backlog :-p
20:50 karolherbst: and if it's the same for every driver I think that's generally a better plan
20:51 airlied: I think the llvm backend is better for real world big shaders
20:51 airlied: but NIR backend gives spirv
20:51 karolherbst: well.. we can translate back and forth
20:51 karolherbst: but yeah
20:51 karolherbst: this big shader issue is something we have to figure out
20:51 airlied: once we close up the ugly big shaders gaps I'd be happy to see llvm taken out
20:52 EdB: airlied: the libclc part is https://reviews.llvm.org/D84392
20:53 jenatali: karolherbst: What was left to do with the nir printf stuff?
20:54 airlied: for nir pr8ntf do we need and clc changes?
20:55 airlied: seems 0robably not
20:55 jenatali: airlied: No, dont't think so
20:55 karolherbst: jenatali: mostly somebody caring
20:55 jenatali: Unless we wanted to implement it in CL C instead of in nir
20:55 karolherbst: and I wanted the llvm printf stuff to land first so we have the common buffer infra in place
20:56 airlied: might take a look on llvmpipe, but i need to switch back to kernel hacking rhis week
20:56 karolherbst: yeah.. my monday doesn't look so pleasent either
20:56 karolherbst: regressions to take care of
20:56 jenatali: karolherbst, airlied: Just FYI I'm taking a 2 week vacation starting Tuesday, probably won't be on IRC but if need me for something you can ping me on email
20:57 EdB: you may need the liclc printf prototype that came with the patch
20:57 karolherbst: EdB: anyway, I'll try to take another look at your printf patches.. I just wanted to make luxmark3 run :D hence image support
20:57 karolherbst: also some annoying s390x issues :/
20:58 jenatali: EdB: For nir/spirv, Clover uses the LLVM opencl-c.h, not libclc's headers
20:59 FLHerne: Who uses Mesa on big mainframes, and why? :p
20:59 EdB: k
20:59 karolherbst: FLHerne: apparently some people like to use admin GUI apps
20:59 karolherbst: and then you need something to drive the desktop...
20:59 karolherbst: so llvmpipe
21:00 airlied: vnc gnome desktops on s390 ftw!
21:00 karolherbst: yeah..
21:00 karolherbst: airlied: 16 bit is broken :/
21:00 karolherbst: uhm
21:00 karolherbst: color depth
21:00 karolherbst: 24 works fine
21:00 airlied: surprised 16 bit works on le sometimes
21:00 karolherbst: :D
21:01 karolherbst: yeah.. but I guess with VNC you kind of prefer 16 bit
21:03 EdB: karolherbst: I change the code to do if (img.slice_pitch()
21:03 EdB: changed
21:04 karolherbst: cool
21:04 karolherbst: that looks better :)
21:05 karolherbst: airlied: what do I have to do to enable images with llvmpipe?
21:13 airlied: karolherbst: hopefully nothing but i doubt that
21:13 airlied: if you are using set image views now
21:14 karolherbst: I was more interesting in where I have to enable it :D
21:14 airlied: LP_CL=1 run a test tell me what it does
21:15 karolherbst: "Note: device does not support images. Skipping test..." :p
21:15 airlied: ah lp_screen.c
21:15 karolherbst: I have to enable PIPE_COMPUTE_CAP_IMAGES_SUPPORTED, but not sure where for llvmpipe
21:15 airlied: somewhere in there
21:15 karolherbst: ohhh
21:15 karolherbst: I totally missed that
21:16 karolherbst: how many images does llvmpipe support?
21:16 karolherbst: 32?
21:16 karolherbst: PIPE_MAX_SHADER_IMAGES?
21:17 karolherbst: let's see...
21:21 airlied: yeah I think 8 or 16
21:21 airlied: for GL
21:21 airlied: but not sure if compute uses same limit
21:22 karolherbst: well.. clover is a bit stupid here anyway :/ apparently 32 is too low for CL for read only images
21:22 karolherbst: and I think we have to report the texture limit there
21:22 airlied: yeah SAMPLER_VIEWS is different
21:22 karolherbst: ahh
21:22 airlied: I think sampler views is 128
21:23 imirkin: DX10 requires 128 sampler views and 16 samplers
21:24 airlied: ah yes I think it does 32 samplers + 128 sampler views
21:25 imirkin: DX11 might bump that requirement to 32 samplers, not 100% sure. in practice games targeting GL 4+ frequently require 32 textures (or at least more than 16).
21:25 jenatali: If D3D10 really was 16, then yeah D3D11 bumps it to 32
21:25 karolherbst: yeah.. we have a game which requires more than 64 even
21:25 karolherbst: really annoying for nine
21:25 imirkin: jenatali: well, i'm fairly sure the DX10 NVIDIA GPUs definitely only do 16 samplers :)
21:26 imirkin: and those were the definition of DX10 pretty much
21:27 jenatali: imirkin: Ah no, it's still only 16
21:28 jenatali: I was thinking of vertex buffers
21:28 imirkin: oh? i thought vertex buffers was 16.
21:28 imirkin: i'd have to recheck, but i thought that's all the hw supports...
21:28 imirkin: (even DX11/DX12 nvidia hw)
21:28 imirkin: hmmmm
21:29 imirkin: and to be clear, that's vec4 vertex inputs? hm
21:29 jenatali: No, not number of inputs, number of buffers
21:30 imirkin: oh yeah. just kidding. hw supports 32.
21:30 imirkin: all is well
21:30 jenatali: :)
21:33 anholt: MrCooper: know an easy way to figure out why apt is getting purged here? https://gitlab.freedesktop.org/anholt/mesa/-/jobs/4953591
22:02 robclark: danvet_: hmm, using obj->resv to replace msm_obj->lock is full of lockdep horror courtesy of mm->mmap_sem.. I've already re-organized submit path to move all the copy_from_user(), but now getting into fun 2nd order issues with other subsystem locks :-(
22:03 robclark: https://www.irccloud.com/pastebin/6OHqbuye/
22:04 danvet_: need the next backtrace
22:04 danvet_: the lockdep summary is nonsense once you have more than 2 locks involved
22:04 danvet_: so need to construct it yourself with all the backtraces :-/
22:05 robclark: there is no next backtrace.. but I know what the issue is.. just not how to solve it in a sane way..
22:06 robclark: possibly it is ignorable, since fault isn't going to race with probe ever..
22:08 robclark: oh, I guess you meant:
22:08 robclark: https://www.irccloud.com/pastebin/G1KaZqON/
22:08 robclark: (thought that was part of the first paste)
22:09 robclark: hmm, ok, I guess I can move a rpm get sooner, maybe that isn't so bad..
22:17 karolherbst: airlied: oh well.. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4954802
23:10 airlied: karolherbst: I might pull your branch later and take al ook
23:10 karolherbst: cool
23:46 danvet_: robclark, hm yeah this is annoying
23:46 danvet_: why does this only splat with dma_resv though?
23:48 airlied: karolherbst: https://gitlab.freedesktop.org/airlied/mesa/-/commit/2bae1ca879dc5825f53f114af92d2504a15827d1 fixes the first crashes :-P
23:48 airlied: I do get some more after that, and fails
23:49 robclark: danvet_: before consolidating msm_obj->lock and obj->resv locking, the other path didn't acquire obj->resv
23:49 karolherbst: airlied: heh...
23:49 airlied: not sure if clover's use of the API is correct :-P
23:50 robclark: danvet_: anyways, I have a fix for that which didn't turn out too bad.. worst upshot, at least for explicitly fenced userspace, is that in some error cases we could needlessly power up the gpu..