01:06 airlied: daniels: can you reboot anongit if you have a minute
03:28 karolherbst: mhh.. guess I now have a motivation getting the nir path into shape for nouveau :D
08:08 daniels: airlied: sure, should be back shortly
08:26 airlied: daniels: is this one of times it doesn't come back :-)
08:26 daniels: airlied: maybe! bigger hammer applied
08:29 airlied: daniels: thx, seems up enough for me to send PR
08:34 daniels: you sure know how to spend a Friday night
08:36 airlied: daniels: I've reach my limit of two xmas movies this week already
08:37 airlied: daniels: I'd have spent my friday morning doing it, but anongit was down :-P
08:39 airlied:returns to movies land
08:55 daniels: heh
08:55 daniels: enjoy :)
14:43 jenatali: daniels, kusma: \o/
14:43 daniels: got there in the end
14:43 daniels: all it required was some minor tweaking of nginx params, complete replacement of nginx, also replacement of the behind-nginx second proxy, and redoing the Windows VM setup from scratch
14:44 jenatali: daniels: Damn. Sounds like I owe you a beer (at least) :)
14:47 daniels: jenatali: tbh I think conversions tips the balance firmly in your favour :P
14:51 danvet: tzimmermann, just crossed my mind, since we do shadow buffer for all vram systems with the generic stuff
14:51 danvet: for cases where we don't need it, could we still pass the real buffer mmap to userspace?
14:51 danvet: by essentially overwriting ->fb_mmap
14:52 danvet: and essentially leave the shadow stuff only for fbcon
14:52 danvet: just as an idea really, should probably be implemented by someone who cares about fbdev mmap userspace performance
14:55 kusma: jenatali: Once this bloody pandemic is over, I think we should try to all meet up for beer or twenty. Fingers crossed for XDC 2021 ;)
14:56 jenatali: kusma: Indeed :)
15:00 danvet: jenatali, well or bring xdc22 to seattle or something, would make it even easier :-)
15:00 jenatali: danvet: I'm seeing if I can convince folks, no promises though :P
15:57 alyssa: Meson question: what's the preferred way for a Python script to generate multiple files? (a source and a header, in this case)
15:57 alyssa: The usual `capture: true` method of generating code doesn't make sense for multiple outputs.
15:57 bnieuwenhuizen: multiple scripts maybe?
15:58 alyssa: I see egl's meson.build invoking the script twice with a source/header option.
15:58 bnieuwenhuizen: yeah I think that is what we do for nir stuff as well
15:58 alyssa: *nod*
15:59 alyssa: bnieuwenhuizen: Oh, the nir_intrinsics.py generation looks... "special"
16:00 alyssa: Passing `meson.current_build_dir()`. That would allow multiple writes, I think.
16:01 karolherbst: alyssa: you can also just add arguments to the script being paths to files
16:01 karolherbst: and you just don't capture
16:01 alyssa: karolherbst: Yeah, I wasn't sure how to know where to write but ^^ just found the answer in NIR.
16:01 bnieuwenhuizen: yeah IIRC there was some mess though with meson wrt dependency checking or something?
16:01 alyssa: This is why I'm scared of build systems.
16:02 alyssa: Looks like swr/rasterizer/codegen does exactly that, pass in current_build_dir and have multiple outputs.
16:02 karolherbst: alyssa: check the i965_gram_tab target
16:02 karolherbst: ahh yeah, swr seems to be doing it as well
16:02 alyssa: And anv_entrypoints, and.. well, now I know what to grep for. Thanks bnieuwenhuizen and karolherbst :)
16:03 alyssa: Kinda funny that we all write graphics drivers in Python :-P
16:05 karolherbst: uhm....
16:05 karolherbst:owns some bash scripts for ... "stuff"
16:08 daniels: multiple invocations is preferred unless you have a very good reason
16:10 alyssa: 👂
16:20 sravn:wonders if writing more than 20 fbdev patches makes one care about fbdev
16:26 danvet: sravn, trying to sing up some of the folks sending in patches?
16:47 sravn: danvet: jumped on the W=1 train and have drivers/video/ free of warnings. Preparing patches..
16:47 daniels: alyssa: partly just principle of least surprise - having one invocation per output file makes it far easier for people to figure out how it's being generated
16:48 alyssa: yeah, I can see that
16:48 daniels: and it's also about giving yourself less room to screw up - if you pass a single file and the invocation just emits that file then it's straightforward, but if you pass it the build dir and let it spam multiple files into it, it's easier to screw it up and get out of sync with what the build system thinks you're emitting vs. what you actually emit
16:48 daniels: then someone with a lot of CPU cores gets very unhappy
16:49 sravn: danvet: maybe I shall try to ask Geert for fbdev help, he cares for old stuff
16:49 daniels: but if it takes like a minute to parse the input, and that parsing is invariant between both output stages, then that's a pretty compelling case for merging them and eating the downside in exchange for faster builds
16:49 danvet: sravn, for the drivers where we have at least some drm drivers (even if not feature parity maybe)
16:50 danvet: I'd just sun-set them
16:50 alyssa: daniels: Sure, makes sense, thank you.
16:50 daniels: alyssa: :)
16:50 alyssa: daniels: The use case here is generating the numbering for an enum.
16:51 alyssa: Depending on what numbering/ordering is used in the header, different source code would be generated
16:51 alyssa: (Most basically - if the ordering matches the hardware, the value is used as-is. If it does not, we need a look-up table to do the pack.)
16:51 alyssa: If both are generated together, there's no question about staying in sync.
16:52 alyssa: If they are not, and a determinism issue gets introduced down the line... good luck :|
16:52 daniels: ordering as in endian, or?
16:52 alyssa: enum { A = 1, B = 7, C = 23 }
16:53 alyssa: where we explicitly specify A,B,C but the code decides at build time to assign 1,7,23 based on some heuristic
16:53 alyssa: ("Heuristic" is overselling it. It just does whatever the first instruction alphabetically does in the hardware ;P)
16:56 sravn: danvet: sunsetting the ones with drm replacements would be fine, I am just missing the knowledge to create the list
16:56 sravn: ofc, I can see some similar names and make a proposal from that. But I would not trust it
16:57 danvet: sravn, pci ids should be a good start
16:57 danvet: the arm platform devices are more icky, but if you look for the of match string, should work too
16:58 danvet: everything else we just keep for another decade or so :-)
17:03 daniels: alyssa: 🤔 I see
17:07 sravn: danvet: will give it a try when I have submitted the W=1 patches. If we can land a sunset rather than a warning removal that would be great
17:29 alyssa: 🌇
18:52 tzimmermann: danvet, should be possible. we use the shadow fb mostly to save vram on systems that need it
18:57 tzimmermann: although i'm not sure where the threshold is
19:20 tzimmermann: danvet, however there's no way of pinning the HW buffer to vram from within fb helpers. makes HW buffers in vram it kinda hard ATM
19:21 tzimmermann: well, maybe we should really make shadow fb the default and HW fbdev opt-in
19:21 tzimmermann: only a handful of cma-based drivers actually support it
20:23 lrusak: can anyone help out here? https://stackoverflow.com/questions/65042610/texture-share-problem-between-two-apps-by-use-of-eglexportdmabufimagequerymesa-a
20:25 lrusak: the texture is GL_BGRA but after exporting the image the fourcc given from eglExportDMABUFImageQueryMESA is DRM_FORMAT_ABGR8888
22:10 emersion: you mean GL_RGBA lrusak_?
22:12 HdkR: What's wrong with GL_BGRA?
22:15 emersion: replied