01:10agrisis: I want to do some development on the rockchip drm driver to see if I can leverage hw scaling within the driver itself. Regarding development workflow, would it be prudent to compile it as a module so I can continually rmmod / modprobe it without needing to install a new kernel?
01:11agrisis: or may that not necessarily work and I will need to recompile the kernel each time?
08:26danvet_: narmstrong, I think gut feeling says good call on the kmb dsi driver
08:26danvet_: the host side doesn't look like any other
08:26danvet_: I have no real clue about this, but I suspect that once it looks like a proper dsi host driver
08:26danvet_: it might just be one of those we have already :-)
10:18MrCooper: airlied anholt: instead of git cherry-pick, how about putting the patches somewhere under mesa/.gitlab-ci/*/ and applying them from there?
10:27narmstrong: danvet_: yeah but physically it’s separate ips, so they should have their own DT node and their relationship should be explicit (ports, syscon, ...), after whatever does the driver is another issue
10:35danvet_: narmstrong, I'm concurring
10:35danvet_: I looked at the dis host driver
10:35danvet_: and it seems to be kludged together without clear abstraction
10:35danvet_: more fighting the abstraction we have already
10:35danvet_: so your dt comment looks more like canary in the coal mine
11:15EdB: karolherbst: hello
11:15EdB: so how is your nex image branch ?
11:15karolherbst: EdB: works for me for some stuff, want to investigate why other image stuff fails
11:15karolherbst: but overall it seems to work
11:16EdB: to you want me to give it a try ?
11:16EdB: how do you test it ?
11:16karolherbst: the CTS has a ew image tsts
11:17karolherbst: clGetInfo should just pass
11:17karolherbst: the others have more or less random issues
11:17karolherbst: but 2D stuff should work everywhere
11:17EdB: what's the branch name ?
11:20EdB: clover upstream
11:20karolherbst: EdB: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7069
11:20karolherbst: I pulled in all the other patches as well for better support :D
11:20karolherbst: but those are mainly enabling features
11:21karolherbst: "WIP: clover: clGetImageInfo CTS fixes" is the main one to make the API validation happy, but also not really any functional change
11:22EdB: karolherbst: you probably don't push it
11:26karolherbst: ohh, it's all on my branch
11:31EdB: sorry was was only looking at your commit
11:31EdB: didn't saw it was aaron one
11:38EdB: I think I will give it a try with just the bare minimum use few commits to see how it work based on upstream on my computer
12:03EdB: sad, according phoronix what I started five years ago on my sparce time is only here thanks to Redhat and Microsoft :/
12:18karolherbst: EdB: yeah well... that's usually how it goes. No different with radeonsi
12:18karolherbst: or nouveau
12:24EdB: mh :/ apparently my card doesn't even advertised a simple 2D format support
12:25EdB: First, I will write a test piglit test for clGetSupportedImageFormats
12:25karolherbst: EdB: it should though.. maybe you need some other patches
12:25karolherbst: "clover: Fix incorrect error check in clGetSupportedImageFormats " is critical
12:25EdB: got this one
12:26karolherbst: EdB: did you enable images in the driver?
12:26EdB: yep, I update si_get to have image support
12:26EdB: then I /home/edb/projects/mesa-opencl/piglit-git/bin/cl-api-get-image-info
12:27EdB: It whould have skip if no image support was found
12:27karolherbst: I see
12:27karolherbst: yeah.. no idea then. With all the patches at least the clGetImageInfo thing just works here
12:27karolherbst: but maybe there is more to do
12:27EdB: here is failled with "Unexpected CL error: CL_IMAGE_FORMAT_NOT_SUPPORTED -10" when an image is created as CL_MEM_OBJECT_IMAGE2D
12:28EdB: that should be a base image format :)
12:28karolherbst: odd :D
12:28karolherbst: but maybe there is some more clover only stuff in gallium
12:29EdB: test_conformance/images/clGetInfo/test_cl_get_info also failled miserably :)
12:30karolherbst: what does it complain about though? that you get NOT_SUPPORTED?
12:30karolherbst: maybe you should just gdb and see what goes wrong
12:31EdB: probably here is_format_supported
12:32EdB: if I remeber well aaron also had some stuff for the context to be more than PIPE_COMPUTE and another flag
12:33EdB: let's keep it on a side of my brain and start digging :)
12:37karolherbst: ohh, right
12:37karolherbst: there were some radeon specific patches as well
12:37karolherbst: I just left them out
12:37karolherbst: like the blitter not being there and stuff
12:37karolherbst: I suspect you will require some of them
12:38karolherbst: EdB: what's the biggest unknown to me is how the image stuff works on an llvm level. In nir we just add a constant index or indirect from in shader constants in the shader, so we don't have to pass anything in via the kernel args
12:39karolherbst: would like to know what llvm expects from clover here
12:40karolherbst: also the changes from the resources array to a new one will change indicies as now constant and images can have the same index.. but I guess all this set_compute_resources thing should get removed anyway..
12:40EdB: for llvm, there is implict harg add
12:40karolherbst: yeah, I saw that some args were added
12:40karolherbst: but I don't know what they should contain
12:40karolherbst: an index? or something else?
12:41karolherbst: anyway.. I kind of hope that using pipe_image_view just works for r600 and radeonsi
12:41EdB: some scalr arg for image
12:41karolherbst: and then we can use pipe_const_buffer and get rid of set_compute_resources :)
12:42EdB: and some sampler index I think in case of sapmler
12:42karolherbst: indicies are fine
12:42karolherbst: EdB: one thing I still have to work out are inline samplers
12:42karolherbst: but clover isn't prepared for that at all as it seems
12:42EdB: not sure btw
12:42karolherbst: do you know if there is some llvm magic for it?
12:42karolherbst: but can't be, because you have to pull them out of the kernel
12:43karolherbst: maybe r600 handles it somehow?
12:43karolherbst: no clue
12:43EdB: I did look at it but it was a lng time ago
12:44EdB: image without sampler could be easier
12:44karolherbst: I don't think that works though
12:44karolherbst: I got some compiler issues
12:44karolherbst: overloads not there and stuff
12:44karolherbst: guess it's some CL 2.0 stuff or so
12:45karolherbst: uhm.. for image reads I think?
12:45EdB: I really didn't push that far
12:46karolherbst: me neither, I just saw a CTS test hitting it
12:46EdB: but since it work for AMD ROC, there should be a way :)
12:46EdB: the llvm part is the same
12:46karolherbst: but clang might disable overloads for CL 1.1 or 1.2
12:47karolherbst: cl_khr_gl_msaa_sharing mhhh
12:47karolherbst: ahh no
12:47karolherbst: CL 1.2
12:48karolherbst: and read_write is CL 2.0.. okay
12:48karolherbst: oh well
12:48karolherbst: there is still a lot of to do :D
12:49karolherbst: cl_khr_depth_images also sounds interesting
12:49karolherbst: cl_khr_mipmap_image as well
12:53EdB: yeah things to keep us busy :)
13:10EdB: so my usage is PIPE_BIND_SAMPLER_VIEW|PIPE_BIND_COMPUTE_RESOURCE
13:13EdB: yeah, I need https://gitlab.freedesktop.org/awatry/mesa/-/commit/c76d2778909e900427ef545c092ce6a298fe516f
13:13EdB: WIP: radeonsi: Add PIPE_BIND_COMPUTE_RESOURCE to supported usage checks
13:16EdB: ah, it's better :)
13:17EdB: the test failled a bit latter now
13:28EdB: ok, clGetImageInfo pass now
13:29EdB: let's try further
13:34EdB: hu, test_conformance/images/clFillImage/test_cl_fill_images crash here __memcpy_ssse3 () from /lib64/libc.so.6
13:42EdB: I really dislike CTS suite for not having a uniform way to get test program option
13:43karolherbst: they should port it over to deqp :p
13:47EdB: test_cl_read_write_images 2D gives FAILED 14 of 152 sub-tests.
13:48EdB: it's a good start
13:48EdB: it's only FAILED 2 of 152 sub-tests. with small image option
13:56EdB: well, every test that involve a kernel failled
14:27karolherbst: I suppose something on the clover <-> llvm interaction fails then
14:28karolherbst: EdB: does it work if you revert my patch to use pipe_image_view?
14:28EdB: didn't test yet, but all of the error are LLVM related
14:28EdB: so that not what is triggering an error at that time
14:30EdB: I'm making a branch without your change but with basic image support before going to investigate on LLVM
14:30EdB: I want basic api support for a start
14:30EdB: then I will play with compiler side
14:53mmenzyns: karolherbst: If a motherboard has a general purpose pcie 4.0 x16 branch. This branch either goes: into primary pcie x16 port, or it splits up into x8 primary pcie slot and two x4 m.2 slots. Can be the x8 pcie's version of primary slot affected by those m.2 ports? Meaning: There is a pcie 4.0 graphics cards connected, and a pcie 3.0 ssd. Does the GPU still run on 4.0? I am convinced I know the answer, but I need someone to confirm or
14:53mmenzyns: deny it.
14:54karolherbst: mmenzyns: the version shouldn't be affected by it. It just depends what all devices can do
14:54karolherbst: if the GPU can only do 3.0 it stays at 3.0
14:55karolherbst: slots are distribution across devices though, but you also have multiple controllers (like on the CPU and motherboard)
14:55karolherbst: so it usually depends on the system on what happens
14:55karolherbst: but usually the real physical slots get their lanes from the CPU and on board devices from the motherboard
14:56karolherbst: not sure where m.2 ssds get their lanes from
14:56karolherbst: I guess someone would only know for real after trying it out
15:00mmenzyns: The motherboard in question is a B550 Aorus Master. It should have two branches connected into CPU. A 16x general branch I described, and there is also a dedicated 4x branch for a third m.2 (it has three m.2). Then there are two pcie 3.0 4x connected into chipset.
15:03karolherbst: ahh yeah
15:03karolherbst: I am not sure if for 4.0 all devices have to support it though
15:03karolherbst: but with v2 vs v3 it also didn't matter
15:04karolherbst: just devices being "v2" could be driven in v3 mode, just with the 5.0 speed
15:04karolherbst: or there is no such thing as a "v3" mode
15:04karolherbst: but again, no idea how that is with v3
15:11mmenzyns: Well, the question was about if the v4 gpu would get affected (except of course it getting only half of the lanes) by ssd's lower version, or not.
15:12karolherbst: mhh, no idea. I know that with v2 and v3 it didn't make a difference, but it could have changed with v4
15:17mmenzyns: Alright, thanks
21:22EdB: karolherbst: I have this branch as a base for images fixes https://gitlab.freedesktop.org/edb/mesa/-/commits/clover/misc_images_support_fixes
21:26karolherbst: EdB_: sure.. but wouldn't you have gotten more or less the same if you just picked the other patches? well.. I guess besides the blacklisting of image types
21:27karolherbst: the image dimension stuff is slightly better your way though, so I probably just adjust that and add a v2 while mentioning it comes from you
21:28karolherbst: although we really should just make it pure virtual
21:28karolherbst: but no idea why you even bother with doing that from scratch