00:00 karolherbst: addressing mode as well.. just that this is more annoying
00:00 karolherbst: welll...
00:00 jekstrand: jenatali: All the hardware you run on does. :P
00:00 karolherbst: we can for surface operation
00:00 karolherbst: but also only a subset
00:00 jenatali: jekstrand: Yeah, I know... I'm giving feedback to our API design, don't worry :)
00:00 karolherbst: why...
00:01 jekstrand:wonders how many D3D features are going to come out of this
00:01 karolherbst: I kind of see why those addressing modes exist
00:01 jenatali: More than 1?
00:01 karolherbst: but why...
00:01 karolherbst: OpenCL "sometimes" feels like it tried to please developers as much as possible, leaving drivers with implementing insane crap :D
00:01 jekstrand: jenatali: I think integer coordinate handling may be wrong...
00:01 jenatali: jekstrand: Hm?
00:02 jenatali: I don't think so...
00:02 jekstrand: jenatali: I think we want to add 0.5
00:02 karolherbst: jenatali: so yeah.. none of that exists in the ISA :)
00:02 jenatali: jekstrand: I don't think you do
00:03 jekstrand: jenatali: Why not?
00:03 jekstrand: jenatali: That makes it center-pixel
00:03 karolherbst: LOL
00:03 karolherbst: "This is similar to the GL_ADDRESS_CLAMP_TO_BORDER addressing mode."
00:03 jenatali: jekstrand: I don't understand why you would
00:04 jekstrand: karolherbst: As long as it's not similar to GL_CLAMP :)
00:04 karolherbst: jekstrand: why doesn't the string "GL_ADDRESS_CLAMP_TO_BORDER" appear inside mesa? :p
00:04 jekstrand: karolherbst: It's GL_CLAMP_TO_BORDER
00:04 karolherbst: yeah...
00:04 karolherbst: guess they made a mistake there :)
00:04 karolherbst: and nobody noticed
00:05 karolherbst: well.. we did now
00:05 karolherbst: but
00:05 karolherbst: but GL_CLAMP_TO_BORDER isn't something you can specify inside glsl
00:05 jekstrand: karolherbst: File a bug. :)
00:06 karolherbst: can I file a bug "samplers_t are just insane, please remove it entirely?" :p
00:06 jekstrand: heh
00:06 jekstrand: The good news is that I'm getting data inside my shader
00:06 karolherbst: yeah...
00:06 karolherbst: wanna write the lowering of the entire sampler bitfield? :D
00:06 jekstrand: The bad news is that it's very clearly wrong. :)
00:06 karolherbst: heh
00:07 karolherbst: jenatali: I guess you already have the lowering, aren't you?
00:07 karolherbst: uhm...
00:07 karolherbst: *haven't
00:07 jenatali: karolherbst: We have DXIL-specific lowering, which is almost definitely not what anybody else wants
00:07 jenatali: Considering hardware can probably do all the things we can't
00:07 karolherbst: ours can't
00:07 karolherbst: so we would just do the same :p
00:07 jenatali: DXIL has separate textures and samplers
00:07 karolherbst: so does our hw
00:08 karolherbst: gallium even supports it
00:08 jekstrand: What's the point of txl with a sampler and integer coordinates?
00:08 jenatali: ... I don't understand then. Filter mode is part of the sampler, which texture to use is part of the image, what's the problem?
00:08 jenatali: jekstrand: Where are you getting a txl?
00:08 karolherbst: jenatali: mhh.. I guess we could just extract the constants after compiling?
00:09 karolherbst: that might be a way out...
00:09 jenatali: karolherbst: You don't always have the constants, they can be passed as kernel args
00:09 karolherbst: right..
00:09 karolherbst: but then we also can deal with it before running the kernel
00:09 jenatali: Sure
00:09 karolherbst: and create samplers accordingly
00:09 jenatali: Yeah, that's what we do
00:09 karolherbst: I see...
00:09 jenatali: Our "constant" samplers are just created by the runtime
00:09 karolherbst: and samplers created in the kernel need to be like real constants, right?
00:10 jenatali: They're just reflected out to the runtime
00:10 karolherbst: sure but we still have to find all the constants used as samplers, no?
00:10 jenatali: We treat kernel arg samplers the same as inline samplers for read ops, the only difference is that kernel arg samplers are specified by the API, and constant samplers are specified by the kernel code
00:10 jenatali: Sure, that's easy
00:10 karolherbst: mhhhh...
00:11 karolherbst: maybe it's not _that_ bad then...
00:11 karolherbst: just annoying to deal with
00:12 karolherbst: oh well...
00:13 karolherbst: just wondering how much of mix and matching we actually have to do in the end
00:13 karolherbst: given that our sampler views are like 6x32 bits or something and contain a bunch of random stuff
00:14 jenatali: jekstrand: Which CTS test are you running that's giving you a txl?
00:14 jekstrand: basic_readimage
00:14 jenatali: Oh, I forgot which one txl is, nevermind :)
00:15 jenatali: jekstrand: Is it assumed that nir tex coordinates are always normalized? Or are non-normalized coords allowed as well?
00:15 karolherbst: jekstrand: I suspect that our spirv parsing code might not set certain things clover expects to be there in case you run into some weird bugs :)
00:15 jekstrand: jenatali: Non-normalized ar allowed
00:15 jenatali: Hm, ok
00:16 jekstrand: jenatali: Well, depending on driver support, of course.
00:16 jenatali: Sure
00:17 jenatali: Well, let me know if there's anything I can do to help :)
00:18 jekstrand: At the moment, I think I broke clover with my image read/write fix :)
00:18 jenatali: :D
00:48 jekstrand: Woo! I'm getting border color!
00:50 jekstrand: Hrm.... Something is wrong here...
00:50 jekstrand: Illegal message type (SHADOW) surface format (B8G8R8A8_UNORM) combination. (009)
00:50 jekstrand: Why am I getting shadow samplers?????
00:50 karolherbst: why not? :p
00:52 jekstrand: except it's not a shadow
00:53 karolherbst: ahh
00:54 jekstrand: Why is my Y coordinate 512.5?
01:16 jekstrand: I think something's dispatching wrong
01:17 jekstrand: I'll figure it out tomorrow
06:18 danvet: Lyude, I guess you discussed this with airlied, but your pull request is missing a "who should merge this and why" intro
06:19 danvet: (or bskeggs or drm-intel maintainers or whomever)
06:30 airlied: danvet: yeah they mentioned it in here earlier, but it still should have that info for completeness :-P
07:12 RAOF: Hm. Am I doing something wrong, or is v3d interpreting buffers over wl_drm incorrectly? I can see the white of the glmark horse, but it looks like the stride is horribly wrong - it's just white stripes.
07:36 MrCooper: daniels: thanks for the review! Had me scratching my head for a while, it finally clicked when I noticed that none of the pipelines on the Pipelines tab were detached
07:45 danvet: pinchartl, I guess you still wont ever apply patches you review to drm-misc?
07:56 pinchartl: danvet: I wouldn't say "ever" -
08:00 danvet: mlankhorst, quite a bunch of patches in drm-misc-fixes
10:34 danvet: siqueira, I guess with melissa and sidong you have enough review expertise for your vkms patches?
10:35 danvet: same really for all other in-flight vkms patches, ok if I leave them to you?
10:35 danvet:was on vacations 2 weeks
10:39 daniels: MrCooper: heh, np - it took a while because I had to unpack what all the clauses actually meant, checking them against real jobs :P
11:41 tagr: danvet: welcome back!
11:42 tagr: danvet: I did a bit of thinking and ultimately came up with this patch in Mesa, which slightly tweaks the way that applications can "advertise intent" about modifiers usage and which will allow split render/scanout setups to work in a way that's very similar to how combined drivers work
11:43 tagr: danvet: https://gitlab.freedesktop.org/tagr/mesa/-/commit/940c1c23905ca568aaaf580fbb805cf5ced1d2fa
11:43 tagr: danvet: I've also got a kmscube implementation that makes use of that: https://gitlab.freedesktop.org/tagr/kmscube
11:44 tagr: and I think the same should work for X modesetting, though I still have to carve out the time to implement it there
11:44 tagr: the Mesa commit should explain why I think this is a good solution, but I'd be interested in your thoughts on the matter and whether you see if there could be any problems with that approach
11:45 tagr: basically the idea is to make implicit modifiers easier to support by making the API more explicit
11:45 danvet: is the mesa thing for the case where we combine the display/render into one overall mesa device?
11:46 tagr: danvet: yeah, it solves one particular problem there, but it's more of a general thing
11:46 danvet: if it leaks outside of mesa I'm not sure how useful it is, since I'm kinda leaning towards "it's a bug" that -modesetting uses the gbm modifier interfaces even when modifiers aren't enabled
11:47 danvet: so not sure we can rely on this "create without modifiers, still expose modifiers" trick for that compositor case really
11:47 tagr: danvet: basically it comes down to the problem that some applications end up allocating buffers without modifiers but still pass on the framebuffer modifiers to KMS
11:48 danvet: yeah, but if we allow modifiers we might break those
11:48 danvet: in cases where they worked before
11:48 danvet: if we allocate with implied modifiers, and then the app doesn't ask for the modifier info
11:48 tagr: the fundamental issue is that the DRI driver currently doesn't know whether the application intends to pass on the modifiers or not
11:49 danvet: yeah
11:49 danvet: that's why I think we shouldn't invest too much into this
11:49 danvet: if there's so low hanging tricks, ok
11:49 danvet: otherwise we just reinvent modifiers without modifiers
11:49 danvet: or well modifiers without the explicit modifier protocols
11:49 danvet: which is kinda something we wanted to avoid
11:49 tagr: so the proposal is to change that and make the "implied modifiers" be explicit it that the application can call gbm_bo_create_with_modifiers(..., NULL, 0) to advertise to the DRI driver that it cares about modifiers but not exactly which ones it gets
11:51 tagr: that's currently not possible because GBM will convert modifiers == NULL into ->resource_create() (for gallium drivers) and make it indistinguishable from gbm_bo_create()
11:52 tagr: but if we plug this through all the way, then applications can be more explicit in what they request and DRI drivers can derive that it's fine to pick whatever modifier is best suited and expect the application to pass it on
11:53 tagr: whereas for gbm_bo_create() it really has to assume pitch linear because the application may be completely modifiers unaware
11:53 danvet: I'm not sure gbm_bo_create is that strict
11:53 danvet: it's more "whatever worked before"
11:54 danvet: but yeah for split devices it pretty much means linear
11:54 danvet: since we never really had an implicit way to pass that info around
11:54 tagr: danvet: it's not that strict for combined render/scanout, but for split devices we don't have a way to get at the buffer layout without modifiers
11:54 tagr: right
11:54 danvet: yup
11:54 daniels: tbh modesetting should be fixed to not try to query the modifiers if it didn't allocate with modifiers
11:55 daniels: there's an argument that gbm should report an invalid modifier if the surface/bo wasn't explicitly allocated with modifiers
11:55 tagr: daniels: but that would be breaking things like X
11:57 tagr: danvet: there's also this: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/497
11:58 tagr: danvet: which is an earlier proposal to try and make modifiers support work without pulling in *all* of atomic
11:58 tagr: it's basically enabling modifiers on top of universal planes
11:59 tagr: to get around the kernel preventing X from doing atomic
11:59 tagr: I suspect you may not be too happy about it because preventing atomic from X was probably as much because of modifiers support as it was for anything other atomic features
12:00 daniels: well, quite
12:00 danvet: yeah you can't enable modifiers without atomic
12:00 danvet: too much black screen
12:00 tagr: you can with a bit of hand-waving =)
12:01 daniels: well, you could go fix X to fall back when you enable exotic non-linear modes ... but then you've fixed atomic too
12:02 tagr: my original point was that we can kind of side-step most of that with the compromise of supporting implied modifiers
12:02 danvet: yeah the thing is that the badly broken atomic is only in 1.20
12:02 danvet: 1.21 has "working" atomic
12:02 danvet: except it still doesn't fall back if the modifier doesn't work
12:03 danvet: so yeah "atomic is disabled by the kernel" is not a hold-up
12:03 danvet: all the bugs for that are fixed in 1.21, enabling it again is a one-liner to ask for atomic v2
12:03 tagr: and I agree that implied modifiers aren't an ideal solution, they do give us a quick fix while we clean things up for good
12:03 danvet: the trouble with modifiers are the modifiers
12:06 vsyrjala: i believe blacks screens should be eliminated by making present unflip everything for modesets, even if the screen pixmap isnt being resized. iirc atm it only does it for resizes
12:08 danvet: also all this is kinda moot if a 1.21 release just doesn't happen :-)
12:48 siqueira: danvet I'm tracking vkms patches with melissawen . We have things under control, don't worry ;)
13:01 danvet: awesome
13:20 danvet: Subject: [PATCH 0/4] dyndbg: POC use dynamic_debug_exec_queries in DRM <- seanpaul maybe of interest for you?
13:20 danvet: seems first attempt to glue our debug stuff into dyndbg
13:21 danvet: j4ni, ^^
15:37 tagr: danvet: the idea was at least partially to come up with a solution that's not too intrusive so that we could potentially make it a fix for 1.20.9
15:37 tagr: but if there's enough reason to cut 1.21, perhaps that's the better way to go then
15:38 tagr: danvet: so the only thing missing in X to make it good enough to request atomic v2 would be to ensure that if a modeset fails for framebuffers allocated using modifiers triggers a modeset with framebuffers allocated without modifiers?
15:43 danvet: that might work for enabling modifiers by default
15:43 danvet: for atomic v2 really you can just do it in 1.21
15:43 danvet: it's no use, since all it does is emulate legacy ioctl using atomic ioctl
15:43 danvet: but at least 1.21 does it correctly, after a pile of fixes
15:45 danvet: wrt that fallback to modifier-less, not sure that's a good idea
15:46 danvet: since that means -modesetting is the only compositor which switches between the two modes
15:46 danvet: which no one else would do
15:46 danvet: implementing the proper logic of removing that modifier from the candiate list and trying the next one sounds better
15:46 danvet: I'd expect the reallocating is tricky, not keeping track of the current list of allowed modifiers on a given crtc
15:47 danvet: also reset the modifier filter list any time a crtc is disable (for all crtc)
16:19 Lyude: hey - who all was asking about the intel HDR backlight stuff? finally got the permission I needed for it so I'm going to start working on getting out some proper patches to remove the EDID whitelisting stuff and implement proper hdr backlight support
16:26 jekstrand: karolherbst: Debugging these image tests. There's something wrong with the inputs that are getting added for the base global invocation id
16:27 karolherbst: mhhh
16:27 jekstrand: karolherbst: They're getting added to one list but not the other so the kernel_input_size is wrong
16:27 karolherbst: ahh
16:27 jekstrand: req_input_mem, rather
16:28 karolherbst: let's see
16:28 karolherbst: req_input_mem should be the size of the full input buffer
16:28 karolherbst: so it would be weird if that gets messed up...
16:29 karolherbst: jekstrand: are you adding kernel parameters or something?
16:29 jekstrand: karolherbst: I'm not but you are. :P
16:30 jekstrand: karolherbst: One second. Playing with another patch quick
16:30 karolherbst: do you see this behaviour without any of your patches? because I don't see how that could happen
16:33 karolherbst: it might also be that I messed something up.. let's see
16:33 jekstrand: my patches shouldn't affect it
16:33 jekstrand: I'm roughly on master, BTW
16:36 jekstrand: karolherbst: Ok, back to my clover-images branch
16:37 karolherbst: I still don't see how req_input_mem can be too small
16:38 jekstrand: karolherbst: I think it's getting calculated off the wrong thing in the module
16:38 ajax: intel never did get around to releasing gen3 docs, did they
16:38 karolherbst: jekstrand: it isn't calculated at all
16:39 jekstrand: karolherbst: Hrm....
16:39 karolherbst: it is literally the size of the buffer containing the input
16:39 karolherbst: cs.req_input_mem = input.size()
16:39 karolherbst: and input is the std::vector thing
16:42 jekstrand: karolherbst: Hrm... Actually, it looks like something's wrong with images maybe
16:42 jekstrand: In particular, a mismatch between arguments and the NIR
16:42 karolherbst: yeah...
16:42 karolherbst: so an image takes 64 bit
16:42 jekstrand: There's a lot of "two things independently go off and do a thing; hope it works out"
16:43 karolherbst: sampler takes sizeof(cl_sampler) however that big is
16:43 karolherbst: yeah...
16:44 jekstrand: I think we want to do driver_location assignment for NIR inputs differently
16:44 karolherbst: ohh.. sampler should also be 64 bit
16:45 karolherbst: jekstrand: ehh... yeah.. I guess for sampler/image arguments it's broken right now...
16:45 jekstrand: And for everything else, it's fragile
16:47 karolherbst: yeah.. I think we should base the offsets of whatever clover can provide to us... just right now the argument stuff is a bit... broken
16:47 karolherbst: at least the offset thing
16:47 karolherbst: but yeah.. I think having a direct mapping between clover args and input vars would be better
16:49 jekstrand: karolherbst: Is there a way to get the size/align information of the arg in the input buffer from a clover::argument?
16:50 karolherbst: probably yes
16:50 karolherbst: I just know that for offsets it's a bit broken
16:50 karolherbst: so we would have to fix it
16:50 jekstrand: what do you mean?
16:50 jekstrand: I see storate()
16:50 jekstrand: *storage() rather
16:51 karolherbst: so what clover does in the llvm backend is to add one scalar argument, but later on when binding clover creates up to three real arguments
16:51 karolherbst: so it all falls apart at this point
16:51 karolherbst: but besides that I think it should work
16:52 karolherbst: uhh.. image_size and image_format also do magic
16:52 karolherbst: same level
16:53 jekstrand: I don't think you're really answering my question
16:53 karolherbst: so before we could base it of the module::argument thing, we would need to fix kernel::exec_context::bind
16:53 jekstrand: What needs fixing there?
16:53 karolherbst: clover puts more stuff in the buffer than arguments exist
16:53 jekstrand: I feel like I'm missing about 70% of this conversation
16:54 karolherbst: so you have one grid_offset argument being a 32 bit integer thing
16:54 karolherbst: but
16:54 karolherbst: clover adds 3x32 bit values
16:54 karolherbst: so you have a mismatch between declared arguments and values inside the input buffer
16:55 jekstrand: Sure
16:55 jekstrand: We could also just use a uvec4
16:55 jekstrand: or uvec3 but stupid CL alignments
16:55 melissawen: hey danvet, I just opened the access request on gitlab for drm-misc, is it for you that I send the link? https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/287
16:56 melissawen: not sure if I did it right
16:56 melissawen: siqueira, ^
16:57 karolherbst: jekstrand: right.. but that means fixing clover :) just saying it's a bit more work than just fixing the nir backend
16:57 karolherbst: we would have to rework some of the llvm bits as well
16:57 jekstrand: karolherbst: I don't see why this means reworking that much of clover
16:58 jekstrand: We just need to expose a few bits so we can calculate offsets in the NIR stuff the same way they'll get placed into the buffer
16:58 karolherbst: ohh, not saying it's much, just saying it's rework which has to be done
16:58 jekstrand: I really don't care about the vec3 issues
16:58 karolherbst: well...
16:58 karolherbst: you can also mimic kernel::exec_context::bind inside the nir backend
16:58 karolherbst: and do the loops as well
16:59 jekstrand: I could make a fake context and bind them all. :P
16:59 karolherbst: you could I guess
16:59 karolherbst: but personally I'd rather fix the stuff because right now it's "not right" anyway
16:59 jekstrand: How does this work in the LLVM back-end? More "do things twice and hope they match"?
16:59 karolherbst: yes
16:59 jekstrand: Yeah, I'm all for fixing things properly
17:01 jenatali: FWIW we reflect all of this out from the compiler to the runtime
17:01 karolherbst: I was just reluctant to make changes which require fixing up the llvm stuff as I have no way of veryfing what I am doing is correct
17:01 jekstrand: karolherbst: Does the LLVM stuff work with LLVMpipe?
17:02 karolherbst: no
17:02 karolherbst: it's really more AMD specific if anything at all
17:02 karolherbst: but maybe it would work? I just doubt it
17:03 karolherbst: and I wouldn't know how much work that would be to add support for it
17:03 karolherbst: airlied might know?
17:05 danvet: mripard, mlankhorst https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/287 pls ack
17:05 danvet: melissawen, it's for drm-misc maintainers to ack
17:06 jekstrand: pendingchaos: Is there anything blocking the SPIR-V memory access MR?
17:11 pendingchaos: I don't think so
17:11 pendingchaos: I'll add the BE commit and squash fixup and add my and bbrezillon's R-b to the BE commit
17:11 pendingchaos: and marge
17:11 jekstrand: pendingchaos: Cool. Thanks!
17:12 karolherbst: jekstrand: I think we could probably get away by just not adding any image arguments and treating samplers as simple 32 bit bitfields
17:12 karolherbst: but I don't think we even have to add samplers
17:12 karolherbst: mhh.. or maybe we do as an indirect? mhhh
17:13 jekstrand: I don't think we need to add actual inputs for images or samplers
17:13 jekstrand: We just need the format and channel order params
17:13 karolherbst: right.. the format is also a bit odd :/ mhh
17:13 jenatali: jekstrand: FYI for when you get to the format/order: https://github.com/microsoft/OpenCLOn12/blob/master/src/kernel.cpp#L384
17:14 jenatali: Apparently the SPIR-V that gets generated has an embedded add of the base enum value for these?
17:14 jekstrand: Ok...
17:14 karolherbst: jenatali: huh? that sounds like a bug
17:15 jenatali: karolherbst: I didn't look too closely to see which layer it came from
17:18 jenatali: karolherbst: Definitely by design: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/a69a0f73adbff40fa2108e0841dd84df2eb37e1f/lib/SPIRV/OCLUtil.h#L300
17:19 karolherbst: right..
17:19 jenatali:shrugs
17:20 jenatali: Dunno why the SPIR-V folks decided these should be 0-indexed: https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_image_channel_order_a_image_channel_order
17:29 jekstrand: karolherbst: Could you give a look at the last few commits of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6472
17:29 jekstrand: karolherbst: You can ignore the ANV commit, of course.
17:30 jekstrand: karolherbst: Actually, give me a second
17:35 jekstrand: karolherbst: Ok, just pushed again.
17:35 jekstrand: karolherbst: One of those will be cleaner once your bitfield operators MR lands
17:36 karolherbst: should I just pull in all the patches and give it a try?
17:36 jekstrand: karolherbst: alignments? I don't think that's necessary but feel free if you want.
17:36 jekstrand: karolherbst: It doesn't regress anything here
17:36 jekstrand: But I don't have everything in basic passing on master
17:37 karolherbst: mhh.. it conflicts with your constant memory MR
17:37 jekstrand: karolherbst: Yeah, that's probably true. :-/
17:37 jekstrand: karolherbst: We can work on landing that one first if you'd like.
17:38 karolherbst: yeah. that would be nice
17:38 jekstrand: karolherbst: Ok, I think the only thing really missing there is your review
17:38 jekstrand: I think jenatali already reviewed it
17:38 jekstrand: I'm trying to not land CL stuff with just one of your sign-off
17:38 jenatali: Much appreciated :)
17:39 jenatali: I'm pretty sure that one was fine by me
17:39 jekstrand: jenatali: It's been tweaked ever so slightly since you signed off.
17:39 jenatali: I've still got a bunch of already-landed stuff in master that I need to update our fork to deal with, and then I can try to rework alignments to use derefs instead of load/store alignments
17:39 jekstrand: jenatali: But I don't know that the tweaks actually affect you
17:39 karolherbst: jekstrand: I guess we can land the constant buffer patch later, so I will give it another run and review it
17:39 jenatali: jekstrand: Yeah, I saw the tweaks, though I didn't look *too* closely
17:40 jekstrand: karolherbst: Yeah, the constant buffer patch is lots of clover bits
17:40 jekstrand: karolherbst: I'm happy to get that landed but it feels like an addition
17:40 jekstrand: karolherbst: I think you might have a much newer version of it in your tree too. I've got something oldish
17:40 karolherbst: ehhh
17:40 karolherbst: can we land jenatali uniform patch first? :D
17:40 karolherbst: ohh wait
17:40 karolherbst: that got merged
17:41 jenatali: Yep
17:41 karolherbst: mind rebasing your mem const MR? :D
17:41 jekstrand: karolherbst: doing that now
17:41 karolherbst: cool, thanks
17:42 jekstrand: Once constants lands, I think I can start rebasing generic pointers. :D
17:42 jekstrand: Ugh... That one conflicts with alignments
17:42 jekstrand: *sigh*
17:42 karolherbst: :D
17:42 karolherbst: yeah, we should start merging stuff :p
17:42 jekstrand: karolherbst: What's the latest on your last nouveau/clover MR?
17:43 karolherbst: it depends on the enum stuff
17:43 karolherbst: but other than that I think I'd merge it
17:43 jekstrand: karolherbst: I think we should land the num stuff. It's been 24 hours and you've got review
17:43 jekstrand: *enum stuff
17:43 karolherbst: okay
17:44 jekstrand: karolherbst: Naturally, I'll have to rework bits of the alignment MR once that's landed. :)
17:44 karolherbst: of course :)
17:51 jekstrand: karolherbst: constant MR is updated
17:51 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6379
17:54 karolherbst: ahh.. somebody removed num_shared :/
17:54 karolherbst: ohh, it got rename :D
17:55 danvet: robclark, ask for topic branch for the iommu stuff, pull that into drm
17:55 danvet: merge it all in one cycle
17:55 danvet: imo
17:55 danvet: airlied, ^^ wrt msm per-process mmu
17:57 robclark: danvet: there might be some conflicty stuff on the iommu side with bamse's smmu handover series.. but depending on what lands in which order, maybe we could do that
17:58 danvet: if it's not too bad, resolve those conflicts in the merge on the iommu side
17:58 danvet: generally best approach
17:59 danvet: we could also do a late pull with the remaining bits
17:59 danvet: prepared pre-merge window ofc
17:59 jekstrand: karolherbst: Yeah, I made it more sensible
17:59 robclark: basically I still need Will and/or Robin to ack it, and hopefully speak up on their preferred approach to land it..
17:59 danvet: by merging msm-next and iommu-next together (ofc both need to be stable)
17:59 danvet: but only sending out once they both landed, just in case
18:00 danvet: robclark, sure
18:00 robclark: at least in the current state, we could land all the drm parts ahead of the iommu parts, so I'm kinda planning to do that either way for next cycle
18:00 karolherbst: jekstrand: now that I rebased on top of master your deref MR is causing more conflicts :/
18:00 danvet: just figured I jump in with more topic branches, since imo waiting a release for feature work is Just Wrong :-)
18:00 jekstrand: karolherbst: Let's focus on constants for now
18:00 karolherbst: okay
18:00 jekstrand: karolherbst: Less rebasing for everyone
18:01 karolherbst: anyway.. pulled in your newest constant stuff and that's still fine. soo let's review a little :)
18:01 robclark: danvet: fair, although a drop in the bucket compared to how long it's taken so far (mostly because getting iommu folks to review things is like pulling teeth)
18:05 danvet: robclark, I'm a hopeless optimist maybe :-)
18:05 robclark: heheh
18:06 jekstrand: danvet: Come on. We all know that's not true. :P
18:07 danvet: jekstrand, it's either that or deep denial about stockholm syndrone
18:07 danvet: :-)
18:11 anholt: cool, can't rebuild container due to gpg failures. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/4355681
18:13 Lyude: seanpaul: surprised I keep seeing mst patches coming from the chromeos folks
18:15 seanpaul: Lyude: yeah, we're trying to make it work Ok on CrOS
18:15 Lyude: seanpaul: remember, we could always use mst on the chamelium :)
18:15 seanpaul: it's a challenge with all of our downstream kernels, backporting is painful
18:15 robclark: anholt: ntp fail? Maybe throw a `date` cmd in there?
18:15 seanpaul: yeah, we plan on revving chamelium with 1.4/mst
18:15 Lyude: btw seanpaul, I'm going to be starting dsc work on nouveau at some point soon, and that'll involve also getting things in shape for mst dsc support
18:16 Lyude: seanpaul: WOOOO!!!
18:16 seanpaul: no eta, but it's in the pipeline
18:17 seanpaul: re: dsc, cool! we don't use dsc anywhere right now, but seems like it's going to be unavoidable
18:17 Lyude: seanpaul: I was planning on doing selftests when the kunit stuff comes out, but I could totally use that time on coming up with the chamelium tests whenever you guys have something working
18:17 Lyude: *something working in hw
18:17 seanpaul: Lyude: i'll use whatever powers of persuasion i have to get you one
18:17 Lyude: yay :)
18:17 seanpaul: we're also spinning up igt in our CI
18:18 seanpaul: so hopefully we'll all be pushing in the same direction
18:18 danvet: yay for igt in ci
18:19 seanpaul: danvet: i'm sure you've been itching to see how our 4.4 fraken-kernel does with igt :-P
18:20 danvet: geeeeeeeeez why did you have to follow up with that
18:20 danvet: but yeah maybe you find some bugs and then upstream the fixes
18:21 karolherbst: 4.4? that's quite new, isn't :P
18:21 karolherbst: it
18:21 airlied: Lyude: mst hub and two chameliums? :-)
18:21 danvet: seanpaul, btw are you having some sign issue in your kernel upgrade process?
18:21 danvet: it feels like cros is going down
18:21 Lyude: airlied: hehe-tbh there's a lot of funny stuff I would also like to test that might not work so well fvor
18:21 Lyude: *for
18:21 Lyude: also, the DP chip on there is surprisingly slow, and that causes a surprising number of issues with some mst hubs
18:22 Lyude: i need to look into upstreaming the fix I had for that
18:22 seanpaul: danvet: we've got a kernel for almost every day of the week, 3.8 3.18 4.4 4.14 4.19 5.4
18:23 danvet: yeah if we end up testing more the mst hubs than the linux sink side maybe a bit too much
18:23 danvet: no 2.6.32?
18:23 seanpaul: maybe somewhere!
18:23 danvet: I thought that was the release that survived for almost as long as 2.4
18:25 seanpaul: there's a system integrator somewhere reading this thinking it'd be a good idea to build a device with 2.6 and backport atomic + mst to it... be careful what you say :-)
18:26 Lyude: to that system integrator: no. go to your room.
18:27 seanpaul:might start sending CrOS meeting invites to Lyude
18:27 Lyude: seanpaul: i'd be totally up for that
18:29 karolherbst: jekstrand: I think !6433 is ready to get merged as well.. any last minute concerns or should I just merge it? The nouveau patches should be fine.. at least they won't affect any graphics workload anyway
18:29 seanpaul: on a more serious note, we're working hard to upgrade our old kernels to fresher ones which is getting easier now that most things are upstream
18:30 jekstrand: karolherbst: Yup. Marge it.
18:35 airlied: jekstrand, karolherbst : not possible to have llvmpipe use the llvm backend
18:35 airlied: we should rename the llvm backend to the amdlegacy backend
18:36 jekstrand: heh
18:40 karolherbst: airlied: I assume it depends on too much AMD specific stuff?
18:44 airlied: karolherbst: not directly
18:44 airlied: but it relies on llvm producing the binary from the input CL C
18:45 jekstrand: That's not gonna work for LLVMpipe....
18:46 airlied: yeah you'd get an x86 binary that wouldn't be at all what you'd want
18:46 karolherbst: airlied: ehh.. you could exec the binary :p
18:47 airlied:isn't even sure what llvm would produce
18:48 airlied: but it wouldn't be anything like llvmpipe wants
18:49 karolherbst: yeah.. I can imagine
18:49 karolherbst: one could probably make it work,but then it's probably also not worth it to actually do
18:51 airlied: llvmpipe alos constructs a lot of scaffolding around the shader
18:51 airlied: like coroutines for compute shaders
18:52 bnieuwenhuizen: also image format encode/decode
18:53 airlied: but there should be a few ppl around capable of regression testing the llvm backend
18:54 jekstrand: I guess I do have a radeon in my personal desktop
18:54 jekstrand: It's not even powered on at the moment but I could probably test stuff if needed.
18:54 airlied:can test it as well, I just have trouble keeping a working baseline before I trash the machine for something other reason
18:56 jekstrand: karolherbst: I just rebased the constants MR on !6433
18:56 karolherbst: yeah... I noticed :D
18:56 jekstrand: karolherbst: A couple tiny conflicts but not bad
18:57 karolherbst: I think gitlab falls apart :/
18:57 karolherbst: ohh wait.. my other MR isn't merged yet
18:57 jekstrand: Does it think I added a pile of commits?
18:57 karolherbst: nvm then
18:57 jekstrand: Yeah, I'm running ahead of the curve
18:59 karolherbst: what happens if ralloc fails btw?
19:00 karolherbst: or do we simply not care?
19:00 jekstrand: we don't care
19:00 karolherbst: k
19:08 jekstrand: karolherbst: Does global_work_offsets pass for you on master?
19:08 karolherbst: ehh... good question
19:13 karolherbst: jekstrand: it does
19:18 jekstrand: karolherbst: Were there any other patcheds in !6379 that you're planning to review?
19:19 karolherbst: I was looking at most of them, but don't have time for in depth review today, so I focused on the ones with no review so far
19:19 jekstrand: ok
19:20 jekstrand: karolherbst: I guess the better question is, do you want me to hold off?
19:20 karolherbst: nope
19:20 jekstrand: Cool.
19:21 jekstrand: Once that lands, I also need to rebase my SPIR-V ray-tracing MR because it also adds new variable modes.
19:21 jekstrand:has too many patches outstanding
19:21 karolherbst: yep...
19:21 karolherbst: even after merging stuff today, I still got 80 patches :D
19:22 jekstrand: If constants are in your tree, that's 14 of them
19:22 karolherbst: yeah
19:22 jenatali: I need to start picking more stuff into our fork or else we're never going to be able to rebase it on top of master
19:22 karolherbst: clc is another big part
19:22 karolherbst: I also have CL 1.2 support for clover :)
19:22 karolherbst: and then it's just random stuff
19:23 karolherbst: ehh svm migrate as well .. mhh
19:25 karolherbst: jekstrand: fyi those are the CTS tests I verify against at the moment: https://gitlab.freedesktop.org/karolherbst/opencl_cts_runner/-/blob/master/clctsrunner.py#L18
19:25 airlied: karolherbst: had you other blocks on clc merging?
19:26 airlied: did the serialize fix go somewhere?
19:26 karolherbst: I should probably verify vec_align and vec_step as well...
19:29 jenatali: karolherbst: vecalign requires packed struct support IIRC
19:29 karolherbst: yeah...
19:29 karolherbst: airlied: huh? I think we fixed all the issues now, no?
19:30 karolherbst: mhh
19:30 karolherbst: I thought somebody picked up "nir/serialize: fix serialization of system values"
19:34 jekstrand: karolherbst: I think the global offsets issue is actually an upstream back-end compiler bug. :)
19:34 karolherbst: :)
19:36 jekstrand: I'm surprised it's not hanging
19:36 airlied: karolherbst: don't see serialize fix in master or libclc mr
19:36 karolherbst: ahh..
19:37 karolherbst: airlied: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/d7a7b3c149443a44c0d0bb63681396b77715d47c
19:38 airlied: should probably get that either into it's own MR as a fix, or into the libclc MR
19:52 jekstrand: karolherbst: RB me. Stick it an MR and land it.
19:54 karolherbst: airlied: do you want to pick it up in the clc MR?
19:54 airlied: probably easier to just land it on master, since it has jekstrand r-b
19:56 jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6545
19:56 airlied: hehe you won the race :-P
19:57 jekstrand: I really should write a "cherry-pick this patch into an MR" script
20:03 karolherbst: airlied: I think the only item left, and this does not block the MR, is how to deal with API constraints on the precision of opcodes
20:04 karolherbst: this is just even more annoying as CL has those native_* opcodes
20:04 karolherbst: so we kind of have to differantiate between cl sqrt and hw sqrt
20:06 karolherbst: and exact is really just -cl-unsafe-math-optimizations
20:06 karolherbst: but it still requires us to keep precision requierments
20:06 karolherbst: I think? mhhh
20:07 karolherbst: actually.. maybe not
20:08 karolherbst: but it feels like we need a flip per instruction in the end
20:32 airlied: karolherbst: i expect that is easier to sort put once we habe a baseline in tree
21:06 jekstrand: karolherbst: If we care about perf *at all*, here's something to stick on your ToDo list: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3479
21:11 jekstrand: Ok, so it's not as bad as I thought. There's a hard_copy_op which gets used for CopyImage and CopyBuffer
21:11 jekstrand: Still, it seems like we could do a lot better there with a kernel
21:27 jekstrand: jenatali, karolherbst: Deref alignment MR has been updated.
21:27 jekstrand: jenatali: Warning: It contains a patch to make bool explicitly 32-bit on CL. I think we talked about this and decided that it was ok but thought you might like thewarning.
21:27 jekstrand: jenatali: That patch is new to this version
21:54 jekstrand: airlied: Thoughts on trying to get some code into the Vulkan loader to make it sort GPUs and put SW rasterizers last?
21:56 jekstrand: airlied: We've got people freaking out internally because they're afraid apps are going to start using vallium
22:04 airlied: jekstrand: yeah it's not an inherently bad idea, maybe I should call it zzzzzallium
22:04 airlied: jekstrand: we could also fix the device select layer and hope people ship it
22:05 jekstrand: airlied: If it goes alphebetical, v is probably high enough in the alphabet :)
22:05 jekstrand: airlied: I think it's in file-system enumeration order
22:05 airlied: yeah it fs enumeration
22:06 airlied: so probably depends more on packaging/build systems :-p
22:06 jekstrand: Yeah :)
22:06 jekstrand: Does it find /etc before or after /usr/share?
22:06 airlied: etc overrides /usr/share
22:06 jekstrand: That said, any app that doesn't filter GPUs is stupid
22:07 jekstrand: But you know someone out there has a stupid app they care way too much about
22:07 airlied: I guess that'll be all of them since nobody has ever seen non-gpu before
22:07 jekstrand: Likely it's going to be called "Aztec Ruins" :)
22:08 airlied: I'm happy to fix device select, not so sure I want to enter into the loader
22:08 airlied: I don't think it does any sorting at all
22:09 Kayden: 99-zzzzallium.icd? :)
22:10 Kayden: the zzz for while you wait for SW rendering to finish?
22:10 jenatali: jekstrand: Thanks for the heads up - should be fine I think
22:10 Kayden: (I kid, but...I am definitely excited to see vallium happening :))
22:11 jekstrand: jenatali: Just rebased generic pointers. That was.... "fun" :)
22:12 karolherbst: jekstrand, airlied: wasn't there this nvidia stuff to do this kind of stuff?
22:12 karolherbst: through glvnd
22:13 jenatali: jekstrand: Nice :)
22:13 jekstrand: karolherbst: This is for Vulkan, not GL
22:13 karolherbst: what I mean is also for vulkan :p
22:13 karolherbst: jekstrand: https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/224 and https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/228
22:13 karolherbst: it is mainly for offloading
22:14 karolherbst: but the system could potentially be abused for setting up device preferences as well
22:14 karolherbst: and say "sw comes last" or so
22:14 jekstrand: karolherbst: Oh, neat
22:15 karolherbst: but yeah.. I think the intention is that nvidia can do something similiar to their whitelist approach they do on windows
22:15 karolherbst: and I think software drivers can potentailly be handled there as well?
22:15 karolherbst: dunno
22:16 jenatali: FWIW, the OS has owned the Windows whitelist behavior since Win8.1
22:17 karolherbst: jenatali: ahh, then can I ask you to remove sh.exe from that list :p
22:17 jekstrand: jenatali: Yeah, it's pretty nice. The Linux people have been talking about how someone should write universal system since pre-Win8.1 :-P
22:17 jenatali: karolherbst: I guess I should clarify - we've owned the mechanism, not the list :P
22:17 karolherbst: :D
22:18 jenatali: Until recently, now we're actually starting to manage the list too
22:18 jenatali: What's sh.exe?
22:18 karolherbst: apparently a game has an executable like that
22:18 karolherbst: but...
22:18 karolherbst: if you install mingw
22:18 karolherbst: you also get our sh.exe
22:18 karolherbst: *your
22:18 jenatali: Oh, it's SuperHot
22:19 karolherbst: I think it was something else
22:19 karolherbst: shadow something
22:19 karolherbst: but superhot seems to have the same name
22:19 karolherbst: I just hit this issue like 10 years ago :)
22:20 karolherbst: but that was fun...
22:20 karolherbst: I was wondering why the shell scripts took so long
22:21 karolherbst: jenatali: silent hunter was the game...
22:22 jenatali: Looks like there's also Shadow Harvest, and "Desolate" as sh.exe...
22:23 karolherbst: yeah.. fun stuff :p
22:23 jenatali: So, sorry, can't remove it :P
22:23 karolherbst: if there would be a better way to indicate if the GPU needs to be powered on besides the file name of the executable :p
22:24 jenatali: Well, some of them have nearby files included in the match, but at least one of them doesn't
22:25 karolherbst: well.. I was more thinking about checking if any d3d lib gets loaded at all or not :p
22:25 jenatali: Yeah, that's part of it - at least it is these days...
22:25 karolherbst: I mean.. maybe it is fixed now. It was a long time ago :D
22:29 jekstrand: generic pointers is now rebased on top of deref alignments. I think it's probably time to figure out how to use my own LLVM again.....
22:29 jekstrand: *sigh*
22:29 jekstrand: Or I could just say, "It's 5:30 PM here" and call it a day. :D
22:34 karolherbst: jekstrand: what should I say? :D
22:34 jekstrand: karolherbst: You should go to bed. :P
22:34 karolherbst: I know
22:36 Sachiel: too early for bed. Go play something instead
22:37 jekstrand: Sachiel: Do you know what timezone karolherbst is on? Do you care?
22:37 jekstrand: (Not caring in the sense of being insensivite but in the sense of you thinking that's irrelevant for your comment)
22:37 karolherbst: the US is known for their "early" days anyway :p
22:38 Sachiel: ohh, I misinterpreted it
22:39 karolherbst: somebody told me once that in the us you have like dinner at 6pm and I was like: wait what?
22:40 karolherbst: do they also go to bed at 9pm? :p
22:40 jenatali: Some of us do...
22:40 karolherbst: I know :D
22:40 Sachiel: I tried having dinner around 7pm a few times, and by midnight I'm hungry again
22:40 jekstrand: karolherbst: I usually eat at 7-8 and bed around midnight
22:40 karolherbst: here dinner is around 8pm or later usually :D
22:40 jenatali: XDC is going to be fun, staying up til 5am :P
22:40 karolherbst: jekstrand: ahh, somebody normal :p
22:40 karolherbst: but yeah..
22:40 bnieuwenhuizen: jenatali: or wake up early?
22:41 jekstrand: Or just don't sleep
22:41 bnieuwenhuizen: or watch the recordings
22:41 bnieuwenhuizen: (I heard we can just submit prerecorded talks now?)
22:41 jenatali: bnieuwenhuizen: I'm presenting at ~1am and ~4am I think
22:41 bnieuwenhuizen: oof that is pretty early
22:41 daniels: jenatali: tbh given your timezone, I'm all for your weird hours - makes life much easier :)
22:42 jenatali: Heh, yeah I'm a morning person
22:42 karolherbst:is waking up around 11 am usually because of... work :D
22:42 jenatali: Not quite *that* early though, at least not usually :P
22:42 jekstrand: I'm a night-owl who can't sleep in. It's terrible. :-(
22:43 karolherbst: jekstrand: uff.. that's annoying :/
22:43 karolherbst: what happens to me is that I usually wake up the same time no matter when I went to bed
22:45 karolherbst: but anyway... I should really go to bed at least :D
22:53 airlied: hmm so device select just picks the first device, I suppose it's fine to just never pick a cpu first
23:01 daniels: jekstrand: I went to bed late last night, got woken up at 5am by foxes knocking through my food waste bin trying to get to the delicious fermenting liquid, couldn't get back to sleep, then had that capped off with a call starting at 10pm
23:51 airlied: trivial things like test my layer changes always turn into day of why isn't the loader loading it
23:52 Plagman: MrCooper: bnieuwenhuizen: i'm running into infinite waits trying to poll a dma-buf fd (coming from a wayland buffer) for implicit sync completion
23:53 Plagman: it's occasional, only if the underlying app is fullscreen
23:53 Plagman: is there example code somewhere i should check to see if i'm failing to handling an important case?