01:54 Plagman: ajax: did we lose egl on the 'headless' platform again?
01:55 imirkin: are you thinking of surfaceless?
01:55 Plagman: uh yeah maybe
01:55 Plagman: trying to find the commit again
01:55 Plagman: basically ~1.5yrs ago i had to carry a mesa patch to enable it there so gamescope would work on a VT session, then at some point it got superceded by a change ajax made upstream (IIRC)
01:56 imirkin: surfaceless platform, probably
01:56 Plagman: and now it's failing again in the same way that it was before my hack
01:56 Plagman: thanks
01:56 Plagman: maybe something that shifted on our end too, maybe emersion made a change or something
01:56 imirkin: (there's also a "drm" platform which renders directly on screen, but i don't think that's what you mean)
01:58 HdkR: I also believe it should be surfaceless
01:58 Plagman: yeah that all makes sense
01:58 Plagman: maybe we're building/deploying mesa wrong this time around, lots of things shifted since last time i tried thaATR
01:58 Plagman: whoa
01:58 Plagman: that*
01:59 Plagman: there was definitely a change last year that let gamescope work in a VT where it otherwise wouldn't
01:59 Plagman: need to find it again and start from there
02:04 HdkR: Looks like surfaceless is always enabled if EGL or vulkan are enabled, and drm always enabled if gbm is available
02:05 HdkR: Had to double check that I wasn't accidently removing these two in my rootfs builds
02:09 Plagman: this is what the failure looks like, fwiw
02:09 Plagman: https://gist.github.com/Plagman/dd7998536c73f3ceacb5f1fa11d4bb8c
02:10 Plagman: maybe build configuration is out of date
02:13 HdkR: `unsupported EGL Platform` I guess platform passed in to eglGetPlatformDisplay is EGL_PLATFORM_SURFACELESS_MESA?
02:13 imirkin: Plagman: how are you building mesa?
02:13 imirkin: you need to make sure to include surfaceless in -Dplatforms=...
02:13 Plagman: i'm checking that now yeah
02:13 imirkin: there indeed was a change
02:14 imirkin: to how the build worked there
02:14 Plagman: it hasn't changed since the time it worked, but it's possible we need to align with a recent change
02:14 imirkin: i don't remember precisely
02:14 Plagman: ah, that would do it
02:14 HdkR: Oh, did that change from 20.3.2 already?
02:14 Plagman: build config is what i'm about to dig into yeah
02:14 imirkin: HdkR: not from 20.3
02:14 imirkin: more like from -50.-50 :)
02:14 imirkin: it was a while ago :)
02:15 HdkR: Then it just has a `with_egl or with_any_vk` check rather than checking platforms
02:16 imirkin: ok, so ...
02:16 imirkin: hm
02:16 imirkin: commit f8dc22bf61c1e6008f6954ffd25c1ee322f500c6
02:16 imirkin: removed surfaceless and drm from "platforms"
02:17 imirkin: surfaceless is now always included
02:17 imirkin: no matter what
02:17 imirkin: drm is detected based on ... something
02:23 Plagman: https://gist.github.com/Plagman/ea0503a27ff86a75bb8adaa4f727cb37
02:23 Plagman: here's how it's built
02:24 Plagman: there used to be surfaceless in 'platforms' but it got removed from the pkgbuild, presumably when it wasn't needed anymore
02:24 imirkin: yeah, it's not required
02:24 imirkin: it's always incldued now
02:24 HdkR: As long as your source is newer than July
02:24 imirkin: ah yeah, that's a good point
02:24 Plagman: it is yep
02:25 Plagman: building ed50cba from just 2 weeks ago
02:25 Plagman: or 3
02:25 imirkin: btw, may i ask why you're building driver support for GeForce 4 Ti?
02:25 imirkin: is that like a common target you need to run on?
02:25 Plagman: this is just forked off of the normal arch mesa-git package, which is a kitchensink
02:25 Plagman: it could use some cleaning up yeah
02:28 HdkR: https://hastebin.com/eremaxiyoh.properties I also have kitchen sink config and this gets me surfaceless
02:28 imirkin: Plagman: can you confirm this is trying to use surfaceless platfrom and not drm platform?
02:29 imirkin: Plagman: are you expecting things to show on screen or to not show on screen?
02:29 Plagman: to show on screen
02:29 Plagman: but i'm doing the showing from my code
02:29 imirkin: ok. so that's not headless/surfaceless.
02:29 imirkin: oh. i see.
02:29 Plagman: egl needs to do exactly _nothing_ except not blow up my process
02:29 imirkin: gotcha.
02:29 bnieuwenhuizen: I think crso still uses surfacelss for showing things on screen
02:29 Plagman: which it is because the init is fatal in wlroots, i guess
02:29 bnieuwenhuizen: cros*
02:29 Plagman: i'm double checking it's still passing surfaceless
02:29 Plagman: but given the 'headless' wlroots backend getting chosen, i think it is
02:34 Plagman: looks like it might be passing EGL_PLATFORM_GBM_KHR now
02:35 Plagman: yeah there's no more SURFACELESS_MESA in wlroots, that got nuked
02:36 imirkin: Plagman: so that's the "drm" platform
02:36 HdkR: Well that explains it
02:36 imirkin: #ifdef HAVE_DRM_PLATFORM
02:36 imirkin: case EGL_PLATFORM_GBM_MESA:
02:36 imirkin: disp = _eglGetGbmDisplay((struct gbm_device*) native_display,
02:36 imirkin: which must not be getting built for you
02:36 imirkin: iirc gbm supports some form of surfaceless as well?
02:36 Plagman: should it be this then? -D platforms=x11,wayland,drm \
02:37 imirkin: drm is no longer an option
02:37 imirkin: it's auto-detected
02:37 Plagman: maybe our build environment somehow made it avoid that then
02:37 imirkin: make sure you have -Dgbm=true
02:37 imirkin: which you do
02:37 Plagman: can i easily check on the runtime copy of mesa if it has it or not?
02:37 Plagman: yeah i do
02:37 Plagman: like in vulkaninfo or w/e
02:37 imirkin: yeah... sec
02:39 imirkin: eglinfo in mesa-demos
02:39 imirkin: should show e.g. GBM platform: bla
02:40 Plagman: yeah it's happily spewing after 'GBM platform:'
02:40 Plagman: others don't show anything in a ssh prompt, which makes sense i guess
02:41 imirkin: do you get a list of configurations afterward?
02:41 imirkin: after EGL extensions string
02:41 Plagman: yep
02:42 imirkin: weird.
02:42 imirkin: :)
02:43 Plagman: yep
02:44 imirkin: in these situations, i usually start up gdb and the problem becomes apparent in a half second
02:49 Plagman: yeah just need to get a debug build of all that stuff on there
02:49 imirkin: just mesa (and wlroots)
02:49 Plagman: interestingly looking at the log this branch doesn't hit in wlroots:
02:49 Plagman: if (egl->display == EGL_NO_DISPLAY) {
02:49 Plagman: and it thinks eglInitialize worked, etc
02:49 Plagman: despite all the spew
02:50 Plagman: eglQueryString is the one that makes it give up
02:52 Plagman: hopefully EGL_PLATFORM_GBM_KHR is the same as EGL_PLATFORM_GBM_MESA? :-)
02:53 imirkin: one _would_ hop...
02:53 imirkin: include/EGL/eglext.h:#define EGL_PLATFORM_GBM_KHR 0x31D7
02:53 imirkin: include/EGL/eglext.h:#define EGL_PLATFORM_GBM_MESA 0x31D7
02:53 imirkin: and one's hopes are realized. there are some exts where that is not the case.
02:53 imirkin: e.g. ARB vs EXT or core ... very confusing.
02:54 Plagman: *shakes fist at fbos*
02:54 imirkin: well, ARB_fbo != EXT_fbo. but that's a seaprate thing
02:54 imirkin: i mean literally enum values
02:55 imirkin: or is that the ext where the enums don't match up either?
02:55 Plagman: nah, was just referring to ext/arb being different functinoality there and not a straight promotion to core
02:55 Plagman: well, to areb
02:55 Plagman: arb*
02:55 imirkin: or ARB_geometry_shader4 != GL 3.2 geometry shaders
02:55 imirkin: that's always nice
02:57 Plagman: ok so the only way the error spew i'm getting can play out is if #ifdef HAVE_DRM_PLATFORM is just not there, or the enums didn't match when these two halves were built
02:58 Plagman: since eglinfo seems to imply the define is decidedly there, and the enums not matching would be far-fetched, maybe i'm just not running against the mesa i think i am
02:58 Plagman: or some glvnd shenanigans are happening
02:58 Plagman: like eglinfo might be using a different mesa as gamescope, somehow
02:58 Plagman: they're all amd64 though
02:58 imirkin: with_gbm makes sure that HAVE_DRM_PLATFORM is set
02:58 imirkin: if drm is missing, it'll complain
02:59 imirkin: strace -f -e openat to figure out if it's loading the right driver
03:00 imirkin: Plagman: do you have a EGL_KHR_surfaceless_context listed in the EGL ext string for the GBM platform?
03:09 Plagman: looks like yes
03:10 Plagman: EGL_KHR_surfaceless_context, EGL_KHR_platform_gbm, EGL_MESA_platform_surfaceless, EGL_MESA_platform_gbm
03:21 Plagman: aha
03:22 Plagman: gdb says the value our side is passing is actually EGL_PLATFORM_SURFACELESS_MESA
03:22 Plagman: not GDM
03:22 Plagman: GBM*
03:23 Plagman: so was looking at outdated source probably
03:23 Plagman: well, too new in this case
03:28 Plagman: not that it makes it any less mysterious
04:26 Plagman: i got debug mesa on there and the error spew manages to spew without _eglError getting hit, which is exciting
04:27 Plagman: looks like libEGL.so doesn't come from my mesa package and there's still no symbols for that, is there any logic there or is that just dispatch?
04:33 Plagman: nope, libEGL is what's spewing that error before i get into mesa code
04:33 Plagman: that might explain it..
04:34 Plagman: that's in vnd?
04:37 imirkin: on my system, libglvnd supplies libEGL.so
04:39 Plagman: yeah same here looks like
04:39 Plagman: it must be vnd that's spewing these errors
04:42 Plagman: and the call wlroots thinks it's making to eglQueryDeviceStringEXT isn't making it to mesa at all
04:42 Plagman: it fails before getting there and it torpedoes the egl init at that point because it gets a null extension string
04:42 Plagman: so i guess vnd is ruining my day?
04:43 Plagman: it's weird though, i don't see any device string code in vnc
04:43 Plagman: vnd*
04:54 Plagman: (gdb) si
04:54 Plagman: 0x00007ffff6ba46c0 in ?? () from /usr/lib/libEGL_nvidia.so.0
04:54 Plagman: what the fuck
04:54 Plagman: fucking piece of shit god fucking damnit
04:54 Plagman: i want my hours back
04:55 Plagman: clear scrollback, nothing to see here, just sadness and broken setups
04:55 HdkR: Well there's your problem, you let a blob on your system
04:55 HdkR: ;)
04:56 Plagman: maybe it's not entirely a broken setup, like why is vnd getting me this in the first place?
04:58 Plagman: might be a vnd bug
04:59 HdkR: ICD priority problem?
05:00 imirkin: does apitrace not let look at integer attachments? :(
05:01 Plagman: are icd priorities a thing in egl-land?
05:01 HdkR: Yea, they have numbering in the front
05:02 HdkR: `Files in the same directory are loaded in strcmp() order, so 40_myvendor.json is considered to be higher-priority than 50_yourvendor.json`
05:03 imirkin: as is 100_myvendor ;)
05:03 Plagman: 10_nvidia.json 50_mesa.json
05:03 Plagman: seems to be arch's setu
05:03 imirkin: you always want nvidia, duh, not stupid broken nouveau
05:03 imirkin: <end of list of gpu makers>
05:03 Plagman: isn't it a vnd code bug though? clearly nvidia wanted nothing to do with eglGetPlatformDisplayEXT
05:03 Plagman: and mesa was the thing that returned me a display
05:03 Plagman: i'm calling eglInitialize on that display
05:04 Plagman: so why wouldn't my proc addrs come back from mesa?
05:06 HdkR: Could the nvidia blob be returning success on initialize, so it binds to that?
05:06 HdkR: Because nvidia blob loves consuming everything, so always succeed
05:08 Plagman: maybe
05:09 Plagman: i don't know how it's supposed to work
05:11 imirkin: re the much earlier conversation of mismatching defines across APIs:
05:11 imirkin: include/GLES2/gl2ext.h:#define GL_HALF_FLOAT_OES 0x8D61
05:11 imirkin: include/GLES3/gl3.h:#define GL_HALF_FLOAT 0x140B
05:12 imirkin: not sure what caused me to remember that. but here we are.
05:14 HdkR: You're using a nullptr display, so it can't do any dpy tricks. Has eglInitialize as the first entry. Which means surfaceless and Nvidia supports that, just accepting it
05:14 HdkR: maybe?
05:15 HdkR: oh, you would have eglGetPlatformDisplay before that. So that has to be succeeding
05:17 HdkR: I'll blame the blob before vnd :)
05:18 Plagman: yes
05:18 Plagman: eglGetPlatformDisplayEXT( NULL ) gives me a Mesa display
05:18 Plagman: after nvidia passed on it
05:18 Plagman: so i'd hope anything downstream of that has me talk to mesa
05:18 Plagman: but nope
05:19 Plagman: say both stacks had working hardware and were both capable of giving me surfaceless EGL from a VT
05:19 Plagman: eglGetPlatformDisplayEXT( NULL ) ought to give you a display for whatever is the current VT, yea?
05:19 Plagman: like for whatever implementation can render on the current VT
05:19 Plagman: straight hardcoded priorities wouldn't cut it there
05:20 Plagman: and i don't think that as a client i can somehow look at the VT and divine some EGL implementation selection backdoor to know what i need to ask vnd
05:21 HdkR: If the platform was SURFACELESS_MESA then I expect the blob to never give a display there, but the blob does support a true surfaceless context in that situation as well
05:24 HdkR: Because of EGL_KHR_surfaceless_context
05:25 HdkR: I believe? Been a while since I tested that config for Dolphin CI :P
05:32 HdkR: Looks like glvnd just walks the vendor list in order until one doesn't return EGL_NO_DISPLAY
05:33 HdkR: https://github.com/NVIDIA/libglvnd/blob/master/src/EGL/libegl.c#L325
05:33 Plagman: yeah, i think that part worked
05:33 Plagman: it's downstream of that when we try to usd the display that doesn't seem to work
05:36 HdkR: tricky
05:39 imirkin: Plagman: "current VT" is a fairly loose concept
05:40 imirkin: Plagman: besides if you want to display on the current VT, you wouldn't use surfaceless
05:41 imirkin: you'd use drm
06:26 Plagman: well that's what i'm doing
06:26 Plagman: i'd be fine with only doing dmabuf + vulkan through drm and prime apis
06:27 Plagman: but wlroots needs to initialize egl/gbm for whatever reason
06:53 jamestmartin: what does the Vulkan MESA_device_select layer do? I can't find any docs for it
08:46 danvet: tzimmermann, drm-fixes forwarded (but really this shouldn't have blocked you for -fixes)
08:47 tzimmermann: danvet, happy new year. i think drm-fixes was not actually relevant for the patch. AFAICT the patch goes to drm-misc-next
08:48 danvet: ah makes sense
08:48 danvet: I'll catch that up too
08:48 danvet: just forwarded to -rc2
08:49 danvet: will whack all the pending pulls on top later
08:49 danvet: I guess mlankhorst could backmerge then
08:49 danvet: or you if he's out
08:49 tzimmermann: danvet, there was also a PR for drm-misc-next-fixes which has not gone in IIRC https://lore.kernel.org/dri-devel/X+JFYlW1SEZa6ShA@linux-uq9g/
08:50 danvet: tzimmermann, seems merged
08:50 danvet: airlied even mentioned the mips fix in his christmas pull
08:50 tzimmermann: danvet, ok great
08:52 tzimmermann: mlankhorst_, happy new year. we just discussed backmerging into drm-misc-next
08:54 mlankhorst_: thanks, backmerge is fine, just need a rationale :)
08:57 tzimmermann: mlankhorst_, -rc2 is needed for TTM patches by christian. but davnet wants to merge some PRs first. maybe he can ping you when it's ready
08:57 MrCooper: jekstrand: FYI, there are people living on the other side of the globe ;)
08:59 mlankhorst_: that's ok
09:00 pq: jenatali, I think Gitlab itself should allow picking the branches and tags to copy when forking, defaulting to "main branch only". Everything else is almost never useful in general. When I fork anything, my first action is to delete everything but main/master. I bet there is a Gitlab.com issue for this feature already.
09:04 pq: Plagman, FWIW, Weston CI depends on surfaceless EGL platform, but doesn't track Mesa master, obviously. If someone wanted, they could add Weston test suite run into Mesa CI...
09:05 emersion: Plagman: https://gitlab.freedesktop.org/glvnd/libglvnd/-/commit/a527411da713b2068974c46d7129326520dc5923
09:05 emersion: Plagman: this is required to make libglvnd not freak out when NVIDIA proprietary drivers are installed and an app queries EGL device exts
09:08 danvet: mlankhorst_, tzimmermann will take a while for -next since there's 6 pending pulls for it already :-)
10:00 danvet: agd5f_, hwentlan is the crc window property conversion to debugfs still in flight somewhere?
11:34 FireBurn: After the issues with the TTM code at merge time, thought I'd test out the latest drm-next code and spotted a new warning
11:34 FireBurn: https://gitlab.freedesktop.org/drm/amd/-/issues/1432
11:37 FireBurn: I'm not seeing the issue in agd5f's tree
11:49 tzimmermann: danvet, so can i simply backmerge from -rc2 into drm-misc-fixes?
11:55 Vanfanel: Hello there. I use drmGetCap() to retrieve DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT, then I can create a GBM BO with those sizes and use it with drmModeSetCursor(). Works good on AMDGPU and VC4. However, on i915, drmGetCap() returns DRM_CAP_CURSOR_WIDTH = 256 and DRM_CAP_CURSOR_HEIGHT = 256, but drmModeSetCursor() returns -22 with a GBM BO of those sizes.
11:56 Vanfanel: Is the i915 driver broken in that respect or maybe I shouldn't be trusting DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT?
11:58 emersion: Vanfanel: you need to make sure you allocate a LINEAR buffer, if you're not using modifiers
11:59 emersion: Vanfanel: the assumptions are being documented here https://patchwork.freedesktop.org/patch/409568/
12:01 danvet: tzimmermann, well should be a fast-forward
12:01 tzimmermann: ok
12:01 danvet: but yes for -fixes this should work
12:02 danvet: if we have merge conflicts that should be resolved in drm.git in -fixes branches we have bigger problems :-)
12:06 tzimmermann: danvet: git merge --verbose --ff-only v5.11-rc2
12:06 tzimmermann: fatal: Not possible to fast-forward, aborting.
12:06 tzimmermann: ideas?
12:06 tzimmermann: done for drm-misc/drm-misc-fixes
12:08 Vanfanel: emersion: from what I understand, in the link you gave me it says: "If the driver provides the capabilities &DRM_CAP_CURSOR_WIDTH and &DRM_CAP_CURSOR_HEIGHT, create the framebuffer with this size.". And i915 seems to support these caps. What's the relation between this and MODIFIERS?
12:08 tzimmermann: "git merge --ff v5.11-rc2" works
12:08 emersion: Vanfanel: there's no relationship between this and modifiers
12:08 emersion: these are two separate constraints
12:08 emersion: the bullet list has two items
12:09 Vanfanel: emersion: ah, they are unrelated. I see...
12:14 emersion: Vanfanel: GBM has a GBM_BO_USE_LINEAR flag, if you haven't seen it yet
12:14 Vanfanel: emersion: was looking for it, but thanks a lot :D
12:14 emersion: np :)
12:14 emersion: wlroots does the same, it works for all drivers, except nouveau because nouveau is buggy
12:15 emersion: it migrates buffers around without synchronization
12:17 emersion: also, nouveau modifier support is buggy, if you
12:17 emersion: 're adding support for modifiers at some point
12:18 emersion: results in black screens and invalid GPU state
12:18 Vanfanel: emersion: I would also ask you... The legacy interface seems to work much better for cursor management than the ATOMIC interface (in the sense that I can do drmMoveCursor() without depending on primary plane pageflip commit), so wasn't there a certain "excepcionality" in the sense that mixing ATOMIC interface for ptimary plane usage + LEGACY for cursor management?
12:19 emersion: why do you want to move the cursor without page-flipping?
12:19 emersion: what works "much better"?
12:20 Vanfanel: emersion: because some games expect the cursor to move independently, even when don't do any explicit pageflipping. I am talking about SDL2 games, which are designed to work on X11 enviroments where mouse movement is independent from window pageflip
12:21 Vanfanel: emersion: some games have menus where they don't do any pageflips, yet they have clickable boxes etc
12:21 emersion: hm, how does your page-flipping logic work? do you only do an atomic page-flip when the game submits a new buffer?
12:21 emersion: the rendering loop with DRM should wait for the page_flip_handler DRM event
12:22 Vanfanel: emersion: since it's SDL2, I do the atomic pageflips when a game calls SDL_RenderPresent()
12:22 emersion: if you do an atomic commit when the game renders, this may cause EBUSY if the previous page-flip isn't finished
12:24 emersion: this tutorial covers this point: https://github.com/ascent12/drm_doc/blob/master/03_vsync/03_vsync.md
12:28 danvet: tzimmermann, so did it work or not?
12:28 danvet:confused
12:28 danvet: also back from lucnh
12:29 tzimmermann: danvet, it did. no conflicts. but i was surprised that --ff-only did not work
12:29 Vanfanel: emersion: I don't get EBUSY returns on the ATOMIC commits, that is not the problem because I am using eglClientWaitSyncKHR() to avoid that
12:29 emersion: i'm not sure how that avoids the issue
12:30 emersion: are you using explicit sync with the kernel's OUT_FENCE_PTR?
12:30 emersion: the issue is that the kernel may not be done with the page-flip
12:30 emersion: not that the client buffer isn't ready
12:31 danvet: tzimmermann, well you didn't fast-forward
12:31 danvet: because there's a lost patch in there
12:31 danvet: :-/
12:31 danvet: tzimmermann, I'd say hard reset and then redo as a dim backmerge
12:32 danvet: tzimmermann, or rebase
12:32 tzimmermann: danvet, hard reset?
12:32 danvet: what you pushed doesn't look too tidy
12:33 danvet: it's a full merge commit
12:33 tzimmermann: danvet, yeah. i was not happy about that
12:33 danvet: tzimmermann, looks like sumits pushed it today
12:33 tzimmermann: but i cannot hard reset a public tree
12:33 danvet: and didn't realized it's not moved forward yet
12:33 danvet: you can
12:33 tzimmermann: danvet, really?
12:34 danvet: just ask sumits to re-apply after you've hard-reset to -rc2
12:34 danvet: well yeah
12:34 danvet: we do that every few months to fix up screw-ups and stuff like that
12:34 tzimmermann: oh
12:34 danvet: it's just that you should really, really avoid it
12:34 danvet: since it disrupts workflow
12:35 danvet: but -fixes doesn't have a lot going on, so not that many people to apologize to :-)
12:35 tzimmermann: lol :)
12:35 tzimmermann: danvet, what's the prodecure? "git reset --hard -rc2" and then "dim push-branch drm-misc-fixes" ?
12:35 danvet: needs dim -f push-branch drm-misc-fixes -f
12:36 danvet: but yes
12:36 danvet: also once done ping sumits
12:36 danvet: or apply the patch you've dropped yourself again
12:37 danvet: anyway lesson for next round: fast-forward drm-misc-fixes to -rc1 as soon as it's out there
12:37 tzimmermann: dammit, that patch wasn't there yesterday :/
12:37 danvet: since committers dont look before pushing
12:37 danvet: yeah :-(
12:37 danvet: shit happens
12:38 tzimmermann: i'll cherry-pick the patch on top of the reset
12:38 danvet: in general try to fast-forward -fixes as soon as -rcX is out
12:38 danvet: yeah works too
12:38 danvet: just make sure you add your sob on top
12:39 tzimmermann: ok
12:39 tzimmermann: if anything goes wrong, i'll reset again. infinite number of tries then ;)
12:39 tzimmermann: just kidding
12:39 danvet: it doesn't count on the same day :-P
12:44 tzimmermann: danvet, done. i'd appricate a quick look
12:45 danvet: tzimmermann, lgtm
12:45 danvet: fun is if anyone pulled the intermediate state
12:45 danvet: and then ends up with a merge commit when they pull
12:45 danvet: but dim should prevent them from pushing at least
12:47 danvet: also if they use dim update-branches, it should properly rebase
12:57 Vanfanel: emersion: I am trying to fix the cursor problem first, I thought it would be easier with the LINEAR flag bit it's not working. Thing is, drmGetCap() reports 256x256 as I said, so I am using a GBM BO of that size, and passing GBM_BO_USE_LINEAR flag on it's creation. However, I strangely receive this on drmModeSetCursor() with that BO: [drm:i9xx_check_cursor [i915]] Cursor dimension 16x16 not supported
12:57 tzimmermann: danvet, i sent out a mail to chrstian while the intermediate state was present. let's see :)
12:59 Vanfanel: emersion: since it's 256x256, why could i915 reporting a not valid size of 16x16?
13:01 emersion: Vanfanel: bad size provided to drmModeSetCursor?
13:02 emersion: drmModeSetCursor takes the size as parameter
13:04 Vanfanel: emersion: yes, drmModeSetCursor() takes size as parameter, and I am passing it 256x256, which is what drmModeGetCap() returns
13:04 mlankhorst_: danvet: hm did you push drm-misc-next out?
13:04 sumits: tzimermann, danvet: I was under the impression that drm-misc-fixes is meant for fixes for current -rc. hence pushed a patch onto that. is that not the case?
13:05 Vanfanel: emersion: so I am missing something here or i915 is acting strangely
13:05 sumits: tzimmermann^^
13:05 danvet: sumits, you did all right, it's just that drm-misc-fixes was stuck a bit too much in the past
13:05 danvet: mlankhorst_, uh did I do something stupid?
13:05 danvet:not touching drm-misc-next right now
13:05 mlankhorst_: I mean to drm/drm-next :)
13:05 emersion: Vanfanel: dunno, it works with wlroots so i don't think i915 is buggy
13:06 emersion: are you 100% sure you pass the right size?
13:06 sumits: danvet, ok, thanks for confirming - don't want to be doing the wrong thing, hence wanted to clarify :)
13:06 emersion: i'd check with printf
13:06 danvet: mlankhorst_, still working on it
13:07 emersion: both right before drmModeSetCursor and right before gbm_{bo,surface}_create
13:07 sumits: tzimmermann, danvet: if it's easier to do hard-reset, I can re-apply the patch once you're ready, no problem
13:07 danvet: mlankhorst_, ok I think I got them all
13:08 danvet: agd5f_, lots of stuff in drm-next, might want to sync
13:08 danvet: dolphin, j4ni ^^ (vivijim not around it seems)
13:08 danvet: pinchartl, ^^ ready to roll out drmm_ for rcar I hope :-)
13:09 pinchartl: danvet: see my recent pull request :-)
13:09 mlankhorst_: ok thanks
13:10 danvet: pinchartl, I just pulled that
13:10 danvet: and the imx one with drmm_ stuff
13:10 danvet: and everything else
13:10 danvet: hence the ping
13:10 emersion: well, not printf, fprintf(stderr, …), otherwise there are buffering issues that might make you miss the printf
13:10 emersion: (or whatever logging facility you already have)
13:10 danvet: pinchartl, i.e. you can convert over to the new helpers now
13:13 mlankhorst_: pushed, enjoy! Forgot to compile test this time, so time to live on the edge. :)
13:13 FireBurn: danver: drm-next is broken for me jus tnow
13:14 FireBurn: https://gitlab.freedesktop.org/drm/amd/-/issues/1432
13:14 FireBurn: *danvet
13:17 Vanfanel: emersion: I was passing SDL cursor size instead of the GBM size... really sorry. I can't thank you enough for listening me and helping me to look directy at the problem.
13:17 emersion: FireBurn: but this is fixed in agd5f's tree?
13:18 emersion: Vanfanel: good catch! no problem
13:18 Vanfanel: :)
13:21 tzimmermann: sumits, i added your patch already. thanks for the offer
13:21 sumits: tzimmermann, thanks much!
13:26 FireBurn: emersion: agd5f's tree is still based on 5.10-rc3 not 5.11-rc2
13:27 danvet: FireBurn, can you crash that with kallsyms?
13:27 danvet: also does the amd tree crash the same way?
13:27 emersion: often there are bugfixes only available in agd5f's tree, not in drm-next
13:27 danvet: it could be a bug in drm-misc-next too, or an interaction
13:27 danvet: agd5f_, ^^ fyi
13:27 emersion: is there a reason why drm-tip doesn't use agd5f's tree btw?
13:28 emersion: also, amd/drm seems unused
13:28 danvet: emersion, amd doesn't use the dim scripts
13:28 FireBurn: I'll try will kallsyms, I ususlaly test with agd5f's tree, I thought I'd add in drm-next due to the TTM issue that slipped in via drm-misc
13:29 danvet: they internally use commit rights, and then agd5f cherry-picks it all over to the public side
13:29 danvet: so no benefit for them really
13:29 danvet: since they'd only realize when stuff is wrong when agd5f cherry-picks
13:29 danvet: not when they push anything
13:30 danvet: FireBurn, yeah lots of ttm changes in drm-misc landed these days
13:30 dv_: hi, not sure if this is the right place for this - has there been any (rough) date announced for when mesa 21 will be released?
13:30 danvet: FireBurn, might also be good to test drm-misc-next, or bisect
13:30 danvet: hopefully it's not a merge commit :-/
13:30 FireBurn: Indeed
13:30 FireBurn: I'll see what kallsyms produces
13:32 emersion: ok
13:43 MrCooper: dv_: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8356/diffs
13:52 kallisti5: psst. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8323/ is pretty great and could use some feedback
13:52 kallisti5: dcbaker: ^^ :-)
13:52 FireBurn: I've added te kallsyms stuff, let me test linus's rc2 then bisect from there
14:14 agd5f_: danvet, just sent a new years reminder on the crc stuff.
14:26 danvet: agd5f_, yeah figured it's not going to happen over the break
14:27 danvet: tzimmermann, I guess you send out a pull as soon as könig pushed the ttm patches?
15:08 FireBurn: Hi I bisected the issue https://gitlab.freedesktop.org/drm/amd/-/issues/1432 goes back to 3d1a88e1051f5d788d789011823d9accc4e03dad
15:08 FireBurn: drm/ttm: cleanup LRU handling further by Christian König
15:26 agd5f_: danvet, for linux-next, should I just email sfr, or is there a more formal process?
15:26 danvet: it's just sfr
15:26 agd5f_: cool
15:57 danvet: vivijim, btw I applied a pile of pulls to drm-next, you might want to sync
15:57 danvet: or maybe not yet
15:57 danvet: just fyi
16:01 Vanfanel: emersion: I am also seeing a big and strange difference in i915 vs all the other drivers I have at hand (AMDGPU, VC4): in i915, the cursor plane is NOT scaled, so even if I use a plane to scale a 640x480 to 1080p, the cursor is tiny and it's movement is restricted to a part of the screen.
16:02 emersion: are you scaling the primary plane?
16:02 emersion: the cursor plane isn't supposed to be scaled with the primary plane
16:03 emersion: i recently fixed a related amdgpu bug
16:03 emersion: you need to manually scale the cursor plane if you need to
16:04 emersion: with a more recent kernel, amdgpu will prevent you from using the cursor plane if the primary plane is scaled
16:04 Vanfanel: emersion: I am activating the UNIVERSAL PLANES cap, and yes, I am using the primary plane on AMDGPU and it works there... so maybe your fix will "correct" that and it will behave the same as i915 does, right?
16:04 emersion: amdgpu hardware can't behave the way you'd expect in this case, so it'll just fail
16:05 vivijim: danvet: thanks for the heads up... I will take a look to the gt-next portion and see... I will probably need to sync indeed
16:05 emersion: as i said earlier: if you do scaling, you really want to use the atomic interface and implement proper fallbacks if it doesn't work
16:06 emersion: would be nice to report the bug to vc4
16:06 emersion: note: don't expect many drivers to support scaling on the cursor plane
16:06 Vanfanel: emersion: the problem is that I need to support hardware that doesn't have working ATOMIC interface (like RADEON I think, I am told these things by users in the SDL2 bugzilla)
16:06 emersion: (note: amdgpu supports scaling on the cursor plane if it matches the scaling used on the primary plane)
16:07 emersion: yeah, some drivers don't support atomic
16:08 emersion: my recommendation is: start with only the basic stuff, no scaling, just a primary plane and a cursor plane
16:09 emersion: then after that works you can start thinking about optimizations like scaling, and you will need to keep the fallback in place in case the driver doesn't support it
16:09 emersion: the atomic interface makes it easier to implement fallbacks and check if something is going to work or not
16:12 Vanfanel: emersion: yes, I started with just the basic stuff, no scaling, etc. and I have that code handy too, it does indeed work. I am on trying to implement plane usage on both ATOMIC and LEGACY because of the hardware I told you about. In fact, it works pretty well already, except for this mouse cursor scaling thing I just found out.
16:13 emersion: i wouldn't try to implement scaling on legacy
16:13 emersion: because you need two syscalls to find out whether something works
16:13 emersion: (pageflip + setcursor)
16:14 emersion: so that'll result in bad result displayed to the user
16:15 Vanfanel: emersion: well, I can do an initial try with both calls, and if it works, I can set a compatibility flag
16:16 emersion: the problem is when it doesn't work
16:16 emersion: users sees no cursor, you need to wait before trying something else otherwise you get EBUSY, etc
16:18 Vanfanel: emersion: well, I can do all those tests and waits when I create an SDL "window", and I don't have to repeat all that until another window is created
16:19 Vanfanel: emersion: in the case that scaling is working in the intended way, is there a way to scale the cursor plane? A way to tell DRM to scale it as it does with the primary plane?
16:20 emersion: what i'm saying is that it's a hack. sure you can implement hacks, but it'll be fragile and UX/code quality will suffer
16:21 emersion: you can set scaling on the cursor plane just like you do it on the primary plane, but i don't know how with the legacy API
16:23 Vanfanel: emersion: I am starting to have an idea... is it theorically possible to call drmModeSetPlane() on both the CURSOR and PRIMARY plane? One drmModeSetPlane() call after another, I mean, so both planes are told to be scaled and read by the same CRTC
16:23 danvet: Vanfanel, imo don't try to use planes (or fancy features) without atomic
16:23 danvet: mostly because they're not implemented by these drivers anyway
16:23 danvet: plus there's fairly few such drivers
16:24 danvet: the one silly exception is nouveau still not having enabled atomic by default
16:24 danvet: at least last time I checked
16:24 emersion: yeah, just use atomic
16:24 Vanfanel: danvet: VC4, i915 and AMDGPU all have working scaling on primary planes here... is that such a bad idea?
16:24 danvet: Vanfanel, that's not a bad idea
16:24 danvet: because they also all have atomic
16:25 Vanfanel: danvet: I already have ATOMIC implementations for them, too. Just going back to LEGACY for HW that doesn't have ATOMIC :)
16:25 danvet: the "planes, but not atomic" was a useful evoluationary step for drivers$
16:25 danvet: but not really something that's all that useful for userspace
16:25 danvet: Vanfanel, yeah, but for hw without atomic just have unscaled primary plane + cursor
16:25 danvet: because that's realistically all there is really
16:26 Vanfanel: danvet: ohh I understand now! For legacy-only HW, I won't have primary plane scaling anyway
16:26 danvet: there's not a single driver support that intermediate step in upstream anymore of "not atomic" but "advanced plane features supported"
16:26 danvet: Vanfanel, ah I guess I misunderstood what you have
16:28 Vanfanel: So, for ATOMIC, use PLANES to scale. For LEGACY, just unscaled PRIMARY + CURSOR. That's the way, right?
16:28 danvet: yup
16:28 danvet: also I guess with atomic it's always "try to" since you need a fallback
16:29 Vanfanel: danvet: aaaw, planes look SO nice always.. :D But you are right
16:29 Vanfanel: danvet: in general, HW that supports ATOMIC, also supports primary plane scaling, right? I will fallback anyway, but.. in general
16:31 danvet: no
16:31 danvet: that's why there's atomic's TEST_ONLY
16:31 Vanfanel: danvet: also, following your advicem I shouldn't be using drmModeSetPlane() in LEGACY mode at all, am I right?
16:31 danvet: so you can figure out whether the exact config you want is support
16:31 danvet: also even if there is scaling, if you change any parameter the answer could change
16:31 danvet: like bw limits, or alignment constraints
16:31 danvet: or scaling limits
16:31 danvet: or clock limits
16:31 danvet: or any other kind of thing hw/driver might not like
16:32 danvet: so atomic = you have a chance to figure out what actually works
16:32 danvet: not atomic = all these features are guaranteed to work
16:32 Vanfanel: danvet: I mean, in LEGACY mode, I should use drmModeSetCRTC(), but not drmModeSetPlane() ?
16:32 danvet: yes to that question
16:33 danvet: I was answer the previous one
16:33 Vanfanel: danvet: yes, sorry, I read and understood both answers :)
16:33 Vanfanel: thanks!
16:34 danvet: emersion, we don't yet have a handy "how to atomic" intro in the uapi section of the docs?
16:36 emersion: well, i have https://git.sr.ht/~emersion/foss-north-kms :P
16:37 emersion: do we want tutorial-style things in the docs?
16:37 emersion: it would definitely be nice to have something explaining atomic
16:39 danvet: even manpages have example sections
16:39 danvet: so I think it'd make some sense
16:39 danvet: at least a slimmed won one
16:40 danvet: https://dri.freedesktop.org/docs/drm/gpu/drm-internals.html?highlight=drm_device#display-driver-example
16:40 danvet: emersion, ^^ precedence for code examples in docs
16:41 emersion: nice
16:41 Sumera[m]: emersion: that is a great introduction, thanks so much! I wonder how many more such resources are hiding on the web...
16:41 emersion: at the end of the talk, there is a list of links
16:42 emersion: glad you like it :)
16:42 danvet: Sumera[m], $ make htmldocs
16:42 danvet: in the kernel tree
16:42 danvet: then browse Documentation/output/gpu
16:43 Sumera[m]: danvet: is there a place in the docs where links to talks/blogs related to drm are present?
16:43 danvet: oh I misunderstood your comment I think
16:43 danvet: I guess we could add it
16:43 danvet: but need to make sure there's a date next to each link
16:43 danvet: so readers know how potentially outdated the blog/talk is
16:43 Sumera[m]: hehe, yes- I have gone through the documentation- but it is a bit overwhelming at first sight 😛
16:44 emersion: ascent12's drm_doc: https://github.com/ascent12/drm_doc
16:44 emersion: daniels' kms-quads: https://gitlab.freedesktop.org/daniels/kms-quads
16:44 danvet: yeah it's a big pile and lacking good overviews and intros
16:44 Sumera[m]: danvet: yep, sounds like a good idea
16:45 danvet: emersion, hm can't we trick ascent12 into contributing some of that to upstream?
16:45 emersion: that would be fantastic, but i fear he doesn't have a lot of time for this stuff these days
16:50 pinchartl: danvet: I'll handle that. thanks for pulling
17:02 mattst88: danvet: is https://patchwork.freedesktop.org/patch/395580/?series=82783&rev=1 still not upstream yet?
17:09 mattst88: ickle: ^
17:43 danvet: mattst88, I guess needs airlied when he's back tomorrow-ish or so
18:40 jekstrand: MrCooper: I know there are people living on the other side of the glob. Not sure what you're implying though.
18:42 jekstrand: MrCooper: If it's about the archive thing. Nothing's deleted. I figured I could either send out an e-mail and have a week's debate about it or I could just do it and put it back if someone complained.
18:42 jekstrand: I'm not all that set on it.
18:43 anholt:thinks it's a nice cleanup without losing history, we've talked about it so many times over the years and I never heard objections.
19:08 turol: do the v3d vulkan people want bug reports for incorrect rendering and what's the preferred way to submit a repro?
19:10 anholt: turol: not me any more, but yes, in the mesa issue tracker.
19:11 turol: do you want the reproduction case as a program, renderdoc dump, gfxreconstruct dump or something else?
19:12 anholt: I expect they'd be happy with a renderdoc or gfxreconstruct, either seems reasonable
19:12 anholt: (if it's of something properly redistributable, we should probably get it into traces-db)
19:12 turol: it is
19:12 turol: https://github.com/turol/smaaDemo
19:13 turol: MIT licensed
19:13 anholt: sweet. (and I assume you've run it past the validation layers?)
19:13 turol: but it requires some input textures
19:13 turol: yes, validated
19:13 turol: works on everything else (amd/nvidia linux/windows) and for several years now
19:14 turol: both the SMAA and FXAA effects are broken
19:14 turol: MSAA currently crashes but that's my bug
19:14 anholt: submitting it to https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/ would mean that we can get it regression tested for some drivers in the future. (note: only amd so far, but work is in progress for others)
19:14 turol: can it do a screenshot compare?
19:15 anholt: that's what it does. exact pixel comparison, punt to the driver dev to evaluate the change when pixels change.
19:15 turol: nice
19:15 anholt: (well, not that repo, the CI infra we've got that uses that repo)
19:18 ajax: hurf. again i find myself trying to fix an s390x bug. why.
19:30 enunes: anholt jekstrand hi, sorry to bother with this again but can I get a new review on this nir patch https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6506 ?
19:37 jekstrand: enunes: No worries. It's our fault for ignoring it.
19:40 enunes: thanks!
19:41 zmike: maybe a dumb question, but is cnd_signal in util_queue_add_job() expected to be a "long" call or is that just due to context switching?
20:49 ajax: is there an easy way to locally run some ci job?
20:49 jekstrand: ajax: Step 1: Install a local GitLab instance....
20:50 ajax: like say i want to see what the meson-s390x job would do, without pushing to gitlab and clicking buttong
20:50 ajax: if the answer is no that's fine, i don't mind clicking buttons, just hoping to cut down some cycle time
20:50 jekstrand: ajax: In more seriousness, I have had some success with pulling the CI docker image and running the appropreate scripts the mesa tree.
20:50 jekstrand: I don't think there's a simple "run a CI job" script. I wish there were.
20:52 ajax: alternatively i wish the ci ui would let you click on the job you wanted and depsolve backwards to which jobs it has as prerequisites
20:53 anholt: ajax: some docker tips for iterating on CI debug are on docs.mesa3d.org
20:54 anholt: for driver debug, I will often pull down the artifacts .zip from the build job, unzip and untar, move it in place, and LD_LIBRARY_PATH there.
20:56 ajax: i probably should just set up a personal runner on some fast machine and only have it accept jobs from my fork
20:57 anholt: definitely recommend personal runner, though you'll occasionally be the lucky winner of cpu-dependent bugs in mesa.
20:57 Plagman: emersion: urgh ok, i guess that was just unlucky timing on my part - that change should get pushed out!
20:57 anholt: note that you have to manually tag the job in gitlab-ci.yml to force it to your runner, which kinda sucks.
20:58 anholt:is usually carrying around some patch to force jobs to auto-run and run on their runner.
20:59 ajax: could we put some rule in that auto-runs if the branch name in the fork starts with like /ci-/ or something?
21:00 anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7884
21:17 ajax: mmmm. i don't love running ci on arbitrary branches. i'm certainly guilty of pushing things that i know don't even build just so i have a backup on another machine
21:19 anholt: the question is how much load is that on the system vs the developer time spent managing CI runs
21:20 anholt: if it doesn't even build, then it'll be really cheap (but generate an email to you about your pipeline fail)
21:26 ajax: nod
21:27 ajax: don't get me wrong, i'm generally in favor of whatever makes the developer's life easier, but that does have a non-zero cost as measured in USD, and i'm not the one writing that check
23:12 FireBurn: New issue with the TTM stuff