00:27 jekstrand: Is there an LLVM C api for writing an LLVM module to bitcode?
01:08 anholt: sweet. I think I've got a deqp-runner we can use for asan runs in CI now. tomorrow: to integrate.
01:10 airlied: jekstrand: like LLVMWriteBitcodeToFile?
01:11 jekstrand: airlied: To memory
01:11 jekstrand: airlied: There's a thing but it requires SmallVector so it's C++ only
01:12 airlied: LLVMWriteBitcodeToMemoryBuffer
01:13 jekstrand: airlied: Hrm...
01:13 jekstrand: airlied: Where do you find docs for any of this?
01:13 jekstrand:is hopeless
01:13 airlied: I read llvmpipe when I know it's likely we've done it :-P
01:14 jekstrand: lol
01:18 jekstrand: Ok, I've got the C++ API working. It helps if you use the headers from the right LLVM version. :)
01:21 airlied: yeah I can definitely confrim that helps
01:21 imirkin: anholt: won't that just catch a ton of asan errors in deqp?
01:22 airlied:fixed a few asan errors in gl cts already
01:27 jekstrand: info: error, assertion failed: false == llvm::verifyModule(*pContext->getModule())
01:27 jekstrand: That's.... not helpful.
01:28 jekstrand: I wonder if it's because of these unimplemented functions I have with no linkage attributes...
01:30 airlied: if (LLVMVerifyFunction(func, LLVMPrintMessageAction)) {
01:30 airlied: seems to be what we use ti print out verify errors
02:00 jekstrand: Maybe it has to do with the datalayout?
02:05 airlied: my brain likes to forget about datalayout unless forced into it
02:45 jekstrand: My brain doesn't want to learn the first time. :)
02:53 anholt: imirkin: so far, nope, just extensive errors in mesa
02:53 imirkin: ah nice
02:54 imirkin: i remember running one of those suites with valgrind at one point - it was useless.
02:54 anholt: I think vk-gl-cts has been doing some stuff to clean up their tests, because turns out everyone wants asan clean drivers
02:55 jekstrand: glslang used to make valgrind pretty unhappy. I think it's a lot better these days.
02:55 HdkR: TFW your application breaks asan
02:56 airlied: though last I looked our gl spirv stack upsets asan
02:57 airlied: leaky leaky, never got back to figuring it out
02:57 HdkR: I've managed to have llvm asan and valgrind both break on me in different ways. Might be an indicator to stop being so mean so I can still do asan testing :P
03:16 airlied: [701177/701177] Pass: 168845 Fail: 0 Skip: 532332 ExpectedFail: 0 UnexpectedPass: 0 Crash: 0 Timeout: 0 Missing: 0 Flake: 0 Duration: 44:55 Remaining: 0
03:17 airlied: lavapipe vulkan 1.0 cts run, now to get all the changes upstream
03:23 HdkR: \o/
03:24 bnieuwenhuizen: \o/
03:25 Plagman: nice
04:16 mareko: airlied: what's next? GL conformance with zink -> lavapipe? :)
04:26 jenatali: airlied: \o/
04:30 airlied: mareko: clover/llvmpie CL 3.0 hopefully, but zink on lvp would be more of a good for CI task, I got glxinfo to at least work last week
08:36 hakzsam: tomeu: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/5714827 what's wrong with it?
08:45 tomeu: hakzsam: it's a known issue, should happen quite rarely
08:45 tomeu: people are working on this already
08:46 hakzsam: it happened two times with that MR
08:46 tomeu: hmm, that's interesting
08:46 hakzsam:tries again
08:47 tomeu: should be around 2% in the device that exhibits it most often
08:49 hakzsam: I'm just unlucky then? :)
08:51 tomeu: I'm right now trying to find that out :)
08:54 MrCooper: imirkin: in contrast to valgrind, at least UBSan only affects the code which was built with it enabled, though I guess it might not be that simple with ASan
09:11 hakzsam: tomeu: it passed
09:33 danvet: hwentlan, btw if you convert over amdgpu-dc to a bunch of drm_private_obj/state things you'll want to follow what mripard is doing with vc4
09:46 mripard: hwentlan: https://lore.kernel.org/dri-devel/20201113152956.139663-1-maxime@cerno.tech/ for reference
09:47 emersion: danvet: do you know if there's a good way to document #define'ed values?
09:48 emersion: right now it seems those are documented at each usage-site
09:48 emersion: e.g. in drm_display_mode
09:48 danvet: for non-uapi, convert to enum
09:48 danvet: for uapi
09:48 danvet: no idea :-(
09:48 emersion: rip
09:49 dolphin: one sees #ifdef __doxygen__ enum #else real defines #endif
09:49 emersion: documenting at the usage-site works fine until the #defines are used in multiple places
09:49 danvet: emersion, if you feel very bold, extend kernel-doc?
09:50 emersion: also, some drm_display_mode doc comments end with "?!"
09:50 emersion: just so you can feel the doc writer's confidence :P
09:51 emersion: yeah, maybe i'll drop an email to kernel-doc folks
09:55 danvet: oh the display mode stuff goes back to xrandr
09:55 danvet: which goes back further
09:55 danvet: some stuff might very well be entirely lost
09:55 danvet: I think vsyrjala deleted a bunch of it
09:55 danvet: and I killed a few things off too
09:56 danvet: there might be more
10:08 danvet: emersion, %DEFINE does not work?
10:08 danvet: just spotted that somewhere
10:08 danvet: or is that highlighting only
10:08 danvet: I know that function-like #define you can document with just macro()
10:08 danvet: like a normal function
10:09 emersion: oh, referencing a #define is no problemo
10:09 emersion: the problem is grouping the #defines
10:09 danvet: oh yeah that's hopeless
10:09 emersion: let's say you want to document drm_display_mode.flags
10:09 emersion: and drm_mode_modeinfo.flags
10:09 emersion: you don't want to duplicate the docs
10:10 emersion: it would be nice to have a single place where you list and document all of the #defines
10:10 emersion: ideally near the #defines in the code
10:10 danvet: yeah
10:11 emersion: maybe creating a doc section that can be imported/referenced would work?
10:11 emersion: DOC: DRM_MODE_FLAG flags
10:11 emersion: or something
10:13 danvet: emersion, yeah but the cool thing with using types in kerneldoc is that stuff like cscope can get you there
10:14 danvet: so it's a useful link not just in the generated output, but also in sources
10:14 emersion: well, we're talking uapi, so we can't really change the types, right?
10:14 danvet: I'm wondering whether we could
10:15 danvet: just make the enums, see how badly userspace hates us
10:15 emersion: hmm
10:15 emersion: i wonder if sizeof(DRM_MODE_…) would be affected
10:15 emersion: that's probably compiler-dependent
10:16 danvet: I mean we'd need to assigne explicit values anyway
10:16 emersion: do we have an escape hatch in case we mess it up?
10:16 danvet: can we control the enum size with the usual suffix?
10:16 danvet: like ULL or so
10:16 emersion: i suppose we can always re-introduce the defines, then do something like
10:16 danvet: emersion, git revert + cc: stable and looking a bit sheepish
10:17 emersion: enum drm_mode_flags { DRM_MODE_FLAG_ASDF_ENUM = DRM_MODE_FLAG_ASDF };
10:17 danvet: emersion, I think the signedness of the enum is the bigger problem
10:17 emersion: ah
10:17 danvet: since the bitflags we really want to do unsigned
10:17 danvet: so would need to check the spec
10:18 danvet: but in drm at least we shouldn't need to worry too much about old compilers
10:18 danvet: the worst I know is mesa on windows, but luckily that doesn't matter for linux uapi
10:18 danvet: in the gpu userspace ecosystem
10:19 danvet: emersion, what we definitely can't do is use the enum in uapi structs
10:19 emersion: yeah
10:19 emersion: definitely not
10:20 emersion: but a "See enum drm_mode_flags" in docs would be nice
10:22 emersion: > Each enumerated type is compatible with one of: char, a signed integer type, or an unsigned integer type. It is implementation-defined which type is compatible with any given enumerated type, but whatever it is, it must be capable of representing all enumerator values of that enumeration.
10:22 emersion: hm hm
10:22 emersion: so what we're worried about is breaking user-space that does something like this:
10:23 emersion: int flags = DRM_MODE_FLAG_ASDF;
10:23 emersion: and has errrs enabled for unsigned-to-signed conversion?
10:26 emersion: c++ has `enum name : type {};`
10:26 emersion: but doesn't seem like c has it
10:27 emersion: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf
10:27 emersion: a little to early to the party
10:27 emersion: 10 years too early maybe
10:33 danvet: emersion, what about adding a DRM_MODE_FLAGS #define at the top we link to?
10:33 danvet: the others should follow in order I think
10:33 danvet: plus in 10 years we could convert that to the enum name
10:34 emersion: so, something like this:
10:34 emersion: #define DRM_MODE_FLAGS __u32
10:34 emersion: ?
10:34 emersion: maybe we could typedef it instead
10:36 danvet: oh just the empty define
10:36 danvet: so we can attach some kerneldoc to it
10:36 emersion: is this better than a "DOC:" section?
10:37 danvet: shorter to link to
10:37 danvet: there's not automagic format for linking to DOC: from kerneldoc
10:37 danvet: plus cscope understands it too
10:38 danvet: I hope at least
10:38 emersion: ah, cscope, right
10:39 emersion: i'm not a fan of leaking a new symbol in the uapi just for docs
10:39 danvet: well the enum would do that too
10:40 emersion: the enum would be useful
10:40 emersion: but oh well
10:40 emersion: nbd
10:41 emersion: i'm not sure it's fine to use an enum for bitfields in the first place
10:41 emersion: i mean, i like it when my enum values only contain one of the enum members
10:41 emersion: so that you can switch() on them exhaustively
11:07 pepp: tracie.fd.o returns error 500 (eg https://tracie.freedesktop.org/dashboard/imagediff/mesa/mesa/5719329/glmark2/shading-shading=cel.rdc)
15:34 pcercuei: mtretter: I'm reading your https://events19.linuxfoundation.org/wp-content/uploads/2017/12/The-Modern-Linux-Graphics-Stack-on-Embedded-Systems-Michael-Tretter-Pengutronix.pdf
15:35 pcercuei: mtretter: would the "fullscreen shell" be able to handle a fullscreen app + an overlay app (notifications, volume control etc.)?
15:51 emersion: MrCooper: do you know if there's a way to get an explicit fence out of a DMA-BUF's implicit fence?
15:51 emersion: i know you can poll, but if you need to provide a fence to e.g. vulkan, you need a "real" fence
15:51 emersion: or do you? can the DMA-BUF be imported as a fence?
15:56 MrCooper: emersion: AFAIK there's no way yet, jekstrand posted patches for that some time ago
15:56 emersion: ah. that would help gradual adoption quite a bit
15:57 emersion: jekstrand: do you have a link to these patches?
15:57 ajax: kherbst: apologies if i'm being a bit of a hardass about the big-endian stuff, i just want to make sure it gets fixed and stays fixed. when i was poking at that stuff it was way too easy to try a fix in component and and discover it broke an assumption downstream in component b
15:58 kherbst: ajax: yeah.. me as well
15:58 ajax: starting from "mutter looks wrong over vnc" is just too many variables in play
15:58 kherbst: the most annoying part is just, that if I run the CTS with enough tests, the machines are soooo slow it takes me a day to run the regression testing
15:58 kherbst: ajax: sure, but the VK-GL-CTS has a bunch of 565 tests which flip over
15:59 kherbst: the problem is the 565 render target anyway in this issue
15:59 kherbst: I am fairly confident about that
15:59 ajax: kherbst: you may actually be better off setting up an s390x chroot and running it under qemu-user
16:00 ajax: it's "only" like 8x slower, but given how the s390x slices we get are usually so cramped for memory and cpu cores it can be a win
16:01 ajax: yeah, just if it's one bitpacked format it'll be all of them. rgb10a2 is busted too and people sometimes use that as a vertex format...
16:03 ajax: but this is also why i want to get the in-tree unit tests to not be xfails. fix that and then CI will catch it if it breaks.
16:03 kherbst: ajax: too slow
16:03 kherbst: I already tried
16:03 ajax: :(
16:04 kherbst: I have this script merging some CTS mustpass files and nuking duplicates
16:04 kherbst: 90k tests
16:04 kherbst: runs for like 14 hours
16:04 kherbst: but then I am really sure not to break stuff
16:04 ajax: if only our corporate overlords' overloads hadn't dropped quicktransit down the memory hole
16:04 kherbst: the slice I have has 4 cores
16:04 kherbst: so it's not that bad
16:05 kherbst: and I asked for more already :D
16:06 mtretter: pcercuei: no, the fullscreen-shell does not handle an overlay apps. _And_ the client app has to use the fullscreen_shell protocol.
16:07 pcercuei: mtretter: ah, alright, thanks
16:09 pepp: bnieuwenhuizen_, agd5f_ : commit "drm/amd/display: Set new format info for converted metadata." broke TMZ surface display
16:17 mtretter: pcercuei: for such a scenario you might use an ivi-shell and write your own hmi-controller. Handling a single fullscreen application isn't much code and should provide enough flexibility overlays.
16:24 MrCooper: kherbst: I agree with ajax in principle, but note that the low-level format tests can have endianness bugs as well
16:26 kherbst: yeah...
16:26 kherbst: that's why I only sent out the llvmpipe fix, because that fixed it visually and inside the CTS
16:26 kherbst: but I also dislike the fix itself
16:27 kherbst: it was more of a "this is wrong" thing and "it's supposed to be like this" and hoped somebody had a better idea on where to actually fix it
16:29 kherbst: u_format_test output btw: https://gist.github.com/karolherbst/ecefefbffb166d49edcab04cb305c0c2
16:29 kherbst: fun that bgra4444 is also bonkers
16:29 kherbst: huh
16:30 kherbst: rgb565 is fine, but bgr565 broken
16:30 kherbst: mhhhh
16:34 bnieuwenhuizen: pepp: what GPU and what is the easiest way to test?
16:36 pcercuei: mtretter, I'm surprised nothing exists yet for my use-case though
16:41 agd5f_: bnieuwenhuizen, raven
16:41 agd5f_: any raven variant
16:42 agd5f_: also need amdgpu.tmz=1
16:43 bnieuwenhuizen: those I have but what do you use to get a TMZ workload?
16:46 agd5f_: pepp, test case?
16:49 sravn: pcercuei: Have you looked at cage? https://github.com/Hjdskes/cage
16:49 sravn: pcercuei: Seems like it may fit
16:50 agd5f_: bnieuwenhuizen, looks like the tmz flag doesn't get passed to DC
16:51 bnieuwenhuizen: that seems like something plausible, though I'm very weirded out by the named patch causing it ...
16:51 tfiga: danvet: great, thanks
16:52 pepp: agd5f_: bnieuwenhuizen : "AMD_DEBUG=tmz glxgears", then I use the gnome shortcut to switch the window to fullscreen
16:52 bnieuwenhuizen: ok, thanks
16:53 pepp: the culptit commit is odd, maybe I made something wrong in my git bisect steps
16:54 bnieuwenhuizen: or maybe the patch makes the addfb fail and then we never end up even displaying it?
16:55 bnieuwenhuizen: will try to reproduce later today
16:58 pepp: thanks. I'm going to re-test the commits around to be sure that you're looking at the one introducing the issue
17:02 bnieuwenhuizen: agd5f_: pepp: btw do you have any idea how we can end up with invalid DCC data after suspend? re https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=87b7ebc2e16c1 (this results for me that a DCC compressed surface gets interpreted as non-compressed surface on resume until my compositor does a flip, which is especially noticeable now that e.g. weston always uses DCC)
17:03 pcercuei: sravn: that looks promising, but I'm not sure it will allow me to have an OSD
17:04 bnieuwenhuizen: AFAIU in that situation the drm framebuffer still exists so I'm not sure what can change? some pinning failure?
17:09 pepp: bnieuwenhuizen: I don't know..
17:10 pepp: bnieuwenhuizen: regarding the TMZ, I just retested: the first bad commit is really "drm/amd/display: Set new format info for converted metadata"
17:10 bnieuwenhuizen: ok
18:10 sravn: pcercuei: Is it this you are looking for: https://github.com/Hjdskes/cage/issues/95
18:10 gitbot: Hjdskes issue 95 in cage "Add support for wlr-layer-shell" [Enhancement, Open]
18:11 sravn: pcercuei: There is a stale branch, which was what I had seen. So close but not yet there it seems
18:15 pcercuei: sravn: I think so. Thanks
20:07 ajax: anholt: do you have some additional magic for shaderdb on software? run.c doesn't seem to know about any of the swrast env vars for shader dump
20:36 anholt: ajax: I think I've got an MR open
20:37 anholt: you shouldn't need any env vars for softpipe, it reports shader-db through the debug output channel
20:37 anholt: shader-db mr for run.c that is
20:53 ajax: hah, pilot error, i'd horked the build tree i was testing so that swrast would never load.
21:36 kherbst: one question: what do we do once debian drops llvm-8 with our cross builds?
21:40 karolherbst: ohh they already did
21:53 ajax: karolherbst: presumably we do !6629 and/or !7129
21:59 lrusak: emersion, you around?
21:59 karolherbst: ajax: just that the packading doesn't work
22:00 karolherbst: ohh, this is addressed in !7129
22:00 karolherbst: mhhh
22:00 karolherbst: also ugly :/