08:08javierm: tzimmermann: hi Thomas, when you have time could you please take a look to https://lists.freedesktop.org/archives/dri-devel/2023-July/413630.html? (I forgot to Cc you on that one)
08:19tzimmermann: javierm, hi! one thing i don't understand is why the encoder allocates that buffer
08:23sima: javierm, I'm kinda wondering whether we shouldn't make the _rpm one the default
08:24sima: it results in constant surprises like this, and the only reason the default is the default is because the legacy crtc helpers where backwards like this too
08:24javierm: tzimmermann: well, there's no encoder really on this device. So is hard to map the DRM/KMS abstraction. At some point we decided that due the plane not having .enable/disable we could put the init seq in the encoder
08:24javierm: so that's where I moved the allocate of the buffer to be close to the panel init code
08:24tzimmermann: javierm, i see
08:25tzimmermann: let me think about this for a bit
08:25javierm: sima: I wondered exactly the same. It seems to me as if the default should be to not update planes for CRTCs that are disabled
08:25sima: javierm, yeah
08:26sima: also the ordering of first enabling the crtc and then the planes seems to be a lot more what driver authors expect
08:26tzimmermann: javierm, sima, AFAIU the crtc is enabled in the atomic state, just not yet commits
08:26sima: but it's a bit a big patch set to make it happen
08:26tzimmermann: 'commited'
08:26sima: tzimmermann, yeah that's the backwards ordering inherited from the legacy crtc helpers
08:26javierm: tzimmermann: is it? At least in this case the encoder enable callback was never called
08:27javierm: so the CRTC is defined disabled when the plane atomic state is commited
08:27tzimmermann: that sounds like a problem in the the commit_tail function.
08:28tzimmermann: if the crtc is disabled, the plane should not be enabled IMHO
08:29tzimmermann: javierm, can't you allocate the buffer initally and leave it at that?
08:29tzimmermann: why is it done in encoder->enable ?
08:29sima: tzimmermann, yeah hence why I think we should make the _rpm the default, because that's all around more reasonable
08:30javierm: tzimmermann: yes, but that's an orthogonal issue IMO. Just exposed this one about trying to update disable planes
08:30javierm: tzimmermann: drm_atomic_helper_commit_planes(dev, old_state, DRM_PLANE_COMMIT_ACTIVE_ONLY);
08:30tzimmermann: sima, but i'm rather surprised that atomic_check doesn't enforce this?
08:30javierm: that's the only difference between _rpm and the default
08:31javierm: tzimmermann: about the buffer allocation, yes I plan to use devres helper for that. I didn't because I know that there are some impedance mismatch between device and drm_device lifecycles
08:32javierm: but Geert is correct that in this case we could use devm_* for this buffer so I'll do that
08:32tzimmermann: javierm, i'd rather change that in the driver
08:32javierm: tzimmermann: and probably will remove that encoder funcs and just use the plane enable/disable now that you added the enable too
08:33javierm: tzimmermann: just make it safe for the atomic state to be commited to disabled planes ?
08:33javierm: Ok, that would work but I think that is masking another issue
08:33tzimmermann: sima, IMHO the non-_rpm code is more logical
08:33javierm: tzimmermann: I disagree. For instance, I assumed that was the default
08:34javierm: _rpm I meant. I wonder how many people thought the same
08:34tzimmermann: javierm, plane->atomic_enable is being called *after* update_plane. so that would not fix the allocation issue
08:35javierm: tzimmermann: hmm, right. Hence why I prefer to use the _rpm version too :)
08:35tzimmermann: IMHO it makes sense to first do an update of the plane and its content. then enable the display pipeline frm plane to encoder. that's what the non-_rpm commit tail does, as this only enables a stage if the input has been set up already
08:36tzimmermann: but it also means that the driver has to allocate that buffer before calling plane_update
08:37javierm: tzimmermann: hmm, I see. So that when is enabled you already have content in the framebuffer and prevent an initia visual glitch
08:37tzimmermann: that's the idea, at least
08:38tzimmermann: javierm, the size of that buffer is static?
08:39javierm: tzimmermann: for now, but it won't once I add support for 4-bit grayscale and 16-bit RGB
08:40javierm: tzimmermann: I've started pushing the preparatory patches for these new panel families (ssd132x and ssd133x)
08:41javierm: tzimmermann: but I'll just allocate at probe time then using devm_kzalloc() and that should fix it too
08:41javierm: Geert also wanted that so it shows that's better than my approach. Could you please comment on the list ?
08:43tzimmermann: javier, IMHO a real fix would be to allocate this buffer within the plane state in atomic_check. that might need some extra thoughts on how to share the memory across plane updates.
08:48tzimmermann: javierm, can't you simply allocate enough memory for the maximum buffer size? the panels are small and 16-bit color isn't so much
08:54javierm: tzimmermann: but also depend on the panel resolution. I think that will just move ssd130x_buf_alloc() to ssd130x_init_modeset()
08:55javierm: and change the kcalloc() to devm_kcalloc()
08:55tzimmermann: ok
08:55tzimmermann: sima, why don't we make DRM_PLANE_COMMIT_ACTIVE_ONLY unconditional?
08:58tzimmermann: or why don't we outright reject enabled planes on disabled crtcs? if find the current semantics fairly unintuitive
08:58tzimmermann: s/if/i/
08:59javierm: tzimmermann: agreed
09:00sima: tzimmermann, because it could break drivers
09:00sima: on really dumb hw it doesn't matter much when you program the plane registers
09:01sima: and if your crtc->enable doesn't restore planes, then ACTIVE_ONLY drops updates
09:04sima: hm the kerneldoc could maybe be improved a bit and mention drm_atomic_helper_disable/commit_planes_on_crtc
09:04sima: since you might want to use those too if you set ACTIVE_ONLY in your crtc hooks
09:05tzimmermann: ok, no easy fix here
09:15sima: tzimmermann, actually I think since we're adding all planes on modeset it could work for everyone
09:15sima: if you use the _rpm version
09:16sima: we definitely had a few confusing iterations on the helper design in this area
09:16sima: overall I think making the flow in _rpm the default would be best
09:17emersion: what is the difference between DRM_EVENT_VBLANK and FLIP_COMPLETE?
09:17sima: so maybe also inverting the ACTIVE_ONLY flag and requiring those who need them all to set it
09:17sima: emersion, uh ...
09:17sima: emersion, in atomic?
09:18emersion: oh, is it that VBLANK is for DRM_IOCTL_WAIT_VBLANK, and FLIP_COMPLETE is for page-flips? but otherwise sent at the same time?
09:19emersion: hm, seems like it
09:19sima: emersion, yeah
09:20sima: the timestamp and frame # are supposed to match between vblank events and flip complete events
09:20sima: (you'd need a really funny driver for them not to)
09:23javierm: sima: but wouldn't make _rpm the default would prevent what tzimmermann mentioned? That is, updating a plane state prior to an enable ?
09:23sima: javierm, well you can still open-code
09:24sima: it's just about flipping the default around to the less surprising one
09:24sima: not even open-code but just use the one we have as default now
09:24javierm: sima, tzimmermann: actually, you could even with _rpm if you use a shadow buffer right? Because user-space can update that shadow bufer, is only the commit that will not happen
09:24javierm: which makes sense because the HW plane is disabled
09:25sima: javierm, tzimmermann oh I got confused, we do not reject planes on disabled crtc
09:25sima: it's just about what we push to hw and what we don't
09:25javierm: sima: yeah
09:25javierm: sima: also, _rpm (I understand is for runtime power management) is a terrible name
09:26sima: javierm, mripard, mlankhorst I thought we've done this already, but apparently not: ack for adding ogabbay to drm-misc for pushing the occasional accel patch?
09:26javierm: because is not only about rpm but also about DRM_PLANE_COMMIT_ACTIVE_ONLY
09:26sima: javierm, well it's just the flow you want for a driver doing rpm
09:27javierm: sima: yes but even if you don't have rpm support in the driver, it may not want planes updates when disabled
09:27sima: where you can only update planes when the crtc is on, which both needs a) plane commit after crtc changes and b) active_only
09:27javierm: sima: so _active_only would be a better name and keep the kernel-doc that explains that is what drivers that support rpm want
09:27sima: javierm, yeah that's why I think we should just make it the default, because it's the less surprising one of the two we have
09:27javierm: sima: 100%
09:27sima: javierm, hm yeah, but gets a bit a long name
09:28sima: so maybe a patch set that 1. sets the current default for all the drivers that use it 2. flips the default to _rpm 3. removes _rpm explicitly set from all drivers currently doing that 4. rename to a more descriptive but longer name?
09:28sima: maybe in 4. also mention the 2 per-crtc plane commit functions, since they might be needed
09:29sima: and perhaps a few notes that helpers by default add all planes when a crtc has a modeset
09:29javierm: sima: 5. everyone yells at you for breaking a few CIs :P
09:29sima: since o.g. atomic helpers didn't have that, and I think some of the confusion is from those times 8+ years ago :-/
09:29sima: javierm, well more for breaking backports, but yes
09:30javierm: but agree that the current behaviour is counter intuitive. That's why I broke Geert workflow since he was using the panel for fbcon and displaying the linux logo
10:21sima: PSA I just rolled drm-next to -rc2, in case anyone needs that
10:22sima: agd5f, tzimmermann mlankhorst mripard robclark jani dolphin tursulin ogabbay ^^ hope I got all the usual suspects
10:52tzimmermann: sima, thanks! i want to forward -misc-next after the PR has been merged
10:54sima: tzimmermann, ah I can look at that too
11:03javierm: tzimmermann: as mentioned in the thread and v2 shared, I believe that allocating in .fb_create callback and taking into account the format as Geert mentioned is the correct approach
11:04javierm: that way we only allocate when and what is needed and let the resources to be freed on device unbound
11:05javierm: tzimmermann: that should work from an atomic state management POV right ?
11:25sima: javierm, hm allocating in fb_create sounds a bit strange ... I'd expect drivers to either allocate in gem_create or in prepare_fb
11:25sima: the drm_framebuffer really should be a metadata container only, plus fb_create should try to validate as many constraints as possible
11:26sima: or maybe I'm just completely lost :-)
11:39pq: Is there any KMS UAPI doc saying KMS object IDs are totally volatile and not persistent in any intended way?
11:39pq: I have a "why don't we just make persistent connector names from CRTC IDs?"
11:42pq: ...not to mention that CRTC-connector association is not necessarily 1:1
11:43pq: or fixed
12:12javierm: sima: I think you are correct
12:14sima: pq, hm we don't have docs for that I think :-(
12:14sima: pq, I think the rule we could document is that for a connector either the PATH property, or if that doesn't exist, the connector's name can be assumed to be stable by userspace for configuration management purposes
12:15sima: anything else is indeed not stable
12:15sima: or at least it would be great if userspace treats it as unstable, because I don't really want to handle those kind of regressions
12:17sima: javierm, might be good to augment the kerneldoc for drm_mode_config_funcs.fb_create and link to the other two hooks as guideline?
12:18sima: pq, I guess for plane/crtc/encoder id uapi doc it would be good to add a disclaimer that userspace should treat them as unstable, and select suitable objects by looking at their properties/features
12:19sima: and for connector's id spell the PATH/name rule out?
12:19sima: emersion, ^^
12:20emersion: yes, this is my understanding as well
12:28mareko: alyssa: any further comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24059 and the shader profiles?
12:34javierm: sima, tzimmermann: by reading the kernel docs it seems that struct drm_plane_helper_funcs .begin_fb_access and .end_fb_access are the correct hooks to allocate/free these buffers ?
12:35javierm: sima: or .prepare_fb and .cleanup_fb as you suggested but it looks to me that the former are more suitable?
12:35alyssa: mareko: --> gfxstrand
12:36alyssa: gfxstrand: punting that to you. if you're ok with it, i'll retract my objection. if you're not, hopefully you'll have input on a better approach
12:58pq: sima, there is no connector's name in UAPI, and it's not stable either, right?
12:59pq: sima, FWIW, my ideas (and the odd question) are in https://gitlab.freedesktop.org/wayland/weston/-/issues/777
12:59emersion: pq, type_id and type are in uAPI
12:59pq: but they are unstable, right?
13:00emersion: pq, https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3979
13:00emersion: pq, not for connectors without PATH
13:00pq: or did connector_type_id counter get converted into something more stable than a global counter shared by all driver instances probing at the same time?
13:01emersion: i think it's per-device
13:01pq: that would be new
13:01emersion: yes, the counter is drm_mode_config.connector_ida
13:02emersion: that thing is per device
13:02emersion: afaik
13:02emersion: hmmm
13:02emersion: wait, nevermind
13:03pq: I think there was IRC talk about maybe making it more reliable, but I presume it was left at just talk.
13:03emersion: there are two ida_alloc, one for connector index, one for connector_type_id
13:03emersion: and yeah, type_id is global
13:03emersion: the connector index can still be used
13:04emersion: that should be stable
13:04pq: yes, using the index in a connector (resource?) array was a suggestion
13:04emersion: and it's what my wlr patch is doing
13:05pq: but connector names are traditionally manufactured from connector_type_id
13:05emersion: the connector name is not stable
13:05pq: yes
13:05emersion: connector path, then fallback to index, should be
13:05pq: combined with device path, yes
13:05emersion: yup
13:06pq: good, we still agree, and I didn't miss something over the years :-)
13:06emersion: yup, sorry, i misremembered the details
13:07pq: np
13:07pq: soo... did we have connector names in sysfs? :-p
13:08pq: yes, we do
13:08pq: I suspect it's the name unstable connector name there
13:09sima: pq, oops I assumed something exists that doesn't ...
13:09pq: sima, welll... does sysfs count?
13:09sima: pq, emersion so first thing is that I think we indeed once had a global id assigner for connector ids or something like that
13:10emersion: pq, the DRM name == sysfs name is unique but not stable, indeed
13:10pq: there is no way to associate a /sys/class/drm/card1/card1-DP-2 with a KMS connector ID, is there?
13:10emersion: DRM name as in drm_connector.base.name, used in logs, not exposed to user-space
13:11emersion: apart from sysfs
13:11sima: hm we still do actually
13:11pq: :-D
13:11emersion: pq, type + type_id no?
13:11pq: emersion, d'oh, right. Manufacturing the kernel's name and looking for that.
13:11emersion: you need to have the function which converts a type to a string, we have a copy in libdrm but might lag behind
13:12pq: yeah
13:13pq: sima, someone even sent patches to add PATH property for every connector to fix this, but I don't think it went anywhere.
13:13sima: yeah I think connector->name (kernel-internal) respectively sysfs name file is fairly unstable too
13:14pq: it is
13:14pq: PATH for all: https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html
13:14emersion: i think there were some concerns wrt. userspace assuming PATH means DP MST :/
13:14emersion: but yeah PATH for all would be nice
13:15pq: 4 years later...
13:15pq: damn, time flies
13:16sima: uh the patch to improve mst PATH docs would be good at least ...
13:19sima: well maybe with some link to point at which exact connector id is used, since we have the kms obj id and the connector type id
13:49Company: is there something like godbolt for GLSL => SPIRV or GLSL => nir?
13:49Company: godbolt has HLSL => llvm il but I'm wondering if there's something better
14:21gfxstrand: alyssa, mareko: I think alyssa's argument about how this is the most conservative possible thing has me about won over.
14:21gfxstrand: Give me a few more hours to let it all settle in my brain (it's still early on a monday) and I'll give a full RB.
15:10alyssa: enunes: did you get a chance to look at nir_reg stuff?
15:11alyssa: do you need me to do the lima patches?
15:24sima: tzimmermann, drm-misc-next pr pulled and pushed out
15:25sima: airlied, ^^ fyi
15:25tzimmermann: thanks
15:25sima: airlied, the backlight fbdev->dev refactor also touches some drivers in arch and some platform_data, and the screen_info.h refactor also touches some arch stuff
15:25sima: airlied, should we have some shared gdoc stuff for these kind of things that need to go into the pr to linus?
15:30grillo_0: tzimmermann, I started making a patch addressing the TODO about the multi-plane support on `drm_format_helper.c`. Did you have any drivers in mind that would benefit from this when you wrote the TODO?
15:30tzimmermann: grillo_0, there are none AFAIK
15:34enunes: alyssa: I started looking into it, so far broke everything with the new intrinsics and am going through them with deqp
15:34enunes: this week I should have more time to finish that and send the patches
15:36alyssa: enunes: awesome, thanks!
15:36alyssa: if you post the patches I can eyeball them now to see if anything looks obviously wrong
15:36alyssa: maybe save some debug time
15:38grillo_0: Oh ok, so maybe is not worth solving this TODO if no driver will use it rn.
15:51javierm: sima: this is what I proposed earlier today based on your suggestion (but forgot to Cc you) https://lists.freedesktop.org/archives/dri-devel/2023-July/414138.html
15:52javierm: sima: if you think that makes sense, I can post as a proper patch
16:05ekurzinger: hello, would there be any interest in a patch adding "timeline" versions of the drmSyncobjImport/ExportSyncFile functions?
16:08eric_engestrom: Company: I've never used it myself, but for glsl -> spirv (and a bunch of others) there's https://shader-playground.timjones.io
16:08emersion: ekurzinger: yup
16:13tyalie: hi. I would like to add a 32bit floating point single channel video format to the fourcc codes. I'm here to test the waters a bit before posting on the ml
16:13eric_engestrom: Company: for dumping NIR, Mesa has NIR_DEBUG=print
16:14eric_engestrom: not as interactive, but it's better than nothing
16:14Company: both of those are pretty much exactly what I was looking for
16:14Company: awesome
16:15sima: javierm, yeah that's defo a lot better, allocating anything in the commit paths past the point of no return is no-no (and I thought it's documented in the right places, and kinda should be implied by the void return values everywhere ...)
16:20emersion: ekurzinger: i believe this new IOCTL would be mostly useful for compositors, and for implementing a Vulkan/GL ext to import/export syncobjs
16:21zmike: austriancoder: any chance you can look at the etna part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24117 again soon?
16:24javierm: sima: cool, thanks for proof reading it. I'll post as a patch then
16:26DavidHeidelberg[m]: eric_engestrom: can I just say "I trust you" on the MR? :D :D (I'll try to look at it today....)
16:27eric_engestrom: in case you haven't seen yet, I've split it up into a bunch of independant MRs
16:27eric_engestrom: once they've all landed I can send the second half as a new batch of independent MRs
16:28eric_engestrom: but obviously in terms of CI resources used to merge, it's better to merge it all at once
16:30DavidHeidelberg[m]: anholt: Do you think this is good enough for the nightly runs: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24051 ?
16:30DavidHeidelberg[m]: eric_engestrom: I saw :D
16:30zmike: eric_engestrom: I glanced at them, seems good
16:30DavidHeidelberg[m]: eric_engestrom: I would just merge all-in-one
16:32eric_engestrom: `Seems-good'ed-by: @zmike` :P
16:32eric_engestrom: I jest, but thanks for taking a look :)
16:32zmike: I'll ack at some point maybe
16:32zmike: today is a rodeo and a half
16:33eric_engestrom: DavidHeidelberg[m]: agreed, that's why I made a single MR at first, but it was too daunting
16:34DavidHeidelberg[m]: I would review now, but my brain is in state of https://cyberpunk.fandom.com/wiki/Cyberpsychosis
16:34DavidHeidelberg[m]: I love how EdgeRunners depicted that state, it's so perfect.
16:36mareko: gfxstrand: your reply gives me an impression that doing nothing is better than removing ALUs and shader outputs
16:48gfxstrand: No, just that I looked at it at 8:00 AM on a Monday and wanted to let it settle in my brain more.
16:49austriancoder: zmike: yes.. within the next 24 hours.
16:49zmike: austriancoder: oh awesome, thanks
17:08alyssa: mareko: your WIP nir linker, is it able to push constants from producer->consumer at a component level?
17:09alyssa: eg if you have a vertex shader that does `colour = vec4(tex.rgb, 1.0)`, it'll turn that into a vec3 and fold the 1.0 into the fs?
17:09alyssa: (this is a pattern I notice comes up a lot.)
17:10alyssa: rereading the design doc it looks like yes
17:10alyssa: nice :~)
17:50mareko: alyssa: yes
17:50alyssa: \ o /
17:50mareko: at 16-bit granularity if you have 16-bit varyings
17:50alyssa: sure
17:50alyssa: AGX has 16-bit varyings but they need to be packed into 32-bit stores .. I'm thinking how to handle that with your proposal
17:51mareko: it also forwards constants from TCS output stores to TCS input loads if it can prove that it's correct
17:51mareko: I mean TCS output loads
17:51alyssa: I think "scalarize all the way to 16-bit, run the linking opts, and then revectorize in the backend" is the way to go for that
17:51mareko: yes, we are missing the vectorization pass
17:52alyssa: a bit annoying, but it would correctly optimize a silly case where the app writes a 16-bit varying `half4(foo, 0.0, 0.0, bar)`
17:52alyssa: scalarize -> link_varyings -> revectorize should construct the packed half2(foo, bar) write
17:52alyssa: whereas trying to keep things at 32-bit would not allow any opts
17:53alyssa: so I think this is AGX's weird packed i16vec2 varyings are firmly a Me Problem
17:54mareko: alyssa: see section 7 in my design doc
17:56alyssa: mareko: yeah, I got that
17:56alyssa: it's just that after compaction I still end up with 2 store_output instructions in NIR for the low/high halfs
17:56alyssa: and need to map that back to a single 32-bit store_output taking in the pack_32_2x16_split of those
17:56alyssa: but I can do that in the backend, this isn't a reason not to scalarize
17:57alyssa: so, everything in the doc looks good to me I think
17:57mareko: the only unimplemented optimizations are from section 5 and 6, though I at least finished the new use-dominance NIR utility I need for it
17:57alyssa: \o/
18:03gfxstrand: gerddie: You've got a new NIR registers patch for r600. Have you pushed it anywhere?
18:11alyssa: gfxstrand: https://gitlab.freedesktop.org/gerddie/mesa/-/commit/0d29b0a6158043f3e73efa15871049ea5017916f
18:15gfxstrand: Oh, someone should make that an MR so we can stick it in our tracker.
19:55mdnavare: vsyrjala: emersion : Looking at how DRM adds EDID modes, looking at how hactive and vactive are populated, it only takes 12 bits so the max hdisplay would be 4095, how does DRM handle 5k and 8k modes?
19:56mdnavare: +gildekel
19:57gildekel: Thanks mdnavare
19:57emersion: sorry, i am not familiar with this code
19:58emersion: the uAPI uses more than 12 bits i believe
20:06mdnavare: static struct drm_display_mode *drm_mode_detailed(struct drm_connector *connector,
20:06mdnavare: const struct drm_edid *drm_edid,
20:06mdnavare: const struct detailed_timing *timing)
20:06mdnavare: {
20:06mdnavare: const struct drm_display_info *info = &connector->display_info;
20:06mdnavare: struct drm_device *dev = connector->dev;
20:06mdnavare: struct drm_display_mode *mode;
20:06mdnavare: const struct detailed_pixel_timing *pt = &timing->data.pixel_data;
20:06mdnavare: unsigned hactive = (pt->hactive_hblank_hi & 0xf0) << 4 | pt->hactive_lo;
20:06mdnavare: unsigned vactive = (pt->vactive_vblank_hi & 0xf0) << 4 | pt->vactive_lo;
20:06mdnavare: unsigned hblank = (pt->hactive_hblank_hi & 0xf) << 8 | pt->hblank_lo;
20:06mdnavare: unsigned vblank = (pt->vactive_vblank_hi & 0xf) << 8 | pt->vblank_lo;
20:14gildekel: My confusion is around the E-EDID standard:
20:14gildekel: ```
20:14gildekel: Horizontal Addressable Video is represented by a 12 bit number (Upper nibble of byte 4 and
20:14gildekel: the 8 bits of byte 2) - Range is 0 pixels to 4095 pixels.
20:14gildekel: ```
20:15gildekel: It seems like the Detailed Timing Descriptor is limiting pixel value to [0-4095]
20:15gildekel: So I am wondering if I am misunderstanding a translation somehow, or if there was an augmentation at some point
20:15gildekel: Because clearly we read >4K modes correctly in DRM
21:30cambrian_invader: are `lima_bo`s supposted to be created with width/height aligned to 16 bytes?
21:31cambrian_invader: lima_resource_from_handle seems to think they are
21:31cambrian_invader: who is supposed to ensure that?
21:32cambrian_invader: it doesn't seem to be enforced in the kernel in the drm_gem_dumb_create callbacks
21:33enunes: alyssa: eh ok this is very broken but builds now, and crashes horribly, so next step is to spend time debugging it https://gitlab.freedesktop.org/enunes/mesa/-/commit/b73ad53e1890e57e393dbb947d584f94de6c7aad
21:33enunes: to be continued tomorrow
21:38alyssa: enunes: https://gitlab.freedesktop.org/enunes/mesa/-/commit/b73ad53e1890e57e393dbb947d584f94de6c7aad#8c112c80505c210cfadaf7b5eb40c2d38d042888_169_172
21:38alyssa: instr->dest.write_mask is unused in the new approach
21:38alyssa: this should be legacy_dest.write_mask
21:40alyssa: enunes: also, lima/pp uses func->reg_alloc, but that's no longer valid in the new approach
21:40alyssa: change to func->ssa_alloc
21:40alyssa: (since you're using the handle->index as the reg indices)
21:40alyssa: with those 2 fixes, things /should/ work for lima/pp. I hope :)
22:09cambrian_invader: well, disabling the check causes problems
22:09cambrian_invader: so I guess whatever's allocating the buffer needs to add some lines at the end?
22:13DavidHeidelberg[m]: mupuf: do you plan to do the CI workshop on XDC 2023, as on 2022 again?
22:14DavidHeidelberg[m]: gallo: ^
23:31anarsoul|2: cambrian_invader: kernel isn't really aware of BO width or height, it cares about size. However if you want to render into BO it needs to be aligned to tile boundaries
23:31anarsoul|2: tile on Utgard is 16x16
23:32anarsoul|2: lima ensures that BOs that it allocates for rendering or for sampling are aligned properly. If you need to import an BO, it's a job of the driver that allocates the BO to ensure that it's compatible with lima (or rather with HW)
23:34anarsoul|2: IIRC you'll get ppmmu fault if you attempt to render into a buffer that is not aligned to tile boundaries