05:31imirkin: where might the arguments of nir_intrinsic_load_ssbo be documented?
07:11MrCooper: anholt__ jekstrand: actually it's kind of the opposite of missing needs:, and there was already a fix pending: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5802
07:12MrCooper: tomeu: can you land the first commit of that, so people don't waste more time on this?
07:22tomeu: MrCooper: ok, it's coming
07:51airlied_: danvet: indefinite
08:01danvet: airlied_, ?
08:06danvet: ah found it
08:08MrCooper: tomeu: arm_build still needs to be added to needs: of the .lava-test:* templates though
09:11MrCooper: eric_engestrom: FYI, the CI pipeline has been red for a while on 20.1 — that happens when it's not gating :)
09:19pendingchaos: imirkin: nir_intrinsics.py (search for 'load("ssbo",')
09:29tomeu: MrCooper: ok, checking
09:38tomeu: MrCooper: what I don't understand is why arm_build needs to be an explicit dependency of the lava-test jobs, if they already depend indirectly through kernel+rootfs_*
09:38MrCooper: because dependencies aren't handled transitively
09:39MrCooper: try triggering the arm_build job and then cancelling it
09:39tomeu: that may have changed recently?
09:39MrCooper: nope, always been like this
09:39tomeu: yeah, tried that and the kernel+rootfs_* were skipped
09:39tomeu: and the panfrost jobs didn't start
09:39tomeu: see https://gitlab.freedesktop.org/tomeu/mesa/-/pipelines/173978
09:42MrCooper: hmm, maybe they did fix that then?
09:43MrCooper: that would allow slimming down the needs: quite a bit :)
09:44tomeu: looks like that to me
09:46MrCooper: indeed, looks like it: https://gitlab.com/gitlab-org/gitlab/-/issues/198570
09:48MrCooper: or https://gitlab.com/gitlab-org/gitlab/-/issues/31526 , looks like this was fixed in 12.8 already
09:48MrCooper: tomeu: do you want to slim down all the needs: ?
10:09tomeu: not now, but I will come back to this at some point later and can look at it if nobody has yet
10:14MrCooper: sounds good
10:28xuxing: Do you have any ideas why some window manager Render from top -> bottom? I under stand that the painter algorithm requires Paints from bottom to top.
10:37MrCooper: tomeu: BTW, should .gitlab-ci/container/lava_arm.sh try copying the minio cache from mesa/mesa before building it from scratch?
10:49MrCooper: tomeu: that might avoid spurious failures due to VK-GL-CTS fetching stuff from sourceforge.net, not to mention saving CI resources
10:50tomeu: MrCooper: sorry, copying which cache?
10:51MrCooper: lots of people are hitting failures like https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/3505066 , but the files should already exist in minio under mesa/mesa/?
10:55tomeu: I had no idea we were uploading temp build files to minio
10:55tomeu: thought it was "just" the git repo
10:59MrCooper: err, you added that yourself :)
11:00MrCooper: in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515
11:02MrCooper:→ lunch, bbl
11:18xuxing: Any one know why XRenderComposite, composites from top to bottom?
11:33FireBurn: So after the issues with GCC 10.1 & LTO I switched to using Clang & LTO but I think I've stumbled upon a memory leak, I'm compiling mesa with valgrand enabled but I was wondering if there were any instructions on how to use it with mes
11:38karolherbst: FireBurn: use libasan
11:38karolherbst: compile with -Db_sanitize=address
11:39FireBurn: Is it just mesa or libdrm too?
11:39karolherbst: I think it's a meson feature actually to handle all the flags
11:39karolherbst: but you can always preload libasan
11:47nroberts: I tried to test vkrunner after looking janesma’s MR but now it gets a double-free error while destroying the vulkan context, and if I run it with valgrind then valgrind crashes 😣
11:48nroberts: VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
11:48karolherbst: yeah, don't use valgrind :p
11:48nroberts: “valgrind: the 'impossible' happened:”
11:48nroberts: oh, is it a known problem with Mesa?
11:49karolherbst: the annoying thing about valgrind is, that just combining it with gdb makes a big mess and ends in a huge waste of time :p
11:49karolherbst: no, valgrind is just annoying
11:49karolherbst: applications are super slow
11:49karolherbst: races don't occur
11:49nroberts: ah, right
11:50karolherbst: and I still have to find the case where libasan failed but valgrind succeeded
11:50nroberts: it has saved me from lots of silly mistakes on the past, so I won’t write it off completely yet :)
11:50karolherbst: sure, but libasan is just better to work with :p
11:52mslusarz: nroberts: Valgrind crashing like that usually means the application is corrupting Valgrind state - IOW application is buggy as hell
11:52nroberts: ok, great 😬
11:58dj-death: what NIR lowering pass is turning derefs of variables into load/store instructions?
12:00nroberts: dj-death, nir_lower_io ?
12:05dj-death: nroberts: doesn't seem to deal with arrays
12:07dj-death: maybe that's nir_lower_explicit_io()
12:07nroberts: dj-death, the I/O are usually split up to temporary variables in nir_lower_io_to_temporaries so I guess arrays would all have constant indices
12:08nroberts: then maybe nir_lower_io_arrays_to_elements splits them up to regular slot writes
12:08nroberts: (well, I don’t know what iris/i965 does, but at least v3d does the temporaries)
12:08dj-death: that's for anv actually
12:09dj-death: a few things escape me
12:09dj-death: like it seems you can build infinitely complex structures in UBOs or push constants
12:10dj-death: and I can't seem to find where the lowering of accesses to those structs happens
12:11karolherbst: dj-death: lower_io
12:11karolherbst: you usually have a chain of derefs and lower_io translates those to offsets
12:13dj-death: karolherbst: that's limited to some types of variables right?
12:13dj-death: karolherbst: like it won't touch ubo/ssbo
12:13karolherbst: why wouldn't it?
12:16dj-death: because I'm missing this commit : https://gitlab.freedesktop.org/mesa/mesa/-/commit/be96b069ad4e41f9d440d04b5dbbffe599774473
12:17dj-death: actually it's just making it clearer
12:17dj-death: that lower_io() is not allowed on ubo/ssbo
12:18tomeu: MrCooper: but I'm uploading the built stuff, not the different projects that are needed to build it
12:20karolherbst: dj-death: now I am wondering if that breaks nouveau...
12:21karolherbst: but we still have eg nir_lower_explicit_io to deal with all other things
12:22MrCooper: tomeu: the problem is the same thing is rebuilt in each forked project, when it could be fetched from mesa/mesa/
12:22tomeu: oh, you are referring to the namespace
12:23tomeu: yeah, for container images we share the same images
12:23tomeu: not sure what was daniels thought when he enabled the bucket per-namespace
12:23MrCooper: actually it would probably be better to just try fetching from mesa/mesa/ first, no need to even copy to the forked namespace
12:24karolherbst: dj-death: ohh.. yeah, explicit_io is now called so... that's the pass to handle the other types
12:24karolherbst: for me it's all the same :p
12:25dj-death: okay, thanks
12:25karolherbst: but I am wondering if ubo are missed somewhere.. mhh
12:25karolherbst: dj-death: gl_nir_lower_buffers
12:26karolherbst: for ubos and ssbos
12:27MrCooper: tomeu: upload of newly-built artifacts does need to be restricted to the local namespace, otherwise forked projects could mess with the main project's artifacts
12:28tomeu: makes sense
12:28karolherbst: but that does something slightly different.. anyway
12:30ElBarto: emersion: https://reviews.freebsd.org/D25598
12:33emersion: do you have an image produced by this available somewhere, so that we can try playing with it?
12:34ElBarto: yeah, give me a minute to put it somewhere
12:36ElBarto: I'll do more tests later, this was done quickly as a side task when stuff where compiling on other projects :)
13:28imirkin: pendingchaos: aha, thanks. i foolishly searched for load_ssbo
13:31zmike_: do we have any in-tree util functions for performing bitwise operations? I only saw basic inc/dec in u_atomic.h
13:34imirkin: zmike_: like | and & ? those are built-ins in C...
13:35zmike_: that's guaranteed to be atomic?
13:35imirkin: oh. no.
13:37zmike_: oh, sorry, I left that out of my original question
13:37zmike_: which was somehow the most important part...
14:03xuxing: Hi，in the indirect mode, the render target for PloyPoint is frame buffer?
14:03karolherbst: FireBurn|Home: I also hit a memory corruption bug now...
14:04imirkin: zmike_: so gcc has stuff like __sync_fetch_and_or and so on
14:05imirkin: zmike_: https://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
14:05imirkin: easy enough to add some wrappers
14:05karolherbst: or just use _Atomic :p
14:05karolherbst: (if possible)
14:05imirkin: is that a c++ wrapper?
14:05imirkin: ah. fanciness.
14:06karolherbst: you can mark a field as atomic now :)
14:06imirkin: so if you have _Atomic a, b; a | b == atomic?
14:06karolherbst: or variable or something
14:06karolherbst: no, it's set at declaration type
14:06imirkin: or rather, a |= b is done atomically
14:06karolherbst: if a was declared as "_Atomic int a;" then yes
14:07karolherbst: there is also a atomic.h file or so... let's see how the file is called in C
14:07karolherbst: c++ has nice docs as always: https://en.cppreference.com/w/c/atomic
14:08karolherbst: sounds like to be the C11 function name
14:08imirkin: ah, so you can't do a |= b then?
14:08karolherbst: of course
14:08imirkin: have to use basically __sync_fetch_and_or? :)
14:09karolherbst: but the atomic functions are for fields you didn't declare as atomic :)
14:09imirkin: so it's just official names for those
14:09imirkin: oh. ok.
14:09karolherbst: yeah. I used the C11 stuff a while ago and looked at the assembly :)
14:09karolherbst: quite fun
14:10FireBurn|Home: Do you still see the memory issue if you revert the two patches?
14:10karolherbst: FireBurn|Home: which ones?
14:10FireBurn|Home: 18cb8f23222422c7fb9764362e659d15ec0b64eb & 12e18d9e7aded72dbfa513bce010e793f0d31cf9
14:11karolherbst: let me check...
14:11karolherbst: it's not nir related though
14:11karolherbst: or at least it also happens with TGSI
14:11karolherbst: GTF-GL43.gtf21.GLCoverage.CoverageGL21 triggers it for me
14:13TheRealJohnGalt: I have an indefinite shader compilation issue on a single application that ends up loading the entire system to a hang with https://gitlab.freedesktop.org/mesa/mesa/-/commit/12e18d9e7aded72dbfa513bce010e793f0d31cf9 . However it seems like it would be specifically related to the application from looking at this, and not a mesa issue?
14:13karolherbst: that commit really seems to have done it :p
14:13karolherbst: FireBurn: anyway, in my case it seems to be something else
14:15FireBurn: Let me know how you get on with bisecting
14:15karolherbst: first I am hoping the cts doesn't explode when turning on libasan :D
14:15zmike_: imirkin: yeah, I was looking at that, but then it seems u_atomic.h also supports solaris and msvc, which I can't test for
14:15zmike_: so I guess I'll do it another way
14:16karolherbst: ufff right
14:16karolherbst: we are still not at c11 in mesa :/
14:16karolherbst: I always forget that
14:16zmike_: it's only 2020
14:16zmike_: give it another 10-20 yeras
14:16karolherbst: we are at c++14 though :p
14:16karolherbst: c11 would be so nice...
14:17FireBurn: TheRealJohnGalt: You might want to create an issue for it, I was seeing some build issues with that commit too
14:19FireBurn: karolherbst 18cb8f23222422c7fb9764362e659d15ec0b64eb isn't NIR related
14:19FireBurn: Two differnt patches both giving me issues around the same time
14:19karolherbst: yeah.. but the commit before both of those are already broken. soo
14:20karolherbst: FireBurn: https://gist.githubusercontent.com/karolherbst/3f2da44a6037684289b6045313f2fe0e/raw/5d62b8144cf3f8d6bcf76eee0731e5984ec6cc80/gistfile1.txt
14:20imirkin: zmike_: i'd guess that compiling with solaris cc is broken anyways
14:20imirkin: zmike_: and msvc ... should be easy to track down the names
14:21TheRealJohnGalt: FireBurn: the build issues I ran into were from !5728, not !5683. The latter builds fine.
14:21zmike_: imirkin: eh, it's the difference of a single uint32_t on a struct, so for now I think I'll take the memory hit
14:21zmike_: can always optimize later
14:21TheRealJohnGalt: I think your issue is really the same.
14:21karolherbst: zmike_: bump the req to c11 and see who complains :p
14:22karolherbst: I'd really love to see all the c11 wrapper to vanish
14:29nroberts: if anyone is interested, I bisected the vkrunner crash down to this Mesa commit https://gitlab.freedesktop.org/mesa/mesa/commit/65d242ff5e57319c065c
14:30nroberts:glares at dj-death
14:36dj-death: nroberts: you using perf queries with vkrunner?
14:37nroberts: not knowlingly…
14:38dj-death: it's possible the ralloc context got screwed up somehow
14:40dj-death: nroberts: is there a backtrace/valgrind error to look into?
14:40pcercuei: How would I go with registering a new fourcc code? Is there an authority regulating this?
14:41nroberts: dj-death, I tried it with valgrind but it segfaults and says valgrind has hit an internal error
14:41nroberts: you could replicate it if you build vkrunner and run vkrunner examples/*.shader_test
14:41nroberts: I guess I should write this in an issue instead of IRC… :)
14:42nroberts: if you run the tests individually it works, but if you run them all it crashes
14:42nroberts: so I wonder if it is something to do with creating and destroying a vulkan context multiple times
14:43karolherbst: pepp: b6db703e0f007fbcf4389ec607ae4c3e8fc9ee0d causes memory corruption for me :/
14:43karolherbst: with GTF-GL43.gtf21.GLCoverage.CoverageGL21
14:44dj-death: nroberts: sounds like a ralloc issue then
14:44dj-death: nroberts: though we only recreate stuff at the instance level
14:45dj-death: nroberts: I suppose the recreate the instance multiple times then
14:45pepp: karolherbst: hmm... I'll take a look
14:45nroberts: dj-death, right, yeah, I think it will end up doing that
14:48karolherbst: pepp: doesn't happen with iris though :/
14:49dj-death: nroberts: debugging
14:50karolherbst: llvmpipe is also fine :/
14:50karolherbst: now that's annoying
14:57pepp: karolherbst: does https://gitlab.freedesktop.org/snippets/1095 help?
14:58karolherbst: pepp: it does
15:02pepp: karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5821
15:03Lyude: anyone have an 8k monitor who would be willing to send me a copy of it's edid?
15:08Vanfanel: Hi there. I am trying to create a cursor with gbm_bo_create(), then gbm_bo_write() to the created gbm_bo, then drmModeSetCursor() on the in-use CRTC and open drm fd. It "works", but even if I am creating an ARGB8888 cursor BO with gbm_bo_create(), all bits of each pixel seem to be ignored except the two last ones, which are used to AA(alpha) instead of BB(blue) as expected. Here is the small test
15:08Vanfanel: program I have done to illustrate the issue, this is the line where I set the bytes of the buffer: https://github.com/vanfanel/LBE_DOCS/blob/6ff44805110c18206dee9e8064253792756fea91/DRM_GBM_CURSOR-ONLY_TEST/main.c#L65
15:08Vanfanel: Any ideas on what could be going on?
15:09imirkin: Lyude: looks like https://git.linuxtv.org/edid-decode.git/tree/data/samsung-qp82r-8k-hdmi4 should do it?
15:10tomeu: MrCooper: here it is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5822
15:10imirkin: Lyude: and there are examples of a tiled monitor which presents an 8k resolution over 2 tiles in that dir
15:10Lyude: always forget that site exists
15:10imirkin: (dell-up3218k-dp1-tile0, etc)
15:13dj-death: nroberts: heh
15:13dj-death: nroberts: works fine here
15:13nroberts: ah, damn
15:13nroberts: ok, I guess I can try to do a bit more debugging here too
15:15dj-death: nroberts: I did find a uninitialized variable, but don't think it will cause you an issue
15:16nroberts: ok. thanks for looking into it anyway
15:42glennk: Vanfanel, memset takes a single byte as argument
15:46Vanfanel: glennk: oh my... then that's why the rest is ignored. Silly me, I had forgotten XD
15:46Vanfanel: glennk: thanks for your help, even if it was an stupid question
15:53MrCooper: dj-death nroberts: building Mesa with ASan enabled might give a clue
15:53MrCooper: though it might hit lots of unrelated issues first :)
15:58nroberts: right, yeah, worth a try. thanks
16:33eric_engestrom: MrCooper: I know the CI's been red on stable for a while, but it's not about gating; that wouldn't have changed anything
16:34MrCooper: by definition of "gating", it would have :)
16:34eric_engestrom: I mentioned that a few days ago, but the issue is that people don't `cc: mesa-stable` on CI enabling/disabling patches, leaving stable branches in old states
16:34eric_engestrom: no it wouldn't
16:35MrCooper: if it's gating, nothing can be merged unless it's green
16:35eric_engestrom: my point is: it's not the code that went bad and the ci catching it, it's the ci going bad and the code not working around it
16:35MrCooper: but since it's not gating, it inevitably turns red and redder sooner or later
16:36eric_engestrom: gating would only have prevented releases until devs backport the ci workarounds they forgot to cc:
16:37MrCooper: it means nothing breaking the CI can be backported
16:38eric_engestrom: the root issue is that the CI (as a tool) gets changed (eg. stuff goes down) and the CI (as config files) only gets updated on master, people almost never `cc: mesa-stable`
16:38eric_engestrom: leaving maintainers to either learn to ignore when jobs fail because the underlying machine is down (what I've been doing), or have to fix the configs themselves (I don't have time to do this)
16:39eric_engestrom: the third option is people using `Cc: mesa-stable` on all CI configuration changes
16:40karolherbst: can't we maintain the CI config files somewhere else?
16:41eric_engestrom: gitlab needs it to live in the branch that's being tested afaict
16:41karolherbst: would a git submodule pointing to a branch work? :p
16:42eric_engestrom: that's clever
16:42eric_engestrom: but I doubt it works
16:42eric_engestrom: (feel free to try it!)
16:42karolherbst: there is a way to set a submodule which points at a branch instead of a commit, but ... mhh, don't know how to set that up :D
16:42karolherbst: I did it once though
16:43eric_engestrom:assumes you can just manually edit the submodules config file and replace the commit sha with a branch name?
16:45imirkin: on occasion, people submit changes which fix tests
16:45imirkin: how would that work?
16:45imirkin: (given the exclusion files/etc)
16:46eric_engestrom: we'd need to re-organize the way we do the config files though; for starters the pass/fail/skip lists depend on the code, not the ci config
16:48eric_engestrom: actually no, they also depend on the CI config, specifically the version of the test repo we use...
16:48eric_engestrom: hmm, they are too tied together, I don't think it's realistic to split the CI config out
16:49eric_engestrom: consistent backports are the only solution I can see, but it relies on devs remembering to do it _every time_
16:49MrCooper: some kind of out-of-band mechanism for disabling certain jobs due to runner issues might be nice, but if CI was gating for the staging/stable branches as well, it shouldn't be that hard to find and backport those changes
16:49karolherbst: eric_engestrom: maybe we can have a gitlab bot checking for that or so
16:50MrCooper: though then there might be the reverse problem, jobs never getting re-enabled on stable branches once they're disabled :)
17:07pepp: MrCooper: maybe we could try disabling runners using instance level env var (https://docs.gitlab.com/ee/ci/variables/#instance-level-cicd-environment-variables) ?
17:11karolherbst: eric_engestrom: maybe we simply need a bot which opens the MR against the stable branches automatically and then we deal with the fallout ourselves...
17:11karolherbst: maybe that's the easiest solution
17:14daniels: we can easily split out YAML files, but we can't split the _whole_ config because someone will enable new tests on master and it'll suddenly and violently regress stable branches
17:14daniels: pepp: disabling runners just makes jobs time out, not succeed
17:15pepp: daniels: I meant not creating disabled jobs (something like "rules: if: '$MESA_DISABLED_JOBS =~ /job_name/" when: never)
17:15daniels: pepp: right, gotcha - was just about to suggest the same thing, but with the variables coming from a YAML file in master
17:15daniels: (because then we can CI the changes to those variables)
17:15daniels: and have an audit log of them being enabled/disabled
17:16pepp: daniels: so CI on stable branch would import the YAML from master branch?
17:17daniels: the list of disabled jobs, yeah
17:17daniels: then master just has a list of 'variables: MESA_$JOBNAME_DISABLED: true'
17:19imirkin: pepp: how sure are you about https://cgit.freedesktop.org/mesa/mesa/commit/?id=49d35f3d882bd0f4418a1ce056344b8f06bd75dd ? i think that gl_ViewportMask is only ever supposed to be an output, but it will now appear as an input for the tess/gs stages
17:19imirkin: pepp: also curiously the NV_viewport_array2 spec defines viewport mask as just a plain "out highp int gl_ViewportMask" for gs, not as part of the gl_PerVertex out.
17:21imirkin: [but it *is* included in out gl_PerVertex to tcs/tes - odd.]
17:22pepp: imirkin: well.. I think it's correct but I'm not an expert so if you think it's wrong I can take another look at this change
17:23imirkin: pepp: https://www.khronos.org/registry/OpenGL/extensions/NV/NV_viewport_array2.txt -- note that it doesn't talk about adding anything to gl_in
17:23imirkin: whereas now it goes through add_varying, which for TCS/TES/GS will get added to the input
17:24imirkin: also look at Issue 4 in the ext
17:24imirkin: which says that if gl_ViewportIndex input is enabled via this ext, then it should also not be an input
17:25imirkin: er. if gl_ViewprotIndex output is enabled via this ext ....
17:39pepp: imirkin: so what would be needed is a way to add these variables to the per_vertex_out object but without adding them to the input fields. Is that correct?
17:40imirkin: pepp: yes. and check what some of the other exts say, since they seem to disagree
17:41imirkin: pepp: and in GS, it should actually not be part of gl_PerVertex at all - weird
17:56imirkin: pepp: looks like ARB_shader_viewport_layer_array also doesn't add them to the inputs
17:57imirkin: pepp: oh wait, you're just doing the change for VS, right?
17:57imirkin: then my comments are wrong :)
17:58imirkin: pepp: yeah, sorry, you're only changing the VS setup. That all sounds right then, sorry!
18:27zmike: jekstrand (and other compiler experts): if I get a nir_variable for a ubo in shader->uniforms and data.location is -1, where should I be reading to figure out how/why this is happening?
18:30pepp: imirkin: no problem. Good to know it's correct :)
18:31jekstrand: zmike: Uh.... UBO variables generally shouldn't be trusted.
18:31jekstrand: zmike: Not sure that's a good thing but it is a thing.
18:31jekstrand: tarceri or kusma might know more
18:32zmike: they seem to be reliable for every piglit test I've seen except this one
18:32jekstrand: I think there has been some attempt to make them trustworthy
18:32jekstrand: But I don't know how they're supposed to work
18:33kusma: Yeah, we weren't able to fix the vars for the d3d12 driver either
18:36zmike: odd that it's been working for me thus far then
18:36zmike: are the piglit ubo tests not extensive enough to catch more problem cases?
18:38FrankyCyborg: hello! I have some strange issue, getting the build process of mesa to finish the initial configuration.. is there some general mesa discussion/support channel?
18:45imirkin: FrankyCyborg: you've found it
18:54FrankyCyborg: before I bother you, I might try something to solve this.. could be that some other channel already gave a useful hint...
19:03nanonyme: Btw, is the intent to keep the --prefer-iris=true opion default now that it's known that it's an actively dangerous combination with older intel ddx?
19:03nanonyme: Option even
19:06nanonyme: Uhm, I mean default in Mesa
19:07imirkin: i don't think anyone cares
19:07imirkin: afaik most people at intel will tell you to not use the intel ddx but rather use modesetting.
19:12nanonyme: Hm, so it's a configuration that's allowed but not really supported? That's a pity but I guess can't do much better than that without a time machine.
19:14airlied_: karolherbst: did you figutr out the gtf test memory corruption?
19:14karolherbst: airlied_: yes
19:14karolherbst: airlied_: did you hit it as well?
19:14airlied_: cool, i saw it earlier in the week, but been on holidays
19:15karolherbst: airlied_: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5821
19:16airlied_: karolherbst: btw i started fix8ng asan in cts
19:17airlied_: some of the delete vs new in there
19:17karolherbst: ahh, cool
19:17karolherbst: so far I didn't run into issues though
19:17imirkin: nanonyme: i don't speak on behalf ot the intel team, but that's my observation as an unbiased bystander
19:18imirkin: i did prefer the intel ddx myself, but found that it managed to leak oodles of memory over time
19:24nanonyme: imirkin, sure. I get it that it's not the preferred option. Apparently intel ddx has features that modesetting does not though and some users prefer it as a result
19:24imirkin: yeah, it was way faster
19:24imirkin: but uptime is more important to me
19:24imirkin: and X would end up taking up all available memory
19:24nanonyme: imirkin, TearFree is the thing the user mentioned
19:25imirkin: yeah, it has that, but it's not important to me ;)
19:25nanonyme: Let me guess. You have Wayland? :)
19:25imirkin: i just don't give a shit about tearing
19:25nanonyme: Ah, okay. That works too
19:45zmike: mareko: do I need any other changes on that piglit MR?
19:48zmike: jekstrand: just to follow up, it seems you were right and there's been (lots of) solid work in 2020 to improve ubo variable reliability, which explains why things have generally been working for me
19:49airlied_: karolherbst: https://paste.centos.org/view/10f085f7 were all the CTS asan fixes I had
19:49karolherbst: ohh, cool
19:49zmike: my issue was related to a bug in recent-ish patches there, so I think it's all solved now
19:49karolherbst: airlied_: that's based on master, isn't it?
19:52airlied_: karolherbst: whatever master was when I was hacking on it
20:49tomeu: anholt__: it's only cheza what uses the bare metal stuff, right?
20:49anholt__: cheza, db410c, db820c
20:51anholt__: (and there's WIP etnaviv)
20:51anholt__: but that hasn't landed yet
20:51tomeu: ok, I thought it had its own scripts for building the kernel and rootfs
20:52anholt__: I tried splitting them out, and it wasn't great.
20:52tomeu: looking at it now, but I don't think I will be able to fix it tonight
20:52anholt__: (I've could dig up a wip branch if you're interested)
20:52tomeu: well, I'm just re-adding the stuff I removed
20:53tomeu: just takes a good while to build
20:55anholt__: yeah, these builds are rough. I started looking into sccache at home, and it looks really interesting ("all jobs get to share the CPUs for compiling, and ccache is global"), but i haven't managed to stand it up even locally yet.
21:06tomeu: having them in their own jobs helps quite a bit
21:50jekstrand: karolherbst (or anyone else who hacks on CL): What flags do you have to pass to clang to get it to consume CLC?
21:50jekstrand: Playing with spirv-llvm-translator
21:50jekstrand: Sachiel: ^^
21:55karolherbst: jekstrand: uhm... wait
21:56karolherbst: clang -emit-llvm -target spir64-unknown-unknown -cl-std=CL1.1 -include opencl-c.h -o $out_file -c
21:56jekstrand: karolherbst: I'm guessing the -cl-std is what we're missing. That sounds important. :-)
21:56karolherbst: and then you can use the out file with llvm-spirv
21:56jekstrand: karolherbst: Where does this opencl-c.h come from?
21:57jenatali: I think you might also need "-x cl" unless the file ends in .cl
21:57jenatali: opencl-c.h is included with clang
21:57Sachiel: -target is the only thing I'm not using, let's see if it magically helps
21:57jekstrand: Ok, cool.
21:57karolherbst: that's clang opencl header stuff
21:57karolherbst: it's interesting stuff though :)
21:57karolherbst: I learned from there on how to do function overloading :D
21:57jenatali: Sachiel: I was shocked to see that you can actually compile OpenCL source to x86 machine code...
21:57karolherbst: jenatali: :D
21:57karolherbst: but does it surprise you?
21:58jenatali: I mean... it makes sense if I think about it long enough
21:58jenatali: I just expected it to explode
21:58karolherbst: well that was the whole point of llvm, no?
21:58jenatali: Heh, fair
21:58karolherbst: compile C++ to gpu binaries, why not? :p
21:58karolherbst: and other fancy stuff
22:00karolherbst: actually, would be fun to write up C to spirv :D
22:00Sachiel: thanks, that helped
22:18jekstrand: jenatali: I'm pretty sure Intel ships an OpenCL driver that compiles to crazy vectorized AVX512 or something like that.
22:18jekstrand: Or at least we did in the past
22:18jenatali: Yeah I've seen references to that floating around
22:18jenatali: I don't know that it still ships though
22:18jekstrand: I have no idea
22:18jekstrand: I just know it was a thing
22:21imirkin: not to mention krh's thing...
22:22jenatali: Krh's thing?
22:22imirkin: he had some intel gen -> avx interpreter/recompiler
22:24jekstrand: Back when he worked for Intel, he wrote his own simulator for Gen8 graphics
22:25jekstrand: It transpiled Gen ISA to AVX2
22:25jekstrand: Never got it complete. I don't remember if he ever implemented control-flow or not.
22:26jekstrand: But it worked well enough for some fun little demos and it was pretty fast
22:31pcercuei: Hi, how would I go with registering a new fourcc code? Is there an authority regulating this?
22:33imirkin: in the kernel, we just pick names we like
22:33imirkin: i'm not sure there's an official authority... just convention i guess
22:33imirkin: but maybe there are official codes. dunno
22:33kisak: looks like there's a fourcc.org, but I don't know anything about it
22:34ccr: nobody expects the spanish fourcc inquisition
22:34pcercuei: I guess I can just send a PR and see what's the feedback.
22:34imirkin: that was monty python, right?
23:21imirkin: is there an ext which allows dynamically uniform indexing into ssbo interface arrays?
23:21imirkin: (in GLES)
23:21imirkin: OES_gpu_shader5 only allows constant integral expressions for ssbo/image arrays
23:43alyssa: do all tilers struggle with urxvt + glamor?
23:44alyssa: It looks like, absent a compositor at least, it's flushing every single line. Which means scrolling is extremely slow
23:44alyssa: It's not clear to me if this is panfrost's fault or glamor's
23:46alyssa: I'm thinking X11 isn't so great, someone should rewrite it
23:46alyssa: call it... I dunno, Wayland maybe?
23:51karolherbst: alyssa: but you know, then everybody complains they need to port over and stuff :p
23:51karolherbst: and then everybody procrastinates it for 10 years
23:53alyssa: karolherbst: f'naaaa
23:55alyssa: it looks like glFlush is being called a -lot-
23:55alyssa: so I'd say glamors?
23:55alyssa: sure we could try to make flushing faster but uh
23:56airlied: well I think it's just X11 sucks
23:56airlied: since it's immediate rendering
23:56alyssa: airlied: so nothing to be done then? :|
23:57airlied: use a compositor :-P
23:57alyssa: so [wontfix] the issue? :P