00:08 airlied:has to stop falling down another pahole
00:08 airlied: but mum, that struct has 35 bytes of holes in it
00:13 Kayden: instead of pragma PACKED it's using pragma SWISSCHEESE?
00:26 airlied: Kayden: should write an anti-pahole utility call swisshchesse that finds the worst packing for a struct
00:26 imirkin_: one bit per dword?
00:28 airlied: make sure every bool has uint64_t either side of it
00:29 Kayden: hahaha
01:13 gentz: So, hello folks. I've been for the last good while trying to render a green triangle on a black background, but I keep getting a pink triangle on a red background when I glReadPixels it, which is unexpected to say the least.
01:13 gentz: I imagine it some sort of format mismatch, but I'm not exactly sure what. It only happens when I render to a PBuffer made with EGLDisplay made using EGLMesaSurfaceless, or a Renderbuffer/PBuffer made with a EGLDisplay made with the EGLDevice that has the EGL_EXT_device_drm extension.
01:13 gentz: My triangle comes out fine when I render to a Renderbuffer made with a EGLDisplay made using EGLMesaSurfaceless or a Renderbuffer/PBuffer made with a EGLDisplay made with the EGLDevice that has the EGL_MESA_device_software extension.
01:13 gentz: With that said, does this issue sound like a issue any of you have encountered recently/seen on the issue tracker?
01:16 imirkin: gentz: sounds like your channel ordering is off
01:16 imirkin: black = 0xff000000
01:17 imirkin: but flip it, and you get 0x000000ff, aka red
01:17 imirkin: my guess is you're picking the wrong config? or not using glReadPixels quite right?
01:20 gentz: Hmm, but all the configs have 30 color bits, so flipping the channel ordering wouldn't work, no?
01:20 imirkin: oh, you're doing stuff with 30bpp?
01:21 gentz: The red I'm getting is 251.
01:21 imirkin: maybe you can share some sample code
01:21 gentz: And I recall reproducing it with the other color formats.
01:33 gentz: Oh, nvm. Some reason eglChooseConfig was still giving 30bpp formats even when I requested 24bpp formats (by adding EGL_{RED,GREEN,BLUE}_SIZE). Seams to only happen with 30bpp formats.
01:33 HdkR: gentz: That's because requesting 24 means minimum size
01:34 HdkR: So returning 30bpp formats is within spec
01:34 HdkR: " If this value is zero, color buffers with the smallest blue component size are preferred. Otherwise, color buffers with the largest blue component of at least the specified size are preferred."
01:35 gentz: Ah, I should read the spec more closely. The triangles with wierd colours appear to only happen with 30bpp configs.
01:45 gentz: imirkin: https://github.com/rust-windowing/glutin/blob/37a31ee6a76416b170ca548aa6b48078152ab838/examples/headless.rs https://github.com/rust-windowing/glutin/blob/37a31ee6a76416b170ca548aa6b48078152ab838/examples/egldevice.rs
01:48 gentz: If you want to run the stuff locally, `cargo run --example headless && cargo run --example egldevice` and then open in gimp all the generated `headless*.png`s. Some of them should give triangles like this: https://imgur.com/S7pIjMB.png
01:48 gentz: While the non-broken ones should look like this: https://imgur.com/GBCNieT.png
01:53 kisak: oh hey, anyone feel like bumping the version on mesa git master?
02:00 imirkin: gentz: there's some examples for how to select configs properly
02:00 imirkin: unfortunately it's very hard
02:00 imirkin: e.g. http://directx.com/2014/06/egl-understanding-eglchooseconfig-then-ignoring-it/
02:01 HdkR: lol, "then ignoring it"
02:01 imirkin: or https://cgit.freedesktop.org/mesa/kmscube/tree/common.c#n121
02:01 imirkin: it's basically useless as-is =/
02:24 gentz: Hmmm, is `glReadPixels` not meant to convert the format? 30bpp w/ GL_RGB and GL_UNSIGNED_BYTE fails, 30bpp w/ GL_RGB and GL_UNSIGNED_INT_2_10_10_10_REV returns a buffer with all zeros, but 30bpp w/ GL_RGBA and GL_UNSIGNED_INT_2_10_10_10_REV returns a buffer (which after some conversion on my side) comes out as a proper triangle.
02:24 gentz: s/fails/returns that miscoloured triangle I've posted/
03:01 imirkin: gentz: GL or GLES?
03:01 imirkin: gentz: also it's possible to confuse the library
03:02 imirkin: i forget the details
03:02 imirkin: but basically if you lie in the right places
03:02 gentz: Should be GL 3.0.
03:02 imirkin: then mesa decides that glReadPixels can be passthrough
03:02 imirkin: even though it can't
03:04 imirkin: hrmph, can't find it ... was in wlroots or something
03:04 imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=109330#c5
03:05 imirkin: and https://github.com/swaywm/wlroots/issues/1438
03:05 gitbot: swaywm issue 1438 in wlroots "transparent screenshot with grim" [Bug, Closed]
03:52 gentz: Thank you imirkin. Using eglGetConfigs and sorting stuff myself turns out to take a lot less lines than trying to populate some silly attrib_list while also allowing my library provide better error messages to users for when their search fails. (This config got rejected for X reason, and this one for Y reason and so on, instead of just "lol, we found nothing").
03:52 imirkin: cool
03:53 gentz: I'm guessing a similar task should be done for GLX?
03:54 imirkin: wouldn't hurt
04:09 icecream95: pq: As well as R1_*, Mali Midgard also has RGB1 (real 3bpp, no padding)
06:24 tomeu: anholt: you have already solved your problem with the u-boot prompt, and now are having trouble with the ramdisk, right?
06:25 tomeu: because the u-boot part of https://people.freedesktop.org/~anholt/LAVA%20_%20Scheduler%20_%20Jobs%20_%2035.html now seems quite normal
07:44 rendiasso: it is a bit of embarrasing , estonian bigger personalities are pulled into a war with entire nutters, as always things as i say get totally unacceptaly stupid on #osdev #asm and channels alike, GPU based ones are better than of those.
07:45 rendiasso: They have moderators and operators who generally do not understand anything.
07:48 rendiasso: One of the estonian ex-banker wrote couple of days ago, that it is sad when people forget mathematics or just never knew the basics of math where programming paradigm is highly influenced by math and hence becomes entirely easy when you know number theory!
07:52 rendiasso: So for instance if you play with addition and 32bit bitfieds under gnome-calculator or windows calculator , you will notice that with couple of additions the bitfield can be manipulated like needed based of humans built number theory which all adds up.
07:52 rendiasso: a simple number theory connects every part of the summation falwlessly and without any trouble if you remember the maths.
07:55 pq: gentz, do also check glGetError or whatwasit
07:55 pq: icecream95, wow.
07:56 rendiasso: currently we have education that is ranked number in europe based of results, during my times i was just a powerful memoryman and thinker, i remember number theory and calculations that programming requires very well hence.
07:59 rendiasso: So this is not a virus that ADSL microcontroller equipment can be lifted easily to fire optics signalling, very simple calculations prove it, and code is simple too.
07:59 rendiasso: fibre
08:01 gentz: @pq
08:01 gentz: pq: It was zero.
09:07 pq: danvet, when you write "nerv" in DRM docs and patches, do you actually mean NERV from Neon Genesis Evangelion, or is it a mistyped "nerf" as in make the thing less dangerous? :-)
09:40 MrCooper: pq: the latter, possibly due to the German verb "nerven" (meaning "to go on someone's nerves")
12:27 DOmen: what is up to date document regarding patch submissions to mesa ? what is procedure ?
12:33 kisak: https://www.mesa3d.org/submittingpatches.html
12:50 DOmen: kisak: so how do i get somebody to review patch ?
12:50 danvet: pq, mistype for nerf
12:51 danvet: MrCooper, and yeah I think that typo is ingrained in my brain because of "nerven"
17:06 jekstrand: What's theinteger value of EFAULT?
17:06 ickle: 14
17:06 jekstrand: It's not in asm-generic/errno.h
17:06 jekstrand: k
17:07 jekstrand: Any idea what error 524 is?
17:07 ickle: some internal errno
17:07 jekstrand: great...
17:08 ickle: ENOTSUPP
17:08 imirkin_: jekstrand: errno-base.h has the low ones.
17:08 ickle: hmm, not strictly part of the uapi
17:09 ickle: user facing is better using EOPNOTSUPP
17:09 jekstrand: Well, looks like I have some feedback for these kernel patches then. :-)
17:15 jekstrand: Except the public version of the patches doesn't have this line...
17:17 jekstrand:comments it out and hopes for the best
18:05 imirkin_: jekstrand: just curious - do you guys have a direct line with the hw team to work through issues like the one you recently "fixed" with MOV_INDIRECT?
18:05 jekstrand: imirkin_: "direct" would be over-stating it. Do we have a line? Yes.
18:06 imirkin_: like ... did you sit down with an hw engineer and show the issue, or some semi-equivalent?
18:06 imirkin_: or just provided a report of "here's what i saw, here's how i fixed it, good luck!"
18:09 diddledan: backtrace of a new one on Ubuntu following the fixes for Xorg issue #211 - I don't think this is a regression caused by those patches, more an unmasking - most GL applications work fine when using Indirect GLX but one specific demo of a library (or maybe that library) causes the bt at https://paste.ubuntu.com/p/cqrqq4FZWD/
18:10 diddledan: specifically that's the BT of Xorg which is raising a segv
18:11 diddledan: the topmost entry in the BT and several later entries appear to indicate the crash occurring in mesa-dri, which is why I'm posting in here instead of #xorg-devel :-)
18:14 diddledan: args and locals at point of crash: https://paste.ubuntu.com/p/zDGHG4hrx7/
18:38 jekstrand: mareko: Does radeonsi implement ASTC at all?
18:38 jekstrand: mareko: I know you don't have HW for it but do you have a SW or compute decode path?
18:48 imirkin_: afaik stoney/some other apu supports astc
18:48 imirkin_: the rest is software decoded at the st/mesa level
18:49 imirkin_: (same as the etc2 fallbacks)
18:49 imirkin_: same on nvidia - the tegra's support astc, desktop parts don't
18:51 jekstrand: Was the astc sw decode added for Chrome?
18:52 imirkin_: dunno. mareko added it. but it's required for ES 3.2
18:59 jhli: daniels: Could I get your sign-off on the getfb2 libdrm wrapper patch? https://patchwork.freedesktop.org/patch/350140/
19:04 bnieuwenhuizen: jekstrand: I think there is SW decode
19:05 bnieuwenhuizen: jekstrand: imirkin: also 1 generation seems to have HW support but when we enabled it in RADV we got a bunch of AMD people complaining it was not validated. Given that CTS does not seem that thorough not sure I trust it working
19:06 imirkin_: bnieuwenhuizen: it's definitely enabled in radeonsi for some APU(s)
19:06 bnieuwenhuizen: imirkin_: ETC is on some. ASTC IIRC is not
19:07 bnieuwenhuizen: (not at driver level at least. pretty sure it is enabled via some SW stuff for some GLES / AEP stuff)
19:07 imirkin_: yeah, well definitely there's SW fallbacks
19:08 imirkin_: trying to find where the format stuff is figured out
19:08 imirkin_: not easy to find.
19:08 Kayden: jekstrand: st/mesa fakes ASTC support by using uncompressed textures, like our old ETC hacks.
19:09 Kayden: jekstrand: iris is currently using it for ASTC5x5 only on Gen9
19:09 Kayden: we should be getting it on other platforms by virtue of not supporting the formats
19:10 imirkin_: bnieuwenhuizen: you're right - it's enabled for ETC2 on stoney/raven/vega10. not for astc.
19:10 imirkin_: i had misremembered =/
19:15 imirkin_: so yeah, i guess at this point, adreno a4xx+, intel gen9+, and nvidia tegra have native astc support. the rest is sw fallbacks. (maybe v3d?)
19:26 ajax: etna and panfrost too it looks like?
19:27 airlied: id.guess it works on some amd chips but enabling it might trigger patent issues
19:29 imirkin_: probably safe to assume that any ES3.1+ targeted mobile chip will have astc
19:30 imirkin_: it's required as part of AEP and/or ES 3.2
19:30 airlied: not too many android amd gpus
19:31 imirkin_: no, not too many.
19:31 imirkin_: weren't amd gpu's used for some console at some (moderately recent) point?
19:31 imirkin_: i know PS4 has one, but i'm thinking later than that.
19:31 Kayden: xbox one as well
19:31 Kayden: IIRC they are the exact same chip
19:32 imirkin_: as the PS4?
19:32 Kayden: yeah, originally they were at any rate... not sure if that's changed with the updates to those platforms
19:32 Kayden: just wildly different software
19:44 bnieuwenhuizen: airlied: see my message above about AMD people claiming it was not validated when I enabled for raven/vega
19:46 daniels: jhli: done now, thanks a lot for pushing this forward!
19:49 airlied: bnieuwenhuizen: ysah i read not validsted as omg patent payments
20:05 anholt_: with the current ci config, is there some trick to running all the jobs, or all the jobs downstream of some stages's job, other than waiting for their deps to finsih running then clicking the arrow?
20:06 mareko: jekstrand: no, it doesn't implement ASTC
20:19 diddledan: possibly my stack trace is not much help - valgrind says I'm hitting a stack overflow?
20:19 mareko: xbox has always used an AMD GPU, while playstation switched to AMD starting with PS4
20:20 HdkR: mareko: That's underselling the Original Xbox's NV2A
20:20 HdkR: :)
20:42 kisak: dcbaker: did https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3440#note_396341 catch your eye the other day? (I won't bother you again on this)
20:42 gitbot: Mesa issue (Merge request) 3440 in mesa "radeonsi/19.3: disable display dcc" [Radeonsi, Merged]
21:04 jekstrand: kusma: Looking at those Zink bugs
21:04 jekstrand: kusma: AFAICT, the driver seems to be doing the right thing but something is still going sidewayw
21:17 jhli: daniels: np, thanks for the signoff and pointing out the null check :)
21:22 daniels: jhli: np, thanks for chaisng it up
22:19 jekstrand: kusma: One was your fault; one was mine.