01:47 airlied: gfxstrand: could you glance at the nir patch in 25536?
01:54 Company: excellent, using an UBO for push constants became magically fast when I stopped using MapBuffer() for the VBO and used BufferSubData() there, too
01:54 Company: I clearly have no idea what I'm doing
01:55 Company: but things went from 600 to 1600 fps, so I'm at least moving in the right direction
06:01 lina: anholt: I think you want another lina maybe? ^^
06:01 emersion: there can only be one!
06:05 Daanct12: *insert the spiderman pointing each other meme*
06:08 kode54: sorry about my departure, I'll try to be a little more mature about things
06:09 kode54: quick question about modifiers, since I want to resolve that
06:09 kode54: are they vendor specific identifiers for buffer formats?
06:09 kode54: like, and can you ask the driver or device what the format for a specific modifier is
06:15 emersion: a modifier can be used with multiple formats
06:15 emersion: IOW: for a fixed modifier, there is no single format
06:15 emersion: the driver may support the modifier for multiple formats
06:16 emersion: or do you not mean "pixel format FourCC", by "format"?
06:17 kode54: I guess I might have meant that
06:17 kode54: I wasn't sure how unique modifiers were for formats
06:17 kode54: or how much of a description is associated with one
06:18 emersion: you might be interested in https://dri.freedesktop.org/docs/drm/userspace-api/dma-buf-alloc-exchange.html
06:19 kode54: I'll look at that
06:52 kode54: Thanks, that clears everything up
07:26 kode54: again, thanks, it didn’t occur to me that modifiers literally meant that, the unique descriptor for how a given fourcc is laid out in memory
07:27 kode54: Like, something could be linear, or a specific form of tiled or something else
07:27 kode54: Neat that soreau is working on modifier support for old AMD gpus
07:28 kode54: Assuming they support more than some basic layouts
07:28 kode54: Though it might help if each fourcc they support is at least paired with the explicit layout the devices expect
07:29 kode54: If they don’t support more than one layout for a given format
07:30 kode54: Incidentally, I sold my Arc gpu and plan to acquire a 6750 XT
08:16 pq: kode54, no worries. When I told you that, it wasn't just the last comment, but I had been reading you here for couple days and some of your gitlab comments too. Happy to see you now.
09:47 karolherbst: ohh.. gcc and clang will have a __element_count__ attribute to bound check VLAs at runtime
09:47 karolherbst: we might want to do something like we have on the kernel side for it now
09:47 karolherbst: in case somebody is bored
09:54 mareko: gerddie6: why does this fail, and if it fails because of the flake, why? because the flake is listed in the flakes file https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49890490
10:13 mareko: gerddie: ^^
10:23 zzag: anholt: sometimes kwin crashes when destroying EGLImageKHR. libepoxy crashes with "No provider of eglDestroyImageKHR found. Requires one of:". Do you know what can potentially cause it?
10:24 zzag: not really reproducible crash, but it's weird
10:24 zzag: eglDestroyImageKHR should not require a current opengl context
12:07 pepp: digetx, robclark: I don't get why virtio_gpu_do_fence_wait exits early if dma_fence_match_context returns true
12:07 pepp: does it assume that previous jobs will always complete before the next ones?
12:30 robclark: pepp: if they are on the same timeline/fence-context/ring_idx then they should complete in order
12:36 pepp: robclark: hm ok. I have one ring_idx per hw queue type.. I guess I should have one ring_idx per hw queue
12:38 digetx: that's correct, you need to have fence context per queue
12:44 pepp: digetx: right, but unless I'm missing something I can't submit job to a specific queue
12:58 digetx: then you'll need a new job flag to skip ctx matching for such jobs
14:03 karolherbst: anybody here knows how to deal with permission issues on render nodes passed into systemd-nspawn containers?
14:31 psykose: do you get an EPERM on /dev/dri/render* ?
14:31 psykose: i assume you need `DeviceAllow=/dev/dri/renderXXX rwm` in some dropin config
14:33 karolherbst: yeah.. that's what I was missing
14:34 karolherbst: gfxstrand: I need to be able to spill constant spec operations to an initializer function... any ideas or should I just start hacking on it once I find time.... I already see it being quite painful, because spirv_to_nir is entirely not designed for that...
14:37 karolherbst: pocl seems to be doing the same in case you have crossworkgroup variables referencing other crossworkgroup variables :')
14:38 Lynne: dj-death: any ideas when descriptor buffer for anv may get merged?
14:42 dj-death: Lynne: when someone reviews it
14:45 Lynne: you don't have the rule where if it's sitting long enough without a review it gets merged?
14:45 dj-death: I thought that was just for piglit/crucible ;)
15:05 dj-death: Lynne: I've just been made aware of a HW thing, so I need to fix the existing DG2 direct descriptors & update the MR, so there is that too
15:12 Lynne: it's pretty much the last major implementation not to have them yet, even on windows all vendors implemented it
15:12 zmike: it's been implemented for a long time, but one does not simply merge code to anv
15:15 dj-death: do people merge unreviewed stuff in radv?
15:16 zmike: we have weekly slapfights to argue over who has to review things
15:17 psykose: if you bring a fish to the slapfight you're guaranteed to win
16:05 eric_engestrom: zmike: yes, I keep forgetting to create the 23.3 milestone
16:05 eric_engestrom: thanks for the reminder :)
16:05 eric_engestrom: created now: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/44
16:06 eric_engestrom: reminder for everyone: mesa 23.3 branchpoint is happening on Oct 25, the Wednesday _after_ XDC
16:07 eric_engestrom: see https://docs.mesa3d.org/release-calendar for all the dates
16:08 eric_engestrom: if you have any issue that need to be fixed before 23.3.0 final can be released, please add them to the milestone above :)
16:33 anholt: lina: yeah, whoops, meant linyaa about updated prm repo.
16:45 mareko: zmike: are you really arguing about that?
16:46 zmike: what?
16:46 zmike: oh
16:46 zmike: no
16:46 zmike: it's very structured discussion about areas of expertise
16:47 zmike: sometimes we let bnieuwenhuizen do live code readings
16:47 mareko: ooohh
16:49 bnieuwenhuizen: Just trying to make sure stuff doesn't fall through the cracks
16:52 mareko: sounds fun
16:54 mareko: robclark: a306 has 9 new flakes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/49910197
16:58 anholt: mareko: those are all in known flakes.
16:58 anholt: the job failure is in the post-processing stage, because //gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24738
16:59 anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25527 is up, but that MR should probably be reverted until then.
17:08 mareko: so that's why all flake files are ignored
17:30 linyaa: anholt: what about an updated prm repo?
17:30 linyaa: i didn't know people were still using it. but if anyone is, then i'll resume keeping it up-to-date.
17:31 linyaa: do you think it makes sense to move it to gitlab? any opinion?
17:32 linyaa: maybe there are ip issues with hosting it on gitlab. i'm unsure.
17:43 linyaa: anholt: i'm updating them right now...
18:09 anholt: linyaa: thanks! it's been nice to have.
18:10 Company: is there a way to create a dmabuf from userspace? I want to test that my EGL code does the right thing and for that I need to feed it dmabufs from somewhere
18:12 anholt: Company: for some of our testing, we export a dmabuf from GL in another context. but dmabuf testing overall is hard and not done well.
18:13 Company: hrm
18:13 Company: my next question would have been about YUV
18:13 Company: and I don't think exporting YUV works without first getting a YUV buffeer, and with GL that requires importing a dmabuf...
18:14 anholt: welcome to the "not done well" part!
18:15 Company: more stuff to do!
18:15 anholt: piglit generates some bespoke untiled yuv dmabufs using gbm. which frequently fail because they're 2x2 and aligned wrong for import requirements because it can't know those.
18:15 anholt: stride-aligned
18:15 Company: yeah
18:16 Company: do 4x4 instead or 8x8!
18:16 zmike: check weston tests ?
18:16 Company: I had hoped there was some way with simpledrm or whatever to create cpu-backed dmabufs
18:16 anholt: let's be real, I've thought about just cranking it up to like 256 wide with the same pixel data so that we could dodge this.
18:19 airlied: Company: udmabuf?
18:19 anholt: Company: oh, that would be lovely. vgem/vkms are the thing that *should* be doable for this. except dmabuf import doesn't know about managing cache coherency, so you get mismatches between how vgem is mapping buffers (cpu cached woo why not) vs how your gpu wants to access them (data should have been write combined).
18:20 anholt: so things only really work out when you're generating them from a real device on the system that's doing the same caching plan.
18:21 Company: airlied: is that part of the kernel?
18:22 airlied: yeah but all i have is that word
18:22 Company:trying to figure out if it's worth trying to make CI work with it, or if it's just good enough for custom testing
18:22 Company: google says https://github.com/ikwzm/udmabuf
18:23 airlied: it may or may not be useful for you
18:23 Company: well, /dev/udmabuf exists here
18:23 Company: so it's definitely worth looking at
18:24 airlied: the github thing is another thing
18:31 Company: airlied: I assume https://github.com/torvalds/linux/blob/master/tools/testing/selftests/drivers/dma-buf/udmabuf.c is a good starting point?
18:38 airlied: seems like it it
18:57 linyaa: anholt: tgl is up now at https://kiwitree.net/~lina/intel-gfx-docs/prm/
18:58 linyaa: rkl should be another 5min
18:58 robclark: I suppose we could get around to finishing https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23214 to allow gbm to allocate/export yuv surfaces
18:58 anholt: the git appears to be down?
18:59 linyaa: anholt: git clone is broken right now. i took it down for maintenance.
19:00 linyaa: lemme push it somewhere else for now so you can clone, brb
19:17 linyaa: anholt: i created https://gitlab.freedesktop.org/linyaa/intel-gfx-docs.git
19:17 linyaa: wait a few minutes for the initial push. it's fat.
19:17 linyaa: s/push/push to complete/
19:17 anholt: thanks!
19:18 linyaa: do you want DG1 too today? RKL i'm doing now.
19:19 linyaa: basically, i'm going to punt on the discrete cards until tomorrow, unless you need them now.
19:47 anholt: linyaa: something mtl-ish was what I was looking at that made me go try to git pull
19:49 linyaa: mtl is xe-ish, according to intel_device_info.c, but i don't understand how much xe-ish
19:49 linyaa: because dg is also xe-ish, i'll push those after lunch. leaving for 30min lunch now.
20:35 airlied: gfxstrand: the copy prop pass also hits the cast deref in 25536
21:49 alyssa: karolherbst: https://rosenzweig.io/0001-nir-opt_algebraic-Optimize-LLVM-booleans.patch
21:49 alyssa: llvm moment
21:49 karolherbst: ....
21:50 karolherbst: I mean... `iand` is probably the cheaper operation here, so it kinda makes sense
21:53 alyssa: karolherbst: my kernel got nir:
21:53 alyssa: ine(umax(iand(b2i(x), 1), iand(b2i(y), 1)), 0)
21:53 alyssa: truly inventive.
21:54 alyssa: with that patch it becomes
21:54 karolherbst: keep in mind that we generally compile with -O0
21:54 alyssa: ior(x, y)
21:54 karolherbst: but yeah..
21:54 karolherbst: it's all madness :D
21:54 alyssa: big pile of .cl's coming soon
21:55 karolherbst: oof
21:55 alyssa: to a mesa repo near you
21:55 karolherbst: btw.. we still have to fix memcpy :')
21:55 alyssa: yes..
21:55 karolherbst: though... we aren't so silly and copy megabytes of data
21:57 linyaa: anholt: now, all the public prms are up. no mtl docs yet, but there are discrete alchemist/acm/arctic-sound docs, and both are 12.5. though i don't know how similar the ISA and arch are between mtl vs acm.
21:57 anholt: thanks!
21:59 linyaa: alyssa: now that it's oh-so-easy to write shaders, will you volunteer for writing hw-generic vulkan video encode shaders? ;-)
22:00 karolherbst: yooo
22:01 karolherbst: that would be a fun project, I just don't know how viable it is to do emulated video encoding/decoding via the vulkan APIs
22:01 karolherbst: but should be fine.. I guess
22:07 mattst88: the intel vaapi media driver has tons of encode shaders shipped as blobs -- presumably they're essentially compute shaders?
22:07 karolherbst: not necassarily
22:08 karolherbst: but probably?
22:08 karolherbst: in any case... it would kinda be cool if we could have a sw video encoder/decoding lib inside mesa
22:08 karolherbst: for various codecs
22:09 linkmauve: karolherbst, depend on ffmpeg maybe instead?
22:09 Lynne: take the dirtiest most convoluted ISA and overall architecture you can think of, and you still wouldn't be halfway to what implementing h264 from scratch would involve
22:09 karolherbst: linkmauve: no
22:09 karolherbst: also
22:09 karolherbst: ffmpeg doesn't have that
22:10 karolherbst: or at least, not what we'd need
22:11 karolherbst: they don't even have cuda based encoders/decodes, alone CL based ones. For anything accelerated they use prop APIs
22:11 karolherbst: it's super sad
22:11 karolherbst: but ffmpeg won't help us here
22:12 airlied: and gpus suck at decoding videos
22:12 karolherbst: can't be worse than vp9 on the CPU
22:12 Lynne: yeah, you wouldn't really gain much from this type of a decoder (what we call hybrid)
22:12 airlied: karolherbst: can't it? :-P
22:12 karolherbst: ehh.. wait.. I meant the vp9 encoder
22:13 Lynne: most of the overhead of any well written decoder implementation is with token parsing for entropy decoding, which GPUs cannot do in parallel
22:13 karolherbst: yeah.. I'm less worried about decoders, I'm more worried about encoding
22:13 karolherbst: atm, e.g. gnome only supports vp9 for screen casting, which you can guess, is a horrible idea
22:13 airlied: hopefully it grows av1
22:14 karolherbst: it doesn't fix the problem of users not having GPUs supporting av1
22:14 karolherbst: maybe in 15 years we can rely on it
22:14 karolherbst: we still deal with h.264 videos today
22:14 karolherbst: and recording
22:14 karolherbst: because that's what people actually use
22:15 linkmauve: karolherbst, AV1 is encodable in real time on not-that-performant CPUs nowadays.
22:15 karolherbst: does it use <5% of the cPU?
22:15 karolherbst: if not, it's useless
22:15 linkmauve: Of course not.
22:15 karolherbst: yeah, so it's useless for users
22:15 karolherbst: for screencasting purposes
22:16 linkmauve: Users do screencast using CPU encoders all the time.
22:16 karolherbst: yeah.. and on gnome it's super broken
22:16 karolherbst: h.264 would be fine, but it also doesn't push your CPU to its limits
22:18 karolherbst: sorry, but relying on CPUs encoding for av1 won't cut it
22:18 Lynne: encoding is easier, you can definitely implement a meh encoder on the GPU
22:19 karolherbst: yeah.. as long as your CPU isn't at load that everything becomes laggy or the encoder can't keep up, that would be fine
22:19 karolherbst: the issue is, you can totally encode vp9 on the CPU, but you get like 5 fps in avarage
22:19 karolherbst: maybe av1 is simpler on the cpu?
22:19 karolherbst: but the overall problem remains: high load on the CPU
22:19 karolherbst: and power efficiency tanks
22:21 Lynne: av1 is definitely not simpler than vp9
22:21 karolherbst: yeah.... the only useable CPU encoder I've experience is h.264
22:22 linkmauve: AV1 encoders are much more efficient than libvpx though.
22:22 karolherbst: eveyrthing else is too heavy
22:22 karolherbst: yeah.. but libvpx is beyond terrible in terms of speed
22:25 linkmauve: I can do 90 fps at 1080p using SvtAv1EncApp on my i5-8350U laptop, not even tweaking the toggles too much.
22:26 linkmauve: Just asking for one pass, since that’s what screencasting does.
22:26 linkmauve: 106 fps now.
22:26 karolherbst: I'm getting 9fps on my i7-10850H
22:26 karolherbst: for 1080p content
22:27 Lynne: if you turn on realtime mode you should get 100+
22:29 Lynne: ffmpeg -i <input> -c:v libvpx-vp9 -quality realtime -speed 16 -b:v 2M -f null - gets me over 600fps here
22:30 karolherbst: okay.. then it's just not very efficient but potentially usable
22:33 karolherbst: Lynne: interesting.... maybe it's the wrongly used in the end, but I'm getting like 100 fps here with proper content
22:33 karolherbst: and 1080p is still kinda low, some laptops come with 2560 or something
22:33 karolherbst: and then it becomes tight again
22:34 karolherbst: and what if you are also in a video call and have to decode as well
22:34 karolherbst: but anyway... the way gnome uses vp9 for encoding was terrible the last time I've tried
22:34 karolherbst: maybe that was also on aarch64....
22:35 linkmauve: ffmpeg still limits libaom’s cpu-used setting to 0..8? :/
22:35 linkmauve: That really should get fixed someday.
22:35 karolherbst: yeah...
22:36 karolherbst: but uhh... it's still a terrible user experience, if you are actually wanting to do something while recording :D
22:36 karolherbst: and screencasting comes with extra overhead
22:36 linkmauve: karolherbst, on ARM you still don’t have a proper VP9 encoding uAPI in the kernel.
22:36 karolherbst: anyway.. I kinda want to see it working on "all" laptops with great user experience before I'm convinced here
22:37 linkmauve: So acceleration would be moot anyway, even if the hardware did support it.
22:37 karolherbst: linkmauve: ? how does that matter for cpu encoding?
22:37 linkmauve: karolherbst, ah, I thought you meant VP9 as it has hardware encoding, as opposed to AV1 which doesn’t yet on most ARM SoCs.
22:37 karolherbst: ah yeah, fair, but the point was, if your CPU/GPU doesn't have the fixed function hardware, you could also probably use the GPU and get better power efficiency than encoding/decoding on the CPU
22:37 karolherbst: ahhh no
22:38 karolherbst: hardware is fine
22:38 karolherbst: the problem is just, that not everybody has it
22:38 karolherbst: and you need to find a solution in case you don't have hardware encoding
22:38 karolherbst: and decoding
22:38 karolherbst: burning through your battery ain't fun if you could get it cheaper
22:38 Kayden: linyaa: yeah, alchemist docs are up at https://www.x.org/docs/intel/ACM/ - MTL is really similar. some differences with MOCS/PAT/modifiers/etc, but using those docs should be mostly right for either platform
22:38 linkmauve: karolherbst, I doubt your GPU will do it cheaper than your CPU.
22:39 karolherbst: why not?
22:39 karolherbst: I'm not necssarily talking about faster
22:39 karolherbst: only with less power
22:39 linkmauve: That’s also what I’m talking about.
22:39 linkmauve: But I don’t have numbers right now.
22:39 karolherbst: yeah.. probably also because of lack of generic GPU impl
22:40 linkmauve: Maybe check what Lynne mentioned, “hybrid encoders”.
22:40 karolherbst: not sure if that means a e.g. CL based impl
22:40 karolherbst: sometimes encoding/decoding is shader assisted on top of fixed function hardware
22:44 karolherbst: anyway.. could be a fun project
22:45 bcheng: if I'm not mistaken x264 has some cl accelerated routines in it but I think they didn't get great results out of it
22:45 karolherbst: there are proprietary products using CL for accelerated h.264/h.265 to cover all features on all hardware
22:46 karolherbst: and they are faster than doing it on the CPU in general
22:46 karolherbst: just in the open source world we don't have anything usefull
22:46 karolherbst: I think there are also CUDA based ones, but that's kinda pointless to have
23:00 lumag: airlied, mripard, mlankhorst, could you please review and ack https://patchwork.freedesktop.org/patch/556295/?series=123412&rev=1 for merging through msm-next?