00:17karolherbst: Lyude: you can also just do -v2
00:58dviola: I could send a v2 but I don't want to cause any distraction, Gerd is the author of the patch and he sent his v2 here: https://lore.kernel.org/patchwork/patch/1290000/
01:06dviola: I tested his patch yesterday and just wanted to get my Tested-by in it :)
01:11airlied: dviola: you can just replyh on the list with a Tested-by lien
01:16dviola: airlied: good to know, thanks
01:44airlied: more ttm cleanups away!
02:08airlied: mripard: I pushed rc2 to drm-next, can you resend the PR?
02:08airlied: patchwork didn't seem to find it
08:15narmstrong: sravn_: like @pinchartl I'm not really fan of reviewing this set of patches, I'll really prefer having a clean and squashed version
08:30pq: Does anyone run IGT against VKMS on a big-endian machine?
08:30pq: Some CI maybe?
08:38pq: Lyude, +1 from me for min_bpc - not that I have a user (yet) but I can imagine needing it.
08:41pq: Lyude, if you are interested in what userspace might want for HDR, we have lots of talk at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
08:41pq: Lyude, and https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/3
08:50mripard: airlied: I will
12:45Yuti: In case of new model of bridge drivers, can we use this drm_set_link_status_property api as it is a connector property?
12:47emersion: i don't think i quite understand the question, Yuti
12:51Yuti: new model of bridge driver, bridge driver will not create connector. so if link training fails how it is suppose to use this api?
12:51emersion: ah, ok
12:51emersion: (no idea)
13:55tomba: pinchartl: any idea about the question from Yuti above? Is it ok to just dig up the connector from the state?
13:57pinchartl: Yuti: good question
13:57tomba: in theory there could be two bridges in the chain, one says the link is ok, one says it's bad.
13:58pinchartl: if we want to support that we'll need to expose bridges to userspace
13:58pinchartl: which I don't think is a good idea for as long as it can be avoided :-)
13:59pinchartl: ideally the bridge should just say "my output link is bad"
13:59pinchartl: and the framework should connect that to the appropriate connector
13:59pinchartl: but we don't have any such infrastructure in place
13:59pinchartl: so for now I think it's ok to dig up the connector for this
16:13sravn_: narmstrong: Agree on the review part - the full patch-set is unreviewable. I already asked about a submissions in ~4 filebased patches
16:14daniels: tomba: if any bridge is bad, the link as a whole is bad
16:14daniels: the effect to userspace is the same - it needs to do a fresh modeset on that connector
16:15tomba: daniels: yes. but if bridge a first sets the connector as bad, but then the second bridge sets the connector as good, overwriting the bad value.
16:16daniels: right, hence with multiple bridges you'd have to store the state per-bridge and collect that into the connector
16:19vsyrjala: the core sets it to good at the start. the driver should only ever have to set it to bad
16:22tomba: who resets it back to good? isn't that the driver's job when it sees the link is now ok? or did you mean that it's set to good at the start of a modeset?
16:24tomba: (well, I can read the code myself too tomorrow =)
16:26emersion: user-space resets it to good
16:27vsyrjala: via atomic ioctl it's userspace's job. for legacy modeset the core does it automagically iirc
17:02jekstrand: bbrezillon: I think I addressed your comments from Monday re: alignments
17:03jekstrand: karolherbst, jenatali, cmarcelo: You may also want to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6472
17:20yshui: I got a __gnu_cxx::recursive_init_error in radeonsi_dri.so
17:21yshui: looks like there 2 threads calling ac_create_passmgr at the same time
17:22yshui: stack trace: https://dpaste.com/AGS6T7HYB
17:50yshui: ok, this is pretty annoying.
17:54jenatali: karolherbst: For CLOn12, we're converting the libclc blob into a header and #include-ing it into the resulting DLL we build, which makes libclc a build-time dependency (and a hard one) rather than a runtime dependency, like it is right now for Clover
17:55jenatali: Thoughts on whether we should leave Clover's dependency as runtime or should we make it build-time as well?
17:55yshui: looks like this bug is already reported: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3199
17:55karolherbst: jenatali: I'd keep it a runtime dependency I think...
17:56karolherbst: otherwise you run into the issue where you have to rebuild mesa when updating libclc
17:56karolherbst: but mhhh..
17:56karolherbst: I mean, what would be the benefit of converting it into a build time dependency anyway?
17:57mdnavare: vsyrjala: hwentlan: on vrr enabled crtc property, whenever IGT or userspace changes i from disable to enable or vice versa there would be a full modeset in the driver right?
17:58mdnavare: vsyrjala: So when it changes from enable to disable, thats when the vrr disable should get triggered?
18:02hwentlan: mdnavare: i don't expect this to require a full modeset
18:04jenatali: karolherbst: Well, for us, we distribute binaries rather than source :P
18:04jenatali: For you, I don't really know, just wanted to see if you had an opinion :)
18:04karolherbst: yeah, don't do build time dependencies except you have a very very very very good reason not to
18:24mdnavare: hwentlan: but only we do a full modeset, we will set the crtc state variables for VRR when say it changes from disabled to enabled right? Then ones everthing is set it can ust work with set VRR parameters
18:25mdnavare: hwentlan: Until now userspace sets the prop to disable, then again we would need to rewrite the registers in atomic commit to disable VRR ?
18:26mdnavare: hwentlan: Because in the kernel atomi check we have this condition I believe same as AMD: old_crtc_state->vrr.enabled == new_crtc_state->vrr.enabled then continue
18:28Lyude: j4ni: mind taking a look at the new version of https://patchwork.freedesktop.org/series/80540/ to see if you're happy with the naming changes?
18:33vsyrjala: Lyude: btw in case you're interested in handling downstream ports better: git://github.com/vsyrjala/linux.git dp_downstream_ports_5
18:33vsyrjala: haven't yet read through your patches to see what they do
18:44Lyude: vsyrjala: the patches mainly just move the downstream port handling code (along with sink count handling, and extended dprx caps) in i915 into shared helpers in drm, then use them in nouveau
18:46Lyude: vsyrjala: I like those patches :), feel free to cc any you want my review on. we could definitely use those in nouveau
19:23jekstrand: jenatali, karolherbst: Generally, runtime is better, yeah.
19:24jekstrand: The one thing that makes me think otherwise on this one, though, is that clc isn't loaded via standard linking paths like other dependencies so it does make things a bit weird
19:25jekstrand: How big is the SPIR-V blob?
19:25jekstrand: what if you zlib it?
19:26jekstrand: I wouldn't loose any sleep over embedding that, I don't think.
19:26jekstrand: But it's probably more "the Linux way" to dynamically load it.
19:27jenatali: Sure, sounds fine
19:33airlied: i had a 12mb version when it did shuffle
19:34airlied: we shoild make sure everything in libclc blob is used
19:35karolherbst: jenatali: we could have a build time option for it though
19:36jenatali: airlied: Yeah, I'm pretty sure we did an audit and we're only including things that're used
19:36jenatali: karolherbst: Seems like something good to add after the initial checkin, I think, if we expect runtime to be the "normal" way
19:37jekstrand: jenatali, karolherbst: So, is the plan going to be that if it can't runtime load CLC, you just don't get CL support for SPIR-V clover drivers/
19:37karolherbst: good question
19:37jekstrand: I think I'd rather that than carry around both paths
19:37jenatali: jekstrand: I suspect we'd want something a bit better than that - some kernels will fail to compile if they use functionality that's only available from libclc
19:38jekstrand: jenatali: Eventually, though, CLC is going to be required for conformance.
19:38airlied: jekstrand: yeah no lib no cl
19:38jekstrand: So we really want it to be a hard requirement by the time nouveau becomes close to conformant.
19:38jenatali: Seems reasonable
19:39karolherbst: yeah.. I guess that's fine
19:39jekstrand: The only question is if people think nouveau CL is useful enough right now to bother maintaining a non-CLC path. My gut reaction says, "no"."
19:39jenatali: You can get pretty far without the libclc functionality though. E.g. we were running some Photoshop workloads without it
19:39karolherbst: we just need to have a solution for the warnings we print I think?
19:39jenatali: karolherbst: The solution is to fix the translator to not emit the "groups" capability for the async stuff
19:40airlied: its a small bootstrap window of time
19:41airlied: karolherbst: the che repo will uave the bits soon
19:41karolherbst: okay, cool
19:42karolherbst: I just have the blob :D
19:44jenatali: Oh, something else that should probably be improved with libclc: NIR_PRINT becomes useless :)
19:58karolherbst: jenatali, jekstrand: btw, it kind of feels like that pushing for inclusion for libclc at this point doesn't really sound "right" as there are a couple of outstanding issues we should get resolved. Just wondering what would be the benefit of merging it earlier before sorting out the fma issue as well?
19:58karolherbst: daniels: ^^
19:59jenatali: karolherbst: We're looking to get upstream to more closely match what we've built in our downstream fork, so we can more easily rebase and get our stuff upstream
19:59karolherbst: yeah, I totally get this point, but that's not a good reason for rushing things
20:00jenatali: Sure, that's my only reason for pushing it sooner rather than later
20:00airlied: well you could just bring in the baseline stuff that doesn't hit the fma issue yet
20:00jekstrand: I think we have a chicken-and-egg problem.
20:00airlied: so we can avoid endless rebasing of the mangler and all that
20:01karolherbst: I mean... I think we could default to something
20:01karolherbst: I am not too worried about the fma issue
20:01jekstrand: We need to accelerate both haves of the CLC stuff. Landing something in Mesa seems like it would help motivate the rest.
20:01karolherbst: just all the other little ones we have besides it
20:01karolherbst: every issue which is related to conformance we can ignore at this point, that's totally fine
20:02karolherbst: but it's more of the warning stuff which makes clinfos output quite annoying
20:02karolherbst: or NIR_PRINt being useless
20:02karolherbst: or runtime crashes
20:02karolherbst: just the sum of it makes me worry we are rushing a bit too much here
20:03jenatali: Runtime crashes shouldn't happen, that's a bug :)
20:03karolherbst: right, and I only hit it when libclc wasn't there
20:03karolherbst: I think...
20:03karolherbst: but yeah..
20:03jenatali: I'm unfortunately not super familiar with the converter to make the fix to drop the "groups" capability from async ops... but I'd love if someone was willing to help with that
20:03karolherbst: most distribution might enable stuff and just stick with a libclc too old
20:03jenatali: As for NIR_PRINT, I'm not sure what to do about that
20:03karolherbst: jenatali: I could look into it
20:04karolherbst: no idea either :) but we can discuss it at least :p
20:04airlied: karolherbst: didstor will update libclc in their llvm updates
20:04karolherbst: airlied: right.. but that will take some time
20:04jenatali: karolherbst, airlied: I think we should at least have sane behavior when libclc isn't present at runtime
20:04karolherbst: but it's not about requiering libclc or not
20:04airlied: karolherbst: we have a few months before anyone will ship this
20:04karolherbst: it's just about throwing a sane error instead of crashing
20:04jenatali: Whether it's a well-behaved error, or compiling some kernels but not others
20:05jenatali: If we're not doing that, it's a bug and I/we should fix it
20:05airlied: it's not like we have a working opencl impl that apps will use yet :-P
20:05karolherbst: yeah.. I'd fail compiling kernels
20:05karolherbst: or fail creating the device
20:05karolherbst: airlied: what happened with the idea of compiling clc early?
20:05airlied: that was for CI only
20:05airlied: oh sorry
20:06airlied: not awake
20:06airlied: I thought it got loaded early
20:06airlied: which should be enough to fail device load
20:06karolherbst: I saw the spirv warnings a few times when running clinfo
20:06karolherbst: essentially.. it happens whenever you create a kernel
20:06karolherbst: airlied: yeah.. I can try to look into it
20:07karolherbst: or do you want to?
20:07airlied:is trapped in non-cl dungeon at the moment
20:07karolherbst: have fun
20:07jenatali: Not sure if that's better or worse :P
20:08yshui`: can someone help me with https://gitlab.freedesktop.org/mesa/mesa/-/issues/3199 ?
20:08karolherbst: I will update my local copy of the patches and see into which issues I run
20:08airlied: parallel simulatenous kernel graphics memory management and software vulkan dungeons
20:08jenatali: karolherbst: Bottom line, I'm not in a super rush to land the libclc changes to Mesa, though I do want to get the LLVM changes in
20:08yshui`: seems like this couldn't possibly happen...
20:08karolherbst: jenatali: yeah and I think getting the llvm stuff in first is more important
20:08airlied: jenatali: tom stellar is on leave for 8 weeks now :-P
20:08karolherbst: mesa has the shorter release cycle here :p
20:09jenatali: airlied: Oh no :(
20:09airlied: stellard (always forget the d)
20:09karolherbst: yshui`: do you have two copies of llvm inside the application?
20:10yshui`: karolherbst: highly unlikely, it's just a normal EGL+GL application. the only copy of llvm should be mesa's
20:10karolherbst: yshui`: what version of llvm are you using? your own or distribution provided?
20:11jenatali: karolherbst: FYI, I've got some changes to that series I need to make based on all the discussions we've been having -- specifically, dropping any patches related to __builtin handling. You'll need an updated libclc spv binary which has the noinline implementation of it then. I can send you one
20:11karolherbst: jenatali: okay, cool
20:11yshui`: karolherbst: distribution, archlinux
20:11yshui`: statically linked with mesa
20:11yshui`: i did build my own mesa though
20:13karolherbst: don't do that?
20:13karolherbst: so you set shared-llvm=false?
20:14karolherbst: (or disabled or whatever_
20:14yshui`: hmm, so that's something one should never do?
20:14karolherbst: I say stick to whatever your distribution is doing
20:14yshui`: but how does statically linked llvm cause this problem?
20:14karolherbst: and arch seems to leave shared-llvm alone
20:14Lyude: kind of amazed you managed to statically link it
20:14karolherbst: yshui`: because it's llvm
20:14karolherbst: llvm build system is... broken
20:15karolherbst: best to just stick to whatever are the defaults
20:15yshui`: hmmm, i don't know if the other reporter is doing the same thing though
20:15Lyude: tbh too, static linking doesn't usually work on a lot of projects in general.
20:15karolherbst: Lyude: that's the problem. Linking usually works, but at runtime everything breaks apart
20:15yshui`: they might be using shared llvm
20:16karolherbst: yeah.. dunno
20:16karolherbst: I would try with shared first and see if that resolves the issue
20:16yshui`: nonetheless, i am still curious what exactly is happening
20:16karolherbst: heh.. but this is weird
20:16karolherbst: so you said you link statically?
20:16karolherbst: but we do see symbols called from the so file
20:17yshui`: llvm is statically linked into mesa, mesa is shared
20:17karolherbst: " 0x00007ffff0f193a3 in llvm::PMTopLevelManager::setLastUser(llvm::ArrayRef<llvm::Pass*>, llvm::Pass*) () from /usr/lib/libLLVM-10.so"
20:17karolherbst: looks like shared llvm to me
20:17yshui`: that wasn't me.
20:18yshui`: that has to mean the other reporter is not using statically linked llvm
20:18karolherbst: yeah, seems like
20:18FLHerne: yshui`: One reason it can break is if a client application uses LLVM of a different version
20:18karolherbst: or something is messed up and ended up with two versions or whatever.. mhhh
20:18yshui`: FLHerne: i know, but it's unlikely this is the case here.
20:18FLHerne: yshui`: I used to see that with KDevelop pretty often
20:19karolherbst: yshui`: mind running with strace and see what files are getting loaded?
20:19yshui`: karolherbst: i'd say that's unlikely the cause
20:19karolherbst: LD_DEBUG=libs I mean
20:19yshui`: karolherbst: ok, do you want me to rebuild with shared-llvm first?
20:20karolherbst: nah, run with LD_DEBUG=libs and share the output somehow
20:20karolherbst: then you can recompile :)
20:20karolherbst: huh... wait
20:20karolherbst: I see it
20:20karolherbst: #14 0x00007f889c1e4665 in llvm::PMTopLevelManager::schedulePass(llvm::Pass*) [clone .localalias] () from /usr/lib/dri/radeonsi_dri.so
20:20karolherbst: #15 0x00007f889ccca32f in ac_create_passmgr (target_library_info=0x7f887800b2f0, check_ir=<optimized out>) at ../mesa/src/amd/llvm/ac_llvm_util.c:227
20:20karolherbst: mhhhhh what's wrong there? :p
20:21yshui`: what's wrong?
20:21karolherbst: why is a system radeonsi driver loaded?
20:21karolherbst: but you use your own mesa?
20:21karolherbst: or something with debug symbols going wrong?
20:21karolherbst: anyway, that's weird
20:21karolherbst: I expect that your own libGL got pulled
20:21karolherbst: but system drivers
20:21karolherbst: but LD_DEBUG=libs will show that as well
20:22yshui`: I built my own mesa, then install it, then use that libGL
20:22karolherbst: yeah.. then the stacktrace doens't make sense
20:22karolherbst: why does it show the symbols for some lines, but not the others?
20:22yshui`: karolherbst: inlining?
20:23jekstrand: karolherbst: What warnings does CLC dump out on startup?
20:23karolherbst: no, inlining ususally doesn't do that
20:23jekstrand: karolherbst: I assume they're SPIR-V warnings?
20:23karolherbst: jekstrand: unsupported spirv caps
20:23jekstrand: karolherbst: Then we should support those caps. :-P
20:24jenatali: Specifically for the Groups capability
20:24jenatali: jekstrand: Nothing in libclc *actually* requires the Groups capability
20:24jenatali: The SPIRV-LLVM-Translator mistakenly adds it for the async ops
20:24karolherbst: I guess the event stuff pulls it in?
20:25karolherbst: it should be easy to fix
20:25karolherbst: hold on
20:25jekstrand: jenatali: Sounds like we should just fix SPIRV-LLVM-Translator
20:25jenatali: jekstrand: Agreed :)
20:25jekstrand: That does *not* sound like a good reason to not include CLC :)
20:25jekstrand: If anything, we should include it in the hopes that it annoys someone into fixing the bug. :-P
20:26jenatali: karolherbst: I was re-reading the Clover code. Looks like it should throw when creating a context if the libclc spirv file isn't present
20:26karolherbst: jenatali: isGroupOpCode
20:26karolherbst: fix that :p
20:26karolherbst: "return OpGroupAll <= OC && OC <= OpGroupSMax"
20:26jekstrand: Wow, that looks like a lazy check
20:26karolherbst: but that sounds right?
20:26karolherbst: jekstrand: mind breaking into it and see what triggers it?
20:27jenatali: karolherbst: I dug into it a bit further than that, I think it's something else, one sec
20:27yshui`: karolherbst: anything wrong with the libraries?
20:27jenatali: karolherbst: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/914b25575c2532b851c9d8fa1b2cf0849b1470da/lib/SPIRV/libSPIRV/SPIRVInstruction.h#L2483
20:29karolherbst: that's unrelated
20:29karolherbst: I think?
20:29karolherbst: let's see
20:29karolherbst: yeah. I saw that now
20:30jekstrand: Sounds like it needs an isGroupOpCode thrown around it
20:31jenatali: Or give it a different base class or something
20:31jekstrand: Or maybe make GroupWaitEvents not depend on it
20:31karolherbst: jekstrand: yeah...
20:31karolherbst: or just check the op
20:31jekstrand: Yeah, it looks like it could just be SPIRVInstTemplateBase
20:31jenatali: I got as far as finding that, then filed the issue and decided the debug spew didn't bug me that much :P
20:31karolherbst: I'd just go for that and see what the reaction is
20:32karolherbst: I mean, I can fix that tomorrow :p
20:32karolherbst: just not today
20:32jenatali: It can wait until tomorrow, we don't need to land libclc today
20:33jekstrand: Yeah, I just don't like "there's this little bug that's causing a warning" as a reason to not load CLC
20:33jekstrand: The "NIR_PRINT spews everywhere" is much more reasonable. :-)
20:33karolherbst: right :)
20:34jenatali: jekstrand: Thoughts on how to fix that? We don't really want NIR_PRINT to spew all the libclc code
20:34jekstrand: jenatali: Hrm.....
20:35jenatali: My workaround has been to set a breakpoint after libclc and toggle the print variable in a debugger, but that's a really hacky workaround :)
20:35jekstrand: jenatali: This is terrible but we could add a little flag to `nir_shader` which says "don't print me"
20:35karolherbst: we could just do that at runtime *cough*
20:36jenatali: Yeah, I was thinking about moving the var to not be a function-local static, but the linkage for that gets tricky actually
20:36jekstrand: Have a little global variable that lets you disable printing temporarily and do that on driver init while the CLC shader is compiling.
20:36airlied: yeah just add an intenral flag to shader
20:36jenatali: Agreed, shader flag seems reasonable
20:36karolherbst: jekstrand: I think having a flag on nir_shader is actually a good idea
20:36jekstrand: Not sure if nir_shader or shader_info is the best place
20:37karolherbst: we could use it for other stuff
20:37karolherbst: like blitter code or other builtin stuff which is just fine
20:37jekstrand: I'd like to not dump BLORP shaders most of the time
20:37karolherbst: and have another env variable NIR_PRINT_EVERYTHING :p
20:37jenatali: Sure, I like that approach, I'll add that into the libclc series
20:38jekstrand: I think I'm inclined to make it a bool in shader_info right after "label"
20:38jekstrand: call it "internal" or something like that
20:38jekstrand: And we can have NIR_PRINT=0, NIR_PRINT=1, and NIR_PRINT=2 or something like that
20:38karolherbst: jekstrand: we could make use for it for shader cachine as well
20:38karolherbst: so we never ever remove those from the cache
20:38airlied: I vote for NIR_PRINT=2
20:39jenatali: Works for me
20:39karolherbst: yeah.. I think treating internal shaders special has its merrits
20:39jekstrand: NIR_PRINT=2 would mean we wouldn't be able to use `env_var_as_boolean` and might have to make an `env_var_as_int` instead.
20:39jenatali: karolherbst: I'd love if you were able to reproduce the crash that you saw without the libclc binary... I'm struggling to see how it would happen
20:40karolherbst: jenatali: yeah, I will check tomorrow
20:40karolherbst: jekstrand: why not making it a bitmask?
20:41karolherbst: 1 for application provided, 2 for internal
20:41karolherbst: we can go nuts with that then :D
20:41airlied: jekstrand: env_var_As_unsigned?
20:41airlied: we already have it
20:42jekstrand: airlied: Oh, I forgot we did. Neat!
20:42karolherbst: 4 for libclc because it's so big and special :p
20:43jekstrand: For now, let's just add a `bool` flag to the shader and use NIR_PRINT=2. It's not like NIR_PRINT is ABI.....
20:43jenatali: Until it is, somehow :P
20:47jekstrand: jenatali: I'm sure someone somehwere has a script that they're going to be annoyed they have to change. I don't care. :-P
20:47jenatali: Well, I'd certainly hope they don't change it... libclc takes a long time to print :P
20:50jekstrand: jenatali, karolherbst: Is there anything else I should be reviewing?
20:51jenatali: jekstrand: I don't think I have anything else... I still need to rewrite the float<->int rounding/saturating conversion stuff
20:51jenatali: And deal with address space problems for images
20:51jekstrand: Wow, did I actually get to the bottom of the pile?
20:51jekstrand: Time to rebase generic pointers and make y'all start reviewing my patches then. :D
20:52jenatali: jekstrand: I think this one needed another look from you actually: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6313
20:52airlied: there is a also an open MR touching nir print already
20:52airlied: so definitely want to race that :-P
20:52jenatali: airlied: Got a link?
20:53jenatali: Eh, that'll be easy enough to resolve
20:54airlied: yeah it wasn't as involved as I thought :-P
20:55jenatali: jekstrand: FYI, in case you didn't see it, our tracking list: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3047#mesa-cl
20:55jenatali: Out of the ones that have open MRs from me, I think only one of them is waiting on review, everything else is waiting on me
20:55airlied: memcpy might be landable
20:56jenatali: Except it's currently based on the alignment MR
20:56jenatali: Probably easy enough to rebase it out though
20:56airlied: yes, so alignment first
20:56jenatali: jekstrand had some... fundamental comments about alignment :)
20:56jekstrand:may have responded with a different MR instead of review....
20:57jenatali: jekstrand: I did skim that MR, it seems sane I think
20:57jekstrand: jenatali: Yeah, the more I think about it, the more I think it's the right call. Hopefully, I can convince bbrezillon of that as well. :D
20:57jenatali: Not sure I have the appropriate wisdom to really comment whether it's better/worse
20:57jekstrand: Or he can convince me why I'm wrong. I'm honestly fine with either.
20:58jenatali: You are failing CI with it, in case you didn't see :P
20:58jekstrand: jenatali: Yeah, I'm not sure how. I didn't even kick off a CI run.
21:00jenatali: It does mean I'll need to rewrite the underaligned load/store splitting pass I wrote, to either operate on strongly-typed loads/stores instead of deref, or to use casts to re-align, but oh well
21:03jekstrand: jenatali: Right.
21:04jekstrand: jenatali: Sorry, that sounds annoying. :-/
21:04jenatali: Eh, not the end of the world :)
21:04jekstrand: jenatali: I've made you rewrite a lot. :-(
21:04jekstrand: Hopefully for the better
21:04jenatali: jekstrand: Yeah, it's okay, the code ends up better at the end
21:05jekstrand: A lot of the stuff I'm looking at really only comes into play once NIR starts doing lots of optimizations.
21:05jekstrand: Which it doesn't currently with clover because we lower_explicit_io very very early
21:06jenatali: Yeah, we do too... though we need to add -O0 so we really need to hoist more optimizations before lower_explicit_io
21:06jekstrand: We'll get there
21:07jenatali: Yep, I have no doubt :)
21:07jekstrand:needs to get cmarcelo or Kayden to review some of his Intel patches
21:09DPA: MrCooper: I've now pulled the current mesa master (d2cf6a8399e38f2c26564aeb6d0646c6c6198518) and the drmModeAddFB error I had has gone away.
21:09DPA: The other output from the other card still doesn't work quiet as it should yet though. If I use different XScreens, it now displays something
21:09DPA: on that output if I move the mouse. If I use a single XScreen, the output from the second dri card just stays black, and the gpu often hangs.
21:09DPA: Also, I think there is really something odd going on with the DRM file descriptors in this case, but I'll have to look into that further.
21:27jenatali: Huh, it looks like merge requests are auto-triggering CI now?
21:27jekstrand: jenatali: Interesting..... daniels? MrCooper?
21:51krh: jekstrand: is that pass going to determine more useful align_mul/offset values?
21:53anholt: krh: nope, it doesn't do good aligns yet
21:53anholt: wait, I was talking about master, maybe you're talking about a new pass?
21:54krh: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6472
21:55anholt: note that !4710 is close, and once it's in I've got a quick MR that basically fixes our aligns.
21:58jekstrand: krh: It should be able to, yes.
21:58jekstrand: krh: Assuming, that is, that you set an alignment on the "base"
21:58jekstrand: krh: If the base is a variable, you get the alignment "for free"
21:58jekstrand: krh: If the base is a cast of something, you need to make sure you set an alignment.
21:59jekstrand: krh: For instance, you may want to set the alignment to whatever your drivers UBO/SSBO alignment is.
21:59krh: jekstrand: we were discussing it in the context of anholt's ubo vec4 lowering pass
21:59jekstrand: krh: It may help there, yes.
21:59jenatali: I suspect it would
22:00krh: it looks like it's doing what we need
22:01daniels: jenatali: more context please?
22:01jenatali: daniels: I just pushed my libclc MR, went to look at the page, and saw CI was running
22:01daniels: we did just upgrade GitLab this morning which changed MR pipeline semantics ...
22:01jenatali: jekstrand was also confused earlier as to why he had CI results for an MR where he didn't request it
22:02daniels: will look in the morning
22:02krh: oh, is that why it also shows the full commit msg by default?
22:02jenatali: jekstrand: The more I think about it, the more I like the alignment on the derefs. It means we can use both the Alignment decoration on pointers, plus the Aligned load/store memory operand, and let NIR rationalize the two rather than assuming LLVM did it right
22:03jekstrand: jenatali: Yeah
22:03jekstrand: jenatali: And I suspect LLVM is going to sprinkle alignment things everywhere, even when we don't need the help.
22:03jenatali: jekstrand: Yep
22:03jekstrand: Especially since it's -O0 and we're going to inline the universe.
22:04daniels: krh: yep
22:04krh: jekstrand: I don't know about these new-fangled casts, but it really looks like the lower_io changes are what we need
22:05krh: daniels: yay!
22:08jekstrand: krh: Well, some of the cast magic is a bit untested right now
22:08jekstrand: But, in theory, it should provide us the information we need
22:08krh: jekstrand: oh, do the occur for GLSL too? I assumed it was a CL only thing
22:18jekstrand: krh: They should. The only issue is that you may not have an alignment at the base of the deref.
22:18jekstrand: krh: In that case, it falls back to the alignment of the type.
22:18jekstrand: krh: But I *think* GLSL uses variables so it should be ok.
22:18jekstrand:hasn't looked at GLSL in a long time.
22:29anholt: for anyone looking, gl_nir_lower_buffers.c is the place where it all happens
22:34jenatali: Cool, XDC schedule is up. Looks like I get to be awake until 5am for my talk
22:42HdkR: Schedule? Time to see how sleep deprived I'm going to become
22:51jekstrand:has a fairly nice time-slot
22:52jekstrand: It's also a time-slot that gives me an excuse to skip the buffer requirements break-out. :P
22:56HdkR: Looks like I'm going to not sleep for a few days
22:58jekstrand:is planning to time-shift. It's not gonna be fun.
22:58jekstrand: Time-shifting to european time is annoying
22:58jekstrand: Asia isn't nearly as bad because you just stay up super-late.
22:58jekstrand: But time-shifting to european means staying awake for most of the usual sleeping hours. :-(
23:17pinchartl: jekstrand: I don't know what you're talking about
23:17pinchartl:waits for the Android BoF @LPC to start at 5:00am local time
23:26kisak: it would be nice if there was a note somewhere for what timezone the schedule is in
23:26jekstrand: Yeah, it would.
23:26jenatali: That's just crazy talk
23:27kisak: I don't need anything fancy, my brain can process UTC at least
23:27jenatali: It is UTC+2
23:27jekstrand: Yeah, it's 2020. It would probably cause your computer to turn into a block of swiss cheese or something.
23:32pinchartl: jekstrand: when you log in the LPC website you can select your local timezone in your account settings
23:34jenatali: Oh hey, look at that
23:37bnieuwenhuizen: pinchartl: does it use it for displaying the schedule?
23:37pinchartl: bnieuwenhuizen: it should be, yes
23:37jenatali: If you flip the switch that tells it to
23:37pinchartl: the schedule on meet.2020.lpc is also displayed in both UTC and local times for me