00:00 tarceri: maybe its better than when I last looked, things are always moving forward
00:03 anholt_: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21578 has some stats for freedreno.
00:04 anholt_: note that that MR doesn't include opt_algebraic gutting or copy prop removal.
00:05 tarceri: I think one of the things was I needed to handle things other than just mat4 or vec4
00:05 tarceri: I think there was a least 1 regression in shaderdb from that
00:06 anholt_: I've got a couple listed there.
00:07 anholt_: oh, something I was thinking about as we make progress on this: since nir_opt_algrebraic is good at matching the biggest pattern, I think some of the variants you have dealing with 1.0s being optimized away should end up being unnecessary once we have GLSL optimization deleted.
00:08 tarceri: I hope so because I think there were more corner cases
00:12 tarceri: Although I think nir might have been getting to them first also
00:13 tarceri: *nir opts
00:19 alyssa: ~irregular reminder that alu is cheap and memory is not~
00:23 alyssa: (so I'm good with small shaderdb alu count regressions if they mean shorter compile time, etc)
00:25 tarceri: It's really a massive chain of todos with these things. You try to remove one pass and you need to remove another handful, fix ten year old bugs, and speedup NIR passes :P
00:26 alyssa: Lol
00:26 alyssa: I want a graph of "line count of src/compiler/glsl/ over time"
00:26 anholt_: finding that glsl ir opt code I wrote 13 years ago is still load-bearing is a little distressing.
00:26 alyssa: scaled appropriately and captioned "not stonks"
00:27 zmike: ideally zoomed in until it has become pixelated
00:27 alyssa: 100%
00:28 tarceri: lol
00:30 anholt_: alyssa: btw, did the midgard change you suggested (I think) in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21476
00:30 tarceri: I'm not sure if it will ever get there but ideally GLSL IR would get to a point were its just a small layer between ast and nir. Being able to to the gl compile calls in NIR would be great rather than having to wait until link time.
00:33 alyssa: anholt_: italove was working on that AFAIK, not planning to work on it myself unless italove gets stuck
00:35 alyssa: anholt_: Oh, I see you added patches yourself
00:37 alyssa: r-b'd
02:20 kode54: where should I report an issue with the xe kmd? the mailing list?
02:30 airlied: kode54: there is also the xe gitlab repo, I think it has issues enabled, or just the ml
02:38 kode54: I'll check there
02:41 kode54: oh, already reported: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/210
02:43 kode54: oh damn
02:43 kode54: I didn't notice that repo was ahead of cgit.freedesktop.org/drm/drm-xe
07:08 sergi: anholt_: It's solved and there is a proposal to uprev piglit in mesa https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21574
10:03 javierm: tzimmermann: are you following this thread? https://lists.freedesktop.org/archives/dri-devel/2023-February/392936.html
10:03 javierm: tzimmermann: I would like to know your opinion since you were also involved in the nomodeset cleanups
10:26 mi6x3m: hey, can anyone of you mesa devs explain to me how anv_GetPhysicalDeviceFeatures2 is mapped to GetPhysicalDeviceFeatures2 at runtime?
10:27 mi6x3m: i dont find any reference to anv_GetPhysicalDeviceFeatures2 other than the definition
10:27 mi6x3m: so I figured the string anv_ is added to GetPhysicalDeviceFeatures2 SOMEWHERE to resolve it
10:27 mi6x3m: but i cant find the place :(
11:02 kj: I think they get generated at build time with src/vulkan/util/vk_entrypoints_gen.py so you'll see vk_entrypoints_gen in the meson.build
11:03 kj: But I don't really know all the magic behind it of how it works exactly
11:03 vsyrjala: digetx: your stuff broke i915. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12790/fi-snb-2520m/igt@gem_exec_fence@basic-busy.html
11:04 mi6x3m: kj, aha!! important piece of intel, thank you
11:04 mi6x3m: let me check
11:15 tzimmermann: javierm, thanks for the review
11:15 tzimmermann: javierm, i've seen the virtio patch. but it seems unrelated to actual nomodeset option
11:19 javierm: tzimmermann: not quite, the goal of the patch is to disable modsetting while still keeping the rendering part
11:19 tzimmermann: javierm, IIRC there was some discussion about the semantics of nomodeset when we merged it. and IIRC we decide to ignore those corner cases then. that's back on the table now, i guess
11:20 tzimmermann: TBH, i think i'd prefer a module option here.
11:20 javierm: tzimmermann: yeah, we didn't add nomodeset handling to DRM only drivers (i.e: that have DRIVER_RENDER but no DRIVER_MODESET)
11:20 tzimmermann: let me type up a reply mail
11:21 javierm: tzimmermann: a separate option than virtio-gpu.modeset then?
11:21 tzimmermann: no
11:21 tzimmermann: let me take a look. if there's already such an option, we wouldn't need another
11:21 javierm: tzimmermann: yeah, that's what my point: https://lists.freedesktop.org/archives/dri-devel/2023-February/393399.html
11:23 javierm: *that was
11:35 digetx: vsyrjala: afaics from the log, it's the vgem problem, not i915; looking at it, thanks
11:46 DavidHeidelberg[m]: I would love to merge CI sections today, any concerns? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20272
12:00 javierm: tzimmermann: thanks for your answer. I agree with your thoughts
12:01 javierm: tzimmermann: I'll let others decide what should be done for this particular driver, but we should think about the 'nomodeset' and modules 'modeset' params semantics and try to make it consistent
12:06 tzimmermann: javierm, wasn't that super complicated? IIRC we couldn't outright remove pre-existing modeset parameters because too many blogs, comments, guides refered to it?
12:06 javierm: tzimmermann: I didn't mean to remove 'nomodeset' or modules 'modeset' but just make the behaviour consistent
12:06 javierm: i.e: make all drivers to fail probing for example
12:07 tzimmermann: javierm, we do this for modeset, don't we?
12:07 tzimmermann: they all fail registering/probing
12:07 javierm: tzimmermann: as mentioned in the thread at least i915 and nouveau only disable the KMS part IIUC
12:08 javierm: so I wonder if in that case the aperture helpers would kick the firmware-provided framebuffer anyways
12:10 tzimmermann: nouveau apparently doesn't register
12:11 vsyrjala: iirc i915 becomes a dead husk if you use that
12:12 tzimmermann: i915 doesn't register either
12:12 tzimmermann: yeah
12:12 tzimmermann: so do all the other drivers with modeset
12:13 tzimmermann: that's why i called it repurposing modeset
12:13 tzimmermann: virtgpu would then register, but as render-only driver
12:13 javierm: tzimmermann: right, sorry my bad. I just grepped the drivers that weren't doing a "return" after the check
12:14 tzimmermann: no worries, we've been fighting with the semantics ever since
12:14 tzimmermann: i guess we could do this for other drivers as well, if we convince maintainers
12:14 javierm: but I see now that both drivers check later if use_kms or nouveau_modeset respectively and return with no success
12:14 tzimmermann: that would be i915, nouveau, radeon
12:15 tzimmermann: i just don't know if anyone cares. i'm not even sure why virtio needs that option
12:16 vsyrjala: i915 already has a i915.disable_display. though all that does it claim all connectors are disconnected
12:16 tzimmermann: and a few other drivers only support modesetting (ast, mgag200, bochs)
12:17 vsyrjala: that's as far as we're willing to take it in i915. anything else would be madness when the display hardware is still actually present
12:19 vsyrjala: well, i guess we could take it a notch further by rejecting all kms ioctls, if that were possible. but we still need to initialze the full kms stuff internally
12:19 tzimmermann: vsyrjala, i tend to agree. i don't see the benefit of that option; besides 'because we can'
12:20 javierm: tzimmermann: yeah, those allow to disable modsetting (which is really disable register / probe) and to override the global 'nomodeset' param
12:21 javierm: tzimmermann: it seems the goal is to reduce the attach surface since ChromeOS doesn't use virtio-gpu for KMS, only for rendering
12:22 javierm: *attack
12:22 javierm: tzimmermann: anyways, if all drivers fail to probe with either 'nomodeset' and the modules 'modeset=0' then I'm a happy camper and the semantics are consistent
12:23 javierm: even if the naming is confusing :)
12:24 tzimmermann: javierm, i've send an email about the real-world use of the option.
12:25 digetx: tzimmermann: robclark already said explicitly on the ML that the config option is for security reasons and nothing else
12:26 digetx: but yes, I suggested that the commit message should be improved
12:27 tzimmermann: digitx, did he. i see two mails from rob. neither speaks of security
12:28 digetx: tzimmermann: https://lore.kernel.org/dri-devel/CAF6AEGsT8_o+v0vzGu1nyh6Z82pj8FnGUdMFc0Lq+4OWoSjRBQ@mail.gmail.com/
12:28 tzimmermann: javierm, maybe we should warn if modeset is anything but -1? and then tell users to use nomodeset instead. https://elixir.bootlin.com/linux/v6.2/source/include/drm/drm_module.h#L62
12:29 javierm: tzimmermann: yeah, could be. I guess in practice though most people will just use 1 or 0 for this param, or just the global 'nomodeset'
12:29 javierm: tzimmermann: probably if you remove the per-module parameters nobody will even notice :)
12:30 tzimmermann: digitx, i didn't see this before. thanks
12:30 tzimmermann: it's still really vague AFAICT
12:31 tzimmermann: those modeset ioctls are DRM-wide. so why isn't this a DRM-wide option?
12:35 javierm: tzimmermann: that's a very good point. It would make more sense to have a Kconfig option to just disable KMS then
12:35 javierm: so that drm_core_check_feature(dev, DRIVER_MODESET) will always return false for example
12:35 digetx: perhaps it could be a DRM-wide option as alternative; it's a global vs per-driver option preference, the global variant should work in Rob's case
12:36 javierm: digetx: yeah, because the only DRM driver that will be used in the VM will be virtio-gpu anyways
12:36 digetx: actually, not true :) there is option with passthrough gpu + virtiogpu
12:37 digetx: and Google uses that case it too
12:40 javierm: digetx: ah, so they pass-through the host GPU and use the native DRM driver in the guest? I thought that they used the virtio-gpu native contexts support and that only used the mesa driver in the guest
12:40 javierm: but still virtio-gpu to tunnel the native DRM driver ioctls over virtio
12:42 digetx: there are multiple use-cases, depending on product; pass-through second host GPU + virtio-gpu is one variant, solely native context virtio-gpu is another
12:42 javierm: digetx: got it
14:32 llyyr: I get `amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.` when starting any opengl application on Mesa built from the main branch, looking at the git logs there were some related changes to src/egl and it's probably also related to my issue #8394
14:32 llyyr: `mpv --no-config` can reproduce this, goes away with `mpv --no-config --gpu-api=vulkan`
14:40 MrCooper: llyyr: that's on Linux?
14:40 llyyr: yes
14:41 llyyr: there's more info on https://gitlab.freedesktop.org/mesa/mesa/-/issues/8394 but i'm on sway/wayland
14:41 emersion: with a recent-ish kernel?
14:41 llyyr: 6.1.2
14:41 llyyr: 6.1.12*
14:42 emersion: yeah
14:42 emersion: do you have the allow-kcmp Meson option set?
14:43 llyyr: it's set to auto
14:43 emersion: it's supposed to be enabled then…
14:44 llyyr: I just copied the options from my distro (tumbleweed) and set `Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec` because they don't build with those anymore
14:45 llyyr: also it works fine on 23.0.0
14:47 llyyr: !13422 is the only related change that's on the main branch but not on 23.0.0
14:55 digetx: tzimmermann: you've re-added (likely accidentally) the wrong conflict resolution for drm-shmem to dim's rerere, don't you mind if I'll revert it?
14:55 tzimmermann: digitx, ok
14:56 tzimmermann: i picked the dma-lock patch and the export_symbol_gpl patch IIRC
14:56 tzimmermann: digetx ^
14:56 vsyrjala: digetx: is a fix coming soon, or do we need to think about a revert?
14:57 mripard: marex: I'm sorry, I did my best
14:57 robclark: javierm, tzimmermann: for displaying guest windows there is a sort of "wayland proxy" that proxies the surfaces/fences to host compositor so kms in the guest is unused.. I'll respin the patch with a better commit msg after breakfast
14:57 jani: vsyrjala: is it broken on drm-misc-next too, or is this just about wrong conflict resolutions?
14:58 jani: I mean the conflict resolution could be wrong even if it builds
14:58 jani: idk
14:58 robclark: digetx: re: #ifdef vs #if IS_ENABLED() in the driver struct, #ifdef is already used (for example, for debugfs) nearby, so sticking with #ifdef there seemed more consistent.. but agree with your other comment about better commit msg
14:59 vsyrjala: jani: not sure. i presumed it's broken in general
15:00 digetx: vsyrjala: jani: that is a general issue, I'll try to fix it asap; if it will be taking too much time, then will be good to revert
15:01 javierm: robclark: I see. That's the virtio-wayland thing, right?
15:01 javierm: robclark: and I understood that was unused, it was just about compile vs runtime option
15:04 tzimmermann: jani, vsyrjala, digetx, i'll take a look
15:04 digetx: vsyrjala: jani: that's a warning about a missing resv lock; the dma-buf locking rules became stricter since 6.2 kernel and they are enforced for shmem in the offending patch
15:04 digetx: robclark: ack
15:10 tzimmermann: digetx, vsyrjala, jani, i'm going to revert 67b7836d4458 ("drm/shmem-helper: Switch to reservation lock")
15:12 digetx: tzimmermann: okay, that perhaps the best option; will fix it without rushing and we'll try again
15:13 tzimmermann: digetx, from what i can tell, the _pin code never acquires the lock
15:13 tzimmermann: and that is probably not hot-fixable
15:14 digetx: the shmem shouldn't get the pin lock, it should be a lock missing in other place for dma-buf exporting code path
15:15 jani: tzimmermann: eyballing the commit, does that revert also help with the conflict?
15:15 jani: *eye
15:16 digetx: tzimmermann: it's not a problem for the current drivers as they don't rely on the new resv locking rules
15:16 tzimmermann: digetx, exactly. but not just there. enything that calls drm_gem_object_funcs now needs to hold that lock first
15:17 tzimmermann: jani, we'lkl see
15:17 digetx: tzimmermann: I've the same thought, will see where the lock is missing
15:18 tzimmermann: jani, if i post a revert, how do i get your CI to test it?
15:19 tzimmermann: digetx, you mention that you are working on a fix. do you want to try first?
15:19 robclark: javierm: yeah, virtio-wl (although I'd like to see it replaced w/ a virtgpu-wayland context type so we can get rid of a downstream guest kernel driver.. but no one has had time for that yet)
15:21 robclark: javierm: I'm in favor of a compile time option because it is easier to reason about.. which is important when you have four different host kernel LTS branches and three different guest kernels for different guest OSs (plus beta+stable and CrOS-LTS version branches for each of those)
15:21 digetx: tzimmermann: I already reproduced the reported warning, working on it, though also busy with other things in parallel
15:23 javierm: robclark: yeah, it's harder to re-enable it by mistake
15:24 robclark: right
15:24 MrCooper: llyyr: git bisect would probably be easiest to find what broke it for you
15:34 jani: tzimmermann: Cc: intel-gfx, ensure it applies on top of drm-tip, that's all
15:34 jani: tzimmermann: in the more general case, if you post a series, also ensure you Cc the complete series
17:39 marex: mripard: let's see what happens now
17:59 karolherbst: uhm.. llvmpipe uses 32 bit pointers when doing a 32 bit build, right?
18:02 airlied: if a tree falls in the woods...
18:04 HdkR: One would hope so
18:04 karolherbst: yeah.. just noticed today, that llvmpipe always claims to be 64 bits, so CL is probably broken in 32 bit applications :)
18:05 airlied: if a tree falls in the woods...
18:05 airlied: :-P
18:05 airlied: I wonder where you'd find a 32-bit CL program in the wild
18:05 karolherbst: wine
18:06 karolherbst: but also apparently somebody uses it on a 32 bit host...
18:06 airlied: for wine wouldn't it need an application to use it?
18:06 karolherbst: sure
18:06 karolherbst: already got bugs like that
18:06 airlied: I wonder where you'd find a 32-bit CL program in the wild
18:06 airlied: for Windows
18:06 karolherbst: yeah
18:06 karolherbst: I fixed a bug recently for that
18:07 airlied: but maybe there are a bunch
18:07 karolherbst: it's windows
18:07 karolherbst: applications were 32 bit only for a looong time
18:08 airlied: yeah I'm just more surprised there's any CL apps
18:08 karolherbst: airlied: https://github.com/gchudov/cuetools.net this what a user filed a bug with
18:09 karolherbst: and the release archives only contain 32 bit versions
18:09 karolherbst: not sure you can even build it as 64 bit
18:10 karolherbst: anyway.. that bug wasn't 32 bit specific.. but the llvmpipe one is :)
18:15 airlied: karolherbst: PIPE_CAP_COMPUTE_ADDRESS_BITS?
18:15 karolherbst: yeah
18:15 airlied: COMPUTE_CAP_ADDRESS_BITS evn
18:16 karolherbst: anyway, that needs to return the bits of the host machine I guess
18:16 karolherbst: currently checking if that's the only issue
18:17 airlied: just change it to sizeof(void*) * 8
18:17 karolherbst: but rusticl should be able to run a 64 bit GPU on a 32 bit host.. so maybe something funky is going on
18:18 airlied: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21601
18:31 karolherbst: oh yeah.. I see a few fails :)
18:31 karolherbst: let's see what's going on there
18:45 karolherbst: nice.. it's image arguments which are broken
19:24 dwlsalmeida: airlied Lynne Hey there, I am trying to cook up some initial vulkan video vp9 support in Mesa following along your footsteps. I have an AMD box which I can test through RADV. Do any of you have any documentation on the firmware interface? I am taking cues from radeonsi, but sometimes I miss a more unambiguous source.
19:25 airlied: dwlsalmeida: no the radeonsi interface is all the info available
19:27 airlied: dwlsalmeida: the interface is usually sane until you have to work out how references work
19:28 dwlsalmeida: airlied I noticed this was a problem with AV1 as well, IIRC? something about it being hard to uniquely identify a frame
19:28 dwlsalmeida: in v4l2 there's timestamps, so that was easy over there
19:29 airlied: yeah the fw appears to write some frame indexes into the context buffers, and gets upset when they are different
19:30 airlied: it was also a bit painful for h264, but more around how vulkan DPB mgmt is explicit
19:30 airlied: I thought av1 was the same problem, but it was slightly different
19:31 marex: mripard: hey, so, I spent a while communicating with jagan_ now and I think there is a cyclic dependency between DSIM probe and DSI83 bridge probe
19:33 marex: mripard: basically, since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/bridge/ti-sn65dsi83.c?id=6ef7ee48765fa3067858d11ecdf3acbc7c19df80 , sn65dsi83_host_attach() called from dsi83 i2c bridge driver .probe callback requires dsi_host to be available , at its .probe time
19:33 marex: mripard: if no dsi_host available, DSI83 does -EPROBE_DEFER and that's the end
19:34 dwlsalmeida: airlied Btw this confuses me -> void *render_pic_list[32];
19:34 dwlsalmeida: I assume this comes from h264 (i.e. 16 x 2 fields), and just carries over to the other codecs? because VP9 only has up to 8 frames as references at a time
19:34 dwlsalmeida: Also would you mind a quick review once this progresses a bit more? I can open up a MR same as you did
19:34 marex: mripard: at the same time, if DSIM bridge/host attemps to look up bridge in its .probe() callback, it fails with EPROBE_DEFER too, because the bridge driver didn't probe yet
19:34 marex: mripard: so, there is a cyclic dependency between DSIM host and DSI83 bridge , since they both depend on each other at .probe() time
19:35 marex: mripard: it seems that is why jagan was going on about the .attach time bridge look up all the time
19:35 DemiMarie: airlied: totally undocumented firmware interface? That sucks.
19:35 DemiMarie: I wonder if anyone has tried fuzzing the firmware.
19:37 DemiMarie: marmarek: this kind of stuff is why I am nervous about GPU security
19:37 airlied: dwlsalmeida: render_pic_list is a vaapi ism anyways
19:37 airlied: but yes it's sized for h264
19:45 dwlsalmeida: airlied do you happen to remember where this number comes from? -> #define RDECODE_VP9_PROBS_DATA_SIZE 2304
19:45 dwlsalmeida: The actual probability table is 2040 bytes long
19:45 dwlsalmeida: I do vaguely remember this number 2304 from somewhere though ...
20:08 airlied: dwlsalmeida: is it sizeof struct rvcn_dec_vp9_probs_s ?
20:21 karolherbst: airlied: seems like your llvmpipe pointer fix actually breaks 32 bit stuff now
20:21 karolherbst: https://gist.githubusercontent.com/karolherbst/fd278ba287ca2a3d945eb180d63835ab/raw/dddfa26d4e983bb5f04462fda3ec589898e8bf22/gistfile1.txt
20:22 karolherbst: uhh.. maybe there are just more bugs around somewhere...
20:23 mareko: tarceri: what does gl_nir_link_glsl/spirv need nir_link_opt_varyings for? can we move it after gl_nir_link_glsl/spirv?
20:28 agd5f: DemiMarie, if you have specific questions we can ask the firmware teams.
20:30 agd5f: er dwlsalmeida ^^
21:06 dwlsalmeida: airlied agd5f it isn't, that's why I am asking. I think I will run a frame through vaapi on my machine to dump the stuff from radeonsi and have a look, it will probably be a good starting point, but I will keep your suggestion in mind if I am totally stuck thanks a lot
21:08 airlied: dwlsalmeida: normally I just break on the get_*_msg functions and finish them and stare into the result structs
21:09 airlied: dwlsalmeida: for those buffers though it's normally just a matter of not caring or understanding
21:10 airlied: the fw wants what the fw wants, so you give it 2304 + 256
21:12 airlied: the 256 is for segment data
21:12 airlied: so it's likely the hw just left some extra space or aligned something
22:06 anholt_: nir_lower_precision so far increases freedreno reg pressure by 1%, instr count -.14% Now to go write unit tests and see if it's actually working as intended.
22:19 tarceri: mareko: no you want to remove varying before linking uniforms etc because you can eliminate more of the shader and uniforms
22:42 karolherbst: `rusticl_llvm_gen` the horros
23:40 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21612 I'm not sorry