00:13alanc: robclark: I think that just means the CNA who assigned the CVE hasn't marked it as ready for publication yet
00:16robclark: alanc: that sounds like incentive to not fix the associated gitlab issues :-P
04:27robclark: alanc: disregard my last statement... even if they remain embargoed nonsense forever distros still see them.. but maybe we need some clear doc (either in drm kernel docs or mesa) about security boundaries and how UMD isn't one (see https://docs.vulkan.org/guide/latest/validation_overview.html#_undefined_behavior ... but also that is just making explicit for vk what is implicit for legacy APIs, ie gl/es, etc)... that would at
04:27robclark: least give us something to copy/paste link to to argue against nonsense CVE's rather than have to spend time...
18:36DavidHeidelberg: karolherbst: around? I'm trying to use cl.clCreateImage2D in tinygrad which supposedly should work, but on both freedreno and iris it fails with -40 (cannot allocate). I looked at gallium properties and rust code and it looks like it should work, but somehow it doesn't
18:43karolherbst: DavidHeidelberg: -40 as the CL error code?
18:43karolherbst: -40 is CL_INVALID_IMAGE_SIZE
18:44karolherbst: usually means that the image is bigger than supported by the hardware
18:44karolherbst: is checked inside `validate_image_desc`
18:50DavidHeidelberg: yeah, but both iris and fd has max caps (at least it seems to me (16384)
18:52DavidHeidelberg: 1st alloc: 12565x6
18:52DavidHeidelberg: 2nd: 50260x192
18:52DavidHeidelberg: 3rd: 50260x192
18:55karolherbst: DavidHeidelberg: all fail?
18:55karolherbst: ehh
18:55karolherbst: 2nd and 3rd should fail
18:55DavidHeidelberg: I assume just the 3rd fails
18:56karolherbst: yeah, that's not supported by the drivers
18:56DavidHeidelberg: the status is read afterwards, so...
18:57karolherbst: yeah.. looks like rusticl behaves correctly here then, need to split the image on the application side
18:57karolherbst: or just use a raw buffer
19:00tnt: or use 12565 x 768 . I guess the GPU uses tiling for better caching when using images vs buffer and you might want to keep that behavior.
19:01DavidHeidelberg: got suggestion on Adreno there is more efficient to use 2dimage because of cache
19:01DavidHeidelberg: *faster cache for it
19:01karolherbst: yeah... makes sense
19:01karolherbst: then you kinda have to split the image if you need images as huge as those
19:02karolherbst: could also use a 2darray thing and slice it :D
19:36DavidHeidelberg: karolherbst: btw. 16x16k limit seems to apply only on 2d mipmapped textures
19:36karolherbst: mhhh
19:36DavidHeidelberg: for nvidia is possible 65x65k, haven't found data for intel yet
19:36karolherbst: yeah.. that seems plausible
19:37karolherbst: if you can ignore MSAA and mimpas you can often bumb the limits
19:37karolherbst: we just don't have the interfaces in place in gallium to report that
19:39DavidHeidelberg: u say "new pipe cap to the moon"? :D I heard people love caps
19:42karolherbst: yeah....
19:42karolherbst: at least we still have that one MR to clean up compute caps, but I need to pick that up
19:43karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23870
19:43karolherbst: or maybe we want to have a special query for texture stuff...
19:43karolherbst: the current interfaces aren't great
19:43DavidHeidelberg: AMD should have also 65x65 https://forums.bit-tech.net/index.php?threads/gpus-with-high-max-texture-sizes-to-enable-more-256x-512x-textures-in-minecraft.280478/
19:44karolherbst: the thing is...
19:44karolherbst: gallium uses 16 bit in a couple of places, so I'm not quite sure we won't run into weirdo issues as some of the values are signed
19:44karolherbst: so we might get to 32x32 easily, but 64x64 might be difficult
19:50DavidHeidelberg: hmm, well, if we get closer to the usefulness of proprietary drivers, why not. I'll just do quick test on freedreno if it'll pass the texture..
19:59karolherbst: yeah.. the question is if we need new caps or not
19:59karolherbst: but I susepct we will
20:01DavidHeidelberg: the regular textures keep the same limit.. so, me too
20:04jenatali: IIRC you run into issues sampling at that resolution too, not enough bits for subpixel precision or something like that
20:06karolherbst: some drivers just scale internally to support sampled images
20:07karolherbst: (well.. the ISA might also have restrictions there)
20:11jenatali: I know the D3D spec says texture coords go to 16.8 fixed point, so if the size is greater than 16 bit that has to change and you lose subtexel precision
20:58tnt: i915 0000:00:02.0: drm_WARN_ON(new_crtc_state->do_async_flip && !plane->async_flip)
20:58tnt: Should I worry ?
21:03emersion: sounds like a bug
21:05tnt: yeah, although I'm realizing my kernel isn't all that recent so I should update first before dragging anyone into it :)
21:29DavidHeidelberg: karolherbst: btw. 65535x65535 passed on freedreno, sadly the code fails later (unrelated to the problem, but not fixed yet). At least the creation worked.
21:30karolherbst: DavidHeidelberg: the issue is that pipe_box is all signed :)
21:31karolherbst: and I'm sure people will complain changing that to unsigned or bumping to 32 bit because overhead on the GL side
21:31karolherbst: so I'd rather make 32x32 work for now unless there are _strong_ reasons to bump it and go through all the work of making everybody happy here
21:32karolherbst: there are also 32 bit limits on buffer sizes which is a more urgent issue and will probably also require some of that
21:33DavidHeidelberg: right, the pipe_box making it clean it won't work :D
21:44tnt: Does glsl has some function to check if a condition is true in any thread of a workgroup ? Something like anyInvocationARB but that works for the whole workgroup ?
21:45DavidHeidelberg: karolherbst: but.. but... "x and width are used by buffers, so they need the full 32-bit range."
21:46karolherbst: mhhhhh..
21:46karolherbst: I wonder if we could expose 64x32....
21:46DavidHeidelberg: yup :D
21:47DavidHeidelberg: imho this would cover a lot, because still full 64x64k takes lot of VRAM even these days
21:47karolherbst: yeah..
21:48karolherbst: I guess freedreno has to report 16x16 for gl stilll, because MSAA and mipmaps?
21:48DavidHeidelberg: sure, I think that apply for everyone in general
21:48DavidHeidelberg: btw. my hack maybe will work, because it's "50260x192" texture
21:52DavidHeidelberg: we could add pipe cap which will be used for CL and then for height just rusticl would MIN(32768,val)
21:52DavidHeidelberg: would report
21:53karolherbst: why does it need to be 50260x192 anyway?
21:53DavidHeidelberg: I have totally no idea, I tried to read tinygrad code, but I would have to spend much more time to understand it
21:54karolherbst: yeah.. it's not the best project...
21:54karolherbst: and not even fast
21:54DavidHeidelberg: imho it's good that it works relatively good with Mesa, on other hand, the hunt after getting low number of lines.. leads to very condensed code
21:54karolherbst: yeah.. it's silly
21:55karolherbst: I should fix those openvino bugs, but they are bugs in openvino.. :D
21:55karolherbst: DavidHeidelberg: anything clblast based should also work btw
21:55karolherbst: and that's actually fast
21:56karolherbst: llama.cpp and whisper.cpp should just work (tm). I've tried the latter already. So if you can get the same thing done with something clblast based, I'd just use that
21:58DavidHeidelberg: hmm, I'll have to find time to do more exploration :) I stayed with tinygrad since airlied published the blog
21:59karolherbst: if you want to see something cool, use this: https://github.com/ggerganov/whisper.cpp
21:59karolherbst: "Real-time audio input example" specifically
21:59karolherbst: though
21:59karolherbst: Intel's iGPU was too slow for that
21:59karolherbst: :D
21:59karolherbst: kinda
22:00karolherbst: the base model works, but uhm.. results are not that great
22:00karolherbst: ohh.. I haven't seen that "--print-colors" flag yet.. should try
22:09DavidHeidelberg: wow, I'll check on XT6800