00:16airlied: if nir has 64-bit const load followed by a u2u32 do we have a pass that turns that into a 32-bit constant value?
00:18pendingchaos: constant folding?
00:20airlied: ah maybe it's not getting run at this point
00:22airlied: pendingchaos: that was it, thx
00:56karolherbst: mapping an image doesn't contain client side copied data
00:56karolherbst: the heck
00:59karolherbst: I found the error :/
01:01karolherbst: have to set image_slice_pitch in clEnqueueMapImage for array images :)
01:08karolherbst: now it's not coloum 0 failing :)
01:16karolherbst: ehh.. wait
01:26karolherbst: ./build/test_conformance/images/clFillImage/test_cl_fill_images 1Darray
01:26karolherbst: PASSED 37 of 37 sub-tests.
01:27karolherbst: uff.. I think I whacked clover enough for today :D
01:29karolherbst: EdB_: 1Darray and 2Darray are now wokring at runtime :)
02:11airlied: bleh always fall into vgpr vs sgpr problems playing with amdgpu :-(
02:12karolherbst: I am sure I got images right now, but luxmark still doesn't start drawing this one thing :/
02:12karolherbst: guess it's something else
02:13karolherbst: it also only uses 10 kernels...
02:15karolherbst: ehh, hey
02:15karolherbst: it does application cahing of kernels
02:20karolherbst: ehh heh
02:20karolherbst: the other benchmarks oomed my machine :D
02:21airlied: yeah inline everything might kill us :-P
02:21karolherbst: I guess so
02:21karolherbst: although I am still annoyed that the small benchmark doesn't work
02:22karolherbst: something fishy going on and I suspect that fixing random image issues is probably the past way forward
02:22karolherbst: but I already pass all of those... :/
02:23karolherbst: well.. most
02:23karolherbst: but the remaining fails I have are just filter related
02:23karolherbst: and the fails are really small :/
02:24karolherbst: maybe I should fix test_kernel_image_methods ... this could show more
02:24karolherbst: airlied: https://gist.githubusercontent.com/karolherbst/f46fc3c5de3552ec8a414eaacfcb5bdb/raw/83884740d0455b414c9d950f97de58c2deb177b4/gistfile1.txt
02:24karolherbst: samplerless reads fails..
02:25karolherbst: ahh.. clang
02:25karolherbst: "/usr/lib64/clang/10.0.1/include/opencl-c.h:14326:23: note: candidate function not viable: requires 3 arguments, but 2 were provided" :)
02:25karolherbst: test_kernel_image_methods it is then...
02:25karolherbst: but that's for tomorrow
02:28airlied: image_deref_format is the stuff I talked to jekstand about lat night
02:28airlied: unlikely to be that
02:28airlied: I've hacked llvmpipe support for that up, but clover should probably just lower it all to side-band constants
04:19airlied: karolherbst, jekstrand : it's a bit messy, but the amd llvm backend seem to be averse to ptr math using normal adds
04:19airlied: I think it really wants to use llvms GEP stuff
05:12airlied: oh finally got a simple kernel to build
05:13airlied: mripard: are you on d-m-n-f? can you get me one if you are
05:19airlied: okay got a gpu hang, so at least something is happening :-P
05:25sumits: sravn: I can see no new comments on https://patchwork.kernel.org/project/dri-devel/list/?series=341993, could you please merge it? or if you're busy, I'm happy to merge.
06:39mripard: airlied: dmnf?
06:54mripard: airlied: I'm on it, you should have it in a few minutes
06:54airlied: mripard: cool, once I have it for tmrw should be fine, want to send Linus drm-next if I can and want the ingenic fix
07:58AndrewR: I applied few more patches on top of llvmpipe-cl-img-wip ("clover: add a constant fold pass" and "inline sampler WIP") and removed asser in cl lowering pass, now ffmpeg says: https://pastebin.com/ZX6hLsY2 ("Failed to finish command queue: -14")
08:39AndrewR: Huh: https://unibap.com/en/support/ode-support/ode-spacecloud-os-v1-0-1-release-notes/ - found this while looking for libclc printf patch :}
11:09danvet_: pcercuei, have you replied to sfr that ingenic should be good again?
11:10pcercuei: No. Will do
14:34jekstrand: airlied: Yeah, you likely want to avoid clover's lowering entirely for radeonsi
14:35jekstrand: karolherbst: How do you manage to work later than me? It's kind-of disturbing. :)
14:35karolherbst: you don't want to know when I am waking up
14:36karolherbst: let's say my work schedule is more akin to early US workers than late EU workers
14:36karolherbst: and my day usualy starts around 1 or 2pm or so
14:36karolherbst: and doing big breaks :p
14:38karolherbst: jekstrand: also, our covid situation is now worse than yours, and we go into full lockdown again :p
14:38karolherbst: so there isn't much else to do right now
14:38karolherbst: anyway, images yay :p
14:39jekstrand: Some states in the US are balooning again but not Texas, at least not yet.
14:39pmoreau: karolherbst and EdB_ There are a couple of MR against the OpenCL-CTS that are fixing image tests, which could interest you: 1014, 1015, and 1016.
14:39karolherbst: pmoreau: maybe, but most of the issues I am hitting are clvoer issues
14:39karolherbst: ohh samplerless
14:39karolherbst: yeah, that could be interesting
14:40karolherbst: ehh flags
14:40jekstrand: samplerless? Flags?
14:40karolherbst: smaplerless reads, yeah
14:40karolherbst: some CL 2.0 feature
14:41karolherbst: maybe even 1.2
14:41karolherbst: yeah.. 1.2
14:42karolherbst: the 2.0 ones are for read_write images
14:42pmoreau: jekstrand: The CTS was messing up the creation flags a bit, like creating with WRITE_ONLY but using with READ_ONLY AFAICT.
14:42karolherbst: pmoreau: but for the samplerless tests we fail compiling the kernels
14:43karolherbst: I guess that's because I use a 1.1 context
14:43pmoreau: (for images)
14:43karolherbst: anyway, test_kernel_image_methods is the next test I want to fix
14:43karolherbst: this one needs image_deref_format
14:44pmoreau: Ah, if you don’t make it pass the compilation, I can see why those MRs wouldn’t be as useful for now. :-D
14:44karolherbst: pmoreau: well, I pass the other stuff
14:44karolherbst: but yeah...
14:44karolherbst: my hope is that test_kernel_image_methods will show bugs hit by luxmark
14:57jekstrand: pmoreau: Ah
17:00bshah: Hello, how do I figure out if device is kms capable node or just render node from API?
17:04lynxeye: bshah: A real render node is always /dev/dri/renderDsomething. If you want to test if the card node has display resources or is just a GPU only node you look for mode resource with DRM_IOCTL_MODE_GETRESOURCES
17:04lynxeye: If you get mode resources it's a KMS capable node, otherwise just a GPU node
17:04bshah: okay, that makes sense, and yes I wanted to check KMS capability of card node
17:57mareko: robclark: hi, can you please have a look at this freedreno failure when you have time? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4985693
18:00robclark: krh: don't suppose you have time to look at ^^^ ?
18:03krh: Maybe next week
18:03krh: What broke it?
18:03robclark: looks like !6950
18:06robclark: anyways, if you won't have a chance until next week, I'll probably get to it first.. looks like it is all Pass->Crash so probably something simple.. just not sure if I'll find time today
18:59karolherbst: jekstrand: soo.. I think I understood what clover does for image_formats. It inserts an image_format argument right after the image it belongs to and I was thinking on how to deal with it. Do we want to add arguments on demand? or should we just always add those format args as they really only take a way some uniform space
19:07AndrewR: robclark, sorry for insisting - but do you have this radeon.xml file mentioned in https://github.com/freedreno/freedreno/blob/fwdump/util/fwdump.c ? (not like I can do much with it, but closed fw for Radeons was issue for some folks for quite long time, and I was positively surprized you partially reversed it ....
19:09robclark: AndrewR: not sure if I ever checked it in yet.. but it was just pm4 packet-id's from the open src r600 code (since I noticed that the r600 firmware was fairly similar to the pre a5xx fw instruction sets)..
19:09jekstrand: karolherbst: I think we could probably add them on-demand.
19:09jekstrand: karolherbst: But I don't know that I care all that much
19:10karolherbst: jekstrand: right.. I am more worried about how to insert things into the list, but I guess we can just adjust the list directly and skip using the helpers
19:10airlied: I doubt they are on top of the most used features list
19:10karolherbst: mostly worried about ordering here
19:10karolherbst: airlied: right... but interesting CTS test depend on it :/
19:11airlied: I should try the cts test on my llvmpipe branch
19:11karolherbst: something is still fishy with luxmark, and I have no idea what exactly :D
19:11airlied: though I'm going to try and get radeonsi to submit a kernel without dying
19:11karolherbst: maybe I should just dump all kernels
19:12karolherbst: airlied: btw, mind adding the llvmpipe image fixes somewhere?
19:12karolherbst: maybe push them onto my image branch?
19:12karolherbst: I think stuff generally works now, it's just image_format which I think is missing...
19:13karolherbst: kernel_read_write/test_image_streams shows some value issues though.. should figure out what that is causing as well
19:13AndrewR: karolherbst, did you tried ffmeg's opencl filters?
19:13karolherbst: not yet
19:13karolherbst: I only tried luxmark
19:14AndrewR: robclark, unfortunately I can't recreate even simplest steps of your work :/ (I compiled program itself, but here my competence ends ...)
19:15AndrewR: karolherbst, considering my firnd introduced me to this whole class of renderers this year - I think Luxmark/Luxrender actually very good target :} (biased-biased me)
19:16karolherbst: yeah.. luxmark triggeres interesting issues
19:16karolherbst: and it's a common opencl benchmark as well
19:19airlied: karolherbst: pushed to your branch, though I expect we want to drop a few of then
19:19airlied: once you lower format + order generically
19:19airlied: the nir changes shouldn't be needed anymore once that is done
19:19robclark: AndrewR: the pfp and me instruction sets were not very fully reversed, I only got to the point of knowing which parts of the fw handled what pm4 packets.. and it only really matched r600, earlier radeons had something different and later radeons, it looked like the instruction sets changed again.. so I'm not sure there is anything terribly useful there
19:20karolherbst: airlied: yeah... order and format is what I plan to handle inside clover through kernel args
19:20karolherbst: so I'll drop those
19:22AndrewR: robclark, may be someone will pick up your work (considering how not many devs are working on hard areas of graphcis this is unlkey, but at least lima resurfaced!)
19:22karolherbst: airlied: was more interested in those "make image work at all" patches ;)
19:24jekstrand: karolherbst: As long as you're just moving stuff around in the list, you don't need to worry about the helpers.
19:25karolherbst: jekstrand: well, I need to add a format vec2 arg for each image
19:25karolherbst: although it's really more just 2 32 bit args
19:25airlied: you could put order + format into one 32-bit
19:26karolherbst: yeah.. but clover core des vec2
19:26karolherbst: uhh, wait
19:27karolherbst: it's the same stupid stuff like offsets
19:27jekstrand: Yeah, clover already has the plumbing for a vec2
19:27karolherbst: one arg, but multiple values bound
19:27jekstrand: karolherbst: Yeah....
19:27karolherbst: anyway, not that hard to just reuse it
19:27karolherbst: just need to be careful when adding stuff
19:28karolherbst: image_size is a vec3, but we kind of handle that already somehow, no?
19:28karolherbst: wondering why I never hit that
19:30jekstrand: Yeah, no need to use the image size one
19:45airlied: jekstrand: you mispell subgroups the first time you use it
19:45airlied: oh rather where you define it
19:47jekstrand: airlied: Fixed
19:48jekstrand: Surprisingly, the firefox spell check did catch that....
19:52karolherbst: airlied: mhh :/ I still get tons of crashes with llvmpipe
19:52karolherbst: copy_images eg
19:53karolherbst: hitting this one: assert(layer < (u_minify(resource->depth0, level) + resource->array_size - 1));
19:53karolherbst: in llvmpipe_resource_map
19:53karolherbst: depth is 1, all others are 0
19:53airlied: karolherbst: yeah I should probably do smoe cts tets
19:53karolherbst: well.. it can also mean that clover is using the gallium API wrongly :p
19:53karolherbst: just want to know what llvmpipe expects
19:53karolherbst: array_size 1 for non array images?
19:53karolherbst: no idea ;)
19:54airlied: what is layer getting set to?
19:54airlied: yeah array_size = 1 is expected
19:54karolherbst: okay, cool
19:58karolherbst: although I think I set it to 1... ohh wait
19:58karolherbst: k.. found it
19:58karolherbst: std::max is also super useless
19:59karolherbst: "ERROR: Unable to malloc 7824 bytes for generate_random_image_data" :(
19:59karolherbst: why though
19:59karolherbst: I still have memory
20:16airlied: okay have radeonsi executing now
20:17airlied:needs to get his laptop running with all 3 gpus and llvmpipe now :-P
20:21HdkR: PowerVR since they announced new desktop GPUs are in the pipe today
20:22airlied: yeah I want to plug in an egpu amd into a laptop with intel and nvidia in it
20:22airlied: I suppose I could build an intel/amdgpu/nvidia machine with a DG1 in it now
20:22airlied: if I have 3 PCIE slots
20:23HdkR: You could also use a thunderbolt card with a dual eGPU setup
20:23HdkR: https://www.amazon.com/gp/product/B07FB9QBT7 Has some PLX chip in it to give you dual slots :D
20:24airlied:wonders if running opencl cts on 4 impls at once would be interesting :-P
20:24HdkR: `PCI Express 3.0 compliant interface with 2 lanes per slot` oh no, must have been a different one that used a PLX chip
21:46alyssa: igalia folk: congratulations on the v3dv merge! 🎉
21:47jekstrand:does a happy dance
21:52anholt: so glad it's finally in!
21:53anholt: now they just need to make their ci public :)
21:55jekstrand: And submit conformance. :D
22:12dcbaker[m]: pendingchaos: I had to do a bit of massaging to one of your patches, "sprive: replace discard with demote..." could you look at it and make sure it looks good?
22:18pendingchaos: dcbaker[m]: the vtn_fail change wasn't part of the original patch, but otherwise I think it looks fine
22:19dcbaker[m]: okay, the biggest thing I noticed is that stable doesn't have the ability to compile spriv to a library, I'll back the vtn_fail change out
22:30dcbaker[m]: pendingchaos: fixed now
23:35robclark: if that doesn't ring a bell, I can dig in a bit more.. I didn't have time yet to read your MR
23:37robclark: anholt, bnieuwenhuizen: btw, it would be a cute trick if we could somehow capture stack backtrace for crashes in CI (or like maybe the first crash)
23:55karolherbst: airlied: I think we can't export RGB formats
23:55karolherbst: or maybe the CTS is just broken there
23:56karolherbst: it's fascinating though :D
23:59airlied: karolherbst: RGB or RGBx?