05:35 airlied: karolherbst: managed to produce the polly bug in CI on my to getting clover CI working :-P
06:57 airlied:wonders did I break CI, all my jobs appear blocked
07:01 airlied: ah maybe it was just by local ui got messed up
07:22 MrCooper: karolherbst: BUILD_SHARED_LIBS has always been a bad idea for anyone who isn't an LLVM developer
07:28 airlied: MrCooper: except for clang it's a different rule
07:29 airlied: because consistentcy isn't llvm project strong suit :-P
07:29 MrCooper: hmm, is "Auto-cancel redundant, pending pipelines" enabled in the mesa/mesa CI/CD settings?
07:29 airlied: MrCooper: pretty sure it used to always kill old one when I pushed a new one
07:30 airlied: karolherbst: okay have CI to the stage where I need to figure out how to put the clc library in
07:30 MrCooper: that would be airlied/mesa then :)
07:30 airlied: openat(AT_FDCWD, "/usr/lib/clc/spirv64-mesa3d-.spv", O_RDONLY) = -1 ENOENT (No such file or directory)
07:30 airlied: ah indeed
07:31 airlied: will dig into figuring out how best to land that piece tmrw and we should at least have piglit running on clover
07:31 MrCooper: nice
08:04 mripard: danvet_: ack, I'll add it then :)
08:04 mripard: it's definitely convenient to have those defconfig, but I think not many know about it, so having CI would help yep
08:23 danvet_: mripard, yeah
08:23 danvet_: plus their fragile
08:23 danvet_: but creating a script that does it automatically and handles all the various cross-compiler naming schemes is even worse
08:24 danvet_: so docker image in gitlab ci is needed for that I think
10:04 mripard: danvet_: that's probably a dumb question, but how do you push your defconfig changes to drm-rerere
10:05 mripard: is there some magic dim command for that, or do you pass the magic option to let the server update the branch by hand?
10:48 MrCooper: karolherbst: FWIW, I've never seen pages:deploy fail for mesa/mesa
10:48 karolherbst: MrCooper: mhh, strange
10:49 karolherbst: yeah.. maybe it was always ikiwiki messing up.. dunno
10:49 MrCooper: but it fails often for wayland/ projects as well
11:58 feaneron: karolherbst: sorry about the back and forth on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1443 - do you mind updating it so that i can merge it?
11:58 karolherbst: feaneron: just rebase or something else?
11:59 karolherbst: ohh, you left a comment
11:59 feaneron: karolherbst: "So, @jadahl convinced me on IRC that we should go back to meta_is_udev_.... The reason is that Mutter already have MetaUdev* objects, and my suggestion to rename this function clashed the prefixes. Could you please undo this suggestion?" :)
11:59 karolherbst: yeah, I totally missed that one :)
11:59 feaneron: sorry about that, and thanks for your patience!
12:00 karolherbst: pushed
12:02 feaneron: thank you
12:37 feaneron: does anyone know where i can reach nvidia developers to talk about their ddx driver?
12:42 MrCooper: feaneron: e.g. aaronp on #xorg-devel
12:42 feaneron: thanks
12:47 pcercuei: __drm_gem_cma_create() looks fishy to me
12:47 pcercuei: it does:
12:47 pcercuei: gem_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
12:47 pcercuei: That's already scary
12:47 pcercuei: then in the cleanup code:
12:47 pcercuei: kfree(cma_obj);
12:48 pcercuei: which is not the pointer that was returned by kzalloc()
13:32 danvet_: mripard, I git commit first
13:32 danvet_: then dim rebuild-tip
13:32 danvet_: that pushes the rerere branch too (since that's also where the conflict resolutions are)
13:32 danvet_: it's a bit quirky :-/
13:41 mripard: that works for me :)
13:41 mripard: thanks!
16:08 dcbaker[m]: hanetzer: I can't replicate a build breakage with aarch64 with the options I have (I don't have X11, wayland, or LLVM)
16:08 dcbaker[m]: what options are you using?
16:47 anholt: krh: I would need c++20 for initializing the driOptionValue union in the unit test I wrote :(
16:47 anholt:wishes gtest had a non-c++ option
17:02 tanty: dcbaker[m] could you take a quick look to
17:02 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/351
17:02 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/352
17:02 tanty: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/392
17:08 dcbaker[m]: tanty, I've set the last two to merge, as they look good
17:08 tanty: thanks!
17:08 dcbaker[m]: and commented on the other
17:29 krh: anholt: the main thing we get from gtest is the TEST() macro, that lets us just declare the test and not have to redundantly list all tests somewhere else
17:30 krh: we used the section attribute for that in crucible, that's something we could do in mesa too
17:30 krh: but of course, you have enough yak hair for a XXXL sweater at this point...
17:30 anholt: yeah, it means losing unit testing on windows, but compared to fighting this awful language, it's pretty compelling to me.
17:34 ccr: now that MS owns Bethesda, you could try talking to MS people to laterally move Todd Howard to their team, so "it just works"
17:42 ivyl: Adrinael: do you plan to respin chamelium curl timeout patch with the correct time unit
17:43 ivyl: and what about the making adding assembler to meson_options.txt?
17:44 Adrinael: ivyl, both when I have enough time, and at the same time remember them
17:44 ivyl: kk, so they are not important
17:45 ivyl: I was just wondering if I have missed anything :D
17:59 Lyude: if I'm adding support to igt for doing things like querying device info and handling blitting, does it matter if I just take the easy way out and use libdrm? Asking because it seems like stuff like intel_batchbuffer.{c,h} go out of their way to avoid depending on libdrm
18:00 withnomad: Muxes like a typical mux in synthesized form does not care whether it is pulled on 0 or 1 if the output is a wire, it will take the same energy to fill the pipeline agressively with real work rather than reprogramming the gate to output the zero bubble. Even repetitive zero gate programming on the case labels still reprograms i.e reopens the gate for pulling towards the ground, on other data it will pull for other types of bits from sensitivity list.
18:06 hanetzer: dcbaker[m]: its not an issue with mesa per se. just the gentoo setup of crossdev
18:32 withnomad: What i think based of the literature this condition seems to hold always unless power-gated logic optimizations is used, which would use ome more gates in area but save power based of the last state or something.
18:36 ivyl: Lyude: we try to avoid the dependency on libdrm as much as possible
18:37 ivyl: so it would be better if you would do the ioctl without libdrm
18:50 withnomad: mis be more read accurately another day, netlists are not easy for me also, but probably the mental model i 40to1MUX is like a fifo mostly, where the position of the data is moved down actually it circulates, but never removed from the list, instead it wraps around, that is the only difference with fifo, that probably instead of removal it just wraps around changing the pos on chip.
18:54 withnomad: in case the case comparison is done for the wfid, and it finally changed only then probably it is replaced with a new circulating value.
19:16 Adrinael: ivyl, more context from #intel-gfx: Lyude's doing stuff for nouveau, where it makes sense to use libdrm as that's what real userspace does
19:18 withnomad: I go for the final hack sometimes later on FPGAs, since parallel cases is no longer mux but more expensive version not too many can be used, the mission is to do a cheap adder hacked muxes for FPGA open kits, this is realistic thing, i have ideas, but currently no time yet.
19:22 Lyude: ivyl: yeah - mesa seems to use libdrm for nouveau pretty heavily
19:26 withnomad: i go off now, due to new transistors also on intel FPGAs which are so good and with small leakage, this type of muxes should get an edge on FPGAs over ASICS, in terms of power usage and even area etc. so this is fascinating thing to do.
19:26 krh: anholt: it may be a fair tradeoff - as long as we can unit test in CI
19:41 ivyl: yeah, then that's fine
21:19 linkmauve: Hi, what is the current best solution for running glide programs on top of Mesa?
21:20 linkmauve: I’ve seen nglide for a glide → d3d9 → nine wrapper, also http://www.svenswrapper.de/english/ for glide → opengl, both non-free and only for Windows.
21:37 linkmauve: Ah, OpenGLide seems exactly what I want!
22:04 withnomad: I looked at ZAP-master about those write-combined buffers, it is equivalent in process and performance that of r300 gpu. But does not have async wb FSM ROM/RAM implemented for wishbone. So BURST_LEN there is 4 and wb line fill sync_fifo has 32 entries, it can do hence 128 async ops. r300 upto 256 though when 4 pipelines are there.
22:23 withnomad: GCN hardware can do as many low-latency fast ops as to before the hw naturally limits for that particular process.
22:28 withnomad: and on pipelined stuff like this ARM and r300 if one were to write also self-modifying code with hacked in branches, it could do more too, but the process does not scale for more anyways.
22:31 withnomad: as for conspirants and scammers from my country i can proudly soon say, Hey now , hey now, the DREAM is over , they will be locked up and i survived regardless of their dream and committed actions against me.
22:32 airlied: yay got a piglit cl run to complete in ci
22:34 karolherbst: yay
22:37 anholt: krh: making driconf be structs and generate xml on the fly is -30 lines of code.
22:38 anholt: still need to do valid ranges, and a couple of stubs to hook up classic drivers xml generation, so will probably come out to net 0.
22:45 airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6901
22:45 airlied: now the question is whether it's best to expand the gl container or create a cl container
22:50 anholt: assuming that gl/cl interop is a thing at some point, I'd use the same container
22:51 airlied: anholt: it is a thing, not sure if I can make llvmpipe support it easily :-P
22:51 airlied: I think if someone wants to hooks up CL CTS then maybe a split might be warranted
23:35 airlied:starts mesa 20.2 llvmpipe GL 4.5 cts submission run
23:40 karolherbst: airlied: maybe we should hook it up with my runner.. but it depends on some CL CTS patches to report an error... but I think I should parse whatever we get in stdout instead though :/
23:41 karolherbst: or make deqp-parallel-runner eat that stuff as well?
23:41 karolherbst: dunno
23:42 airlied: karolherbst: yeah not sure what best way to go, also how long CTS takes to run might be a factor
23:42 airlied: piglit is just getting in around 11/12 mins
23:42 karolherbst: _very_long_
23:42 airlied: karolherbst: yes so we'd have to define an acceptable subset
23:42 karolherbst: basic is like 0.1% relative to time
23:42 karolherbst: so we could go for basic and some other tests
23:42 airlied: or just run it with a regular pipeline outside of pre-merge
23:42 karolherbst: or just do whimpy runs
23:43 karolherbst: those are quite fast
23:43 airlied: dcbaker[m]: so the release notes for 20.2 have two minor issues
23:43 airlied: dcbaker[m]: not sure if there's any point in fixing tme
23:44 airlied: New Features has both GL 4.3 and GL 4.5 for llvmpipe, but also has None in the list
23:44 dcbaker[m]: we can fix them on the master branch where they actually count
23:46 dcbaker[m]: updated
23:46 dcbaker[m]: i doubt anyone actually reads the release notes on the stable branch
23:46 dcbaker[m]: I wonder if it would be smarter to not even generate them on that branch and just generate them on master
23:49 airlied: dcbaker[m]: yeah I'd guess most people would get them from the web
23:50 dcbaker[m]: I think that it's really an artifact of the time before I made a script that assembles the release notes and they were handwritten
23:57 Chaekyung:reads the secret release notes
23:58 Chaekyung: I've subscribed to the mailing list so I get them and I do mostly skim through them
23:59 Chaekyung: So until I get them, what is the biggest new feature in 20.2 beyond ACO enabled by default for AMD Vulkan users?