00:07DemiMarie: Why do GPUs not just use ordinary pointers?
00:08karolherbst: they do.. for most/some parts
00:08karolherbst: it kinda depends
00:08karolherbst: not using pointers comes with the advantage of being able to cache/preprocess things
00:09karolherbst: like e.g. on nvidia GPUs constant memory can be placed in so called constant buffers being of 64k in size and you have 8-18 slots of those
00:09karolherbst: they are normal VRAM, but pre uploaded in a cache having register read speed
00:10karolherbst: sometimes hardware is designed around doing some pre computations on bind resources before you can actually use them in shaders or other operations
00:10karolherbst: sometimes you get huge cache benefits in having them organized in smaller heaps
00:24Lynne: if you use descriptor buffers with buffer refs, they're real pointers even in the shader
00:45karolherbst: mareko: seems like 9d7eab2ab17b3ffcf8c965c9e7cf89ff1bf2b7ac regression some CL workloads, I just have no idea why yet :)
00:46karolherbst: but I'm seeing GPU hangs and resets
00:46karolherbst: navi 22
00:47airlied: maybe it should be left on for compute shaders
00:48karolherbst: I know that a kernel doing fmod causes resets
00:49karolherbst: but some others were fine
00:53karolherbst: mhhh `vec2 16 div ssa_41 = isub ssa_40.xx, ssa_39` radeonsi crashing on that...
00:55airlied: it's like there is just some sync somewhere else in the shader that is going wrong
00:55karolherbst: ohh.. it's a different bug
00:56karolherbst: somehow the LLVM value of a vec2 value only has one component
00:56karolherbst: but also looks like a regression.. let's see...
00:58karolherbst: I also did upgrade my testing machine to fedora 38, so I get llvm 16 now
00:58karolherbst: could also lead to some fun problems, but seems to be fine for now
01:04karolherbst: okay.. that one is caused by d692d433f28e0a170685dbcfd941d68e6d767182 radeonsi: use nir_lower_alu_to_scalar correctly
01:07karolherbst: funky...
01:08karolherbst: I don't see why, but it does cause regressions...
01:08airlied: robclark: one of the commits in your fixes pull is missing an Sob
01:08airlied: drm/msm/dp: enable HDP plugin/unplugged interrupts at hpd_enable/disable is commited by Abhinav but has no sob from them
01:08airlied: please fix it and let me know to pull it
01:09robclark: ugg... wasn't CI supposed to save me from this?
01:10airlied: dim would have
01:10airlied: use dim :)
01:15robclark: airlied: sent a resend.. drm-msm-fixes-2023-06-08
01:47karolherbst: uhh.. seems to be more regressions :') I really should add rusticl on hw jobs to CI
01:48airlied: yeah now that it runs on hw, you totally should
01:49karolherbst: just piglit isn't really enough, but I guess I can still start with piglit for iris + radeonsi
01:51karolherbst: get_linear_ids is also bonkers.. but I'll figure it out tomorrow
05:02airlied: karolherbst: took a quick look at fns on radeonsi, got the basic IR translation going, but as we are using the shader calling convention, there's a bunch of implicit ctx to shuffle into each fn
05:07airlied: there is a lot of implicit stuff unfortunately
06:41airlied: agd5f_: dim: d33f628a0d10 ("drm/amd/display: remove unused variables dispclk_delay_subtotal and dout"): committer Signed-off-by missing.
08:31sergi: <anholt> "sergi: what happened that the..." <- Hi anholt,
08:31sergi: I've just realized there is a message mentioning that I missed answering. The ci-uprev tool looks for the "image-tags", but it needed to be more competent to know about the arch renaming. Even worst, it silently ignores the situation. This has been solved with a recent merge request in the tool. If there are missing changes to do an uprev, it stops and reports the trouble.
08:37karolherbst: airlied: yeah... what if the called function only has primitives or arrays of such as parameters? Does that help?
08:52karolherbst: airlied: I think for now we we should always inline everything _unless_ a driver registers a callback to identify what's safe to inline. But I have no idea how that interface should look like yet... but if it only depends on the function arguments it might not be impossible
09:04karolherbst: another radeonsi regression: 39da12b7c7c522e1bb5a51b7310a2b68d30a04aa ac/llvm: clean up visit_load_local_invocation_index and visit_load_subgroup_id :')
09:08HdkR: ACO will solve that :P
09:08karolherbst: I'm sure
09:32daniels: is Konstantin Seurer on IRC?
09:40dj-death: daniels: I think it's konstantin_
09:41daniels: konstantin_: ^ instead of triggering the entire pipeline with every job, can you please use .gitlab-ci/bin/ci_run_n_monitor.py --target '$jobname'? that will mean that your radv RT experiments won't be tying up Raspberry Pi resources anymore
09:45konstantin_: ok
09:48HdkR: The Pi just needs to grow some RT functionality so it is worth testing on :P
10:01javierm: tzimmermann: hi, provided a few examples on the mailing list of use cases for what Geert was asking about
10:01airlied: karolherbst: the problem is implicit things like load_workgroup_id etc
10:01javierm: tzimmermann: with my fedora developer hat, I only care about your series but with my maker dev hat I agree with Geert that we need the flexibility for different configurations
10:01airlied: those come in via registers initially, and if a function access them you have to have some way to funnel them down
10:03daniels: konstantin_: thanks
10:15konstantin_: HdkR: Any driver that supports buffer device address can also support RT
10:15HdkR: konstantin_: good good. The Pi will be running Control with RT soon enough then
10:17konstantin_: No promises, but I have a raspberrypi 4 :P
10:17karolherbst: airlied: we could collect read sysvals per function
10:23karolherbst: I really don't want to require backends to come up with some ABI because not having that should be good enough. Some of those libclc functions are massive enough to cause such problems, so my assumption is that we can cut down a lot of the size just by reducint inlinings of huge clc functions, everything else is just nice to have.. probably
11:07tzimmermann: javierm, am i stupid? could you please EILI5 to me what FB_CORE is good for?
11:07tzimmermann: ELI5
11:08tzimmermann: javierm, i honestly don't understand why the existence or default of FB_DEVICE should be tied to native fbdev drivers
11:09javierm: tzimmermann: you are definitely not :) Probably I'm just bad at explaining things
11:10javierm: tzimmermann: there are multiple use cases AFAICT. You could need either a modern kernel-space (only DRM drivers) or modern user-space (only DRM programs)
11:11javierm: legacy kernel-space (only fbdev drivers) or legacy user-space (only fbdev programs)
11:11javierm: or a combination of those
11:11tzimmermann: yes
11:11javierm: tzimmermann: your patch series is when you want both a modern kernel-space and user-space and that's great, we would probably adopt that in fedora
11:11tzimmermann: sure, same here
11:12javierm: tzimmermann: the FB_CORE is to allow all real fbdev drivers to be disabled but still have DRM fbdev emulation
11:12javierm: that's when you want a modern kernel-space (only DRM drivers) + old user-space (only fbdev programs)
11:12tzimmermann: i got that as well
11:12javierm: tzimmermann: in that case you want FB_DEVICE but only for DRM fbdev emulation
11:13tzimmermann: no
11:13tzimmermann: if i have old userspace, i want it to run on my drivers. whether that is fbdev or DRM doesn't matter
11:14tzimmermann: so i need FB_DEVICE
11:14tzimmermann: unconditionally
11:14javierm: tzimmermann: yeah, but then you need to explicitly disable all the fbdev drivers
11:14tzimmermann: why?
11:14javierm: would be great to have a single Kconfig symbol to say "I want to disable all native fbdev drivers"
11:14tzimmermann: why?
11:14javierm: just to make the config simpler ?
11:14tzimmermann: why?
11:15javierm: I mean, we have a bunch of Kconfig symbols to disable a set of stuff, why we couldn't have one for fbdev native drivers ?
11:16javierm: that's what Geert was asking IIUC and I mentioned that I already posted a series for that, which funnily had even the same symbol name (FB_CORE)
11:16javierm: he was asking if there could be an option to *only* support fbdev through DRM emulation
11:17javierm: because right now in fedora we have CONFIG_FB enabled (for drm emulation) and need to explicitly disable all the drivers. It makes no sense to me
11:17tzimmermann: what you are describing is entirely unrelated to my patchset
11:18javierm: tzimmermann: it is unrelated yes, that's why I said that are complementary
11:18tzimmermann: let me make my point: the only relevant question for FB_DEVICE is "do i have an old fbdev userspace?" if so, FB_DEVICE=y. otherwise FB_DEVICE=n is preferable. whether that fbdev device is provided by aDRM or an fbdev driver is irrelevent
11:19javierm: tzimmermann: yeah, the only open question for your patch-set is if FB_DEVICE should be y if !DRM
11:19tzimmermann: it should just be y or n
11:19tzimmermann: i guess y would be the better setting
11:20javierm: yeah and distros can explicitly disable it
11:20javierm: tzimmermann: at least to unlock your series. We can later revisit as follow-up
11:20tzimmermann: the whole discussion about the actual existence of an fbdev userspace seems artificial to me. you have examples, but those would be covered by FB_DEVICE=y
11:21javierm: tzimmermann: yes, but then it would mean to either a) explicitly disable all the fbdev drivers (what I currently do) or b) keep those fbdev drivers enabled even if not needed
11:21javierm: tzimmermann: anyways, let me say again that this whole discussion is unrelated to your patch-set and we can have it later
11:21javierm: I'll post as RFC on top once your patches land
11:22tzimmermann: i'm thinking about FB_DEVICE_DEFAULT_ENABLE=<bool> plus an module parameter. it would allow distributions to soft-disable the device, but give users a option to override the setting and bring back the device.
11:23tzimmermann: if fb.fb_enable_device=1 has been given to the module or kernel, the device would be created
11:24tzimmermann: i assume that we (SUSE) has users that might have a requirement for the fbdev device
11:27javierm: tzimmermann: I think that is too complicated for no clear benefit. We are soon disabling even X11 support so fbdev user-space can really just go away too
11:28javierm: if there are still fedora users needing fbdev, then can have a custom kernel build with copr or just use a different distro that supports legacy stuff
11:28tzimmermann: that's ~10 lines of code
11:28javierm: tzimmermann: yeah, is not the code itself but giving users the choice
11:29javierm: tzimmermann: http://www.islinuxaboutchoice.com/ :D
11:30javierm: now, a kernel config option to build custom kernels that support fbdev (in kernel or user-space) makes sense to me
11:30javierm: and where kernel-space is only DRM + emulated fbdev
11:30javierm: tzimmermann: I mentioned in the thread that the FB_CORE discussion brought by Geert is really orthogonal to your series and we can have that discussion as follow-up
11:31javierm: tzimmermann: I've reviewed all the patches that Sam didn't. Please let me know if there are some tags still missing
11:31tzimmermann: javierm, thanks a lot for your work
11:32tzimmermann: i'll resend the next version early next week
11:34javierm: tzimmermann: great! I'm pretty sure we will adopt that config in Fedora. We only really need fbdev for fbcon and ({efi,vesa}fb) for nvidia
11:34tzimmermann: javierm, FB_CORE would be selected by FB and DRM_FBDEV_EMULATION?
11:40javierm: tzimmermann: DRM_FBDEV_EMULATION will depend on it https://lore.kernel.org/all/20210827100557.1578746-1-javierm@redhat.com/#r and same for FB_DEVICE (once it lands)
11:41javierm: then you should be able to disable CONFIG_FB which would basically be a config to enable fbdev native drivers
11:41javierm: tzimmermann: but let's discuss those details later once your patches land and I post another RFC
11:41tzimmermann: yeah
13:32karolherbst: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23551
13:32karolherbst: not sure if you saw the pings on the other regressions
13:32karolherbst: 9d7eab2ab17b3ffcf8c965c9e7cf89ff1bf2b7ac causes a lot of resets and now idea what to do with that one
14:00kallisti5: pop quiz time. What is Haiku doing wrong in swapbuffers? :-) https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/haiku/egl_haiku.cpp#L204
14:00kallisti5: SDL apps render with a flicker of "frame,black,frame,black"
14:00kallisti5: commenting out the std:swap on 234 "fixes" it. (but breaks other apps doing double buffering)
14:02kallisti5: (I assume it's other apps doing double buffering.. we get weird random plain-colored untextured 3d object masks without the std::swap)
15:05alyssa: porting llvmpipe (gallivm) to reg intrinsics without learning anything about llvm challenge
15:05karolherbst: don't do it, LLVM will absorb you sooner or later
15:07kisak: is there an alternative? have friends who are already lost in the llvm mire?
15:07ccr: "if you gaze long into the abyss, the abyss gazes also into you."
15:08alyssa: karolherbst: man, there's like 15 backends to convert before we get the win
15:08karolherbst: mhhh... right.. I wanted to do the codegen bits...
15:08karolherbst: though if you just use the intrinsic..
15:08karolherbst: uhhh... pain
15:09alyssa: So, the current state of the MR is:
15:09alyssa: * new intrinsics added
15:09sravn: alyssa: Easy, just write nirpipe in rust:-)
15:09alyssa: * producers + core switched to intrinsics internally (doesn't affect drivers)
15:10alyssa: * convert_from_ssa + locals_to_regs + vec_to_movs have new versions producing intrinsics
15:11alyssa: * helpers to allow backends to parse intrinsics as-if they were nir_registers so they don't need to improve their crappy copyprop
15:11alyssa: * intel/fs, intel/vec4, midgard, and nir-to-tgsi converted to use intrinsics + helpers
15:11alyssa: this is about feature complete for what I was hoping for in this series
15:12alyssa: so I am hopeful that it'll be ready for serious review on Monday and we can get this in sooner than later
15:12alyssa: at which point... phase 2 is converting each backend one-by-one
15:12alyssa: though hopefully I can get everyone on board and we can do the backends in parallel
15:13alyssa: It's not *hard* to convert a backend, but there are a bunch of them
15:13karolherbst: yeah... I kinda want to get rid of the pre SSA phase in codegen, it's just... uhh... a lot of code to read
15:13karolherbst: most of the lowering is done pre SSA for _whatever_ reason
15:14karolherbst: I think most of the code is already SSA compatible, but...
15:14alyssa: shrug
15:14alyssa: I hear there's a shiny new SSA-based backend coming
15:14alyssa: for nouveau
15:14karolherbst: yeah... I don't know what happens to me if I suggest covering all the ISAs codegen covered :D
15:15alyssa: ahahaha, fair
15:15karolherbst: codegen supports like... 4 ISAs
15:15alyssa: >_>
15:15alyssa: right, well
15:15karolherbst: 5 actually
15:15alyssa: if you have good backend copyprop, you don't need the helpers and can just translate intrinsics
15:15alyssa: that's probably the least invasive option here
15:15karolherbst: yeah.. probably good enough
15:16karolherbst: I don't know if codegen has good copyprop, but it has copyprop
15:19alyssa: oh hmmmmm
15:19alyssa: I wonder if llvmpipe would be happy to eat the intrinsics directly
15:20alyssa: since it's just materializing loads/stores anyway
15:20alyssa: so I don't think the helpers would actually help
15:21karolherbst: in codegen that's probably entirely fine, just emiting a mov to/from a non SSA value should be good enough at least...
15:21alyssa: yep
16:30emersion: pq: some qualcom person replied to the color KMS API thread
16:30emersion: hm, i should've asked more about their hw
17:38bb2045: Hi all, can someone give me a refresher on how to fossilize a pipeline with mesa/RADV? `VK_INSTANCE_LAYERS=VK_LAYER_fossilize FOSSILIZE_DUMP_PATH=. ./program_name` doesn't seem to do the trick for me for some reason.
17:48agd5f_: airlied, fixed
17:48agd5f_: airlied, new PR sent
17:48alyssa:stares back at Alyssa from years ago
17:49alyssa: Is f2i32(fceil(x)) actually the same as f2i32.rtp (and so on)
17:49alyssa:raises eyebrow suspiciously
17:50alyssa: firm maybe?
17:50alyssa: seems like it might have precision issues potentially
17:54alyssa: maybe it's ok.. but not really a source modifier. maybe I will rework this code then.
18:01jenatali: Those should be the same
18:02alyssa: jenatali: ok.. 2020 Alyssa thought so too but it smells funny
18:03alyssa: Maybe should introduce NIR opcodes for directed rounding for clarity if nothing else
18:04bb2045: (nvm my earlier question- FOSSILIZE=1 worked just fine :) )
18:05jenatali: alyssa: There's already intrinsics for that from CL
18:05jenatali: Or rather, an intrinsic
18:21alyssa: jenatali: ooh, right, forgot about that
19:28karolherbst: in case somebody is up for some late week gallium review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893
19:28karolherbst: (and vtn)
19:32alyssa: karolherbst: i'll look though idk if i'll get it to before Monday
20:09alyssa: anholt: Could you review some ntt/ttn changes? thanks :)
20:09alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23191#note_1946902
22:38DavidHeidelberg[m]: mupuf: you'll be happy, working on separating kernel from Mesa3D CI repo now. I guess we can easily transition to cpio modules, not sure with firmware thou, that will take longer.
22:58karolherbst: this job failed in a weird way: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/43499700
22:58karolherbst: the crash on c15.r1.log actually
22:58karolherbst: there.... wasn't really a crash with deqp, but the system kinda acting weird?