01:43 hanetzer: so yeah. I simply cannot reach gitlab.freedesktop.org on my machine. Any other way to file bugs?
02:06 kisak: fwiw, gitlab.fd.o is accessible here
06:24 danvet: airlied, I guess a backmerge of your drm-next pull into drm-misc-next would be good for that conflict?
06:24 danvet: mlankhorst, mripard ^^
06:24 danvet: not sure who does 5.10
06:25 danvet: beware nouveau conflict, make sure it compiles and all
06:25 danvet: also make sure you pull in the pull request tag, not a random spot from within the merge window :-)
06:27 airlied: yeah would fix it, tip is good now
06:27 airlied: dont mind waiting for rc1 either
07:25 mlankhorst: danvet: doing 5.9 stil
07:26 danvet: so mripard I guess?
07:26 danvet: airlied, yeah I liked to backmerge main merge window pull to make sure the next feature branch is all caught up for another round of refactoring :-)
08:03 MrCooper: hanetzer: make sure you don't have a stale gitlab.freedesktop.org entry in /etc/hosts
13:03 danvet: emersion, replied once more, I expect this'll blow your mind :-)
13:06 danvet: or maybe we're just talking past each another
13:06 danvet: judging from pq's mail at least
13:08 emersion: ah!
13:09 pq: hehe
13:09 emersion: ok, so this pointer is just for legacy?
13:10 danvet: yeah just for legacy ioctl
13:10 danvet: zero other meaning
13:10 danvet: and you might want to know, if you use stuff like target frame or async mode from page_flip
13:10 danvet: or if you want to vt-switch away, so that you leave a config behind that the next compositor/splash can understand
13:10 danvet: GETCRTC becomes somewhat fun if you don't have the primary plane on
13:12 emersion: my intention was just to document the fact possible_crtcs can have more than 1 bit set
13:12 emersion: which isn't obvious when you read the sentence patched in my email
13:13 emersion: (more than 1 bit set for the primary plane, that is)
13:13 emersion: maybe it's not the right place to document it
13:14 emersion: (ie. maybe this sentence is about internal DRM things, and i'm parsing it from a user-space perspective)
13:15 emersion: wait, can you use multiple primary planes on a single CRTC?
13:16 emersion: (wrt. first example in your reply)
13:17 pq: I suppose that would be driver-specific and you use TEST_ONLY to figure out if it works.
13:18 emersion: > you can
13:18 emersion: assign _all_ planes, including primary ones, to a single crt
13:18 emersion: eh
13:18 emersion: interesting
13:19 emersion: > Primary plane is purely a tag for legacy uapi users
13:19 emersion: hm
13:19 emersion: i'd like to think of cursor as a legacy tag too, except many drivers have restrictions on this plane
13:19 pq: danvet, I had never thought to mix legacy and atomic UAPIs in the same program, but your point about VT hand-off is a good one.
13:20 shadeslayer: Hi, I had a question, if read_pixels calls _mesa_es_error_check_format_and_type here https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/mesa/main/readpix.c#L1084 for validating the format and type for GLES < 3.0, and we have _mesa_gles_error_check_format_and_type here
13:20 shadeslayer: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/mesa/main/glformats.c#L2782 , shouldn't read_pixels also check for format and type when doing GLES > 3.0
13:21 shadeslayer: or do we ensure that with texture_error_check before we call read_pixels when we setup the texture?
13:21 danvet: emersion, yeah cursor is a legacy tag too
13:21 emersion: … in practice many drivers will also only allow configurations where the primary plane covers the whole scanout region
13:21 danvet: emersion, yup
13:22 danvet: so you can still bias your compositor a bit for these tags
13:22 emersion: so, it's legacy, but still pretty important for non-legacy user-space to parse, to produce a configuration that works
13:22 danvet: like generally the primary plane should work as whole scanout in preferred_bpp
13:23 emersion: what is preferred_bpp?
13:23 emersion: cap?
13:23 danvet: I thought so
13:23 emersion: DUMB_PREFERRED_DEPTH
13:23 emersion: only for dumb buffers?
13:24 danvet: well it's a strong hint
13:24 danvet: because fbcon we try to make that one actually work
13:24 danvet: plus some efforts for xrgb8888
13:25 danvet: because a lot of userspace just dies without that
13:25 danvet: like boot splash
13:25 danvet: that's the only one we do in-kernel format conversions for
13:25 danvet: but in that case it should be last in the format list of the primary plane
13:25 danvet: oh that's another reason for parsing primary plane<->crtc link
13:25 danvet: if you want to know the format list setcrtc can take :-)
13:28 Vanfanel: Hi. What would be the way to set a custom cursor using the atomic interface? I am moving from drmModeSetCursor() to atomic. My guess is that I should look for a cursor plane, point it to the GBM BO containig the cursor by modifying some property of the cursor plane... right?
13:28 Vanfanel: Is there some example code for that?
13:35 jadahl: Vanfanel: you use drmModeAddFB2WithModifiers(), drmModeAddFB2(), or drmModeAddFB() with metadata from the gbm_bo to create a fbid that you assign to a cursor plane
13:44 Vanfanel: jadahl: Thanks :) I already have the fb_id. So, it's as simple as modifyng the FB_ID property of the cursor plane?
13:46 emersion: you also need to set CRTC_ID, CRTC_X/Y/W/H, SRC_X/Y/W/H
13:46 emersion: just like the primary plane
13:51 mlankhorst: although you may still want to use drmModeMoveCursor for a more responsive cursor movement on screen. :)
13:51 mlankhorst: after the setup
13:52 Vanfanel: thanks! Also, is it possible (as in "expected to work") to ask for updates of properties of different planes in the same atomic commit?
13:52 mlankhorst: it's the whole point of atomic. :-)
13:52 Vanfanel: I know being "atomic" it's supposed to, but...
13:52 Vanfanel: yeah, great! :D
13:52 Vanfanel: I am starting to like this atomic stuff now that I understand it
13:54 Vanfanel: mlankhorst: isn't drmModeMoveCursor() legacy then?
13:54 mlankhorst: yeah, but special case
13:55 Vanfanel: ok, ok :)
13:56 mlankhorst: people really like their cursor updates not to wait for page flips
13:58 emersion:doesn't do drmModeMoveCursor, no one complained yet…
13:59 Vanfanel: Oh, I see. So is there any real point for moving to atomic from "legacy" drmModeSetCursor()? I mean, setting a cursor can be done without waiting for pagefip, too...
14:00 mlankhorst: drmModeSetCursor doesn't allow arbitrary cursor formats and creates a new fb_id
14:00 jadahl: can you even use drmModeMoveCursor() at the same time as using atomic without things breaking?
14:01 jadahl: or, rather, are you supposed to?
14:01 mlankhorst: when the driver supports atomic, all legacy calls are wrappers to atomic
14:02 pq: Weston doesn't do drmModeMoveCursor with atomic either.
14:02 Vanfanel: jadahl: in the only user case I have tested that with (intel gfx, protracker2 clone) it seems to work
14:02 jadahl: so drmModeMoveCursor() is a CRTC_X/Y... atomic commit?
14:02 mlankhorst: yeah, although some drivers handle it specially to make it as fast as possible
14:05 pq: mlankhorst, so you mean than on some drivers, drmModeMoveCursor can end up blocking while waiting for a vblank?
14:05 mlankhorst: usually not, we set a legacy_cursor_update flag that skips the blocking
14:05 pq: "usually"?
14:07 mlankhorst: right after nonblocking modeset, for example
14:07 mlankhorst: see first part of intel_atomic_commit() and intel_legacy_cursor_update()
14:08 pq: Vanfanel, the point of atomic KMS is that you put as much updates into a single commit as you possibly can: all planes of a CRTC and preferably even multiple CRTCs if their timings are close enough or you are changing the connector routing.
14:08 mlankhorst: yeah
14:08 pq: and the connector routing part includes also turning off the CRTCs you don't use.
14:10 hanetzer: MrCooper: ... I'm a fucking idiot
14:11 Vanfanel: pq: So, in weston, instead of drmModeMoveCursor(), you modify SRC_X/Y props in the cursor plane while passing the same fb_id? Or how do you do it?
14:12 mlankhorst: CRTC_X/Y
14:12 pq: Vanfanel, yeah, that way, in the same commit where we update everything else about that output, or multiple outputs.
14:12 hanetzer: agd5f_: hey. I'm an idiot, had a bad /etc/hosts directive. Where should I be filing that bug again?
14:12 pq: Weston does not update the KMS cursor position more than once per refresh.
14:13 pq: and CRTC_X/Y indeed
14:14 pq: Weston also does not reserve the cursor plane only for cursors, Weston can put *any* content on the cursor plane if it fits. It's just another plane.
14:15 hanetzer: found it. thank god for irc logs :)
14:15 linkmauve: Would it be possible to do so right before vblank, when using the cursor plane for the cursor?
14:15 Vanfanel: pq: so I could display the entire game image on a cursor plane!?? :O
14:15 linkmauve: That way the cursor would be “more up to date” than when the rest of the picture was composited.
14:15 linkmauve: Vanfanel, as long as it doesn’t exceed the cursor plane’s size requirements, 256×256 on my hardware. :)
14:16 pq: Vanfanel, that's what Weston will attempt to do, if the circumstances are right. It's not difficult to get weston-simple-shm window onto the cursor plane, for instance.
14:16 Vanfanel: linkmauve: ah, yes, that limit... :D Maybe good for a NES game
14:17 MrCooper: mlankhorst: still thinking of i915 as the only KMS driver? ;)
14:18 pq: linkmauve, I suppose there would be ways to achieve that, but personally I also do not want that. :-)
14:18 linkmauve: Vanfanel, as long as you don’t have a UI around. ;)
14:18 hanetzer: MrCooper: thank you for reminding me of the power and responsibility of a linux system, I did have a hosts entry for it, dunno why anymore.
14:19 dj-death: anybody would know how to import some python file from a different directory in one of the mesa python script?
14:19 MrCooper: hanetzer: no worries, did you attend a gstreamer conference last year by any chance?
14:19 hanetzer: PYTHONPATH? or some loader script that modifies the sys.something list of where to get 'import foo' from.
14:20 hanetzer: MrCooper: nah. my life and work basically don't permit me to attend conferences.
14:21 MrCooper: anyway, there was a period of time with DNS issues, which resulted in many people adding a hosts entry
14:23 hanetzer: probably it. now to file that bug report
14:25 dj-death: hanetzer: thanks
14:28 Vanfanel: Guys, I am starting to think this: I have a BufferSwap() fn, where I issue an atomic commit. But I also have another atomic commits for setting the video mode, etc. SO, the general idea is that I should pageflip/bufferwap + set video mode + set cursor, etc... on the same AND only atomic commit?
14:31 pq: Vanfanel, correct
14:32 pq: and e.g. Weston has a pretty extensive state machinery to achieve just that across multiple CRTC opportunisitcally.
14:36 MrCooper: dcbaker[m]: FYI, your pushing directly to the main Mesa master branch upset Marge (and delayed the merging of that MR): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6187#note_591314
14:37 hanetzer: dj-death: np
14:37 dcbaker[m]: MrCooper: I don't suppose that's fixable?
14:38 MrCooper: not sure what you mean; all changes to master should be merged by assigning MRs to Marge
14:45 dcbaker[m]: MrCooper: I'm on my phone at the moment so hopefully this makes sense: the commit used for the branch point must be green in the Intel CI and gitlab CI, and the commit immediately after the branch point must be the version bump commit. Allowing Marge to insert additional commits between the tag and the version bump would break that. For non branch points I do use Marge, but for branch points I don't see how it's
14:45 dcbaker[m]: possible
14:55 Vanfanel: pq: thanks! :)
15:09 MrCooper: dcbaker[m]: what dictates "the commit immediately after the branch point must be the version bump commit"? Without that requirement, the branch point tag could be set on any master commit (which should imply GitLab CI was green) which also comes back green from Intel CI, then the version bump could be merged any time after that
15:13 emersion: pq: how do you decide whether to group updates for multiple CRTCs again?
15:21 dcbaker[m]: MrCooper: we've never done it that way, you're proposing a process change.
15:22 MrCooper: "always been done like this" is kind of a weak justification for bypassing the normal merge process :)
15:37 robclark: it would be annoying and weird if another MR sneaked in between version bump and brancpoint.. sounds like marge should just be temporarily paused during the branchpoint process
15:42 mlankhorst: MrCooper: nah, just easier to check what I wrote. :)
15:43 MrCooper: robclark: why is it weird if there are other commits between the branch point and the version bump? Why do they need to be immediately next to each other?
15:45 robclark: MrCooper: well, I mean, if you looked at the version string building one of the commits in that window, it would imply that the commit was in the release branch, when it is in fact not
15:45 robclark: although I suppose one could instead bump the version, and *then* create the branch & tag on previous commit
15:46 MrCooper: just ask Git instead of second guessing from the version
15:46 robclark: (but not sure how you can ensure that intel's CI is green with that approach)
15:46 mlankhorst: and iirc vc4 had the same setcursor bypass for xorg
15:46 robclark: MrCooper: having to go look at git history is an extra step
15:47 Lyude: danvet: btw, when you were talking about consolidating the DP SST probing process into shared helpers, did you have any idea of what that interface would look like?
15:47 sravn: tzimmermann: "mgag200_drv.c:233:9: error: implicit declaration of function ‘vmalloc’;" - when building alpha. Known and fixed somewhere?
15:47 robclark: creating the branch + branchpoint tag on HEAD~1 after pushing the version bump seems like a better way
15:47 MrCooper: mlankhorst: I heard there was a third KMS driver ;)
15:47 sravn: Seen with latest drm-misc-next
15:48 danvet: Lyude, nope
15:48 danvet: but we do know that it seems to be a pretty tricky issue, since past attempts didn't go far
15:48 danvet: so don't worry if you don't have a good idea either :-)
15:48 danvet: just figured I mention this, since you've been digging around in dp code a lot, across different drivers
15:49 Lyude: danvet: gotcha, I've at least figured out a few places we can make into helpers pretty easily on https://gitlab.freedesktop.org/lyudess/linux/-/commits/wip/nouveau-dp-work
15:50 Lyude: (the i915 commits have the stuff I've split out so far, since most of the code I'm stealing from there >:3)
15:50 danvet: mlankhorst, the legacy cursor hack flag is kinda broken, I'm trying to get rid of it
15:50 danvet: replacement is the async plane update
15:51 danvet: but that's not supported everywhere :-/
15:51 danvet: it's all a bit annoying
15:51 danvet: emersion, I think problem is mostly with Xorg where everything gets drawn right away
15:51 mlankhorst: yeah
15:51 danvet: so if your cursor isn't async, you might be unlucky and like 5k cursor updates behind or so
15:51 mlankhorst: yah. :-)
15:51 danvet: real compositors tend to suck a bit less
15:52 emersion: eh
15:52 mlankhorst: I guess once that's fixed we can nuke the helpers in i915
15:52 danvet: there's still reasons for atomic, if your page-flip somehow takes half a second
15:52 mlankhorst: erm legacy handling*
15:52 danvet: people tend to notice that less when the cursor still moves
15:52 mlankhorst: yeah
15:53 mlankhorst: but that will be fixed with async handling fortunately
15:55 Vanfanel: if I want to reuse an atomic ptr for all drmModeAtomicCommit() calls, should I call drmModeAtomicFree() between drmModeAtomicCommit() calls?
15:55 mlankhorst: no, but once atomic commit is done, you only need to update the delta
15:55 mlankhorst: so in practice you should just call it anyway and get a new one
15:56 emersion: re-using an atomic req is mostly useful for test-only commits
15:57 Vanfanel: I understand. So I should create and destroy atomic requests bewteen commits, right?
15:57 sravn: tzimmermann: Problem is that most arch's pull in vmalloc.h via asm-generic/io.h - but alpha has a local copy of io.h with no vmalloc.h use
15:57 mlankhorst: yeah just start over
15:58 sravn: tzimmermann: When I did the drmP.h removal I hit this a lot of times, so alpha is part of my build suite today
15:58 Vanfanel: mlankhorst: create req; fill req; atomic_commit(req); free(req)... etc, right?
15:59 sravn: tzimmermann: The fix is simple, just rambling while building in the background :-)
16:06 dcbaker[m]: robclark: I can't get freedreno's lua stuff to build against lua 5.1.5 (which is the latest gentoo has not masked)
16:06 dcbaker[m]: any chance someone there knows what the actual oldest supported version is?
16:08 robclark: hmm..
16:08 robclark: I think 5.2? I'm not really sure what would be needed for older..
16:09 robclark: dcbaker[m]: so this was the change to get it to work with lua52 (before moving the code into mesa): https://gitlab.freedesktop.org/freedreno/envytools/-/commit/cb73acd69074ee252b637c7384482cbe47906577
16:10 robclark: dcbaker[m]: at least if I didn't screw anything up, it should at least gracefully skip building stuff that depends on lua if it is not present..
16:11 dcbaker[m]: I've got a bunch of missing symbols
16:11 dcbaker[m]: If 5.2 is required I have a patch
16:13 robclark: I'm just cloning lua now.. maybe I can figure out what changed w/ git-diff
16:14 robclark: dcbaker[m]: could you pastebin the missing syms?
16:17 mlankhorst: Vanfanel: correct
16:17 dcbaker[m]: robclark: https://paste.centos.org/view/4ec88866
16:19 dcbaker[m]: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6229
16:22 robclark: dcbaker[m]: thx
16:24 karolherbst: huh, is there a reason that the CTS doesn't run in parallel with piglit?
16:34 robclark: does anyone still run CTS with piglit.. the parallel-deqp-runner is what the cool kids use :-P
16:37 dcbaker[m]: karolherbst: did you pass -c to piglit?
16:40 karolherbst: dcbaker[m]: I did not, and I thought it's not required.. oh well
16:40 karolherbst: robclark: I run piglit tests and CTS stuff in one go
16:41 dcbaker[m]: karolherbst: I think for CTS it is
16:41 karolherbst: okay
16:41 karolherbst: robclark: also I run not just the GL cts but GLES as well and plan to run more if parallelism works correctly :)
16:42 karolherbst: but with the android one I get around 200k tests...
16:43 robclark: running one deqp test per process is *super* slow, because deqp links all the tests (or at least all the tests per gles version) in one mega executable
16:43 robclark: which is why CI has been using parallel-deqp-runner
16:44 karolherbst: I guess parallel-deqp-runner creates multiple lists and spawns n processes?
16:44 robclark: yup
16:44 karolherbst: sadly that doesn't catch _all_ bugs
16:44 robclark: it breaks it down in chunks
16:44 karolherbst: I found a few bugs with piglit which I didn't catch in a normal CTS run
16:45 robclark: it tends to catch more bugs than running serial in different processes
16:45 karolherbst: because stale state and stuff
16:45 karolherbst: well.. not for me
16:45 robclark: well, I mean to catch all different issues you would need O(n^n) runs with all different test orders
16:46 karolherbst: or just zero/randomize out all memory
16:46 robclark: parallel runner shards the tests so it comes up with a pretty randomish order
16:46 karolherbst: but yeah.. it's... a bit problematic
16:47 robclark: you really should try parallel-deqp-runner before you claim that it won't catch some issues ;-)
16:47 karolherbst: VRAM is annoying as we don't clear and our memory allocation is super deterministic
16:47 karolherbst: so you end up with same addresses quite easily
16:47 robclark: sure
16:47 karolherbst: I mean, I am sure it will find other bugs. Does it save the case lists?
16:48 robclark: yes, and it can if you want, re-run chunks with fails to determine if it is a flake or legit fail
16:48 karolherbst: ahh, cool
16:48 karolherbst: now I just need a way to integrate all tests in one run :p
17:00 karolherbst: robclark: mhh.. for me it does nothing at all
17:01 robclark: probably look at the .gitlab-ci/ scripts (or one of the CI jobs) to see the cmdline to use
17:05 tzimmermann: sravn, i see. can you send out a mail for this?
17:06 karolherbst: robclark: seems like it really hates relative paths
17:06 karolherbst: and doesn't check if files are found
17:07 karolherbst: robclark: does it continue on crash btw?
17:08 robclark: karolherbst: yes
17:08 robclark: it somehow figures out which tests crashed and will resume running the rest in the chunk
17:14 karolherbst: I am wondering if I could generate a huge list of cases and just run them all through the same binary.. should work I guess
17:16 karolherbst: yep...
17:16 karolherbst: let me try that
17:19 karolherbst: nice.. let's see how long it takes to run those 114k tests :)
18:44 zmike: Kayden: any chance you're interested in looking over https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5338
18:44 zmike: I think you're the only other person who's worked on the z/s part here
20:38 agd5f_: hanetzer, https://gitlab.freedesktop.org/drm/amd/-/issues
22:27 karolherbst: huh.. do we have some gallium magic which detects that the driver stored shaders in the cache?
22:27 karolherbst: dEQP-GLES3.functional.shader_api.program_binary.binary_persistence.* flipping from Skip to Pass
22:40 pcercuei: Does DRM support paletted 8bpp framebuffers? How would the palette be attached?