00:12 anholt_: thanks to fritz doing some work on the farm, we now have 3x as many chezas running in CI as we did yesterday.
00:20 kisak: nice
04:26 robclark: anholt_: did something fall over? https://gitlab.freedesktop.org/robclark/mesa/-/jobs/1489364
05:02 SirCodesAlot: the build system appears to want to copy the drivers to the directory set by the meson option, dri-drivers-path. I am cross compiling mesa, and I want everything installed to $libdir/dri. The problem I am having is when I copy the cross-compiled libraries to my target, I get an linker error, that the path to the dri libraries are not found, because it is searching for the libraries based on my build directory configuration.
05:02 SirCodesAlot: Is there an option to specify that the dri-drivers-path (or similiar) should only be applicable to the run-time and not the build time?
05:02 airlied: imirkin_: since you are normally more piglit knowledgeable than I, do we have no tests for arrays of images?
05:03 airlied: or at least dynamic uniform indexes to arrays of images
05:06 SirCodesAlot: sorry, if it wasn't clear on the host system that is building the libraries, at the time of installation via `ninja install`, it is expecting to copy the files to [dri-drivers-path] on the host system.. which I want to avoid, since it means I need to manage a file path outside of the build environment.
05:08 SirCodesAlot: I could disable dri-drivers-path and if there is a way to fixup a runpath, or similiar, after the `ninja install` that could work. I'm just not sure how dri-drivers-path is used
05:41 SirCodesAlot: Cool. I found reference to the envr var LIBGL_DRIVERS_PATH in gbm_dri.c.. Setting that appears to override the build directory path to dri/
05:41 SirCodesAlot: not ideal, but good enough
05:47 imirkin: airlied: hmmmm ... curro added a lot of good images tests ... but dunno about that specifically
05:47 imirkin: unfortunately they're a bit hard to read, because they try to be very generic
05:48 imirkin: airlied: https://cgit.freedesktop.org/piglit/tree/tests/spec/arb_shader_image_load_store/indexing.c
05:48 imirkin: which i think should come out as arb_shader_image_load_store-indexing i think
05:57 airlied: imirkin: doh indeed it does test it
05:57 airlied: imirkin: thanks, I was looking for skip->fails
05:58 airlied: not sure if that test should check for ARB_gpu_shader5 or not
05:59 imirkin: images require GL4
05:59 imirkin: so ... :)
06:00 imirkin: those kinds of interactions are a bit unclear
06:01 imirkin: also i think CTS tests that stuff
06:01 imirkin: dEQP too, to the extent allowable in ES
07:20 SirCodesAlot: I seem to be unable to disable vsync for a simple SDL2 app I've written. Both in SDL2 and using the vblank_mode=0 env var, I can't seem to disable it. If it helps I am using kmsdrm, vc4, opengles2, gbm, on an raspberry pi. Is there something I might look at on the mesa side of this to see if it's somehow being forced to stay enabled? or, is there a way to enable additional debug info that might be useful?
07:21 HdkR: eglSwapInterval?
07:23 SirCodesAlot: HdkR: I think so. I have nearly zero experience calling directly into opengl.. from the code I am calling SDL_GL_SetSwapInterval, and SDL_GL_GetSwapInterval. Oddly, SDL_GL_SetSwapInterval(0) returns a success value, and the Get function returns that vsync is enabled
07:23 HdkR: I have no idea what SDL does :)
07:24 SirCodesAlot: yeah.. I'm looking now
07:30 SirCodesAlot: yeah, it looks like that is what it calls.. I suppose I should add a print statement to verify
07:30 hakzsam: arm64_a306_gles2 is broken https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1490191
07:33 daniels: SirCodesAlot: what you want to do with your paths is to set the paths to what they will be on the target and then use $DESTDIR to temporarily install them somewhere else before copying them to the right location on-device
07:34 SirCodesAlot: daniels: ah. awesome. thanks.
07:35 daniels: that's common to all autotools and meson projects; using that everywhere will save you a lot of pain and breakage
07:36 hakzsam: who should I poke for that ARM CI failure?
07:36 daniels: as for vsync, there's no way to achieve tearing with kms on the rpi; no matter what you do, you'll only ever display one frame per vsync
07:37 SirCodesAlot: daniels: good to know. I didn't realize autotools projects used that either. I've got a number of packages I am building with it. I'll have to go back through those too and take a look
07:37 daniels: anholt, robclark: please upgrade all your gitlab-runner versions to the latest to avoid the error hakzsam posted ^
07:38 SirCodesAlot: daniels: ok, also good to know :) saves me a lot of time. is this a limitation of kms implementation or something specific to rpi firmware or hardware?
07:38 daniels: hakzsam: you can hit retry when you see that - it's a transient error caused by a bug in old gitlab-runner. I retried for you and it seems happier
07:38 daniels: SirCodesAlot: both - KMS makes it hard to do tearing, and the RPi hardware doesn't support it anyway
07:39 hakzsam: daniels: I tried to retry it one or two times without luck, but it seems to work now, thanks!
07:40 SirCodesAlot: daniels: do you have an opinion about whether I should use the rpi blob driver, or kms? I realize question may be a bit counter intuitive since development for kms is here(?), but is stability of kms pretty decent?
07:42 daniels: hakzsam: np!
07:43 daniels: SirCodesAlot: yes, it is as far as I'm aware completely stable and just as performant (or more) as the blob
07:44 SirCodesAlot: daniels: alright cool. thanks for the help! I am calling it a night before it gets too late
07:50 daniels: enjoy
08:06 hakzsam: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1483275 any ideas why the output is broken like that?
08:07 daniels: anholt, robclark: for whatever reason db410c-3 was worse than the others, so I've disabled it; please let me know when you've got to upgrade them all
08:14 MrCooper: hakzsam: how is it "broken"?
08:15 MrCooper: daniels: what's the minimum version of gitlab-runner needed specifically?
08:16 hakzsam: MrCooper: that job failed because it took too much time to generate the report
08:19 MrCooper: sounds like you know more than me :)
08:19 MrCooper: are you asking why dEQP generated a gazillion .qpa files?
08:20 MrCooper: or rather cts-runner
08:23 daniels: MrCooper: fixed in 12.5 iirc
08:24 MrCooper: cool, testing has that
08:27 hakzsam: MrCooper: yes
08:28 MrCooper: I don't know much of anything about cts-runner
08:34 daniels: that's bnieuwenhuizen's baby
08:50 hakzsam: export DEQP_NO_SAVE_RESULTS=1 is what I need. Looks like extracting XML results is too slow when there is a bunch of failures
09:04 gentz: Hello folks. Anyone here knows any good resource for gbm? I'm having troubles syncronizing pageflips to vblanks, unfortunately, and can't seem to figure it out.
09:04 gentz: I've tried creating a gbm_surface, making an EGLWindow with it, then setting its swap interval to 1 from the EGL side. Then, at every frame, I draw my stuff, call lock_front_buffer to get a buffer object. With that buffer object, I call ioctl_mode_addfb2 and set the crtc before releasing the fb and buffer object.
09:04 gentz: Alas, unfortunately that doesn't seam to work and this happens: https://gentz.rocks/files/1580285102/20200129_005309.webm
09:14 MrCooper: gentz: GBM isn't directly related to presentation
09:15 MrCooper: gentz: "set the crtc" as in drmModeSetCrtc ?
09:17 gentz: MrCooper: Via `ioctl_mode_setcrtc`, which is, afaik, what `drmModeSetCrtc` would call internally?
09:18 MrCooper: that's a modeset, not a page flip; modesets aren't defined to be synchronized to vblank
09:18 MrCooper: DRM_IOCTL_MODE_PAGE_FLIP is for page flips
09:19 MrCooper: and defined to be synchronized to vblank by default (without the DRM_MODE_PAGE_FLIP_ASYNC flag)
09:22 gentz: MrCooper: Hmmm, I did try calling this function after the modeset: https://gentz.rocks/files/1580287150/src/drm/control/crtc.rs.html#167, but I remember getting BUSY errors.
09:23 MrCooper: you need either a page flip or a modeset, both makes no sense :)
09:24 MrCooper: for page flips, you also need to wait for the event from the previous one before submitting the next one, otherwise you get EBUSY
09:27 hakzsam: how does Marge's queue actually work?
09:30 hakzsam: for example, I assigned !3578 at 9:04 am, while pepp has assigned !3430 at 9:19 am, !3430 is already merged but !3578 is sill waiting (and not even picked up by Marge)
09:38 gentz: MrCooper: Huh, thank you. Yeah, that seems to have done it, now it isn't drawing frames like crazy. Unfortunately the frames look stretched and garbled, but I figure that's something for me to figure out :D
09:39 pq: gentz, wild guesses: pitch/stride in pixels vs. bytes, and if its totally garbled, wrong format modifier.
09:39 daniels: hakzsam: when idle, Marge polls for a list of open MRs assigned to her, ordered by MR ID (not time of last activity). when she finds one, she rebases, waits for pipeline success, merges, and goes back to the idle loop.
09:40 Venemo: 'she' :D
09:40 hakzsam: oh okay, it's ordered by MR ID
09:41 MrCooper: gentz: it sounds like there might be a mismatch for one of the parameters mentioned by pq (or another similar one) between the buffers you're using and the one that was scanned out before you start flipping
09:41 MrCooper: gentz: in that case, you need one modeset to one of your buffers first
09:42 gentz: Adding back the call to `ioctl_mode_setcrtc` before `ioctl_mode_page_flip` seems to have fixed it.
09:42 MrCooper: HdkR: vblank_mode=0 overrides any EGL/GLX API
09:42 pq: MrCooper, oh, is the DRM driver not supposed to reject the flip in that case?
09:43 MrCooper: probably supposed to, but there are definitely some drivers which don't catch all such cases
09:43 pq: d'oh.
09:43 MrCooper:looking at you, radeon
09:43 HdkR: MrCooper: Good to know
09:44 pq: gentz, usually you do one drmModeSetCrtc to get to the video mode and buffer attributed you want, then only drmModePageFlip from there on.
09:44 pq: *attributes
09:45 MrCooper: yeah, otherwise you'll get tearing again from the modesets
09:45 MrCooper: also, flipping to the same fb that's already being scanned out might again break with some drivers
09:46 pq: MrCooper, it can? how?
09:47 MrCooper: I don't know if it's actually an issue in practice, but I wonder if e.g. all AMD/ATI hardware will generate a page flip interrupt when re-programming the same address that's already there
09:47 gentz: Yeah, I'm only doing the `ioctl_mode_setcrtc` + `ioctl_mode_page_flip` for the first frame, then `ioctl_mode_page_flip` for every frame after, and everything's coming out great.
09:49 gentz: MrCooper: It seams to be working fine on my Radeon R7 w/ the amdgpu driver. I'll give it a test drive on my old intel laptop, and if it works on both it's good enough for me :D
10:24 hakzsam: daniels: sorry to ping you again but https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1491671 seems stucked
10:34 pq: Where are the KMS property "panel orientation" values documented? They are not in https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#standard-connector-properties even though the property itself is mentioned.
10:46 MrCooper: hakzsam: there's LAVA-internal queuing which isn't visible from GitLab
10:46 hakzsam: okay
10:46 MrCooper: the job succeeded now
10:53 hakzsam: yes, it was just long
11:06 daniels: hakzsam: we temporarily lost a couple of our rk3399 runners, but they came back around 15min ago
11:21 daniels: anholt_, robclark: in addition to disabling mesa-db410c-3 (gitlab-runner is broken and needs to be upgraded), I've disabled mesa-cheza-8 as it was timing out on most jobs after starting dEQP
12:35 bnieuwenhuizen: daniels: MrCooper: hakzsam: I think robclark added some stuff to log the outputs of failures
12:36 hakzsam: yeah, it can be disabled with an envvar
14:33 robclark: daniels: thx, I'll check on those boards when I get to the office
15:59 MrCooper: jekstrand: please don't push manually anymore, use MRs and Marge
16:05 jekstrand: MrCooper: I usually do. Did my push break something?
16:06 MrCooper: jekstrand: manual pushes/merges interfere with Marge's queue, making her upset: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3582#note_397375
16:06 gitbot: Mesa issue (Merge request) 3582 in mesa "Re-apply reverted fixes (with fixup) from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3202" [Radeonsi, Opened]
16:07 MrCooper: (not to mention wasting CI resources)
16:10 bnieuwenhuizen: so how is it wasting CI resources? (AFAICT there is 1 extra CI run due to marge retrying + 1 less CI run because you avoid the Marge repush with edited commit messages for the manully pushes branch)
16:12 daniels: if everyone does it, it's a thundering herd as everyone races rebase+push
16:12 daniels: if only one person does it then yeah it's more or less fine, but is jekstrand the only person who's allowed to do it?
16:13 bnieuwenhuizen: well, if you push manually then the entire rebase+push isn't needed/doesn't consume CI resources?
16:13 MrCooper: so it doesn't waste CI resources in the best case, but it loses some benefits from Marge, e.g. the Part-of: tags
16:14 bnieuwenhuizen: oh totally, was only attacking the argument here
16:14 MrCooper: also, it can only not waste if manually pushing directly, which is borderline insane at this point
16:15 bnieuwenhuizen: well, that was exactly what jekstrand did :P
16:15 kisak: the more valuable part here is the dev time of re-visiting the merge request for no progress while trying to play nice with the CI
16:19 robclark: daniels, anholt_, looks like mesa-cheza-6 having troubles too.. but I guess this is related to the gitlab runner needing upgrade thing?
16:26 daniels: robclark: yep, same thing
16:26 daniels: mesa-cheza-8 was different though - that was just deqp-runner starting and never ever finishing
16:27 robclark: huh..
17:02 anholt_: robclark: runner upgrade thing?
17:02 robclark:just repeating what daniels said
17:04 daniels: anholt_: see messages from ~7h ago - I disabled mesa-db410c-3 because it was failing pretty much every job. the messages it presents (couldn't create/delete container due to naming conflict) are fixed in gitlab-runner >= 12.5. most of your fleet seems to be on 12.1.
17:04 daniels: i also disabled mesa-cheza-6 because it was just hanging forever in deqp with no output
17:05 anholt_: daniels: thanks for jumping on the disables. I watched for a while on the new boards, but didn't go push jobs just to light them all up.
17:05 daniels: np!
17:06 anholt_: making slow progress on the new lava setup. tremendously frustrating after doing gitlab-runner-based CI, but being able to reboot devices each time and have health checks will be worth it
17:13 daniels: let me/tomeu know if there's anything we can help with!
17:13 tjaalton: any idea what broke llvmpipe on s390x since 19.3? majority of openscad tests produce garbage now
17:13 tjaalton: still broken in master
17:13 imirkin_: same version of llvm?
17:13 tjaalton: yes
17:13 tjaalton: 19.2 was fine, llvm 9.0.1
17:14 imirkin_: i'm going to tentatively point the finger in airlied's direction - he's the only who's been doing major llvmpipe work in recent memory
17:14 imirkin_: and no good deed goes unpunished...
17:14 tjaalton: heh
17:14 tjaalton: okay, I'll file an issue too
17:15 imirkin_: but if it's pretty much everything that's failing, a bisect could also work it out pretty quickly
17:15 imirkin_: i doubt he threw in a "if (s390x) { break everything }" statement...
17:15 tjaalton: if I had a proper test env..
17:15 anholt_: tjaalton: going to need a bisect, but does that version include my formats work? did some endianness stuff there.
17:16 tjaalton: this is a chroot on native hw, but I'm not able to install arbitrary things there, only pull packages from pre-defined sources which is why I pushed git master to debian experimental
17:16 tjaalton: anholt_: not sure, I haven't looked too closely but I did wonder if it's endianness related
17:17 imirkin_: is s390x be?
17:17 tjaalton: yep
17:17 imirkin_: does glxgears produce the expected gears?
17:18 imirkin_: but with the colors reversed (i.e. big gear is blue instead of red)
17:18 tjaalton: I don't have display, the test env uses some offscreen thing
17:19 tjaalton: tried qemu but it's borked
17:22 jekstrand: How does one get to the __DRIcontext and __DRIscreen from within Gallium?
17:22 jekstrand: I don't need it from the driver; mesa/state_tracker is fine
17:30 MrCooper: tjaalton: somebody should probably add an s390x cross-build job to the GitLab CI pipeline...
17:32 ajax: never did finish https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2443, did i
17:32 gitbot: Mesa issue (Merge request) 2443 in mesa "WIP: ci: Add cross-build tests for mips, ppc64el, and s390x" [Ci, Opened]
17:33 ajax:rebases for the hell of it
17:34 tjaalton: filed #2440
17:34 tjaalton: MrCooper: ah, maybe that would've caught this too
17:35 imirkin_: jekstrand: have a look at st_manager.c
17:35 imirkin_: iirc that's what interacts with st/dri2
17:37 imirkin_: i think __DRIcontext == st_context_iface?
17:37 imirkin_: it's all *highly* confusing
17:38 jekstrand: Yeah....
17:38 jekstrand: This is way easier in i965
17:39 jekstrand: imirkin_: Trying to figure out how one would implement a new entrypoint: __DRIscreen *glGetDRIContextMESA()
17:39 imirkin_: i think i've like semi-figured it out on a couple of occasions, but never enough to hold onto the knowledge
17:39 imirkin_: oh dear
17:39 jekstrand: Maybe that's not possible given that all the GL stuff is in mesa/st... :(
17:39 imirkin_: what would one do with such a ptr?
17:39 jekstrand: Use it from an OpenCL driver
17:40 jekstrand: That's not in the mesa tree :(
17:40 imirkin_: but how? it's an opaque pointer
17:40 imirkin_: er, opaque data type
17:40 imirkin_: (or is it not? i'm easily confused)
17:40 jekstrand: You would also have __DRIscreen *glGetDRIScreenMESA() and __DRIextension **getDRIExtensionsMESA()
17:41 jekstrand: That *should* be enough to give someone access to the DRI layer given the currently bound context
17:41 jekstrand: Because, of course, the OpenCL <-> OpenGL sharing stuff is written in terms of "turn this GL texture number into a CL image"
17:41 jekstrand: with zero reference to EGL, GLX, or any context whatsoever
17:41 imirkin_: of course.
17:42 imirkin_: simpler that way.
17:42 jekstrand: much
17:42 jekstrand: I could write GL_INTEL_give_me_internal_details_of_this_texture but I'd rather not plumb everything through GL
17:43 imirkin_: so ... high-level requirement is "get dma-buf for this GL texture id", right?
17:43 jekstrand: And enough internal texture layout details so they know what to do with the memory
17:43 imirkin_: isn't there an EGL_something for this?
17:43 jekstrand: Because, naturally, it's supposed to work on mipmapped arrayed textyres.
17:43 jekstrand: They might be on GLX
17:43 ajax: you can make glx extensions too you know
17:43 imirkin_: IMPOSSIBLE!
17:44 imirkin_: but yeah - i think realistically you have to go through the winsys layer
17:44 jekstrand: Sure, but how is the CL driver supposed to know if it's on EGL or GLX to call the right one?
17:44 imirkin_: ah, because you call clImportGLTexture(gl_texture_id)?
17:44 jekstrand: yeah
17:45 imirkin_: delightful.
17:45 jekstrand: It's supposed to "just work"
17:45 ajax: it doesn't? it'd be a callback into the cl loader
17:45 anholt_: jekstrand: you have to query egl to find if the current context is egl or not
17:45 jekstrand: The CL driver doesn't live in mesa
17:45 daniels: there is a cl_arm_import_memory_dma_buf, but it only takes a single fd and no modifier
17:45 anholt_: epoxy_current_context_is_glx() may help
17:46 jekstrand: Ok, so we can query EGL and GLX to figure out which one it is and then either get the __DRIScreen etc. from them or write EGL and GLX extensions for all the stuff we need.
17:46 daniels: (even so, getting a fd from a GL texture using only actual extensions involves doing a lot of deeply stupid things behind the application's back)
17:46 imirkin_: jekstrand: you could also add a glGetDmaBufForTextureMESA(), no?
17:46 jekstrand: imirkin_: In theory, yeah
17:47 imirkin_: and fail if they're not on dri3
17:47 jekstrand: Part of the issue here, though, is that the dma-buf is only half of the story
17:47 daniels: you also lose if it's not actually exportable
17:47 imirkin_: don't modifiers describe what you need?
17:47 jekstrand: Since it's potentially a mip-mapped array texture, I have to be able to communicate all the layout details.
17:47 jekstrand: modifiers are designed for "simple" 2D images.
17:47 imirkin_: ah.
17:48 jekstrand: daniels: I think the CL extension gives us enough wiggle room there though it's pretty bad.
17:48 imirkin_: how about glGetDetailedTextureDataMESA() :)
17:48 jekstrand: heh...
17:49 jekstrand: I've thought about that.
17:49 airlied: like lots of CL things, clearly bad design
17:49 MrCooper: jekstrand: I have vague recollection of mareko implementing something like this for radeonsi
17:49 anholt_: doing a gl extension for getting the required data feels like the right way to go
17:49 jekstrand: There's really two issues here: 1) How to plumb it through (GL, EGL/GLX, talk DRI directly) and 2) How to encode the data to pass between drivers.
17:50 jekstrand: MrCooper: Yeah, the amdgpu implementation involves a kernel blob of side-band data attached to the BO
17:50 jekstrand: Unfortunately, I have het to see a "good" design for any of this.
17:51 jekstrand: Vulkan tried to do better with their sharing but it's pretty rubbish as well
17:51 daniels: jekstrand: at least - and I didn't actually expect this - it does specify UB if the object you reference is deleted within GL
17:52 daniels: mind you, it says absolutely nothing about what happens if the texture is respecified rather than deleted ...
17:52 jekstrand: daniels: Yeah, well, this is interop. What do you expect? Things to be well-defined?
17:53 daniels: what I'm hearing is that you've volunteered to implement vk/gl interop after this
17:53 jekstrand: No
17:53 jekstrand: I'v voulenteered other people to write tests and start looking into an implementation.
17:53 daniels: (wow, cl_khr_gl_event appears to just throw around 'pending OpenGL operations' without any reference to flush)
17:54 jekstrand: hehe
17:54 daniels: jekstrand: remind me to never get on your bad side :\
17:54 airlied: daniels: same problem with some of the gl/vk semaphore apis
17:55 airlied: doesn't say you really need to glFlush for this to make sense
17:55 ajax: you could always punt on the "how to encode" question by using like iff or some other container format
17:56 jekstrand: My current plan for "how to encode" is to just pack a generation-specific RENDER_SURFACE_STATE packet and hand it off.
17:56 jekstrand: Since it's specified in the hardware, it should be a stable API at least per-generation. :-)
17:57 ajax: you don't want interop between igpu and dgpu?
17:57 ajax: y'all are dgpu vendors too now, no?
18:02 anholt_: given that texture layout is per-gen, I think the full CL interop between dgpu and igpu would be impossible in the general case.
18:05 kisak: friendly note that https://gitlab.freedesktop.org/mesa/mesa/merge_requests?assignee_username=marge-bot&scope=all&sort=created_asc&state=opened is the merge queue (lowest merge request number first, not fifo). NOTE: link will mess with how you usually sort on gitlab.
18:13 cmarcelo: where can I see the config/commandline used by freedesktop marge-bot? (I'm curious to see what value we use for --merge-order, if any)
18:16 ajax: wow. ~20m ci runtime * 10 queued merges = 3h20m of queued work.
18:17 daniels: cmarcelo: https://gitlab.freedesktop.org/freedesktop/helm-gitlab-config/blob/master/marge-mesa-config.yaml
18:17 ajax: we're peaking at around 30 pipelines a day. 10h is longer than a standard workday, unless you're in the US
18:19 ajax: probably that doesn't mean landing 30 MRs per day, but still
18:19 cmarcelo: daniels: tks
18:19 ajax: impressive
18:19 daniels: there's definitely a lump about now (IIRC), but remember that the working day is distributed across a 10h time difference
18:20 daniels: so you've got roughly 19 hours between 9am eastern Europe and 6pm west coast US
18:22 airlied:does worry once llvmpipe can support gl4.6 how long the pipeline blowout might be :-P
18:22 ajax: do we have any numbers about marge's reject rates and causes?
18:23 ajax: how many are novel test failures vs how many are rebase conflicts
18:24 ajax: tsk, gitlab will give me daily job graphs but not hourly
18:24 anholt_: sadly, the marge spam I get is basically all flakes by various runners (freedreno's blits, gitlab-runner docker fails, and lava labs going down)
18:24 anholt_: I'm not doing any systematic review, though
18:26 ajax: enh. you're saying hardware failure is more common than developer failure, speaks well of our developers i'd say
18:26 robclark: I would say, from my perspective, it is pretty nice not to have random things broken each time I rebase ;-)
18:26 robclark: I think most people don't/shouldn't assign to marge until after CI is green on their MR in the first place
18:26 anholt_: ajax: the real failures get shaken out before the marge rebase
18:26 robclark: so I think marge just catches the edge cases where thigns go boom when you put multiple MRs together
18:27 robclark: right
18:28 ajax: well, there's three rates there. what % of marge's ci runs fail, what % of all ci runs for submitted MRs, what % of all ci runs for all branch pushes in all trees (more or less)
18:43 mareko: jekstrand: see mesa_glinterop.h, out_driver data is texture metadata
18:44 mareko: jekstrand: with that, GL-CL interop is mostly done for you on the gallium side
18:48 mareko: jekstrand: it's ABI between Mesa and AMD ROCm OpenCl driver, I think the OpenCL driver uses dlsym to get the entrypoints
19:13 daniels: ajax: if you want a JSON dump of everything about every job (pipeline ID, job name, repo, tags, runner, queue/start/end time, status) then I can give it you
19:15 daniels: anholt_: ^
19:15 daniels: can p trivially extend that to include who triggered the pipeline
19:15 anholt_:opts out
19:30 Venemo: hey
19:30 Venemo: are any of you guys going to FOSDEM?
20:13 jstultz: robclark: another minor kCFI fix in your inbox
20:17 sravn: bbrezillon: Shall I pick "drm/panel: simple: Fix the lt089ac29000 bus_format" or will you apply with the rest of the series?
20:17 sravn: bbazaluk: Patch is a-b if you handle it
20:18 sravn: bbazaluk soory for the noise this was for bbrezillon
20:40 jekstrand: mareko: Is there an extension defined somewhere?
20:42 mareko: jekstrand: it's not an extension, it's a Mesa ABI
20:43 jekstrand: mareko: What library exports those symbols?
20:43 mareko: libGL and libEGL export the functions; I think users have to use dlsym
20:44 jekstrand: I'm not seeing them with nm -D
20:44 jekstrand: Ah, it's in libGLX_mesa.so.0
20:45 jekstrand: Not finding the EGL symbols :-9
20:45 jekstrand: :-9
20:45 jekstrand: :-(
20:45 jekstrand: shift keys...
20:51 anholt_: robclark: https://gitlab.freedesktop.org/kwg/mesa/-/jobs/1500842
20:51 anholt_: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/1500744
20:52 anholt_: I feel like i've done all I can to work around their flakiness, we need to just disable them.
20:56 robclark: anholt_: but does that just turn into whack-a-mole again?
20:57 anholt_: we do need to disable large groups of tests, yes.
20:58 robclark: I mean, other than the blit tests, the other flakes seem to be a timing thing w/ varyings.. and disabling tests w/ varyings makes CI a bit less useful :-P
20:58 krh: do we have a process for becoming a mesa gitlab owner?
20:58 robclark: I'd rather just re-run individual failed tests, than disabling large blocks of tests
20:58 anholt_: robclark: we already re-run the tests.
20:58 anholt_: 5 times
20:59 robclark: in the same group and order
21:00 anholt_: clearly something transient is going on, becuase you can rerun in same group and order in a loop on its own and not reproduce, right?
21:01 anholt_: I'm betting that even if you swapped flake detect out to rerun just the one test, it would still fail to catch the flakes.
21:07 robclark: it is something transient, I think.. and I think re-running the same group of tests in the same order just has a tendency to recreate the same sequence that caused the flake in the first place
21:09 krh: do we have a process for adding new developers to mesa gitlab?
21:09 robclark: anholt_: fwiw, I do see in certain circumstances, that blob adds some nop's to beginning of FS.. we perhaps should look into that, could be some sort of workaround
21:09 anholt_: krh: not really
21:10 anholt_: robclark: oh, that seems extremely important
21:10 krh: anholt_: right, I was hoping the bar would be a little lower with gitlab, since it doesn't need a fd.o ssh account
21:10 robclark: (I guess the blit flakes are something different, but the fragment-out flakes and xfb flakes seems to be some timing between vs and fs warps, or something like that)
21:11 krh: but what I really want is to be able to cc @brkho in a MR comment and for him to set labels on MRs
21:11 anholt_: robclark: my concern with your theory there is that I believe I've taken the failing caselist and run it in a loop and not reproduced, so I don't actually think the grouping of that run is important to the flake.
21:11 krh: but he has to be a developer for that
21:12 anholt_: (so, probably something more like "clocking changes the frequency of it appearing" or something)
21:13 robclark: hmm, I suppose it could be interesting to for performance gov and see if that changes things..
21:14 robclark: that should mean we are max or off, rather than trying to scale thru intermediate freqs
21:14 robclark: I guess we could also limit max_freq
21:14 robclark: (I guess nothing in deqp is actually gpu bound)
21:15 krh: could a mesa owner add https://gitlab.freedesktop.org/brkho as a developer?
21:19 Kayden: working on turnip it looks like?
21:19 krh: Kayden: indeed
21:19 Kayden: I thought reporters could set labels and they definitely tab complete
21:20 krh: maybe that's enough
21:20 krh: any kind of membership should enable the tab complete
21:20 Kayden: added him as a reporter
21:20 krh: Kayden: thanks
21:21 Kayden: normally we look for 25 patches or a couple series of significance before giving commit rights
21:21 Kayden: but there's some leeway there, so if you or Rob or anholt think he should have access I'm more than happy to add it
21:22 krh: Kayden: I agree, I didn't necessarily want commit rights... but gitlab...
21:22 krh: but I'll definitely vouch for him, he's been doing good turnip work in the past few weeks
21:24 Kayden: oh, boo
21:24 Kayden: reporters can label issues, but not MRs
21:24 Kayden: that seems... silly
21:25 krh: yeah, anybody can file an MR, but they can't label it...
21:25 Kayden: upgraded to developer
21:26 krh: cool, thanks
21:26 robclark: yeah, the label thing is silly/annoying.. but I ack brkho (but kinda feel like it's better to have someone outside the same Corp involved in approving/adding new developers)
21:27 Kayden: always nice to have both, for sure
21:28 Kayden: I'm not really worried about giving out extra developer access though, if people are contributing and have people they're working with keeping an eye on things, and we have gitlab CI now, and require reviews...
21:28 robclark: true
21:28 Kayden: in the old days, we were giving out fdo shell accounts to folks so they could have a personal repo, and possibly commit access...mostly because they worked at a company or on a team doing mesa stuff
21:29 Kayden: and at least some of the intel people weren't really into it and didn't stick around
21:29 robclark: I guess we probably should formalize what the post-bz process is for adding a member, since I'm not really sure quite what it is now
21:30 robclark: but yeah, not involving a shell account, plus having CI, I guess probably lowers the bar
21:30 Kayden: (so we said...at least show you can get -some- stuff upstream...just because you work at a corporation doesn't mean you've earned a place in the upstream community yet...)
21:31 Kayden: I think reporter access is fine to give to pretty much anybody with a rationale for having it
21:31 karolherbst: who can change the assigned person of a MR?
21:31 karolherbst: or well.. account rather
21:32 Kayden: Developer+
21:32 karolherbst: k
21:32 Kayden: issues is Reporter+
21:33 Kayden: https://gitlab.freedesktop.org/help/user/permissions
21:33 Kayden:had no idea so just reading the docs
21:34 Kayden: by the way... I was kind of interested to learn more about what we have for draw call reordering in mesa
21:35 Kayden: it looks like freedreno internally reorders some draws? I remember there was some thought of having a gallium layer for that, but I think that never panned out?
21:36 Kayden: I know that ordering things around RT changes matters a lot for tilers
21:36 Kayden: (and probably wouldn't hurt elsewhere, even if it isn't as critical)
21:37 Kayden: in iris I have a bunch of stuff to try and bin things into <rendering> and <compute> to avoid stalls when swapping back and forth. been wanting to also group blits/clears/copyregion
21:37 daniels: btw for labelling, I think the best solution to that is Danger, so we can apply labels automatically based on path
21:37 Kayden: but...thinking about reworking all of that
21:38 daniels: the upstream reason for it to be different between issues and MRs is that a lot of people use labels like 'pick into stable' or whatever
21:38 daniels: anyway
21:39 robclark: Kayden: yeah, I experimented at one point with having a shim pipe context that re-orders things.. I didn't get to the point of actually re-ordering things, but the overhead of serializing was enough that I decided against it..
21:39 krh: daniels: ah, ok... yeah automatic labelling would be great, I often forget to label MRs
21:39 robclark: otoh, maybe if you combined it w/ threaded gallium that would offset the overhead? idk
21:40 Kayden: daniels: Yeah, definitely seen gitlab itself use labels for official stances like "we are actually committed to doing this thing" or so on...wouldn't want randos applying those :)
21:40 Kayden: robclark: Yeah...that's kind of what I was afraid of
21:40 anholt_: daniels: how much of a lava expert are you? trying to sort out my boot in https://people.freedesktop.org/~anholt/LAVA%20_%20Scheduler%20_%20Jobs%20_%2035.html and it really looks like lava's not waiting for the u-boot prompts right.
21:41 robclark: Kayden: fwiw, we were talking y'day about going a step further.. I noticed in manhattan there are a couple render passes that share the same depth buffer (depth test enabled, but depth write disabled) which could be combined into a single pass w/ mrt's..
21:41 robclark: daniels: something that automatically applied labels on MRs would be awesome
21:42 anholt_: Kayden: vc4 and v3d have internal job reordering as well, simpler than freedreno's (no resource shadowing to increase reordering)
21:43 anholt_: if I was building a shared helper, I think it would be tracking structs in resources and jobs, and helpers for serializing jobs at draw/transfer time.
21:43 Kayden: robclark: oh interesting...so combining the draws with the shaders? oof. sounds useful but painful
21:43 krh: definitely painful
21:44 robclark: I think we can do something simpler.. and just set it up as a single mrt, but have the gmem restore/resolve code treat it as two.. and half way thru the batch swap the gmem offset of the color buffer
21:45 Kayden: anholt_: I think simpler is better for me - I should look at how v3d works
21:47 Kayden: each FBO gets a job, and each job has a command list?
21:48 Kayden: do you have a validation list of sorts? (all resources that command submission needs to ensure are pinned in memory, etc)
21:49 daniels: anholt_: wrong link maybe? it's waiting for the prompt just fine, but what it's not doing is ever tftp'ing an initrd
21:49 daniels: hence the initrd wrong-format message at the end, because it's just reading uninitialised memory
21:50 daniels: oh, it should be, but isn't ... that's really odd
21:52 daniels: anholt_: can you please pop your device/device-type definition somewhere?
21:54 daniels: robclark: https://gitlab.freedesktop.org/wayland/weston/merge_requests/352
21:54 gitbot: wayland issue (Merge request) 352 in weston "CI: Add Danger automated checker" [Opened]
21:55 robclark: oh, heh, just hook it in via CI hook
21:57 imirkin_: anholt_: random thought, without knowing uboot ... setenv initrd_size ${filesize} -- is that supposed to work, or was ${filesize} supposed to have been replaced by soemthing?
21:57 daniels: ${filesize} is set by tftp
21:59 imirkin_: oh yeah, it only gets the image
22:04 daniels: right, it just spams the initrd tftp req into the void whilst the kernel's downloading
22:04 daniels: rather than waiting for the prompt like it claims it is
22:04 imirkin_: i'm wodnering if it sees the prompt at some point
22:04 imirkin_: or the timeout is hit? hm, doesn't seem like either would be the case
22:13 curro: dcbaker: when is the branchpoint happening in the end? hoping the last scary patch of !3594 can make it, which is the only one of that MR pending review
22:13 curro: cmarcelo: did you have a chance to take a look at it?
22:14 dcbaker: it was supposed to be today, but there's still a bunch of stuff blocking the branchpoint
22:14 dcbaker: curro: ^
22:14 cmarcelo: curro: going to that now.
22:18 Kayden: workarounds don't necessarily need to land prior to the branch point
22:18 Kayden: those are bug fixes, they're prime targets for cherry-picking
22:20 Kayden: 30 patches of overhead optimizations on the other hand... :)
22:20 Kayden: should land those before the branchpoint :)
22:36 curro: Kayden: even kind of invasive workarounds adding whole lowering passes? ;)
22:47 Kayden: still a bug fix
22:53 curro: good to have that reassurance, you guys are free to cut the RC without my MR then
22:55 curro: cmarcelo: sounds like there is no rush to get that patch reviewed then
23:01 Kayden: curro: how goes SIMD32 stuff?
23:04 curro: Kayden: looking into the Iris cache tracking reworks today... hopefully that qualifies as a bug fix too ;)
23:05 krh: do we have the process for getting patches into stable releases documented somewhere?
23:06 anholt_: daniels: https://people.freedesktop.org/~anholt/db410c-01.dict and db410c-test-job.yml
23:07 anholt_: note that it emits the command for tftping initrd, just before the kernel tftp has completed
23:08 anholt_: (same thing with commands coming after the "dhcp" command)
23:08 anholt_: apparently the logging system in lava is racy, but I don't think it's that racy.
23:10 Kayden: curro: slightly more nervous about that one
23:11 Kayden: does SIMD32 break more than the repeated color clear tests without that?
23:14 krh: dcbaker: I remember you explained it to me a while back, but I was hoping for a doc that I could point somebody to
23:15 Kayden: curro: I'm just getting nagged about this in meetings every other wednesday for several months now, and people expressed that they were "out of patience" like 4 weeks ago
23:15 Kayden: and if the only thing blocking it at this point is tests in CI that are already flakey and blacklisted...
23:23 cmarcelo: curro: ack. so far things seems reasonable in the patch, but I need to think a bit more about it.
23:25 curro: Kayden: i had seen other intermittently failing tests with SIMD32 but i haven't confirmed they have the same root cause
23:25 curro: Kayden: i'm sorry you need to be the object of people's impatience, especially considering the tiny payoff from this performance feature
23:26 curro: seems like a data corruption issue ought to be higher priority? (since it isn't truly specific to SIMD32 nor color clear tests, that scenario just happens to get the timings right for a failure to occur in our CI)
23:35 Kayden: probably ought to be, but likely isn't :/
23:40 bnieuwenhuizen: krh: one of three options: Add a Fixes tag to a commit that is in the stable branch already (2) CC stabe (3) create an MR against staging/${VERSION}
23:43 dcbaker: krh: https://www.mesa3d.org/submittingpatches.html#nominations
23:44 krh: dcbaker: thanks
23:53 mareko: is classic swrast tested by gitlab pipelines?
23:55 airlied: mareko: nope don't think so