01:33 cmarcelo: what is virpipe?
01:38 alyssa: iirc virgl on llvmpipe
01:38 alyssa: cmarcelo:
01:40 airlied: nope
01:40 airlied: it's virgl over a pipe
01:41 airlied: using drisw
01:43 alyssa: wild
01:43 cmarcelo: so, my undestanding is virgl is "OpenGL API that goes through the virtio gpu interface, relies on having something on the other side". so virpipe simulates the other side with LLVMpipe, or some other thing?
01:44 cmarcelo: (regular "other side" for virgl is the virgilrenderer)
01:45 alyssa: the virpipe-on-gl job is tagged as mesa-swrast so I assume so
01:45 airlied: cmarcelo: yeah virglrenderer has a unix socket based server
01:45 airlied: that is used for testing
01:45 airlied: and virpipe connects to that
01:46 alyssa: at any rate, the fails from the virpipe-on-gl job for scoped_barrier seem the same as the llvmpipe ones, so.. yeah
01:46 alyssa: i expect if you fix llvmpipe the virpipe fails goes away too
01:46 airlied: but yeah in CI it'll be llvmpipe in the end anyways
01:59 cmarcelo: alyssa: yes, I'm guessing would be the same
02:01 DavidHeidelberg[m]: alyssa: mesa-swrast tag meaning is limited to the more powerful runners (more expensive)
02:02 alyssa: ah
02:02 alyssa: also why am i thinking about ci on a sunday
02:02 alyssa: ("to avoid thinking about your homework on a sunday" "ah yeah that'll due it")
02:02 DavidHeidelberg[m]: ... sadistic feelings?
02:02 cmarcelo: airlied: I'm likely missing something here: gallium driver virgl ~~~> unix socket bypass ~~~> virglrenderer, where do we draw virpipe? (I thought it would replace virglrenderer, but seems... not?)
02:03 DavidHeidelberg[m]:looking forward to `venus -> zink`
02:03 DavidHeidelberg[m]: instead of virgl and virpipe
02:04 airlied: cmarcelo: no virpipe is just the drisw name for the gallium driver virgl bit
02:04 airlied: since we have multiple drisw drivers and need names to pick between them, llvmpipe, softpipe, virpipe
02:09 cmarcelo: let me try again, in the CI: gallium driver virgl ~~~> dri, but we pick drisw [virpipe variant] ~~~> unix socket bypass ~~~> virglrendered, which uses OpenGL ~~~> LLVMPIPE!
02:10 cmarcelo: airlied: ^
02:14 airlied: yes that is about right
02:15 alyssa: man i'm looking forward to the scoped_barrier only future
02:15 alyssa: I assume anyway that is the end game of this series
02:15 alyssa: setting use_scoped_barrier for every backend, and then removing the option and memory_barrier_* intrinsics altogether
02:18 cmarcelo: alyssa: yeah, that's the end game
02:18 cmarcelo: we have a few steps to go though
02:19 cmarcelo: i.e. I don't plan to do everything in this particular MR
02:24 alyssa: yeah, for sure
02:24 alyssa: i'll write the {midgard,bifrost,agx} patches of course
02:26 alyssa: Nominally scoped_barrier should already work for bifrost
02:26 alyssa: since I hit it with OpenCL
02:28 alyssa: cmarcelo: ooh, and then renaming scoped_barrier -> barrier since it'll be the only one
02:55 jenatali: And hope nobody is rebasing a multi-year-old change that references barrier
02:56 alyssa: jenatali: rebase conflicts make you stronger? :p
02:57 jenatali: It's one thing if it doesn't build but that conflict would be tricky
03:01 alyssa: jenatali: It wouldn't build
03:01 alyssa: there's not currently an intrinsic_barrier is there?
03:02 jenatali: Oh I thought there was
03:02 jenatali: Nevermind
03:28 hays: what is the most sensible way to get current screen resolution when still on the framebuffer (not in X)
03:35 airlied: hays: in what way, like inside an application?
03:36 hays: like when booting and showing a splash screen
03:40 kode54: some clever emulator author suggested to me that the reason Ryujinx is so slow in some titles on ANV is because ANV is "still optimized for integrated graphics"
03:41 kode54: (not a Ryujinx dev, but a nosy dev of another project)
03:43 alyssa: kode54: wdym
03:44 kode54: Soup Odyssey slows to 10-20fps on some areas on an A770, hitting 100% FIFO utilization and maxing out the rendering cores
03:44 kode54: VBA-M dev Squall Leonhart popped into my bug report to Ryujinx to say that the ANV driver isn't optimized for dedicated GPUs yet
03:45 alyssa: oh, that I would believe.
03:45 kode54: it is an interesting point though
03:46 kode54: considering that in Windows, rather than Intel adapting their Iris drivers to Arc, they started over from scratch
03:46 kode54: wonder if that would even be worth it for Linux
03:47 kode54: Xe DG1 may also benefit, since it's a dGPU of a different sort
03:47 kode54: but hell, that sounds like a nightmare, starting over
03:48 alyssa: Not an Intel developer but rewriting ANV seems completely uncalled for
03:48 kode54: indeed
03:48 alyssa: I would be unsurprised if the Windows rewrite was due to politics and not perf
03:49 kode54: maybe someone needs to buy zmike an Arc card
03:50 kode54: I didn't mean to imply that any of the existing code was bad, but it probably has choke points that uniquely affect dGPUs
03:50 kode54: maybe
03:51 kode54: I haven't profiled anything that does particularly bad to see where exactly it's choking
03:51 alyssa: I stand by ^
03:51 kode54: politics, indeed
03:51 alyssa: It is (almost) never warranted to rewrite mature codebases from scratch
03:52 kode54: I wasn't suggesting a rewrite either
03:52 alyssa: so if a corporate team does so anyway
03:52 alyssa: often there are political reasons :p
03:52 kode54: yeah
03:52 airlied: also not sure they rewrote their windows drivers from scratch
03:52 kode54: they certainly ripped out the DX9-11 parts
03:52 kode54: or made them worse
03:53 airlied: those are just pieces of the driver stack though
03:53 airlied: I think their windows d3d12/vulkan drivers might have a lot of common code
03:53 kode54: probably
03:53 airlied: and their media stack looks like they forked it inside itself in a horrible nightmare of code duplication
03:53 kode54: it's a right mess
03:54 kode54: and they've got the hugest driver package of any vendor right now
03:54 alyssa: airlied: why are we not shipping anv on Windows again
03:54 airlied: alyssa: politics :-P
03:54 alyssa: (-:
03:54 kode54: of course it is
03:55 alyssa: oh hey I fixed buffer textures on asahi
03:55 kode54: neat
03:55 alyssa: they were broken for like 2 months
03:55 kode54: oh wow
03:55 cmarcelo: kode54: I'm not particularly versed on the details of local memory, but: our kernel driver team is working on a new version of the driver https://patchwork.freedesktop.org/series/112188/ (there's a corresponding MR for anv to interface with that) that I expect will get us some improvements in that area.
03:55 alyssa: in agx/next I mean
03:55 alyssa: never opend an MR because of said broken
03:55 kode54: yeah, the Xe KMD
03:55 kode54: I was following that loosely
03:56 kode54: I'd definitely be open to actually shoving that into my system when it comes time to test it
03:56 kode54: assuming it's in a relatively ready state
03:56 kode54: I've already been running 6.2 since the first RC, building it myself
03:57 kode54: and running mesa-git with the intel-clc function enabled, also building that myself
03:57 kode54: well, with PKGBUILDs handily supplied by TkG
03:58 cmarcelo: kode54: what is the number for the gitlab issue you mentioned above?
03:59 kode54: oh, sorry, I need to report it on mesa tracker too
03:59 kode54: I initially reported it to Ryujinx, and forgot to post the Mesa issue
03:59 cmarcelo: ok
03:59 kode54: I'll grab the Ryujinx issue and link it on Mesa's tracker
03:59 kode54: I'll try to be a bit thorough with what I write
04:00 kode54: oh
04:00 kode54: someone else already posted an issue
04:00 kode54: I'll reply to it and track it
04:01 kode54: oh
04:02 kode54: it was a different game I found by chance
04:02 kode54: I'll reply to the issue nonetheless
04:06 kode54: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8375 issue just opened a day ago about various titles either underperforming compared to Windows or outright failing to run
04:10 cmarcelo: kode54: thanks for linking
04:17 kode54: funny issue one of those games not mentioned, but I know it's a performance issue nonetheless
04:17 kode54: Destiny 2 underperforms from what I've heard
04:17 kode54: but they can't just make it use DXVK on Windows
04:18 kode54: the game's stupid ass anticheat system will just ban people for that
04:18 kode54: I can't believe that PVP is a big enough proportion of their user base to even warrant a fricking anticheat system
04:19 kode54: then again, they also have a huge number of players who will create new characters and just camp out in the intro stages to powerlevel
04:19 kode54: that must be awfully boring
04:19 kode54: I want that game as a max 4 players game like Borderlands
04:20 kode54: screw this MMO with gacha elements cash cow crap
08:34 hakzsam: daniels: hi, any news on the vesnu-lavapipe front?
10:29 jani: drm-tip rebuild fails with https://paste.debian.net/1272275/ when merging drm-misc-next
10:31 MrCooper: bwidawsk cmeissl[m]: FWIW, if the DRM_IOCTL_MODE_ADDFB2 ioctl fails it's an issue on the compositor side, not the client side, so the device sent to clients in dma-buf feedback shouldn't matter
10:32 vsyrjala: client allocates the buffer does it not?
10:33 MrCooper: yes, but that can't cause the compositor to use a wrong GEM handle
10:37 MrCooper: it indicates some kind of mix-up in the compositor process, possibly in Mesa
10:50 kode54: god dammit
10:51 kode54: why does CONFIG_DRM_XE have no special requirements, but CONFIG_DRM_XE_DISPLAY requires CONFIG_EXPERT
10:51 kode54: I guess it doesn't assume I would be using a pre-baked distribution configuration as my starting template
11:02 mlankhorst: danvet: ping?
11:09 digetx: jani: hi, please let me know if you still have that shmem conflict because I don't have it (maybe I'm doing something wrong?)
11:13 vsyrjala: happens here too. currently on git 2.39.2, should that make a difference
11:15 vsyrjala: last drm-tip rebuild was on 25th, but the conflicting stuff was pushed on 27th. so i guess you didn't actually rebuild drm-tip?
11:17 digetx: have the same git version; when I run `./dim rebuild-tip; cd drm-tip; git diff`, it gives me conflicts for i915 and amdgpu only
11:18 jani: digetx: still seeing it
11:20 vsyrjala: digetx: so maybe you have a local conflict resolution for this in you rerere, but never pushed since you stopped the rebuild when encountering some i915/amdgpu conflicts?
11:21 jani: digetx: given the conflict in the paste, is just choosing the latter part the right resolution?
11:22 jani: apparently not, doesn't build
11:30 digetx: let me try to re-setup the maintainer-tools
11:30 jani: but why?
11:33 digetx: don't see any local conflict resolutions
11:40 kode54: I tested the Xe KMD
11:40 kode54: it can't find any functioning crtc
11:51 daniels: cmeissl[m]: yeah, so the root of your issue is that FD_TO_HANDLE is failing. that's telling you that you can't import the dmabuf into your scanout device. anything beyond that is not going to give you good results. it sounds like this is being caused because platform_wayland isn't invoking the kmsro infrastructure to make it aware of the scanout device as well. probably a bunch more typing required there. this does work for most
11:51 daniels: devices, but i.MX6 is just the worst possible case.
11:53 jani: digetx: no matter what, the last drm-tip rebuild as well as last drm-rerere update was 2023y-02m-25d-19h-52m-27s UTC
11:54 daniels: hakzsam: I know people were busy last week, so I've kicked again
11:54 daniels: hakzsam: tintou is looking into itnow
11:55 jani: tzimmermann: mripard: mlankhorst: please look into getting the conflict between drm-misc branches resolved
11:57 jani:.oO( if we were doing gitlab merge requests, it could warn in advance that merging something will cause a drm-tip rebuild conflict instead of after the fact )
11:58 tzimmermann: jani, looking...
12:03 tzimmermann: jani, fixed
12:04 tzimmermann: the problem is that people land their patches and then walk away without looking for errors in the merge process
12:06 hays: was going to ask again, sorry for the repeat, but i am curious if anyone can recommend tools or methods to get screen resolution and sizing reliably before X is running?
12:07 hays: i found fbset which is a little helpful, but I dont have an /etc/fb.modes
12:09 hays: am trying to (1) find out which device is connected (2) what the maximum or recommended resolution is, set that resolution
12:10 cmeissl[m]: MrCooper daniels thanks! yes, I did try calling primeFdToHandle directly and it indeed already fails, so the failure of drmModeAddFB2 is to be expected. So I was on the right track with kmsro at least. From the code I am not sure how kmsro is expected to work in combination with dmabuf feedback. When I send the render node from etnaviv (renderD128) as the main device it will happily use dmabuf feedback, and also set the required
12:10 cmeissl[m]: `__DRI_IMAGE_USE_SCANOUT` flag if a scan-out tranche is sent, but it won't initialize kmsro. Sending card1 (imx-drm) as the main device will initialize kmsro, but disable dmabuf feedback and fallback to wl_drm. I guess that is caused by `loader_get_render_node` returning NULL in `default_dmabuf_feedback_main_device`.
12:12 digetx: tzimmermann: hoped that refreshing of maintainers-tool will help (it's fetching src git a bit too slow), not sure why I don't see that conflict
12:13 cmeissl[m]: And am I right, that as long as the client does not initialize kmsro it is expected to fail?
12:13 tzimmermann: no idea
12:13 digetx: now I'm thinking that I may've had a local remote branch that helped to resolve the conflict
12:14 tzimmermann: digetx, how old is your git. IIRC older git versions don't deal well with new tools. but i don't remember the exact problems they had
12:14 vsyrjala: i don't rebuild-tip should use local branches (apart from rerere)
12:15 vsyrjala: i don't think...
12:15 tzimmermann: yeah, the local branch does not affect the merging
12:16 digetx: "git version 2.39.2"
12:16 tzimmermann: same as here
12:16 digetx: (gentoo)
12:16 tzimmermann: then this isn't the problem either
12:17 tzimmermann: anyway, it's now fixed https://cgit.freedesktop.org/drm/drm-tip/commit/
12:19 vsyrjala: an now it doesn't build
12:20 vsyrjala: ../drivers/gpu/drm/drm_gem_shmem_helper.c:651:15: error: implicit declaration of function ‘drm_gem_shmem_get_pages_locked’; did you mean ‘drm_gem_shmem_get_pages_sgt_locked’? [-Werror=implicit-function-declaration]
12:21 jani: <jani> digetx: given the conflict in the paste, is just choosing the latter part the right resolution?
12:21 jani: <jani> apparently not, doesn't build
12:21 jani: the same error : |
12:22 jani: pro-tip, when resolving something in drm-tip, just do make olddefconfig; make path/to/conflicting/file.o
12:22 jani: before actually committing
12:23 vsyrjala: i just test build the whole thing
12:27 digetx: jani: yes, the pages_lock is replaced with the resv lock
12:29 digetx: the drm_gem_shmem_get_pages_locked isn't correct, though
12:30 digetx: jani: not sure where you've got the
12:30 digetx: - ret = drm_gem_shmem_get_pages(shmem);
12:30 digetx: + ret = drm_gem_shmem_get_pages_locked(shmem);
12:30 digetx: it should be the other way around
12:33 jani: it's a conflict between drm-misc-next-fixes and drm-misc-next
12:33 digetx: the drm_gem_shmem_get_pages() is always locked after conversion to use resv locks, I dropped the _locked() part
12:33 jani: ddddedaa0db9 ("drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()")
12:35 emersion: mripard: hm it seems like vc4 calls drm_mode_create_tv_properties() but ignores tv brightness?
12:36 mripard: afaik, it only uses the TV margins yeah
12:36 emersion: then it's incorrect to call drm_mode_create_tv_properties()?
12:36 emersion: vc4/vc4_vec.c:756: ret = drm_mode_create_tv_properties(drm,
12:38 kode54: xe kmd fails here with these traces: http://ix.io/4pms
12:38 digetx: jani: but both next and next fixes have ddddedaa0db9
12:39 danvet: mlankhorst, back from vacations
12:41 vsyrjala: emersion: creating the props should be fine. but attaching props you don't support would be wrong
12:41 emersion: ah
12:43 emersion: hm, weird, gud seems to support tv_brightness but doesn't expose it
12:43 emersion: doesn't attach it*
12:44 emersion: the only driver to attach it is ch7006
13:00 digetx: jani: now I see that it's actually drm/drm-next that fails to merge for drm-tip and not misc-next, do you have conflict resolution for drm-next? or how it all works, what am I missing :)
13:04 jani: digetx: drm-tip rebuild (regeneration) works fine now; unfortunately the actual build fails due to the wrong conflict resolution
13:04 jani: digetx: are you new to dim?
13:04 jani: no value judgement there; just checking the facts ;)
13:05 DavidHeidelberg[m]: mupuf: 👀curl for the container, pretty please :P
13:06 digetx: jani: kind of new to dim, yes; I can apply patches with dim, but skipped the drm-tip part because previously all the conflict were complicated and irrelevant to my changes
13:08 jani: digetx: well, basically applying patches with dim must include addressing any resulting conflicts in drm-tip rebuild. whoever applies patches and it causes conflicts in drm-tip rebuild is on the hook for either resolving them or pulling in folks to help
13:09 jani: digetx: if you leave them unresolved, the conflicts pile up as people apply more, and it gets harder
13:11 vsyrjala: hmm. could we make dim do a test rebuild-tip _before_ pushing anything new? would prevent conflicts from piling up and thus making it hard for any single person to resolve the mess
13:11 jani: if you develop on top of drm-tip, and send patches from there, and they fail to apply to an individual branch, it's a good indicator a conflict will occur
13:12 jani: vsyrjala: it's racy, as is the current approach
13:14 jani: adding the local build of drm-tip makes the race window longer
13:15 digetx: seems I figured out what was going on wrong all that time.. I had rerere disabled in my .git global config
13:16 vsyrjala: jani: i suppose. though i don't think our usual problems have been due to the racyness. more because people forget to check the results of the rebuild
13:17 vsyrjala: another idea could be to have ci/something complain if drm-tip is lagging behind
13:18 zmike: mareko: did you have issues with the tc query MR or just questions
13:18 digetx: jani: finally, I've the drm_gem_shmem_get_pages_locked -Werr after fixing rerere \o/
13:18 jani: digetx: right, maybe send a patch to dim to check that config ;)
13:19 jani: vsyrjala: I've had some ideas wrt that, it could flag the conflicts and identify which patch/push caused it and everything, but it's the kind of yak shaving that doesn't just happen :(
13:47 digetx: jani: so that drm_gem_shmem_get/put_pages_locked build error in drm-tip now is due to a wrong merge conflict resolution? should me/we do anything about it?
13:48 vsyrjala: you need to revert that from rerere, and then do it right
14:07 nroberts: does anybody know if the Intel CI has a rust compiler? would it be a pain if the rust port of vkrunner was merged into the master branch? it would at least have to be updated to build using ninja instead of cmake
14:13 digetx: jani: vsyrjala: should be fixed now
14:15 nroberts: I mean meson
14:16 vsyrjala: digetx: builds now. thanks
14:17 digetx: awesome, thank you all! the disabled rerere in my git confit was very obscure and confusing to me
14:18 vsyrjala: digetx: btw i see you ended up with some extra reverts in rerere. 'dim -d rebuild-tip' is useful when messing about with conflicts. i always use that until i have it fully nailed down, and then drop the -d for the final rebuild
14:20 digetx: indeed, missed the dry-run option, thanks
14:21 daniels: cmeissl[m]: the client needs to receive etnaviv as the main device indeed, because etnaviv _is_ the main device - it's the fallback which is used for composition in case it's not possible to use planes, so the buffers always need to be accessible to etnaviv. I think the optimisation is substantially reworking the DRIScreen/pipe_screen/kmsro/etc integration so that we can pass preferred_device down to the driver layer, and it can
14:21 daniels: open kmsro if required
14:30 DavidHeidelberg[m]: eric_engestrom: merge: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21518 ?
14:32 eric_engestrom: DavidHeidelberg[m]: yes, sorry I was off on friday for a long weekend and I haven't gotten around to that MR yet, but I'll add the r-b and marge in a minute
14:32 mupuf: DavidHeidelberg[m]: yeeeees! On it now :)
14:32 DavidHeidelberg[m]: all good news, I love this chat :D
14:33 DavidHeidelberg[m]: eric_engestrom: hope you enjoyed the weekend to the 100% ;-)
14:34 DavidHeidelberg[m]: sse2 fixes got it, armv7 lto workaround awaits, android fix to be merged, mold fix in main branch should probably solve LTO fail when linking release build. Life is great.
14:35 eric_engestrom: :D
14:55 cmeissl[m]: daniels: oh, that doesn't sound like the easiest thing for someone still pretty unfamiliar with the inner workings of mesa. but, yes, using the target tranche device sounds like the best solution. out of curiosity I patched loader_get_render_node to return the primary node if no render node could be found and changed the feedback in the compositor to use card1 as the main device. Both paths, scan-out and composition, still work.
16:25 karolherbst: could somebody look at why gc2000_piglit times out
16:26 karolherbst: probably serial console spam.. anyway, would be nice if somebody looks into it
16:26 karolherbst: zmike: already aware of the UnexpectedPass with zink?
16:26 zmike: what
16:26 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/37035888#L3220
16:27 karolherbst: seeing this randomly pop up in a few MRs, but I can also send an MR
16:27 karolherbst: just wondering if anybody already sent an MR
16:29 zmike: no, never seen those
16:29 MrCooper: UnexpectedPass should arguably cause the job to fail
16:29 zmike: I don't usually look at the full run results
16:29 karolherbst: yeah.. I mean, yes, jobs fail, that's why I'm bringing it up
16:29 karolherbst: I'll submit an MR
16:29 zmike: I wasn't aware that the full run occurred on wayland
16:30 zmike: karolherbst: you can ack and merge it directly
16:30 zmike: add my ack*
16:30 karolherbst: my fear is, it's just some flakes, but I'll see how well that goes
16:30 daniels: (specifically, add it to flakes, not passes)
16:30 daniels: as for gc2000, those jobs are manual for a reason - they're not expected to work all the time
16:31 karolherbst: ohhh
16:31 karolherbst: it's all multi_context .. duh
16:31 karolherbst: sooo..
16:32 karolherbst: something has a threading bug
16:32 daniels: shocked
16:32 karolherbst: very much so
16:33 karolherbst: best part: "warnings from the kernel" yeah I can already figure where that bug lives
16:34 karolherbst: I'll move the entire section into flakes...
16:37 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21561
16:44 daniels: karolherbst: danke!
16:44 eric_engestrom: karolherbst: if you leave them in the fails as well, that means they only get reported as flakes when they pass, which I think is rare
16:45 eric_engestrom: (aka less #zink-ci spam)
17:32 marex: I am curious, there is a patchset which adds support for feeding multiple encoders->bridges from single crtc for lcdif driver , is that something that one can really do ?
17:32 marex: mripard: ^
17:32 marex: my understanding is they read the same base plan using crtc and then pump it out into some "tee" which feeds the encoders and then bridges, all of them with the same data, at the same time
17:33 mareko: zmike: both
17:33 marex: I am a bit hesitant to review that stuff
17:34 mripard: I have no idea whether the hardware is capable to do it
17:34 mripard: but KMS definitely can
17:34 zmike: mareko: ok, I am awaiting your followup with bated breath
17:35 mripard: https://elixir.bootlin.com/linux/latest/source/include/drm/drm_encoder.h#L151
17:35 marex: mripard: the hardware can do it
17:35 marex: mripard: it is the first time software needs to do it
17:35 marex: at least on imx scanout engines as far as I can tell
17:37 marex: https://patchwork.freedesktop.org/series/113210/ its this series
17:46 javierm: robclark, danvet: what if instead of adding a CONFIG_DRM_VIRTIO_GPU_KMS kconfig symbol, the driver is changed to only disable the KMS part with "nomodeset" ?
17:46 javierm: something like the following (untested) patch? https://paste.centos.org/view/raw/921ca0a4
17:46 javierm: that way you could just boot your guest VM with virtio-gpu.modeset=0 or nomodeset
17:47 danvet: yeah that might be a notch cleaner solution for the one-off-custom-built-distro case
17:48 danvet: it won't work in general, e.g. if you also pass through an actual virtualized display and not virtio-wayland
17:48 robclark: hmm, I guess that fits the name, but diverges a bit on how other drivers interpret nomodeset
17:48 danvet: since that would then also get disabled
17:48 danvet: robclark, i915 did it like that in the good old days of ums gem support :-)
17:48 javierm: robclark: not really, in fact many drivers only disable KMS with nomodeset
17:49 javierm: robclark: in fact, DRM only drivers just ignore that option
17:49 danvet: yeah plus that
17:49 robclark: hmm, well, I could *also* possibly add modparam option.. but the build option still works best for us
17:50 javierm: robclark: right, not strong opinion for me. I just wanted to point out that there could be an alternative approach :)
17:51 javierm: regardless, it would be good if all drivers only disable KMS with nomodeset instead of just failing to probe
17:52 robclark: the build option is less subtle, and that makes it easier for folks triaging bug bounty program reports
17:53 anholt_: sergi: what's the deal with the piglit uprev mrs being testonly and getting closed? I would really like to see piglit updated, but I haven't done it because you're clearly working on it, but you keep closing them.
17:57 marex: mripard: btw may I ask you to be a bit more patient with Jagan ? The samsung patches are in like v14 now, it would be really good to finally get those merges, and I think there is like one single outstanding issue now
17:58 mripard: a single outstanding issue we've been discussing since v9 iirc
17:58 mripard: and that he always ignored
17:59 mripard: and he managed to ignore it in both submissions he did today
17:59 marex: mripard: I am aware of that, but I'm afraid stomping on it with NAK isn't going to achieve the right outcome
17:59 mripard: so no, sorry, I believe I've already been more than patient on this one
18:00 marex: mripard: lemme have a look at that discussion again
18:00 mripard: I mean, it was a NAK unless you change it
18:00 mripard: if he changes it, then I'll happily reconsider it, and I already provided what he needs to change it and make me happy
18:01 mripard: at this point, I'm not sure what I can bring to the discussion, hence why I wrote that.
18:06 marex: mripard: is my understanding correct, that all he has to do is s@devm_@drmm_@ ?
18:07 marex: hm, no ...
18:08 sergi: anholt_: the bot is trying uprev_piglit_in_mesa every night but some jobs doesn't produce artifacts when uprev piglit. In a case like that, what the bot does is to create an issue in the target project (aka mesa) https://gitlab.freedesktop.org/mesa/mesa/-/issues/8360
18:09 mripard: marex: he needs to move the call to drm_of_find_panel and bridge to bind
18:09 mripard: first
18:10 mripard: then create the drmm helper you were mentioning
18:10 mripard: and this whole dance to work around the fact that you don't have a pointer to the drm device is moot
18:11 anholt_: sergi: so you just keep opening and closing MRs, and then what's supposed to happen? Are you investigating those issues?
18:12 marex: mripard: to ... bind ?
18:12 marex: mripard: or to samsung DSIM driver probe ?
18:12 marex: mripard: which bind ?
18:12 marex: struct mipi_dsi_host_ops has no ->bind callback
18:13 marex: I do see of_drm_find_panel() used in driver probe callbacks however
18:13 mripard: to exynos_dsi_bind
18:14 sergi: anholt_: MRs with the tag "testonly" are from my user while testing the tool. The bot is running it every night and should create MRs without this tag. In case the bot cannot complete the process, it creates an issue trying to explain. At this point, who will integrate an uprev proposal would come from one that knows more than I. About investigating the cause of the issue, you are right, I can do that. At least start, and request help in case I
18:14 sergi: don't know more.
18:15 marex: but wait, that's outside of this driver, the DSIM bridge driver can also be used by i.MX 'lcdif' and 'mxsfb' drivers
18:15 marex: er, please ignore that
18:17 marex: mripard: actually, no, dont ignore that ... should the drm_of_find_panel also go into samsung_dsim_register_host ?
18:17 marex: mripard: as far as I understand it now, drivers/gpu/drm/exynos/exynos_drm_dsi.c is the Exynos glue code , samsung_dsim_register_host and co is the i.MX glue code
18:18 mripard: marex: you can't use drm_of_find_panel or its bridge variant
18:18 mripard: I mean, you can, DSIM is the proof of that, it's just broken.
18:19 mripard: and you can end up in probe deadlocks depending on the situation
18:19 marex: mripard: let's just focus on the first part , i.e. the "move ... to bind", first
18:19 marex: mripard: and then second which exact function to use
18:19 sergi: anholt_: would be nice if we (together) can think in a workflow. I have an idea about the thinks that could be made automatically with the "post" uprev section https://gitlab.freedesktop.org/gfx-ci/ci-uprev/-/issues/27 But there are things, like what you mention about investigate the issue, that requires a human
18:20 mareko: radeonsi can't fully switch to scoped barriers due to differences between LLVM and ACO
18:20 marex: mripard: so do I understand it right that the ... drm_whatever_panel ... should be called from both exynos_dsi_bind() and samsung_dsim_register_host() ?
18:21 marex: basically before mipi_dsi_host_register() ?
18:21 cmarcelo: mareko: what information is missing in the scoped barrier?
18:21 mripard: samsung_dsim_register_host isn't in the current source tree, so I don't know for that one
18:21 mripard: but it must be called at bind time
18:22 marex: mripard: so do I understand it right that the ... drm_whatever_panel ... should be called from both exynos_dsi_bind() and samsung_dsi_register_host() ?
18:22 marex: errr ...
18:23 mripard: drm_whatever_panel must be called at bind time
18:23 marex: mripard: try generic_dsim_register_host
18:24 marex: ... which is called at ... ugh
18:24 mripard: not in 6.2 either
18:24 marex: mripard: its in patch v13 14/18
18:24 mripard: but how the driver is organized is pretty much orthogonal. If that function is called directly by the driver bind, then fine
18:24 anholt_: sergi: my workflow recommendation would be: drop [TESTONLY] from the MR title once your testing and conclusion-writing process is done, but keep the MR open. Then people can see it. Report the problems in the MR instead of an issue, because that text is only really useful in the context of the MR. Also, s/TESTONLY/WIP/ would make more sense.
18:24 mripard: if it isn't, then it's pbroken
18:25 marex: mripard: its actually called from platform driver ->probe callback
18:25 marex: mripard: that should be OK, no ?
18:26 mripard: https://patchwork.kernel.org/project/dri-devel/patch/20230227113925.875425-5-jagan@amarulasolutions.com/
18:26 mripard: that one is definitely not ok.
18:26 marex: that much I understand, yes
18:27 marex: mripard: should it go into https://patchwork.kernel.org/project/dri-devel/patch/20230227113925.875425-13-jagan@amarulasolutions.com/ just before +return mipi_dsi_host_register(&dsim->dsi_host); ?
18:27 mripard: and in 14, samsung_dsim_host_attach isn't bind either
18:29 sergi: anholt_: The "testonly" tag is from local executions on my machine or from a pre-merge pipeline in ci-uprev (this project uses also marge and tries the uprevs). But those MRs with this tag are only experiments, not made to be used later. The gfx-ci-bot has an scheduled pipeline each midnight (in UTC terms) and creates what we may call "production" MRs for uprev. Those are real candidates.
18:29 mripard: mipi_dsi_host_register is called at probe time, which isn't bind?
18:29 marex: mripard: yes, that's called at probe time
18:30 mripard: then no?
18:30 marex: mripard: so ... which bind ?
18:30 marex: mripard: just, point me to the structure name I am looking for
18:30 sergi: anholt_: But yes, in this case, I'm seeing that I was producing uprev candidates since enter in production. And after that, this piglit uprev starts having trouble with some jobs and their artifacts creation.
18:31 mripard: marex: it's late, it's a driver I don't know, patches I wasn't cc'd for
18:31 mripard: I'm not going to dig into a 15 patches series
18:31 sergi: anholt_: I'll review why those jobs are failing and see if there is something I can do, or ask for help
18:31 marex: mripard: mipi_dsi_host_ops doesnt have a bind callback
18:31 mripard: my review is, since 5 versions, follow the doc: https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
18:31 anholt_: ok, so I guess I've only ever seen your personal test MRs, not the production ones? Have any production ones been generated yet?
18:32 marex: mripard: and each driver which uses of_drm_find_panel does so in driver probe
18:32 mripard: well, each driver is broken then
18:32 mripard: vc4 isn't though.
18:33 mripard: I'm really not sure how it's an argument though.
18:33 marex: mripard: but vc4 isnt a bridge, is it ?
18:33 marex: mripard: I am not arguing, I am trying to understand what to change to move the discussion forward
18:35 marex: mripard: oh component_ops ->bind ?
18:36 mripard: vc4_dsi is a bridge in drm-misc-next
18:36 mripard: https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c
18:36 marex: mripard: https://cgit.freedesktop.org/drm-misc/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1805 so this bind is the one you're talking about ?
18:39 mripard: yes
18:39 marex: mripard: OK, understood, and thanks for the example, that helps a great deal
18:40 marex: mripard: but there is one more problem here, the imx side doesn't use the component stuff
18:40 alyssa: 23:53 <gfxstrand> The other thing is that the pass right now assumes your back-end uses it for everything. It takes bytes rather than a (bit_size, num_components) pair as the input to the callback. It doesn't distinguish between, say, a u8vec4 and a uint if they're both 4B aligned. That's fine for all the HW I'm familiar with, though.
18:40 alyssa: 23:53 <gfxstrand> Maybe not the most friendly for API translation but fine for HW.
18:40 alyssa: It does lead to some silly things, though
18:40 mripard: marex: then I think you can get away with it by calling it in probe
18:40 sergi: anholt_: I think it didn't have the opportunity to create a single one in production
18:41 alyssa: Like an aligned u16vec4 turning into a u32vec2 and a pile of unpacks
18:41 marex: mripard: ahhhhhh
18:41 mripard: so I guess you'd need two callbacks, one supposed to be called in probe, the other in bind
18:41 marex: mripard: THANK YOU
18:41 mripard: exynos would call the probe callback in its probe, and the bind in its bind
18:41 marex: mripard: I think I understand it now
18:41 alyssa: This shouldn't be a problem for AGX since we can coalesce away all the packs
18:41 alyssa: *unpacks
18:41 mripard: while imx would call both the probe and bind callbacks in its probe
18:41 mripard: that would probably work
18:41 alyssa: IDK if the Bifrost compiler is that smart.
18:41 alyssa: gfxstrand: ^ sorry that got split up across threads
18:42 mripard: but I'd still test those odd cases in the documentation on imx
18:42 marex: mripard: I'll try to summarize that and provide feedback ... and, I cannot test on exynos, so all my tests happen on imx
18:42 marex: mripard: that part should be covered at least
18:43 sergi: anholt_: I see the source of the problem. I hope I'll have a solution soon
18:48 marex: mripard: and the function name would them be still of_drm_find_panel() or some drmm_ variant ?
18:49 mripard: it doesn't really matter, it'd be better to use a drmm function straight away, but if you don't want a managed version that's fine too
18:50 mripard: a device managed version is not really an option though
18:50 marex: so unbind has to do clean up?
18:55 marex: mripard: OK, mail is out, let's see what happens
18:55 marex: mripard: thanks for clarifying this to me
18:55 mripard: you're welcom
19:09 gfxstrand: alyssa: If there's genuine value in doing so, we could make the callback take an actual (bit_size, num_components) pair. It's just a bit of a pain to maintain that in the case where we end up splitting something into multiple loads.
19:09 gfxstrand: I guess we could always reduce everything to the smallest bit-size you've ever requested or something dumb like that.
19:10 gfxstrand: And so far, I've primarily worked with two flavors of hardware that need this sort of splitting:
19:10 gfxstrand: 1) AMD/Intel where there's a scalar unaligned load/store that needs to be used for align < 4 and a 4B-aligned vector load/store which you use for everything else.
19:11 gfxstrand: 2) NVIDIA where load/store operate on any power-of-two size from 1B to 16B and it requires the same alignment as the amount of data being accessed.
19:11 gfxstrand: In both cases, they're happy to eat a bit of pack/unpack.
20:08 alyssa: gfxstrand: Yeah that's valid
20:08 alyssa: AGX/Mali are class #2 generally speaking
20:16 alyssa: Well, Mali is #2
20:17 alyssa: AGX is 1B/2B/4B elements requiring natural alignment and you can do up to 4 of them at a time
20:17 gfxstrand: Ok, that's a bit weird
20:17 alyssa: meh, it's basically spicy #2
20:17 jenatali: DXIL looks like AGX too
20:18 alyssa: jenatali: obviously, everyone knows that Direct3D was designed for Apple GPUs right?
20:18 jenatali: Obviously
20:18 alyssa: or was it Apple GPUs designed for Direct3D?
20:18 alyssa: i forget
20:18 alyssa:adjusts tinfoil hat
20:18 gfxstrand: I mean, if someone wants to figure out what the loops should look like operating on bits/comps instead of raw bytes, I'm not opposed.
20:21 alyssa: I don't think there's any benefit for AGX
20:22 alyssa: but I haven't thought about this in too much detail
20:22 gfxstrand: I doubt there's much benefit to DXIL, either, given that it's going to get converted right back into one of the two modes by the client driver anyway.
20:23 alyssa: Provided that we can coalesce the unpacks, I imagine i32vec2+unpack is equal perf to the original i16vec4
20:23 gfxstrand: probalby
20:23 alyssa: (Just carrying the restriction that it needs 4 byte alignment instead of 2)
20:23 gfxstrand: But that's for RA to sort out
20:23 gfxstrand: And RA is magic
20:23 alyssa: Oh... and it requires its destination to be 2-reg aligned instead of unaligned
20:24 alyssa: which (once RA is competent) does not affect register pressure but might result in extra moves/shuffles due to unnecessary live range splitting
20:25 alyssa: basically where I'm at is, I think the splitting logic is fine in the cases we really do need to split
20:25 alyssa: but it's a bit of a blunt hammer that ends up splitting for instrucitons that didn't actually need the split
20:26 alyssa: if I could filter on (num components, bitsize) but do splitting in terms of bytes, that'd probably be good enough 99% of the time
20:27 alyssa: as it is, I don't think I can distinguish i64 scalar loads (which need to be split) from i32vec2 and i16vec4 loads (which don't)
20:28 alyssa: (for the RA friendliness, possibly I could promote i32vec2 loads to i16vec4 at isel time. but that'll probably be worse overall because you really did want the alignment when the result is used as a 32-bit scalar)
20:28 gfxstrand: I think today's project is parallel copy lowering.
20:28 alyssa: Seems legit
20:28 alyssa: I copypasted cwabbott's code, twice
20:28 alyssa: Works like a charm
20:29 alyssa: Even added unit tests
20:29 gfxstrand: I should probably look at how ACO does it and use a better data structure so Daniel doesn't chide me for chosing confusing algorithms. 😅
20:29 alyssa: who cares what data structure you use
20:29 alyssa: this isn't exactly a hotspot :p
20:30 alyssa: Vec<all the things!>
20:30 gfxstrand: lol
20:31 gfxstrand: More that the NIR impl aparently confuses people.
20:42 mareko: cmarcelo: no information as far as I know
20:50 cmarcelo: mareko: can you elaborate on the differences between ACO and LLVM you were talking about earlier?
20:53 mareko: cmarcelo: nir_var_shader_out in the scoped barrier is handled differently between ACO and LLVM
21:00 DemiMarie: Would Mesa be better off without using LLVM for AMD and just generating AMD shader machine code directly?
21:00 gfxstrand: Oh, you mean like RADV does with ACO?
21:00 gfxstrand: DemiMarie: ^^
21:01 gfxstrand: DemiMarie: I think that depends on who you ask. 😅
21:01 DemiMarie: gfxstrand: no idea what RADV or ACO mean
21:01 gfxstrand: RADV is the Vulkan driver for AMD HW that's in Mesa.
21:01 gfxstrand: ACO is the non-LLVM back-end compiler it uses.
21:03 gfxstrand: DemiMarie: Short version is that all the big pieces are in place such that radeonsi could switch over. Some work would have to be done to get ACO working with GL. It's got some Vulkan or RADV assumptions in it today and radeonsi has a bunch of LLVM assuptions.
21:03 gfxstrand: Nothing that isn't fixable.
21:03 gfxstrand: But various parties have differing interests so there hasn't been a concerted effort to make it happen.
21:03 DemiMarie: Will Zink eventually be the only OpenGL driver?
21:04 jenatali: Doubtful
21:04 DemiMarie: Is this for performance reasons?
21:04 pixelcluster: gfxstrand: iirc aren't there some people working towards ACO with GL?
21:05 pixelcluster: I think I remember seeing MRs hinting that
21:05 gfxstrand: pixelcluster: There's been various people who've chipped away a bit.
21:05 pixelcluster: I see
21:05 zmike: I'm using it with GL every day!
21:06 DemiMarie: What advantages does ACO have over LLVM?
21:07 ccr: I have no idea, but I'd bet one of the biggest advantage is that it's not LLVM :P
21:07 gfxstrand: hehe
21:07 gfxstrand: Probably the biggest advantage is that it's blazingly fast
21:07 gfxstrand: While LLVM is a bit of a pig.
21:07 gfxstrand: I think the AMD folks have gotten their LLVM compile times manageable but it's still LLVM.
21:08 DemiMarie: Also LLVM aborts on OOM.
21:08 DemiMarie: Are LLVM’s optimizations useful here?
21:09 alyssa: gfxstrand: hey that's mean
21:09 alyssa: to pigs
21:10 gfxstrand: alatiera: :P
21:10 gfxstrand: alyssa, rather
21:51 agd5f: DemiMarie, LLVM has a lot of useful stuff for compute (e.g., support for functions, and eventually debugger support with GDB) that may be useful for gfx eventually.
21:55 gfxstrand: We should start seeing functions pop up in NIR compilers before too long, I think.
21:57 jenatali: I'd love to see debug data support come through
21:58 jenatali: Not looking forward to writing the PDB writer for DXIL but I am looking forward to source-stepping
21:58 gfxstrand: Yeah, I need to go see where that's at.
21:58 gfxstrand: I know there were some NIR patches. I gave some comments. Some things happened. IDK where they're at now.
22:23 karolherbst: yeah, let's ditch llvm, it's a constant pain 🙃
22:24 karolherbst: (still wants to see aco hooked up in radeonsi)
22:24 karolherbst: gfxstrand: it essentially works, I might have one or two patches, but nothing huge
22:24 karolherbst: there are two bigger issues I'm seeing with proper function support in nir
22:25 karolherbst: 1. a proper function inlining pass
22:25 karolherbst: 2. backends
22:33 agd5f: modulo dealing with the DWARF standards body, we have GDB support in branches today, at least for compute, more or less on par with what you'd get from a CPU
22:33 danvet: airlied, you need to fix your dim setup so no copypasting is needed, dim gets the subject right :-P
22:38 gfxstrand: karolherbst: Those are a couple of load-bearing issues you've got there. 😅
22:38 airlied: danvet: oh I don't use dim to send the pull requests
22:38 airlied: because I don't use mutt
22:38 karolherbst: gfxstrand: yeah.. guess why I didn't started to look into it yet :)
22:38 danvet: airlied, ask jani
22:38 airlied: I only use dim to produce the pull request txt
22:38 danvet: yeah I know :-)
22:39 airlied: but I don't want to use dim to send me PR either
22:39 karolherbst: though I still plan to do the work for llvmpipe + radeonsi and see where it goes
22:39 karolherbst: but other drivers will probably have to do the work themselves
22:39 airlied: I write it up in gmail, but yes the subject line is my defeat
22:40 danvet: iirc what jani has done is do a little script to drop the output of dim into a draft or something suitable for whatever thing you're using
22:40 danvet: but that was for notmuch
22:40 danvet: and set that script as DIM_MUA
22:41 airlied: I could have it email me I suppose and then edit the email before sending it on
22:41 danvet: fwd: [GIT PULL] drm-next would be hilarious
22:42 airlied: yeah I'd still find a way to screw it up
22:44 jani: danvet: I actually upstreamed a notmuch-emacs-mua script to mimic mutt cli interface for composing. it generates the email, but I can edit and hit send at my leisure after that
22:45 airlied:doubts there's a neat gmail integration here :-P
22:45 jani: airlied: I'm sure it's just a SMOP
22:45 airlied:can't even spawn firefox since it's a remote machine
22:46 airlied: jani: indeed!
22:47 jani: it could be a merge request on gitlab where some action generates and sends the pull request mail
22:48 airlied: yes that would be a later dream :-P
22:49 jani: the sad part is, this is all just git, with a lossy medium in between
22:50 jani: and pr-tracker-bot is a hack that monitors and cross-references a mailing list and a git repository
22:58 jenatali: Question for a Vulkan expert: Is it valid to dynamically index between samplers that are bound to a pipeline as immutable samplers?
22:59 gfxstrand: yes
22:59 gfxstrand: They're just samplers
22:59 gfxstrand: From a shader POV, they're not different.
22:59 gfxstrand: Unless you're doing YCbCr
22:59 jenatali: Alright
22:59 jenatali: D3D puts a restriction there FWIW
23:02 gfxstrand: I guess it's possible Vulkan has some but I'm unaware of them.
23:04 gfxstrand: They do get weird around descriptor buffers.
23:04 gfxstrand: IDK why we allowed the two to interact, TBH. We should have just killed off immutable samplers except for YCbCr.
23:04 jenatali: Yeah
23:04 jenatali:shrugs
23:05 Wallbraker: Arg I can't remember the name for the thing, but like everything in a execution wave needs to select the same sampler.
23:05 jenatali: Dynamically uniform
23:05 Wallbraker: That's that the!
23:06 Wallbraker: the name*
23:07 jenatali: Alright well then I guess I'll have to not map them to static samplers when supporting descriptor_indexing
23:07 jenatali: Oh well
23:09 Wallbraker: I would check the spec, as my memories is very hazy here.
23:12 Wallbraker: https://www.khronos.org/opengl/wiki/Sampler_(GLSL)#Non-uniform_flow_control
23:47 alyssa: karolherbst: proper inlining is the biggie
23:48 alyssa: backend support will be churn but whatever, I'm not scared of it
23:48 alyssa: I would type the patches if there was a point (right now there's not, absent proper inlining)
23:56 anholt_: tarceri_: removing grafting is looking fairly good with your matrix reassociator.
23:59 tarceri: Yeah its mostly there, but I was still digging around in the shader-db results before I put it on the back burner