07:02 austriancoder: I am working on providing gpu sub-component load/utilisation values for etnaviv. The hw provides one idle register where each bit represents a component like DMA FetchEngine. I am sampling this register in the kernel every 10ms. So know I am unsure how to process these values. First I calculated the load every second (sum of 100 values / 100) - used values: idle = 0 and non idle = 100. But that has the result that I only
07:02 austriancoder: get load values once a second. So I think a moving average is the way to go.. but which one? simple moving average or exponential moving average?
07:19 MrCooper: anujp: myself and others are happy to help with any issues merging an MR; I expect developers will not be able to push directly to the main repository in the long run, because it bypasses CI and misses out on other benefits such as automatic links back to the MR
07:37 daniels: austriancoder: I would just provide them as binary counters to perf and let userspace analysis tools figure it out
07:38 daniels: trying to synthesise data from drivers is not going to end well I don't think
08:03 danvet: daniels, austriancoder yeah perf pmu might be a good fit for this, we use that a bit on i915 I think
08:24 austriancoder: daniels: shall I reset the binary counter after every second aka 100 samples? The problem is that - in my eyes - userspace is mesa and perfetto .. so I end up with doing the analysis twice. If I could do it in the kernel everybody has the same view
08:25 austriancoder: danvet: are there some docs for i915 pmu?
08:25 danvet: I think best to chat with dj-death
08:42 austriancoder: danvet: will do.. thx
12:01 tfiga: It looks like somewhere between 4.14 and 5.4 I915_FORMAT_MOD_X_TILED stopped working on Haswell
12:02 tfiga: Is anyone aware of such a regression?
12:02 tfiga: We're seeing framebuffer creation failures
12:02 tfiga: [ 3308.923386] [drm:intel_framebuffer_init] unsupported pixel format AR24 little-endian (0x34325241) / modifier 0x100000000000001
12:14 vsyrjala: it's the 'A' part that's the issue. switch to 'X'
12:20 tfiga: vsyrjala: interesting
12:20 tfiga: was there some kind of fallback from A to X on older kernels?
12:20 vsyrjala: we just exposed the alpha format by mistake
12:21 vsyrjala: so it was actually 'X' all along
12:21 tfiga: okay, thanks a lot
12:22 vsyrjala: well, technically we *could* expose alpha formats for the primary plane on some platforms since we know there's never anything but black below it. so with premultiplied alpha it would actually look correct
12:22 vsyrjala: but imo better to be consistent and reject alpha on all platforms that don't actually support alpha blending
12:27 tfiga: makes sense
12:27 vsyrjala: what application is this btw? something custom?
12:37 uajain: vsyrjala: ChromiumOS
12:43 zmike: would someone be able to marge a couple piglit MRs for me?
12:43 vsyrjala: hmm. ah, it's the addfb2 that's failing
12:44 vsyrjala: i think my previous explanation was a little off then. yeah, looks like we didn't allow argb on the primayr on 4.14 either
12:44 vsyrjala: the real issue is that we made addfb2 itself fail when you try a format+modifier combo that's not supported by any plane on the device
12:45 vsyrjala: whereas previously we sometimes allowed you to create such impossible to scanout framebuffers
12:46 daniels: zmike: done
12:46 zmike: daniels: thanks!
12:49 daniels: np :)
14:46 imirkin: doesn't https://cgit.freedesktop.org/mesa/mesa/commit/?id=f611af35948e4d1d56daa94f59d5feb7d44d24ce break things for drivers that don't support stencil export?
14:46 imirkin: mareko: --^
14:54 vktec: This the place for mesa questions? I'm trying to build a static library version of libGL, but I can't figure out what meson options are needed
14:54 imirkin: right place.
14:54 imirkin: i don't think libGL can be static
14:55 imirkin: at least not with DRI
15:02 karolherbst: imirkin: I can confirm this with a gp107 with nouveau
15:02 karolherbst: stencil export is also the reason we can't use u_blitter, correct?
15:02 imirkin: yeah
15:03 imirkin: well, a combination of factors
15:03 imirkin: another is that it requires per-sample shading
15:03 karolherbst: and that's like gm200+ or something?
15:03 imirkin: GT215+ :)
15:04 karolherbst: ohhh
15:04 karolherbst: was thinking about something else..
15:04 karolherbst: how annoying
15:07 vktec: imirkin: What makes it impossible with DRI? And how would I go about doing it with another backend?
15:07 imirkin: vktec: i could be wrong, but i'm pretty sure the loader expects to be able to load the foo_dri.so file
15:07 imirkin: (the loader which is in libGL)
15:08 vktec: afaik it's possible to do dynamic loading even from a static lib
15:09 vktec: Maybe I'm mistaken
15:09 imirkin: nnnnot sure.
15:09 imirkin: also what do you even mean by "static linking" for libGL?
15:09 vktec: I want a .a file rather than a .so
15:09 imirkin: ultimately it'll make a libGL.so, right? you want a libGL.a which is linked into a binary?
15:10 imirkin: and then that binary would dlopen the real driver?
15:10 vktec: Yes
15:10 ajax: and you think you have a libc where dlopen works from static libraries?
15:11 ajax: (last i checked glibc was not such a libc)
15:11 karolherbst: vktec: if dlopen is involved anyway, which problem does using a static libGL solve?
15:11 jenatali: As long as you're using libc.so rather than libc.a, it should support dlopen
15:11 karolherbst: just curious about why somebody wants to do this
15:12 jenatali: But yeah, agreed with karolherbst, I don't see the point
15:12 TheRealJohnGalt: Is bumping issues acceptable? If so, how long should I be waiting to bump issues?
15:13 karolherbst: TheRealJohnGalt: "depends" usually if it took a few days and the issue is critical it makes sense, but if the issue is super unimportant than maybe not? :p
15:13 karolherbst: "be reasonable" I guess is the rule to follow
15:13 xexaxo1: eric_engestrom: don't recall bth. it's been ages since I wrote the egl device bits
15:14 xexaxo1: vktec: having static libGL (or libEGL for that matter) hasn't been possible for a very long time - few years at least
15:14 karolherbst: xexaxo1: there are people having downstream patches to enable that though :p
15:15 xexaxo1: one could static link some of the libGL dependencies within libGL itself - kodi is doing that.
15:15 xexaxo1: karolherbst: interesting - got a link/google keyword?
15:15 vktec: karolherbst: I'm trying to create an as much as possible system-independent binary. Seems like statically linking libgl won't help much though, given it relies on dynamically loaded backends
15:15 karolherbst: xexaxo1: switch homebrew people
15:15 vktec: I'll give up and go a differet route instead :)
15:15 karolherbst: uhm... nintendo switch
15:16 karolherbst: they have essentially a custom winsys and EGL implementation and doing static linking
15:16 karolherbst: vktec: how do you handle diffrent drivers?
15:17 dviola: any ideas if this patch is going to land for 5.8? https://lore.kernel.org/patchwork/patch/1255315/
15:17 karolherbst: well.. for your own machine that's acceptable I guess, but everything around OpenGL is designed around being able to use different drivers
15:17 TheRealJohnGalt: karolherbst: Okay, thank you. There are some incorrect rendering ones I was considering bumping. On one of them I found the exact eid where the issue presents itself on the renderdoc capture, on the other two I found they have the same incorrect rendering on radv as well as radeonsi, just not amdvlk. Basically don't want to seem pushy though lol.
15:18 karolherbst: dviola: normally the autosel stuff could pick it up...
15:18 karolherbst: but I also don't know the precise rules
15:18 dviola: karolherbst: oh
15:18 karolherbst: maybe check the autosel series on stable?
15:18 karolherbst: although..
15:18 karolherbst: we are still in RC
15:18 karolherbst: so I think this has to go through drm then
15:19 karolherbst: TheRealJohnGalt: what usually helps is to figure out if those are regressions
15:19 karolherbst: and if so, check what commit broke it
15:19 karolherbst: that helps a lot
15:19 dviola: I'd just wait then, thanks
15:20 karolherbst: dviola: uhm.. wait... I think I made a mistake.... that patch isn't merged yet, right?
15:21 dviola: karolherbst: yeah, looks like isn't
15:21 dviola: karolherbst: here's my bug report: https://bugs.launchpad.net/qemu/+bug/1882851
15:22 dviola: karolherbst: the patch fixes that bug
15:22 TheRealJohnGalt: karolherbst: Appreciate the help. Yeah, I had gone back to 18.32 and llvm 8 builds quickly to test and found they were only regressions on intel hardware, on amd they were still there.
15:22 TheRealJohnGalt: I guess I should just bump them with more troubleshooting info from what I'd done.
15:23 dviola: some kind of virtiogpu bug, which Gerd Hoffmann fixed
15:24 karolherbst: dviola: yeah.. maybe ping on the mail then?
15:25 dviola: I just did, hence I'll wait :)
15:25 karolherbst: you mean the launchpad one? well...
15:25 karolherbst: I think you should rather ping on the patch itself
15:25 dviola: right
15:25 dviola: oh
15:34 karolherbst: imirkin: btw, will you fix the regression or how do we want to deal with it?
15:36 imirkin: i can send a revert
15:36 imirkin: or you can fix it
15:36 imirkin: should be just a few line fix
15:37 karolherbst: revert sounds fine.. can be done throught he gitlab UI actually :D
15:40 imirkin: probably good to double-check whether it actually breaks those tests or if they started out broken
15:40 karolherbst: I checked
15:40 imirkin: kk
15:40 imirkin: and then just include a (partial) list of the things that break in the revert message then
15:40 robclark: jekstrand: any idea if it is intentional that 2nd src for ushr and friends is explicitly 32b? That seems a bit silly (ie. 16b is *way* more than enough).. I guess the intention is just that they *aren't* 64b?
15:40 karolherbst: 3af0711c402033a8ad7649dc0509e4f7ddc1b640 was fine :)
15:41 imirkin: or spend the 5 minutes copying the st_DrawPixels code to check for the feature and do the fallback that was there prior to the change
15:41 imirkin: either's fine by me :)
15:42 karolherbst: imirkin: well.. if I'd care more about the commit itself, but it seems it got merged based on nothing anyway :p
15:44 imirkin: well - reverts can annoy people too. wtvr.
15:44 karolherbst: well...
15:45 karolherbst: I am annoyed by a commit like this as well
15:45 imirkin: and i'm in a permanent state of being annoyed :)
15:45 karolherbst: no explenation whatsoever in the commit, and the MR says "I have no idea if there is a benefit, but it might be better"
15:45 imirkin: so hard for me to judge
15:45 karolherbst: if somebody wants to fix it for real, they are free to do so
15:46 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5939
15:46 karolherbst: also... single company/community review chains for core changes are also.. well, I don't like that :p
15:47 imirkin: that's just a problem with gitlab i think. if these changes are on ML, then they're a lot more visible. wtvr.
15:47 karolherbst: welll
15:47 imirkin: (did i mention i'm in a permenant state of annoyance?)
15:47 karolherbst: you can get emails on certain labels
15:48 karolherbst: just need to subscribe on them
15:48 imirkin: if it goes to ML, i know everyone sees it. they also see my replies. with the issues thing, it's all private/invisible/etc stuff.
15:49 karolherbst: yeah
15:49 karolherbst: maybe we should subscribe the mailing list onto all MRs :D
15:49 karolherbst: uff.. that would be annoying
15:50 karolherbst: but maybe there is a way to at least send out info on new MRs
15:50 karolherbst: dunno
15:51 karolherbst: anyway.. when I create an MR I also feel myself responsible for not breaking other drivers.. so.. dunno
15:53 Lyude: mlankhorst, mripard - did either of you see the email I sent yesterday about the nouveau pull?
15:53 jekstrand: robclark: I feel like I keep having this conversation with people.....
15:54 jekstrand: robclark: 8 bits is enough for anything but not everyone supports 8 bits
15:54 jekstrand: And we don't want 64
15:54 jekstrand: And we can't have an ALU instr which has two different varying-bit-size parameters
15:54 robclark: ok, that is kinda what I feared.. we need a tuint_but_not_more_than_32
15:54 jekstrand: So either we have 4 shift instructions, one for 8, 16, 32, and 64 or we just have to pick a bit size.
15:54 jekstrand: And everyone can do 32
15:55 jekstrand: Let me back up
15:55 jekstrand: We have three options:
15:55 jekstrand: 1) Require the value and the shifter to be the same bit size
15:55 jekstrand: 2) Have 4 shift instructions, one for each bit size and let the shifter be floating
15:55 robclark:trying to turn on PIPE_SHADER_CAP_INT16 but it seems a bit broken.. so just sifting through the reckage
15:55 jekstrand: 3) Pick a bit size for the shifter
15:55 jekstrand: At the time, I chose 3
15:56 jekstrand: Feel free to down-cast it to whatever you want in your back-end
15:56 robclark: #1 actually matches my hw pretty well..
15:56 karolherbst: robclark: not our hw btw
15:56 robclark: well, atm the problem is asserts in glsl_to_nir, so not getting far enough to handle it in backend ;-)
15:56 jekstrand: Our HW can do any of them, I think
15:56 karolherbst: for 64 bit shifts we still have a 32 bit shifter
15:56 jekstrand: Well, most of them
15:57 jekstrand: But, again, you can insert a down-cast in your back-end
15:57 karolherbst: not that it matters... but still
16:00 imirkin: karolherbst: 32-bit shifter which can take a logical 64-bit input but produce a 32-bit output
16:01 imirkin: so it's just "odd"
16:01 imirkin: and other gens use carry bits, which aren't well-modeled in NIR in the first place
16:03 karolherbst: well.. right
16:03 karolherbst: but you can get the low/high bits of the operation
16:06 karolherbst: which reminds me.. I should implement the carry instructions :D
16:07 karolherbst: ohhh.. wait
16:07 karolherbst: uhm.. those are indeed strange
16:08 imirkin: [and ftr, i don't know that nir _should_ model carry bits properly... it'll always be a bit different with diff hw]
16:08 karolherbst: jekstrand: can we have carry/borrow instruction nir produceing a vec2 result? one for the value, the other for the carry bit?
16:08 imirkin: karolherbst: i think the backend is supposed to merge if it can do it in one go
16:08 imirkin: iirc codegen should
16:08 karolherbst: yeah.. mhhh
16:09 karolherbst: I let them be lowered at this point
16:09 jekstrand: karolherbst: Hrm.... I mean, we could.
16:09 karolherbst: jekstrand: no idea how different it is for different hardware.. but maybe that would be closer for everybody?
16:09 imirkin: karolherbst: if you don't lower, and emit "carefully", codegen should be able to merge the two ops into one
16:09 jekstrand: karolherbst: For us, it'd get a bit awkward because the way we get the bit "for free" is tricky
16:09 imirkin: jekstrand: sometimes gotta pay the price? :)
16:10 karolherbst: jekstrand: sure.. but if it's a vec2 you can still split it up in the backend
16:11 karolherbst: borrow is just a bit weirder to deal with
16:11 karolherbst: mhhh
16:11 karolherbst: maybe two stage lowering?
16:11 karolherbst: vec2 -> current carry/borrow model -> final lowering?
16:11 karolherbst: we also support carry bits on a few other instructions
16:11 MrCooper: karolherbst: revert from GitLab UI is a trap, it creates a topic branch in the main repository (and only reverts a single commit)
16:12 karolherbst: like iadd3, imad, imul, etc...
16:12 karolherbst: MrCooper: well, it was just a single commit
16:13 imirkin: karolherbst: hm, now i can't find where that'd happen -- i thought it'd be in LocalCSE, but i'm not sure that's right
16:13 imirkin: however LocalCSE might do it. hard to tell :)
16:13 karolherbst: imirkin: yeah.. could be
16:13 karolherbst: I'd rather just emit the flags properly with nir :)
16:13 imirkin: karolherbst: but it relies on the ops/sources/etc being identical
16:13 MrCooper: karolherbst: the main point is we don't want topic branches in the main repo
16:13 karolherbst: volta/turing reworked all that stuff super nicely
16:13 karolherbst: would love to make more use of that
16:14 karolherbst: MrCooper: ohh, mhh. what's the difference btw?
16:15 karolherbst: ohh
16:15 karolherbst: the branches itself
16:15 karolherbst: right...
16:15 karolherbst: ufff
16:15 MrCooper: the CI rules treat main repo branches as post-merge
16:15 jenatali: jekstrand, robclark: For what it's worth, LLVM requires the shifter and value to be the same bit size, so that'd be convenient for us as well
16:16 karolherbst: MrCooper: okay.. will try to remember and try to not do it again.. but I guess it would be fine to keep the current one for now? Or would that also cause other issues?
16:26 MrCooper: karolherbst: it's wasting CI resources, therefore I closed it; please delete the topic branch as well
16:27 Putti: Continuing our discussion on #lima. As far as I can tell we have here 3 competing ways of doing memory allocations on AOSP: 1) card+render node meanings using the kmsro driver and gpu driver 2) using ION gralloc for everything really flexible as far as I can tell 3) making the render node able to do contiguous and non-contiguous allocations (currently not supported by lima kernel driver).
16:28 Putti: seanpaul, drm_gralloc used to have support for option number 1, i.e. it had DRM MAGIC authentication support. Currently the new hw composer, drm_hwcomposer, doesn't support DRM MAGIC. Would you like to keep it that way? If yes, why, and that would also mean we are then left with option 2) and 3).
16:28 Putti: And we go with option 2) Would we create a new community project to replace gbm_gralloc with generic "ion_gralloc" that support DRM prime fd sharing also?.
16:28 Putti: and if we go with*
16:29 Putti: For option 3) one consideration is that does the kernel community want the extra code in the GPU drivers for supporting CMA also?
16:30 karolherbst: MrCooper, daniels: is there a way to forbid reverts on repositories? Could help us prevent those situations in the future then
16:31 MrCooper: my preferred solution would be to restrict access to the main repo to maintainers / owners
16:31 daniels: ++
16:32 kisak: can that be done while still letting the regulars assign MRs to marge?
16:32 daniels: Putti: I think it would help to provide the full context i.e. you can't use kmsro inside HWC because gralloc is an external service in modern Android
16:32 daniels: kisak: yep
16:32 MrCooper: yeah, it doesn't affect that
16:33 MrCooper: Marge is an admin, so she'll still have access
16:36 Putti: About option 2), i.e. ION, I don't really know much about it but one issue if we have ion_gralloc is how do we integrate it with mesa3d. So that might be out of the table?
16:42 dllud: Hi! It's also worth pinging tomeu into this Android discussion.
16:42 dllud: According to daniels (on #lima), tomeu faced a similar issue when using etnaviv on imx6.
16:42 dllud: https://gitlab.collabora.com/spurv/gbm_gralloc/-/commits/master
16:42 dllud: tomeu, I guess you used both drm_hwcomposer and gbm_gralloc.
16:42 dllud: Likely with drm_hwcomposer attached to imx6 display node and gbm_gralloc to etnaviv render node.
16:42 dllud: If so, you probably faced the same underlying issue Putti is point to: etnaviv cannot do CMA, and imx6 requires contiguous buffers.
16:42 dllud: How did you sort it out?
16:43 tomeu: guess we allocated with imx6 and passed it to etnaviv for rendering?
16:43 Putti: tomeu, kmsro you mean?
16:44 tomeu: was referring to kernel devices
16:44 tomeu: we did use kmsro
16:44 Putti: which then uses imx6's display controller driver to do the allocation?
16:44 tomeu: has been a while, but I guess that when a buffer might be passed to imx-drm for presentation, it was a allocated in that device
16:44 tomeu: kmsro, yeah
16:45 daniels: tomeu: how did we get around the problem of - etnaviv can't (?) allocate from CMA, imx-drm requires CMA, imx-drm only exposes primary and not render node, gralloc svc (as opposed to HWC) can't access primary node? did we just hack out the master check on the dumb-create ioctl or something?
16:45 daniels: (and by 'we' I mean 'you', I didn't do any of this)
16:45 Putti: lots of people hack the kernel allow unauthenticated access to the card node to workaround the lack of DRM magic code in gbm_gralloc and drm_hwcomposer
16:46 tomeu: daniels: we definitely hacked some ioctl check
16:46 dllud: thanks daniels! that's exactly my doubt tomeu : how did you share the nodes?
16:46 dllud: ahhh ok
16:46 tomeu: has been a good while, but that I remember :)
16:46 xexaxo1: Putti: with the latest kernel those auth hacks should not be needed
16:46 Putti: xexaxo1, let me retry but I doubt
16:46 Putti: xexaxo1, afaik there was authentication changes only regarding render nodes
16:47 Putti: not card nodes
16:47 dllud: xexaxo1, why would the kernel allow two processes on a display node?
16:49 xexaxo1: dllud: from memory - hwc should be using the primary node and gralloc the render one
16:49 Putti: xexaxo1, yes that setup works, but if we need to use kmsro for gralloc meaning card node then it doesn't work
16:49 dllud: xexaxo1, yup :).
16:49 Putti: xexaxo1, lima for example doesn't do CMA allocations so kmsro/card node is required to do that
16:49 dllud: But then we face an issue because the render node we're using (lima) cannot do CMA.
16:51 Putti: so I had 3 options proposed, one of them was adding the CMA support in lima driver (option 3), option 2 was ion, and option 1 was kmsro+render with drm magic
16:51 xexaxo1: Putti: from memory yet again, do you need to use kmsro with gralloc or lima_dri.so (or equiv) does suffice?
16:51 xexaxo1: could swear I saw the latter being a thing
16:51 Putti: xexaxo1, lima_dri.so would suffice probably if our display could handle non-contiguous memory
16:52 Putti: but with the exynos4412 we are using that doesn't seem to be the case
16:52 dllud: daniels: we do have one advantage here, in our case, exynos does expose two nodes: display node and render node.
16:52 dllud: Perhaps we could set:
16:52 dllud: - gbm_gralloc > exynos render node
16:52 dllud: - drm_hwcomposer > exynos display node
16:52 dllud: - Mesa auto picks Lima render node
16:52 dllud: Would this even work? Hm…
16:53 Putti: (and why I say that this doesn't *seem* to be the case is because we have now HW documentation for this part of exynos4412)
16:53 Putti: no HW documentation*
16:53 xexaxo1: upstream exynos does not expose a render node - sounds like you've got some hacks already
16:54 Putti: xexaxo1, lima is the render node, and the exynos driver also exposes render node
16:54 Putti: no hacks regarding this
16:55 xexaxo1: I stand corrected - exynos does expose a render node... seems like I should call it a day o/
16:56 Putti: xexaxo1, I just don't know what I can do with the exynos render node, gbm_gralloc cannot do anything useful with it
16:57 Putti: (anyway, that's offtopic for this discussion)
16:58 xexaxo1: Putti: from a quick look the render-node was enabled since exynos does expose a g2d (2d acceleration) and IPP (image processing) Hw modules via the ioctls.
17:01 dllud: xexaxo1, yes! That was it. Thanks.
17:01 dllud: So I guess I does not support GEM mem allocation? At least it didn't work when we tried pointing gbm_gralloc to it… thus the discussion above.
17:02 xexaxo1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_drv.c?h=v5.8-rc5#n84
17:03 xexaxo1: dllud: ^^ shows gem_create, alhtough gbm_gralloc goes through gbm which looks for exynos_dri.so and doesn't use the ioctl directly.
17:04 MrCooper: that 'Branch cannot be merged' issue is really annoying, feels almost like back before we had Marge
17:19 dllud: xexaxo1, thanks. We're trying it again, to know specifically why gbm_gralloc didn't work with it. I'll report later.
17:22 sravn: danvet, airlied: pcercuei just sent out a new version of the ingenic-drm patchset. I have looked at them all and applied locally. Looks good and builds.
17:24 sravn: Any objections to commiting the full series to drm-misc-next?
17:34 danvet: sravn, pcercuei has commit rights already?
17:34 danvet: hm looks like it
17:34 danvet: sravn, I'd r-b and then ask him to push it all
17:35 sravn: Yup better. Will do. Forgot to check https://people.freedesktop.org/~seanpaul/whomisc.html
18:39 ngcortes: mareko, heads up I just submitted a bug for a change you reviewed: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3283
18:39 imirkin: ngcortes: karolherbst submitted a revert for that change
18:39 imirkin: it doesn't deal with lack of support for stencil writes from shader
18:39 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5940
18:39 karolherbst: yeah...
18:40 karolherbst: seems like my plan backfired somebody fixes it :D
18:40 karolherbst: so I actually wrote the proper fix
18:40 karolherbst: ohhh
18:40 ngcortes: imirkin, ah
18:40 karolherbst: it regreses on iris as well
18:40 karolherbst: oh well
18:41 imirkin: i don't think all intel gens have stencil write support either
18:41 imirkin: iirc it's gen9+?
18:41 imirkin: is the failing test on gen8?
18:41 karolherbst: imirkin: return devinfo->gen >= 9; :)
18:41 karolherbst: for the cap
18:42 ngcortes: imirkin, were there 2 reverts submitted? I saw a different group of tests failing on gen9_iris but the failures went away while the bdw_iris ones stuck
18:42 imirkin: ngcortes: neither change has been pushed
18:42 karolherbst: ngcortes: mind testing with my latest MR?
18:43 ngcortes: karolherbst, can do
18:43 robclark: imirkin: hmm, a lot of things that are in CI don't have stencil write.. hmm, but I suppose this is a case that wouldn't show up in deqp-glesN?
18:43 imirkin: robclark: not sure if gles has glCopyPixels
18:43 ngcortes: imirkin, these results are a little stale, but the gen9_iris failures listed are no longer failing https://mesa-ci.01.org/mesa_master/builds/21729/group/63a9f0ea7bb98050796b649e85481845
18:44 imirkin: robclark: and if it does, not sure that glCopyPixels + GL_STENCIL is supported
18:44 karolherbst: ngcortes: whatever that is on, b65e805aac isn't part of upstream
18:44 robclark: imirkin: hmm, ok.. I guess it would be nice to have a small list of piglit tests that cover things that deqp-glesN doesn't that we could add to gitlab CI..
18:45 imirkin: karolherbst: that's piglit
18:45 karolherbst: ohhh.. right
18:45 imirkin: karolherbst: look at the top, it lists all the revisions
18:45 robclark: I guess that would have caught this issue before it was merged
18:45 imirkin: for the various things
18:46 imirkin: karolherbst: that change is r-b me btw
18:46 imirkin: i'm not signed into gitlab, so i can't comment
18:46 imirkin: (and signing in requires dealing with my phone for the 2fa code)
18:46 cheakoirccloud: https://usercontent.irccloud-cdn.com/file/06RNkxU0/logs.txt.ar.xz
18:47 karolherbst: :D wanted to suggest using github for login, but that wouldn't solve the 2fa issue
18:47 imirkin: my github login has other issues. you don't want to know.
18:47 imirkin: it's all terrible.
18:47 karolherbst: mhhh
18:47 karolherbst: maybe you want to fix that at some point :p
18:47 imirkin: maybe
18:47 imirkin: or maybe i never want to log into github again.
18:48 cheakoirccloud: Mainly I just wanted to upload that file somewhere.
18:48 cheakoirccloud: I had a weird thing happen where kswap ran away with the CPU, but invoking the OOMK didn't fix the issue like it normally does.
18:49 cheakoirccloud: I suspect it's GPU related... because it always is. I'm going to look for a BIOS and hten kernel upgrad.
18:49 cheakoirccloud: *then
20:19 daniels: imirkin: you can get non-phone TOTP solutions
20:20 daniels: MrCooper: it is incredibly annoying - the fix is easy, but it also requires dealing with NixOS, and that exhausted my timeslice for it ... :\
20:20 imirkin: daniels: and using my phone to pull up a token from the authenticator app isn't the end of the world. i just didn't feel like doing it at the time.
20:21 daniels: heh
20:21 imirkin: unrelated to gitlab, my phone is having various problems
20:21 imirkin: the back has started to crack due to the battery bulging out (i think), so you know it's got a lot of life left in it...
20:21 mattst88: I like pass (https://www.passwordstore.org/) + pass-otp (https://github.com/tadfisher/pass-otp)
20:22 imirkin: waiting for pixel 4a to magically solve everything
20:22 mattst88: imirkin: sounds like the phone is about the same age as your Ironlake :)
20:22 imirkin: mattst88: no, the phone is much newer... my i7-920 is from 2011, whereas the phone is from end of 2012 :)
20:26 mattst88: hah, awesome
20:26 Sachiel: I'm impressed it lasted that long
20:27 mattst88: no kidding
20:27 imirkin: things tend to last a while in my posession
20:27 imirkin: this is a nexus4
20:33 imirkin: just bought a replacement battery for the SNB laptop from around that era as well - should let it last another 5+ years
21:31 karolherbst: ngcortes: any test results yet with my fix?
21:34 ngcortes: karolherbst, I think your change did the trick :)
21:34 karolherbst: \o/
21:34 karolherbst: mind replying to the MR? I'd like to merge the change asap :)
21:35 ngcortes: certainly
21:37 ngcortes: replied
21:39 karolherbst: okay.. cool :)