01:40 airlied: uggh the sneaky use 32-bit vertex elements for 64-bit doesn't work so well on big-endian
09:58 bbrezillon: karolherbst: hm, it seems to be a problem with block interface types which are not handled by glsl_get_natural_size_align_bytes()
09:58 bbrezillon: (regressions on intel CI)
09:59 bbrezillon: this being said, I'm not sure what to do. Should I consider block interfaces as structs when it comes to size/alignment calculation?
10:13 MrCooper: daniels: looks like https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5689 includes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5541 ?
10:13 MrCooper: I guess that's one way to avoid trouble due to 'Branch cannot be merged' :)
10:20 daniels: MrCooper: ha! ugh, good catch, thanks
10:58 bbrezillon: karolherbst: I pushed a new version https://gitlab.freedesktop.org/bbrezillon/mesa/-/commits/nir-load-store-alignment
10:58 bbrezillon: this should fix the assert() on ivb
10:59 karolherbst: bbrezillon: okay, triggered a new run
10:59 bbrezillon: karolherbst: thanks
12:48 karolherbst: ehhh.. the arm container can't be built because the job takes too long.. https://gitlab.freedesktop.org/karolherbst/mesa/-/jobs/3358335
12:49 karolherbst: I want to bump libdrm to 102: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/diffs?commit_id=2c91553d599e9c917d62a17f16004b0fc450477b
12:49 karolherbst: but well.. seems like that's impossible
12:59 tomeu: karolherbst: you can increase the timeout in your repo config
13:00 tomeu: I have a branch that makes that job much smaller, but it's blocked on the minio deployment
13:00 karolherbst: tomeu: mhh, where is the setting? and how high does the value have to be?
13:01 karolherbst: ohh, found it
13:22 karolherbst: bbrezillon: seems like the new run is better, and I think the fails are unrelated: https://mesa-ci.01.org/karolherbst/builds/148/group/63a9f0ea7bb98050796b649e85481845
13:36 bbrezillon: karolherbst: much better, indeed
13:43 ernstp: @airlied Where can I find you pgp key?
13:48 ernstp: Trying to find the key for the libdrm .102 sig
13:51 bbrezillon: karolherbst: this one might be related https://mesa-ci.01.org/karolherbst/builds/148/results/8100504
13:59 MrCooper: karolherbst: I wonder what changed though, since it passed before
14:07 MrCooper: karolherbst: generating the current image only took ~17 minutes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/3302647
14:07 MrCooper: if your branch is up to date with current master, there could be something wrong with your changes
14:07 MrCooper: (or something else broke since the above)
14:15 bbrezillon: MrCooper: I'm pretty it's something related to my changes
14:15 bbrezillon: :)
14:18 MrCooper: which changes?
14:22 bbrezillon: MrCooper: the one I asked karolherbst to push to his branch so it gets tested by intel CI
14:22 bbrezillon: :)
14:22 bbrezillon: https://gitlab.freedesktop.org/bbrezillon/mesa/-/commits/nir-load-store-alignment
14:23 MrCooper: I'm talking about the GitLab CI docker image build job failure above
14:24 bbrezillon: ok, nevermind then
14:41 karolherbst: MrCooper: even for arm?
14:41 karolherbst: but yeah, I am on master
14:41 MrCooper: the job above generated the current arm_build image
14:41 karolherbst: but my changes are probably fine though..
14:41 karolherbst: just bumping the libdrm version
14:42 MrCooper: yeah, it's weird
14:42 karolherbst: it does build tons of stuff though
14:43 MrCooper: daniels: ^ could there be something wrong with the fdo-packet-arm2 runner? It's hitting the 60 min timeout for a job which completed in under 17 minutes a few days ago (on fdo-packet-arm-1)
14:46 MrCooper: karolherbst: could retry it and keep an eye on it, to see if it gets stuck at a particular point maybe
14:47 karolherbst: now it weng through...
14:47 karolherbst: 86 minutes though
14:47 karolherbst: MrCooper: https://storage.googleapis.com/fdo-gitlab-artifacts/a0/11/a0119e19d7f710c158729bc4153a6996e891b54664262b502c7be665e0f2f042/2020_06_30/3359420/3700861/job.log?response-content-type=text%2Fplain%3B%20charset%3Dutf-8&response-content-disposition=inline&GoogleAccessId=GOOGOEXJKVLVDILPMJ5V2WSY&Signature=lgrGcDR86%2FRehkaD%2FEG7YGthKwU%3D&Expires=1593529043
14:47 karolherbst: but yeah..
14:48 karolherbst: no clue
14:48 karolherbst: ahhh :/ annoying
14:48 karolherbst: now meson-armhf fails because it uses system libdrm
14:49 karolherbst: maybe I just give up and make the feature optional... *sigh*
14:49 MrCooper: that was even on fdo-packet-arm-1, same one which built the current image in under 17 minutes
14:50 MrCooper: I wonder if there's a slow network transfer maybe
14:50 karolherbst: maybe
14:50 MrCooper: did you keep an eye on it while it was running?
14:51 karolherbst: nope
15:29 karolherbst: MrCooper: any better idea of handling the armhf build? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/diffs?commit_id=d06bc63f923b07a793b87f158151ebe2c84e52f5
15:29 karolherbst: changes in arm_build.sh
15:31 MrCooper: no, looks good
15:33 karolherbst: but yeah.. the arm-1 runner is super fast :O
15:33 karolherbst: MrCooper: mabe ccache?
15:34 karolherbst: but that also would be odd causing those issues
15:34 MrCooper: your 86 minutes job ran on arm-1 as well
15:44 karolherbst: heh
15:44 karolherbst: now it took 19 minutes
15:53 karolherbst: seeems like I finally fixed it :) let's see if the full pipeline succeeds
16:31 daniels: arm-1 and arm-2 are identical hardware
16:46 karolherbst: yeah.. I guess something was up
16:46 karolherbst: but one job took over an hour and then another one took 19 minutes on the same machine
16:47 karolherbst: anyway, review of the CI bits are very welcomed: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580
16:47 karolherbst: still unsure about the tag..
16:47 karolherbst: *tags
18:01 alyssa:wonders why her shader-db won't multithread
18:33 airlied: MrCooper: have had arm rebuilds take 60 mins in the past, must ve a cache
18:35 anholt_: yeah, uncached arm is regularly over an hour. hopefully lava lab maintainers can do the per-arch split for arm_build soon like arm_test does.
18:35 anholt_: (or just move their stuff to arm_test)
20:02 airlied: tarceri: I don't see idr around, maybe you can slab an ack/rb on the glsl patch in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5679/
20:18 mattst88: he's boycotting IRC or something
20:19 airlied: I tagged him in the MR, but I'm not hopeful :-P
20:21 mattst88: I think he's failing at gitlab like I am
20:21 mattst88: in that there's not a way to have gitlab send you mail for things you've participated in *and* in things where you're mentioned
20:23 airlied: wierd, I just firehose gitlab into gmail, so I don't see anything for me at all, which is unfortunate, but it's how I deal with everything :-P
20:24 mattst88: yeah, that seems to be the only solution, which sucks more than a little
20:24 anholt_: mattst88: I feel like I get mail for things I've participated in for the rest of the discussion, and a single mail for being mentioned. is that not the result you want?
20:25 mattst88: anholt_: that is what I want, yeah. maybe gitlab grew support for that since we began using it?
20:25 mattst88:checks settings
20:26 mattst88: I'll review some MRs and see if I get mail
20:27 dj-death: mattst88: odd, I get emails for were I'm mentioned and stuff I follow too
20:27 mattst88: cool, okay
20:27 danvet: I think there's a default setting for how much spam you want
20:28 anholt_: mattst88: as far as I can tell, this is default behavior. https://gitlab.freedektop.org/help/user/profile/notifications talks about participation notifications
20:29 danvet: mattst88, https://gitlab.freedesktop.org/profile/notifications <- set "global notification level" to "participate"
20:29 danvet: then adjust per project
20:30 danvet: oh anholt was faster
20:30 mattst88: okay, thanks
20:31 danvet: and you get fairly useful&hierarchical headers for filtering in the mails
20:32 mattst88: so is "Participate" a superset of "On mention"?
20:32 danvet: yup
20:32 danvet: watch is even more
20:33 danvet: ui is a bit crap here
20:33 danvet: also on the project page it's the bell icon drop-down
20:33 mattst88: okay, great, so that is definitely what I want
20:34 danvet: I took me a while to find that thing :-/
20:35 jekstrand:sets gitlab to the default and it's fine
20:44 karolherbst: somebody willing to review a smaller gallium change? curro maybe as it involves clover as well? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4580/diffs?commit_id=a15388a2d3f5eae98632c17512c7942e796bfdb9
20:52 airlied: oh man piglit qbo test excepts little endian 64-bit behaviour
20:52 karolherbst: airlied: sounds like you are having fun
20:54 airlied:would hate to be trying to ever get conformant GL on big-endian
20:54 karolherbst: airlied: technically with nouveau that should be possible :p just details not working out
20:55 airlied: I don't think it's even possible with a hw device anymore
20:55 karolherbst: nvidia GPUs have a hardware switch for that
20:55 airlied: no they don't
20:56 airlied: they have a hw switch for a few corner cases
20:56 karolherbst: well.. not "hardware" but there is a mmio reg to flip it
20:56 airlied: but nobody can answer the what endianness is SSBO data question
20:56 airlied: I expect for a hw device you just want to hard boundary the dveice to be LE and the CPU to BE and deal with the pain
20:56 airlied: having a device go into a half BE mode is painful
20:56 karolherbst: well, we flip it over for nouveau
20:57 karolherbst: and it works okayish
20:57 airlied: I also don't htink it works on newer gpus
20:57 airlied: they at least don't test it
20:57 karolherbst: correct, on newer gpus it doesn't exist afaik
20:57 karolherbst: but up to pascal you are fine
20:57 karolherbst: just some details not working out so well
20:57 karolherbst: ...
20:57 karolherbst: but could also be that some mesa code is just broken
20:58 airlied: there's a lot of broken details
20:58 airlied: I just wanted to at least get mesa back to where it was a couple of releases ago :-P
20:58 karolherbst: true
20:58 karolherbst: yeah, I think there are tons of regressions as nobody really cares about BE anyway :p
20:59 airlied: I've gotten most of the recent ones, but I expect the pain will be endless
21:00 karolherbst: I think it all started to crumble when imirkin lost his PPC machine :p
21:00 airlied: like it's hard to answer questions like should 64-bit qbo results be big or little endian
21:00 karolherbst: yeah.. no clue
21:01 airlied: if you feed the qbo back into a shader then clearly it needs to be the same as the "gpu" side
21:01 karolherbst: whatever the spec says :p
21:01 airlied: but if you map it from the CPU it's just a buffer mapping
21:01 airlied: the spec doesn't say
21:01 airlied: since it doesn't encode 64-bit values
21:01 karolherbst: ehh
21:01 karolherbst: annoying
21:01 airlied: and maybe it's undefined behaviour to access a 64-bit via 32-bit
21:01 karolherbst: I don't know how much of the GPU gets to be BE, maybe it's just limited to the mmio space, maybe more.. dunno
21:01 airlied: but then we don't always have uint64_t support
21:01 karolherbst: never cared as much
21:02 karolherbst: yeah..
21:02 karolherbst: I'd say the driver needs to convert it to whatever the GPU supports and make everything native to the CPU
21:02 karolherbst: because you can't expect applications to care
21:02 airlied: but it's a buffer where the driver isn't involved
21:02 airlied: the hw writes it to the buffer, the hw reads it or the cpu maps the buffer and reads it
21:02 karolherbst: ehhh.. right :/
21:03 karolherbst: doing dirty page fault tricks to solve it?
21:03 airlied: don't even think you can
21:03 danvet: nothing ever got better with dirty page fault tricks
21:03 airlied: since you need to know the format of the data
21:03 airlied: if you have a buffer with qbo writes a uint64_t, uint32_t, uint32_t to you don't know the difference
21:03 karolherbst: mhhh
21:03 karolherbst: don't support it when the hw doesn't then?
21:04 airlied: oh it's even a problem for llvmpipe, since I have to fix tests to be sane
21:04 airlied: the hw can't support this either
21:04 airlied: since it doesn't know
21:04 karolherbst: well, it could just do be stuff
21:04 airlied: oh if you had a fully be gpu
21:04 karolherbst: right :p
21:05 karolherbst: maybe there is a magic bit which needs to be flipped on certain hw
21:05 karolherbst: who knows
21:05 airlied:wondesr will some pirsit makes one
21:05 airlied: purist
21:05 airlied: I don't think you can flip hw like that
21:05 airlied: like CPUs can do it
21:05 karolherbst: we also don't support be with volta+ in nouveau anymore as the flip seems to be gone
21:05 karolherbst: so...
21:06 karolherbst: yeah.... maybe
21:06 airlied: the nvidia flip afaik doesn't make the GPU operate in BE mode
21:06 karolherbst: I really don't know what the GPU can flip
21:06 airlied: it just changes some of the programming interfaces
21:06 karolherbst: yeah.. probably only mmio and the command submission stuff
21:07 karolherbst: but who knows, maybe there are more magic flips
21:07 airlied: which doesn't really help for anywhere you have shared mappings
21:07 karolherbst: imirkin probably knows more about it
21:07 airlied: and nvidia only did it for apple back then
21:07 karolherbst: yeah.. I think it got worse over the years
21:09 danvet: https://www.youtube.com/watch?v=WnqXHs_tGR4
21:09 danvet: called it 5 years ago
21:09 danvet: just give up :-)
21:09 karolherbst: :p
21:10 karolherbst: I think we only have a single BE check in nouveaus code though
21:10 karolherbst: maybe we have a few more.. but last time I checked there wasn't much
21:10 airlied: I think I'll just try and leep llvmpipe from getting worse, not sure about making it better :-P
21:11 karolherbst: ohh.. we have a few things indeed
21:11 karolherbst: oh well
21:11 karolherbst: like 10
21:11 karolherbst: fun
21:11 karolherbst: ohh.. just flipping some flips around
21:12 danvet: https://youtu.be/WnqXHs_tGR4?t=1674 actually right timestamp
21:12 airlied: I don't think having working BE GPU support is really tractable, it's an endless game of whack a mole
21:12 airlied:hopes nobody at IBM Z series has plugged a GPU into an s390 :-P
21:13 karolherbst: airlied: yeah well, I think I have bad news for you :p
21:22 airlied: ernstp: I thought I'd have pushed it to some key servers
21:24 mattst88: meson-windows seems to be failing: https://gitlab.freedesktop.org/jbeich/mesa/-/jobs/3369459
21:24 mattst88: no merging patches for me today
21:24 karolherbst: network issues
21:24 karolherbst: "error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)"
21:25 karolherbst: no idea, maybe try again?
21:27 mattst88: I saw it on two different MRs, so I think it's more than just a transient failure
21:31 imirkin: airlied: fwiw the nvidia "flip" basically tells it to interpret fifo commands in the other endian. and mmio reads/writes get auto-swapped (separate bits for these, but whatever)
21:31 imirkin: airlied: however when you're uploading I8 data via the fifo, what happens. or I16 data.
21:31 imirkin: very sad.
21:31 imirkin: not to mention whether you want to make "GART" data be BE or LE
21:31 imirkin: i could never fully wrap my mind around it
21:31 imirkin: esp since i never had precise info on what the GPU did at various points
21:32 imirkin: some of those commands had "endianness overrides" so that you could tell it which datatype it was
21:32 imirkin: but not all, and it wasn't docuented for the gens i was interested in
21:33 imirkin: and obviously GL 4.3+ things become completely intractable (ssbo, etc)
21:33 imirkin: but my focus was a FX 5200, so that didn't come up :)
21:34 airlied: yeah once you get to GL4.3 etc I don't see how you can do things without application awareness
22:27 daniels: mattst88: yeah, alatiera is looking into why it's broken and trying to fix it last I heard
22:27 daniels: mattst88: I'm not long off bed but feel free to just bounce it straight back out of CI if it's still problematic
22:28 mattst88: okay, thanks
22:28 mattst88: I reassigned some MRs and they succeeded, so I think it /is/ some kind of transient failure despite my earlier statement
22:29 alatiera:didn't had much luck earlier today, have to wait for tmr
22:29 alatiera: I suggest pinning windows job to the packet runner if ti gets too bad
22:29 alatiera:is going to go to bed soon as well
22:33 daniels: alatiera: wish we did have a packet runner
22:33 daniels: mattst88: yeah, it's not failing 100% of jobs, just ... way too many