01:10 imirkin: anholt: tjaalton: not sure if you saw, but someone bisected the BE thing: https://gitlab.freedesktop.org/mesa/mesa/issues/2472
01:10 gitbot: Mesa issue 2472 in mesa "Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)" [Opened]
01:40 kisak: anholt_: dumb question if you have a spare moment: why is https://gitlab.freedesktop.org/mesa/mesa/blob/master/.gitlab-ci/deqp-freedreno-a307-fails.txt a307 instead of a306?
01:41 kisak: is it just to make it easier to avoid a typo with 630?
01:41 anholt_: probably just a typo
01:43 kisak: okay thanks, a pretty harmless typo it is
02:01 ascent12: Are there any gurantees about the order of modifiers found in IN_FORMATS? e.g. in order of preference. Basically, if I keep pruning possible modifiers to get a working atomic setup, should I prune from front to back?
02:13 ascent12: Actually, thinking about it, it doesn't need to be implemented that way. You'd just prune what gbm_bo_create_with_modifiers gave you the previous time.
03:08 robclark: anholt_, kisak: a306 vs a307 is just alignment w/ android kernel lolz about marketing names vs how kernel identified things to userspace.. if you want to know the history, first there was a305.. then there was a305c which the kernel called a306.. and then there was an actual a306.. but what to call it => a307 :-P
03:10 robclark: (and to simplify things, partially because early on libdrm_freedreno also had a kgsl backend, and partly in case anyone wanted to add support for a305c upstream, we just aligned w/ what downstream kgsl reported to userspace)
04:56 tjaalton: imirkin: oh nice
07:00 emersion: ascent12: it would be nice to have the "fake buffer" support in the kernel not to have to allocate buffers when doing this dance
09:50 tjaalton: what's the best procedure to bisect mesa with meson? just run 'ninja -jN' on the build dir after each step?
09:50 tjaalton: it seems to DTRT but running the tests seem suspicious
10:02 MrCooper: suspicious how? Anyway, yeah, meson generally handles incremental builds fine
10:03 tjaalton: suspicious that I get these big-endianness-ish failures even with 19.2-branchpoint
10:04 MrCooper: alternatively, with ccache, ninja clean before git bisect good/bad shouldn't take much longer (and should keep the build directory tidy)
10:04 MrCooper: BTW, ninja runs multiple jobs in parallel by default
10:05 tjaalton: ah
10:05 MrCooper: we use -j4 in the CI jobs to prevent it from running too many in parallel :)
10:06 tjaalton: I'm already using -j30 to leave a couple of cpu's free on this sparc thing :)
10:06 tjaalton: the final bits linking stuff take a long time anyway
10:07 tjaalton: since the cores are puny
10:07 HdkR: I just let it consume all 64 threads on my system, since the random overheads of switching seems to give most other processes enough time :P
10:07 MrCooper: tjaalton: make sure it doesn't link LLVM statically :)
10:10 tjaalton: heh, doesn't look like it
10:39 hakzsam: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/commits/ci_fossilize I have started to work on Fossilize (it's similar to vkpipeline-db but better) support for Mesa CI. Basically, I want to replay Vulkan graphics/compute pipelines to detect compiler issues (NIR, LLVM, ACO or wathever is involved). Currently, I copy some fossilize pipelines during the VK test image creation, it's obviously not going to fit for large data. Let's assume I have a git lfs
10:39 hakzsam: somewhere, should the repo be cloned inside the runner? I think it's similar to the way tracie works?
10:42 MrCooper: it's better to bake the test cases into the docker image, otherwise changes to that Git repository can break Mesa commits which were previously passing
10:42 MrCooper: it's the same as with piglit/dEQP
10:48 hakzsam: MrCooper: but the docker image is going to be huge?
10:48 hakzsam: especially with traces
10:49 MrCooper: if it's huge, it's going to use a lot of time and bandwidth in each pipeline otherwise?
10:52 hakzsam: it shouldn't if the repo is stored locally?
10:57 MrCooper: locally on each CI runner?
10:57 hakzsam: yes
10:58 MrCooper: that would use up more storage on them than the docker image?
10:59 hakzsam: that's true
11:00 hakzsam: how tracie is going to work then? are we going to add bunch of GB to the docker images?
11:42 hakzsam: MrCooper: there is still a problem with private content if shaders/traces are copied to the docker images?
11:44 MrCooper: maybe, in which case you need to talk to daniels / the people maintaining the CI runners
11:45 daniels: if you have private content which can't leak, you have to assume that you can only run it on specific systems which you trust
11:45 daniels: none of the shared runners should be considered trusted, as there are too many ways to exfiltrate content
11:46 daniels: what tomeu and alf have been looking at for tracie is to have trusted hardware executors stream content directly from an internal network as and when they need to access those traces
11:50 tomeu: hakzsam: MrCooper also, the plan is to "stream" the traces on the go
11:51 MrCooper: can't say I care too much about this sort of thing
11:51 tomeu: so execution and downloads overlap, and only the traces that are being executed need to be on local storage
11:52 tomeu: but even for public test suite data that is to be downloaded on the go, it may be a good idea to have a local proxy
11:54 tomeu: for determinability, it would be enough to have in the container the urls to the data, or checksums, or whatever is needed to download it and be sure it's what you think it is
12:02 MrCooper: what would that buy over baking it into the image?
12:16 hakzsam: tomeu: maybe one solution is to assume that my local runner (on a system that I can trust) has a git lfs stored locally? And to avoid breaking Mesa commits which were previously passing I can store a reference point (sha1) directly in gitlab.yml ?
12:17 tomeu: hakzsam: yeah, that's what tracie is planning to do
12:18 tomeu: MrCooper: traces can be very big, and not all devices will run all traces
12:18 tomeu: and by overlapping data download with execution, we can make better use of the available hw
12:18 hakzsam: tomeu: great. So, no problems with private content :)
12:19 tomeu: ah yes, should also help with that
12:19 hakzsam: tomeu: what do you mean by "stream"? are traces downloaded on-demand?
12:19 tomeu: hakzsam: yes
12:19 tomeu: through in the current implementation it happend sequentially
12:20 hakzsam: this isn't exactly how it's going to work for us because I think we will just have a NFS on that local network, but I get the idea
12:22 tomeu: yeah, though well, as people won't have access to the traces when their code makes them fail, you will need to do the triaging yourself anyway
12:22 tomeu: so just do whatever is easier for you :)
12:23 hakzsam: sure, but it's a different topic :)
12:23 tomeu: for now we are focusing on upstream pre-merge testing
12:23 tomeu: so are more constrained than you
12:24 hakzsam: yeah, saw that. I think i'm going to re-use some concept of the traces system for fossilize
12:25 tomeu: if you are going to also have traces of FOSS games, etc, then maybe tracie should learn to use fossilize as one more tracer
12:25 tomeu: it has already support for renderdoc and apitrace
12:26 tomeu: then we can use fossilize for both pre-merge (with public traces), and for post-merge with secret ones
12:27 hakzsam: fossilize is for shaders only
12:28 tomeu: ah, I see
12:28 hakzsam: it's like shader-db for vulkan
12:29 hakzsam: or vkpipeline-db but definitely more roubst
13:50 tlwoerner: hi fdo community! once again this year I'll be admining your GSoC 2020. the application is due in 5 hours and i need to find a 2nd community member who will act as an admin. if you have any interest or questions please let me know! thanks :-)
14:00 karolherbst: who is the first one and what is the project about?
14:03 jcristau: tlwoerner is the first one
14:04 jcristau: and this is not about an individual project it's about the org-wide admin foo, aiui
14:04 tlwoerner: jcristau: yes
14:04 tlwoerner: mentoring comes later, for now i'm just looking for another (required) admin
14:32 hakzsam: tomeu: what's the expectations checksum for?
14:32 tomeu: hakzsam: if the rendered image matches the chechsum, it's a pass
14:32 tomeu: otherwise it's a failure
14:33 hakzsam: ok
15:13 tanty: hakzsam, tomeu, I'm working in adding gfxreconstruct support to tracie for Vulkan traces
15:13 tanty: I would like to coordinate efforts, if we can
15:14 tanty: I'm also concerned with the "streaming" of traces and making sure that they are not leaked and only run in trusted runners
15:14 tomeu: tanty: nice!
15:15 tomeu: anholt_ seems to have some concerns about the streaming thing
15:15 tomeu: tanty: guess the secret traces are only intended for downstream post-merge testing?
15:16 tanty: correct, AFAIK
15:16 tanty: but I suppose that also needs to be agreed, eventually
15:16 tanty: but, yeah, I think that's the idea
15:20 hakzsam: tanty: great
15:22 tomeu: tanty: for super-secret stuff, probably easiest is to have a gitlab-ci variable that allows overriding the traces-db repo
15:22 tomeu: and in your case it can point to a repo only accessible from your internal network
15:22 tomeu: the expectations are in mesa though
15:23 tanty: yes, I saw that
15:23 tanty: I suppose that's how you are using it in LAVA labs (?)
15:23 tomeu: but if it's of use to the community, guess they can be merged upstream so the expectations live along the code
15:23 tomeu: tanty: we don't do anything secret yet, we're focusing on upstream pre-merge for now
15:23 tanty: oh, nice
15:24 tomeu: but we have been investigating the use of secret traces to make sure we don't paint ourselves in a corner
15:24 tanty: right. Makes a lot of sense.
15:27 hakzsam: tomeu: https://gitlab.freedesktop.org/hakzsam/mesa/commit/9a4696d4259c2b278ddda9c038c906552fb274b1 https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1553762 :)
15:28 tomeu: hakzsam: that was quick!
15:30 hakzsam: it's loosely based on the traces system
15:35 MrCooper: dcbaker (or anyone else interested): FWIW, if you'd like to try reviving the meson-windows CI job, __tim on #freedesktop said: "feel free to experiment with [the gstreamer Windows runners] in personal repo to get a feel for setup/performance, maybe that'll help us decide how much resources it would end up needing"
16:23 imirkin_: bbrezillon: just reading commit "pan/midgard: Turn Z/S stores into zs_output_pan intrinsics" -- is there something that already combines gl_FragDepth writes globally? e.g. if i have if () { gl_FragDepth = foo } else { gl_FragDepth = bar } -- does something already make a temp var out of it and then stick a store at the end of the shader?
17:23 idr: imirkin_: A pass like that exists, but I think it has to be enabled by the driver. Maybe.
17:24 imirkin_: idr: yeah, i remember some glsl pass would do it, ages ago. wouldn't be surprised if such a thing existed in nir too.
17:25 imirkin_: (or maybe the glsl pass was about *reading* outputs?)
17:30 cwabbott: there is nir_lower_io_to_temporaries which does that
17:31 cwabbott: panfrost should be using it hopefully
17:31 imirkin_: makes sense
17:58 jhli: Anyone free to do a quick review for libdrm getfb2 wrapper? https://patchwork.freedesktop.org/patch/351456/
18:33 eric_engestrom: jhli: I tend to dislike `struct drm_mode_fb_cmd2 get; memclear(get); get.fb_id = fb_id;`
18:33 eric_engestrom: `struct drm_mode_fb_cmd2 get = { .fb_id = fb_id, };` is more readable IMO
18:35 bl4ckb0ne: plus you avoid a few lines of assembly to clear it
18:35 jhli: eric_engestrom: Sure, I can change that
18:35 eric_engestrom: jhli: has the kernel side of this already landed?
18:36 eric_engestrom: I found https://patchwork.kernel.org/patch/9873449/
18:36 tjaalton: it has
18:36 eric_engestrom:fetches drm-misc
18:36 jhli: In drm-misc: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=455e00f1412fe51fa7bd21ad6fe0015b163fa9e5
18:37 tjaalton: after this lands in libdrm, a new release would be nice ;)
18:53 kisak: looks like the db410c runner (one?) is overloaded right now, to the point marge-bot is blocked
18:58 jhli: eric_engestrom: any other concerns before I submit a new rev?
19:05 dschuermann: jekstrand: wording question: do you prefer annotating cf_nodes as 'uniform_cf' or 'non_uniform_cf'? and is a diverging IF already non-uniform or only the blocks inside? (same for loops)
19:05 daniels: anholt, robclark: ^ db410c hurting?
19:05 kisak: oh, whatever db410c snafu there was, it's passed and there's just a large backlog
19:06 kisak: https://gitlab.freedesktop.org/tpalli/mesa/-/jobs/1555595 when degraded, the rest in the set of 4 are fine (and newer runs)
19:06 kisak: 16 minutes -> 4 minutes
19:11 robclark: daniels, anholt_: db410c-1 seems to be running..
19:11 kisak: maybe it has a hard time transitioning between the 19.3 branch and newer?
19:13 anholt_: kisak: note the 12 minute docker image pull at the top
19:13 robclark: I think switching containers can be painful, afaiu.. or at least at one point there seemed to be an issue that emmc was slower than expected
19:13 robclark: yeah, that
19:16 bbrezillon: imirkin_: I don't know
19:16 imirkin_: bbrezillon: check cwabbott's comment to me about it a bit later - worth double-checkign you have that pass enabled
19:21 bbrezillon: imirkin_: we don't call nir_lower_io_to_temporaries() explicitly
19:21 bbrezillon: but I see it called in glsl_to_nir
19:21 imirkin_: ah ok
19:21 imirkin_: cool
19:24 bbrezillon: well, looks like it's conditioned on get_param(PIPE_CAP_TGSI_CAN_READ_OUTPUTS) == 0
19:26 bbrezillon: which is the case on panfrost
19:28 imirkin_: makes sense
19:35 anholt_: rebooted db410c-3 (oopsed in OOM handling), hopefully it'll be back up shortly to fix our queue times
20:10 imirkin_: anholt_: thanks for diving into all the formats stuff. it also annoyed me considerably, but i never had the courage to do antyhing about it
20:10 anholt_: imirkin_: it's been a slog. I've got a big branch of deduping format pack codegen stuff from mesa/main, and just ran out of steam in getting it regression free.
20:11 imirkin_: yeah, i can imagine
20:11 anholt_: it's particularly painful given that we don't have the GL CTS in CI, so I end up having to babysit my branches through intel CI.
20:11 imirkin_: but i think you've already cleaned things up considerably
20:11 anholt_: thanks!
20:11 imirkin_: so even if you happen to stop here, it's quite a bit nicer than it was
20:12 anholt_: I'm so happy about the image-formats branch.
20:12 imirkin_: there's definitely some piglits which are super-sensitive to incorrect packing
20:12 imirkin_: teximage-colors is the one that jumps to mind, but i could be off on that
20:13 anholt_: yep, definitely had regressions in that one!
20:13 anholt_: GL_BITMAP
20:13 imirkin_: something which basically tries to copy from every format to every format
20:13 imirkin_: lol
20:13 imirkin_: nvidia actually has bitmap sampling support, but i don't think it's a proper gallium format
20:13 Kayden: bitmap is the worst :(
20:14 imirkin_: (and i've never actually tried using it)
20:14 imirkin_: (i'm sure it interacts _really_ nicely with 3d images using mipmap-linear sampling...)
20:34 ajax: i can't really imagine mipmapped bitmaps making much sense
20:39 imirkin_: ajax: esp with inter-mipmap interpolation, using 3d coordinates? :)
20:39 imirkin_: but "make sense" and "things you can do in GL API" aren't necessarily the same set of things
20:42 karolherbst: imirkin_, anholt_: some months ago I was trying to fix a GLES bug in CopyTexImage regarding our silly RGBA4 situation: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/123
20:42 gitbot: Mesa issue (Merge request) 123 in mesa "WIP: fix GLES CopyTexImage for drivers not fully supporting RGBA4" [Gallium, Mesa, Opened]
20:43 karolherbst: I kind of assume the format rework makes it easier to fix this one as well or not?
20:44 anholt_: format stuff should be a lot less mysterious -- MESA_FORMAT to equivalent PIPE_FORMAT is now #defined.
20:44 anholt_: PIPE_FORMAT names are still awful to understand
20:44 anholt_: and you can use format util functions anywhere
20:45 karolherbst: yeah.. but the issue we had was that we need to validate the API format, not the drivers format what we've been doing
20:45 karolherbst: because.. GLES
20:46 imirkin_: karolherbst: afaik it shouldn't be easier or harder to fix
20:46 karolherbst: so eg if you get a RGBA8 texture and want to render it to RGBA4, but internally we upraded it to RGBA8, we still can't accept the call
20:46 karolherbst: I think it was this way?
20:46 imirkin_: karolherbst: it's basically a policy decision, at the GL state tracker level ... do you require renderability for certain formats when allocation textures
20:46 imirkin_: imho - yes.
20:46 karolherbst: yep..
20:47 imirkin_: allocat*ing*
20:47 karolherbst: imirkin_: but I think it could be easer if we can now save the same format type, we can have simplier compares instead of adding another format layer
20:47 karolherbst: or so
20:47 karolherbst: the annoying bit of my MR was that I added a new API format enum essentially
20:47 imirkin_: karolherbst: should just be "if GL_format is required renderable, make sure to add PIPE_BIND_RENDER_TARGET", right?
20:47 karolherbst: not really
20:48 imirkin_: why not?
20:48 karolherbst: the problem is, we have to throw an error, but we just accept what's coming
20:48 imirkin_: we should accept it.
20:48 karolherbst: nope
20:48 karolherbst: GLES
20:48 imirkin_: GL_RGB4 is required renderable.
20:48 karolherbst: the CTS complains :)
20:48 imirkin_: er, GL_RGBA4
20:48 karolherbst: right, but the CTS complains that we do not return an error
20:49 imirkin_: so when allocating a texture, we should return one that's PIPE_BIND_RENDER_TARGET
20:49 imirkin_: even if it's just a texture, and not a rb/etc
20:49 imirkin_: which goes through various fallback logic.
20:49 karolherbst: right.. but that could be RGBA8, right?
20:49 imirkin_: or RGBA32F
20:49 karolherbst: right, but thats wrong for GLES
20:49 imirkin_: oh?
20:49 karolherbst: as we have a RGBA4 texture and render it to a rgba8 fb
20:50 karolherbst: _but_
20:50 karolherbst: because the texture is now rgba8 internally, we just accept that
20:50 imirkin_: uhm
20:50 karolherbst: but, because it's gles, we have to assume the actualy API format
20:50 karolherbst: and reject it because rgba4 != rgba8
20:50 imirkin_: that means it's looking at the wrong format
20:50 imirkin_: should be looking at InternalFormat
20:50 imirkin_: rather than TexFormat
20:50 karolherbst: internalFormat is rgba8
20:51 imirkin_: erm
20:51 karolherbst: ;)
20:51 imirkin_: then there's more to this test that i'm not understanding
20:51 imirkin_: is the info in the link you sent?
20:51 imirkin_: if so, i'll have a closer look this week (can't promise tonight)
20:51 karolherbst: you can take a look at the patch though
20:52 karolherbst: the changes in src/mesa/main/teximage.c
20:52 imirkin_: yeah, that's a big change. i think that just the last hunk in st_format is sufficient. and if not, i'd like to clearly understand why.
20:53 karolherbst: because we don't save what's the format on an API level
20:53 karolherbst: at least the situation was like that the last time I looked into it
20:53 imirkin_: iirc that's what InternalFormat should be
20:53 karolherbst: maybe somebody cleaned that up
20:53 imirkin_: old code: "else if (formats_differ_in_component_sizes (texFormat, rb->Format))"
20:54 karolherbst: or maybe I missremember it a bit
20:54 imirkin_: so it's looking at the texFormat instead of the internalFormat
20:54 karolherbst: ahh yeah.. maybe I just wrote garbage then :)
20:54 karolherbst: but the painful part was still we had different format enums we can't just compare
20:54 karolherbst: so maybe the new format rework indeed makes it easier
21:06 imirkin_: well, the point is that TexFormat != InternalFormat, even if they were to use the same "enum space"
21:06 imirkin_: but InternalFormat is the GL thing
21:06 imirkin_: while TexFormat is a more normalized thing, which hopefully now is a pipe_format
21:16 karolherbst: mhh, true
21:22 imirkin_: TexFormat also represents the true storage (which in our sample case would be RGBA8), whiel InternalFormat would have GL_RGBA4
22:59 krh: Kayden: I know your love our old kernels... https://gitlab.freedesktop.org/llandwerlin/mesa/commit/96e1c945f2bc4047a603753ae10fc4f27754361c breaks on our 3.18 kernel HSW devices
23:05 dj-death: krh: maybe you need the fix : 1c6fdbc83cf1094c735b964902da421978005cb3
23:06 ickle: it's the if (!getparam(REVISION)) return false; causing intelInitScreen2 to bail out
23:11 Kayden: yeah it's probably trivial to fix
23:12 Kayden: it's just hard to keep track of which things that have been around since forever aren't technically around sometimes
23:13 dj-death: 3.18...
23:13 ickle: heh, we brought hsw back from the dead
23:16 Kayden: Yep that is not a joke, they actually use 3.18
23:16 Kayden: that is one of the reasons I quit developing for i965
23:31 krh: there was a fix: https://lists.freedesktop.org/archives/mesa-dev/2019-August/222179.html
23:31 Kayden: D'oh. ML
23:31 Kayden: Didn't see that
23:31 Kayden: happy to see it land
23:33 krh: I'l put it in an MR now
23:33 dj-death: https://patchwork.freedesktop.org/patch/325031/?series=65432&rev=1
23:33 dj-death: we got confused...
23:34 krh: yeah, it's definitely REVISION, whether or not it was introduced in 4.1 or 4.16
23:35 dj-death:sends a MR
23:36 dj-death: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3727
23:36 gitbot: Mesa issue (Merge request) 3727 in mesa "intel: Load the driver even if I915_PARAM_REVISION is not found." [I965, Opened]
23:36 krh: dj-death: so fast!
23:36 jekstrand: dschuermann: That's a good question. I don't have a quick answer off-hand.
23:37 krh: dj-death: and the Fixes: tag will make sure it gets into 20.0?
23:37 dj-death: yeah
23:37 krh: dj-death: thanks, let me test and then R-b
23:38 dj-death: I did Rb if you just want to assign to marge
23:39 krh: dj-death: can I test it first? I have the chromebook right here
23:39 dj-death: sure
23:39 krh: dj-death: I'll test, r-b, tested-by even, and the reassign
23:39 dj-death: thanks
23:39 dj-death:-> zzzz
23:40 krh: g'night
23:47 Kayden: mareko: by the way, if you're looking at more CPU overhead reductions - I think replacing _mesa_HashTable for GLuint -> object lookup with util_sparse_array would likely help quite a bit
23:48 Kayden: been meaning to do that
23:49 anholt_: yeah, I'm hoping that'll help a bunch for GL.
23:51 jekstrand: It's about 5x as fast as the hash table in my micro-benchmarks
23:51 Kayden: and just about every single GL call would hit it
23:51 jekstrand: And that's without the fact that it would let us remove a lot of locking.
23:52 Kayden: yeah, true
23:53 jekstrand: Much of the locking we do currently is simply to protect the hash table. util_sparse_array is thread-safe
23:53 jekstrand: The contents aren't but the data structure itself is
23:53 Kayden: the API confused me a bit
23:53 jekstrand: As is the free list I wrote for it
23:53 Kayden: wasn't sure if I wanted the freelist or not
23:53 jekstrand: We want the free list for managing GL object IDs
23:53 jekstrand: But, yeah, the free list is a little confusing.
23:54 jekstrand: There was no good way to implement the free list without things getting at least a little confusing