02:56mareko: who is still using xa and xvmc?
02:56imirkin: xvmc works with the earlier nvidia GPUs
02:57imirkin: nv3x - g96 -- has an engine which consumes what xvmc provides
02:57imirkin: afaik some players have dropped support for it. not sure if it's all or just some.
02:58imirkin: (and hooking those up to vdpau results in stuff being slower overall since software like mplayer has *super* optimized mpeg parsing code, whereas mesa's is pretty crap in terms of perf)
03:00imirkin: i have such a GPU plugged in right now, in case you want something tested
03:00mareko: not really
03:00mareko: vaapi is our main video API and supports more codecs at this point, vdpau is unlikely to receive new features
03:00imirkin: ok, well it's the same idea
03:01imirkin: my point is that mesa's VLD code is crap
03:01imirkin: (no offense to the people who wrote it, but you're competing with projects whose sole purpose is to make that stuff fast)
03:01mareko: so you're saying we shouldn't delete xvmc
03:02imirkin: i would not support that. that said, MPEG-1/MPEG-2 is definitely less relevant today
03:03imirkin: originally my personal use-case was decoding ATSC broadcasts, which my CPU (at the time) couldn't handle. that's still a thing, of course. modern CPUs will actually decode MPEG-2 faster than shipping it to a GPU to decode.
03:03imirkin: but unless it's hurting someone, i'd rather it stick around.
03:03imirkin: i'm happy to make updates / test it if needed
03:05imirkin: [no comment about "xa" -- afaik freedreno was the last user of that, not sure it's still useful. maybe on a2xx? robclark would know]
07:44danvet: airlied, there's some other -next pulls pending iirc
07:45danvet: one is a fixup for something in the imx pull
07:45danvet: from phillip zabel
08:54airlied: danvet: i think i merged that one already
08:54airlied: and pushed it out earlier
09:10danvet: airlied, ah yes
13:02danvet: mripard, btw if you're bored with vc4 stuff, converting from devm_ to drmm_ might be a good idea
13:03mripard: danvet: added to the todo list :)
13:03danvet: mripard, https://dri.freedesktop.org/docs/drm/gpu/todo.html#plumb-drm-atomic-state-all-over <- is this one done after your series?
13:06mripard: I didn't realise it was on the todo list
13:07mripard: but yeah
13:07mripard: only prepare_fb and cleanup_fb, but it looks like it should keep the plane state
13:07mripard: (cleanup_fb at least takes either the old or new state depending on the occasion)
13:07danvet: yeah I think prepare/cleanup makes sense as-is
13:08danvet: mripard, you're adding a patch to remove the todo on top of your series?
13:11danvet: ickle, happy with v5 of the dma-buf debug option?
13:17danvet: agd5f_, drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:929:24: warning: unused variable ‘adev’ [-Wunused-variable]
13:18danvet: I guess you have the fix for that already somewhere?
13:18danvet: at least I think that's not one due to my local patchpile
13:19danvet: or maybe due to lack of backmerge of drm-next into drm-misc-next
13:20ickle: ok, can't see anyway to mangle_sg_table() an odd number of times
13:26danvet: j4ni, pls holler if there's some non-i915 conflicts left after you're done
13:26danvet:just pushed some -misct
13:27danvet: ickle, thx for checking, I'll drop the (v2)
14:57danvet: mlankhorst, airlied before we do a -misc-next pull we need the fix for the drm_device->pdev fallout from tzimmermann
14:57danvet: otherwise probably too much fallout
14:57tzimmermann: danvet, it's in patch 1 of the patchset v4
14:58danvet: yeah just wanted to point that out since airlied asked for a -misc-next pull from mlankhorst earlier today
14:58tzimmermann: ah, ok
14:58danvet: for the omapdrm modular build fix thing
14:59tzimmermann: i hope that christian can check if this fixes amdgpu, and then i merge it
14:59tzimmermann: the rest of the patchset is really just i915 + the deprecation of pdev
15:03tzimmermann: danvet, airlied; is tomorrow still ok?
15:06danvet: looks like mlankhorst won't do the pull today anyway, so should be fine
15:08mlankhorst: Yeah I'll wait
15:36agd5f_: danvet, yeah, I think I saw a fix for that
15:45jekstrand: bnieuwenhuizen: Starting on Ray-tracing? Or just picking off the fruit that's hanging so low it's practically fallen off the tree already?
15:50bnieuwenhuizen: jekstrand: started implementation.
15:51bnieuwenhuizen: have our BVH format here: https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/wikis/RDNA2-hardware-BVH so now I'm off implementing world's dumbest BVH building algorithm
15:51jekstrand: bnieuwenhuizen: I think my BVH building MR has what I did with embree
15:51jekstrand: bnieuwenhuizen: That's a good way to get started
15:51bnieuwenhuizen: and then for MVP of the actual raytracing I'll try to pull some out of your raytracing MR but still build a single ubershader
15:52bnieuwenhuizen: just to get some of the raytracing details right
15:52bnieuwenhuizen: as you may notice in the page above a lot of stuff is not HW supported in the BVH so we have some design work for e.g. instance nodes left
15:53bnieuwenhuizen: the advantage of the dumb algorithm is that it wouldn't be too hard to have it in a nir shader
15:54bnieuwenhuizen: (of course perf is a disadvantage ...)
16:00jekstrand: Yeah. I've got a thing for ANV to add inernal support for CL kernels.
16:00jekstrand: I'm hoping to get that out the door soonish.
16:00jekstrand: Lots of stuff has been blocking on landing COMPUTE_WALKER support which happened last week.
16:00jekstrand: And me being on vacation for a while.
16:01jekstrand: It's a new way of doing compute-shader dispatch
16:02jekstrand: It's a pretty uninteresting change in and of itself but all RT-capable HW will use it and I don't want to write vkCmdTraceRays and dispatch_kernel twice just to pretend to support the old method.
16:07jekstrand: It's so much nicer than the weird media pipe stuff we had to do for CS dispatch before.
16:16danvet: tzimmermann, I think kernel test robot also found the vram helpers leak
16:16danvet: [drm/vram] 1086db71a1: WARNING:at_kernel/rcu/rcutorture.c:#rcutorture_oom_notify[rcutorture]
16:16danvet: maybe reply there once you pushed it to -fixes
16:16FLHerne: bnieuwenhuizen: "As a result the effective size of this structure is 128-bytes, which leaves a 16-byte gap at the end to store useful information." <- is that right?
16:17danvet: I didn't find it yet there
16:19bnieuwenhuizen: FLHerne: if you count in cachelines?
16:20bnieuwenhuizen: FLHerne: they need to be 64-byte aligned so the 16 bytes at the ends are useless for compaction
16:20FLHerne: Oh, I see how I'm meant to read it now
16:22FLHerne: Having read the previous one -- "noteworthy is that this node is exactly a 64-byte line without any holes" I assumed the '128' was still referring to the structure size, which doesn't make sense unless you have 144-byte cachelines :p
19:42imirkin: how do people deal with interpolateAtSample() with non-ms buffers? you're supposed to always return the center position
19:42imirkin: (and by "people", i mean "drivers")
19:43imirkin: i'm thinking a binary patch atm, but there could be other ideas too
19:45bnieuwenhuizen: same way as a ms 1-sample buffer?
19:45imirkin: bnieuwenhuizen: my point is you're supposed to ignore the sample id
19:45imirkin: whereas with a MS buffer you're allowed to return undefined results if it's a weird sample id
19:47imirkin: (there are some deqp tests, e.g. dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at_sample.non_multisample_buffer.sample_n_default_framebuffer which now verify this)
19:48imirkin: the man page says 'If multisample buffers are not available, the input varying will be evaluated at the center of the pixel. If sample sample does not exist, the position used to interpolate the input varying is undefined.'
19:49imirkin: so my question is, what mechanism do drivers use to ignore the given sample id and always evaluate at sample 0? it would appear that the hw isn't helping with this (we have ops to retrieve sample positions for a given sample id)
19:54pendingchaos: it looks like radeonsi uses shader variants (interp_at_sample_force_center/interpolate_at_sample_force_center)
19:54imirkin: ok. i guess binary fixup it is.
19:54imirkin: shouldn't be too hard
19:55imirkin: i've done it for gl_SampleMaskIn before. very annoying when spec differs from hw =/
19:55imirkin: (the underlying hw value for us there is the coverage, irrespective of per-sample or per-pixel shading)
23:01Lyude: mripard, any chance you're around?
23:44imirkin: dcbaker: so if i forgot to cc stable on some patches, the idea is that i create a MR with cherry-pick -x'd commits onto that branch?