00:00 psykose: setting libdir would always override it, i'd guess some auto stuff changed when unset
00:00 psykose: don't think anyone has touched that in a million years though
00:02 Lynne: I've had meson randomly do /usr/lib64 for me, then randomly stop
00:04 psykose: well
00:04 psykose: could be because of https://github.com/mesonbuild/meson/blob/5ef824b2f3649bde1239d4b23c2bd20ecea795cf/mesonbuild/utils/universal.py#L975
00:04 psykose: not the most robust detection
00:05 psykose: (all bypassed with --libdir of course)
00:07 Lynne: "if os.path.isdir('/usr/lib64') and not os.path.islink('/usr/lib64'):"
00:08 Lynne: well, on my debian system, /usr/lib64 exists, and contains ld-linux-x86-64.so.2, and I had a flashback to wondering why it's there and what happened when I decided to remove it
00:08 psykose: :p
00:09 psykose: so meson will default to the debianlike block i guess unless that fails and then use lib64
00:36 kode54: the mesa-git package I used uses arch-meson and doesn't pass --libdir for the 64 bit target
00:37 kode54: the issue was that the mesa scripts installed stuff to lib64, then the pkgbuild tried to create a symlink in lib
00:37 kode54: which it assumed existed
01:56 kode54: psykose, the arch-meson script does:
01:56 kode54: --prefix /usr
01:57 kode54: then --libexecdir lib
01:57 psykose: and so no libdir set in it
01:57 kode54: guess that pkgbuild I use needs to be set
02:18 tleydxdy: it does sound like a issue that'll affect all arch-meson package, might best be fixed in arch-meson?
02:25 psykose: offtopic but in alpine we have the same kind of wrapper and pass --libdir /usr/lib for that, not sure why arch didn't, maybe they thought it was merely redundant?
02:25 psykose: open an arch bug and find out :p
03:10 HdkR: asdasd/win 10
03:11 HdkR: Yep, that's how brains work
05:45 kode54: figured it out
05:45 kode54: it wasn't anything they did
05:45 kode54: or that arch did
05:45 kode54: it was because I stupidly untarred an archive to root (a modified opencl icd binary) that replaced my /usr/lib64 symlink with the folder from the archive
05:46 kode54: which in turn rendered /bin/bash inoperable as well
05:46 kode54: which in turn caused dracut to generate corrupted images
05:46 kode54: good thing I know my way around a rescue system
09:33 danvet: mripard, I pulled your pull, maybe forward drm-misc-fixes to drm-fixes so that -next shows up in linux-next like it should?
10:58 mripard: done
12:51 melissawen: danvet, not yeat, but I will (or maybe siqueira)... vkms is somewhat broken after dont-know-yet DRM changes and mairacanal is debugging/working on stabilizing it
13:16 danvet: tzimmermann, can you help me remember to ping airlied when he's back next week about the legacy driver removal?
13:16 tzimmermann: danvet, sure
14:19 shadeslayer: hm, I recall I was passed a branch that would help me get the backtrace for eglretrace failures like this one https://mesa.pages.freedesktop.org/-/mesa/-/jobs/34197586/artifacts/results/summary/results/trace@freedreno-a530@valve@counterstrike-source-v2.trace.html
14:19 shadeslayer: but I can't find it anymore
14:33 danvet: mripard, [PATCH] drm/vc4: Fix refcount leak in vc4_hvs_bind
14:33 danvet: in case you missed
14:36 danvet: emersion, thx for reviewing some of the drm printing patches, you're also going to push them?
14:36 danvet: or waiting for respin?
15:08 danvet: tzimmermann, an absolute horrible idea just crossed my mind for the fbdev default format saga
15:08 danvet: could we change the parameter to u32 and do a horrible check if the value is > 32, the assume it's a drm fourcc code?
15:08 danvet: and then gradually move all the drivers over to either going with the default of 0 and letting the helpers auto-select
15:08 danvet: or a real fourcc code?
15:09 danvet: I fear otherwise we'll never get out of this mess
15:09 tzimmermann: danvet, didn't we want to add something like a preferred_format field to drm_mode_config and set the format there?
15:10 tzimmermann: if set, fbdev emulation would use it
15:10 danvet: yeah, but that misses the vc4 case
15:10 tzimmermann: otherwise fall back to the current crazyness
15:10 danvet: and some other ones, where we want fbdev to just use something much less
15:11 danvet: and yeah mode_config could use the same trick maybe?
15:12 tzimmermann: tbh, i'm not sold on the idea of treating fbdev different from the other clients. it now uses 16-bits for the console to adapt to low memory. but how is that different from the other clients?
15:12 danvet: mostly it's telling that no one cares that much about fbdev
15:12 danvet: but yeah
15:13 danvet: mripard, ^^
15:13 danvet: maybe these distros should have a kernel cmdline that supplies a bunch of low-res fbdev formats or something
15:14 tzimmermann: and on the rpi4, the 16-bit setting feels out of place. in my opinion, we fbdev should go with the default. setting a low-mem policy seems system-specific
15:15 danvet: yeah ...
15:15 tzimmermann: well, there's always video=-32
15:15 tzimmermann: on the kernel command line
15:21 mripard: the Pi4 also uses CMA
15:29 tzimmermann: i mean, 8 GiB of it
15:36 mairacanal: tzimmermann: about the default value, after 37c90d589dc0, I'm having a problem with the depth default value on the vkms. I'm getting a similar error as the vc4 in the vkms, but with the following output "[drm] bpp/depth value of 32/0 not supported". When I use the preferred_depth as 0, it is not changing to the default depth of 24 apparently.
15:37 danvet: mairacanal, since I spot you, I dropped some comments on the addfb format check patches, pls look before you push
15:37 mairacanal: I checked! Thanks for the feedback!
15:37 tzimmermann: mairacanal, we should set a default depth in vkms. or maybe let fbdev pick some useful value
15:39 danvet: oh the epic bpp vs depth confusion
15:39 danvet: or not
15:40 danvet: I guess we lost the default cases for when preferred_depth is 0?
15:40 mairacanal: danvet, it seems like it
15:45 tzimmermann: i just fixed a lot of confusing bpp/depth handling. some fallout is expected
15:45 danvet: I think I see where the mixup could be
15:46 danvet: drm_fb_helper_find_format() compares drm_fourcc codes
15:46 mripard: tzimmermann: the smaller Pi4 only has 1GB
15:46 danvet: I think it should look up bpp/depth of each plane format, and match that against the provided one
15:46 mripard: and the CMA Pool is still around 256MB
15:46 danvet: and ignoring the contstraint if the provided value is 0
15:46 danvet: and skipping non-legacy formats
15:46 danvet: or something like that
15:47 danvet: I think that's closer to what we've had
15:47 mripard: so, yeah, plenty of space, but saving a few MB if we can avoid it is still valuable
15:47 tzimmermann: mripard, not that i disagree. my point was simply that it's a system-specific setting. it doesn't really depend on the driver or gfxchip
15:47 danvet: and needed as interim, until we have fourcc rolled out a lot more
15:47 mripard: tzimmermann: oh, definitely then :)
15:48 tzimmermann: danvet, please don't go back to the old code in _find_format
15:49 tzimmermann: i'm happy that i removed bpp/depth there
15:50 tzimmermann: i add a comment on bpp/depth handling. it is all inconsistent and crazy. see https://lore.kernel.org/dri-devel/20230102112927.26565-2-tzimmermann@suse.de/
15:51 danvet: tzimmermann, oh I know it's terrible
15:52 danvet: tzimmermann, the other option is that you need to figure out preferred depth before you pass it down
15:52 tzimmermann: i'd rather go through drivers and fix them one by one, if necessary
15:52 tzimmermann: or what you just suggested
15:52 danvet: but as-is it doesn't work, because we seem to end up with preferred_depth=0 in there, and no such format exists
15:52 danvet: it's 100 or so
15:52 danvet: so interim we need to handle preferred_dept=0 somehow
15:53 tzimmermann: i'll add code to handle it
15:53 tzimmermann: if we have no bpp given, 32 is the default
15:53 tzimmermann: and from the bpp we can select a meaningful depth
15:54 danvet: yeah
15:54 mairacanal: before the change, it used to be 24
15:54 danvet: yeah for 32bpp it's 24
15:54 danvet: and for 16, 8 it just matches
15:54 danvet: nothing else should be needed
15:55 tzimmermann: or even simpler: where it says "No compatible format found", we can always select 32/24
15:55 tzimmermann: that's xrgb8888. drivers are expected to provide it
15:57 danvet: tzimmermann, that might change defaults in a few cases
15:57 danvet: hm
15:57 tzimmermann: really?
15:58 danvet: ok I think I see what's going on now
15:58 danvet: we can't mix up the preferred_bpp we get as parameter with mode_config.preferred_depth
15:59 danvet: because a ton of drivers only set one or the other
15:59 danvet: so if we have preferred_bpp, we should _only_ use that to filter formats
15:59 danvet: if we don't have that, then we can use preferred_depth
15:59 danvet: but mixing them up gives us all kinds of fun
15:59 danvet: like the preferred_bpp for fbdev of 16 and preferred_depth of 24 or so
16:00 danvet: so new idea
16:01 tzimmermann: it's not so easy. we can have xrgb1555 in simpledrm et al. that's 16/15. we need to communicate both values to fbdev
16:01 danvet: if we have a preferred_bpp, we convert that directly into a fourcc
16:01 danvet: yeah, but only after we looked up what the driver supports
16:02 danvet: hm this is a nice mess
16:02 danvet: because we also need to pick the right fourcc from the driver, we can't hardcode
16:02 danvet: because of big endian lol
16:02 tzimmermann: that's what drm_fb_helper_find_format() is for
16:03 tzimmermann: it picks a supported fourcc code from bpp/depth
16:03 danvet: yeah but it's not good enough
16:04 danvet: because in most cases we only have either bpp or depth
16:04 danvet: not both
16:04 tzimmermann: indeed
16:04 danvet: that's the root cause of this entire mixup
16:05 tzimmermann: i think we should add the logic directly to drm_fb_helper_find_format()
16:05 danvet: and because of drivers like vc4, you cannot even assume that the fbdev preferred_bpp and the mode_config.preferred_depth refer to the same thing
16:05 danvet: yeah that's what I suggested
16:05 danvet: more or less
16:05 tzimmermann: ok
16:05 danvet: we need to additionally make sure we don't mix up fbdev and mode_config
16:05 tzimmermann: what do you mean by mix-up?
16:06 danvet: so the mode_config.preferred_depth can only be passed around if we have a 0 fbdev preferred_bpp
16:06 danvet: otherwise you end up with bpp=16 preferred_depth=24 or some fun
16:06 tzimmermann: no that does not work
16:06 danvet: (not sure we have such a driver, but that's essentially what vc4 wants)
16:06 danvet: it did before
16:06 tzimmermann: because of the xrgb1555 case
16:08 tzimmermann: the current assumption is that there's a valid pair bpp/depth. this apparently breaks several drivers. IMHO the best fix is to try to auto-detect the values that are 0
16:08 danvet: yeah
16:08 tzimmermann: so if bpp==0, try to get a compatible bpp from depth
16:08 danvet: but additionally, you cannot assume that the values you get are a pair
16:08 danvet: which means, one of them is always 0 in find_format
16:08 tzimmermann: and if depth==0, get it from bpp
16:09 tzimmermann: why is one always 0?
16:09 danvet: it has to
16:09 tzimmermann: why?
16:09 danvet: they're entirely unrelated, drivers actually set different format preferences for mode_config (userspace) than fbdev
16:09 danvet: so if you just smash them, then it'll fail in the cases where the preference differs
16:10 danvet: so it's either a) use preferred_bpp to look up, guess depth or b) use mode_config.preferred_depth to look up, pick first format with right depth
16:10 danvet: not both at the same time
16:10 tzimmermann: no
16:11 tzimmermann: it's expected to get both values from the driver. if that does not work, we can still try to fix it up
16:11 danvet: that would be the reasonable thing
16:11 danvet: but this isn't very reasonable
16:12 danvet: they are different, you can't use them together and assume it'll make sense
16:12 tzimmermann: having just one of them has lead to numerous problems in the past
16:12 danvet: for added infuriation, they're also different in the bpp vs depth sense
16:12 danvet: yeah that's why the find_format needs to look which format fits best for a driver
16:12 danvet: and why we should just pass fourcc codes around
16:13 danvet: but alas, lots of drivers
16:15 tzimmermann: i don't disagree. it's just that your assumption of taking one value and easily guessing the other is wrong. that has not worked in the past and lead to numerous problems. guessing here comes down to brute-force trying out combinations
16:16 tzimmermann: i have to leave now. let me send a patch and disuss that instead. it seems the discussion is currently going nowhere
16:18 danvet: https://paste.debian.net/hidden/74cf4011/ very rough sketch of what I have in mind
16:19 danvet: https://paste.debian.net/hidden/ba0db049/ probably more what we want
16:20 danvet: https://paste.debian.net/hidden/6fa34fb8/
16:20 danvet: since we have people working on low-bit fbdev emu support and stuff like that
16:20 danvet: tzimmermann, ^^ maybe for tomorrow
16:39 macromorgan: mripard: would you be able to elaborate slightly on your comment about the ERR_PTR? https://lore.kernel.org/dri-devel/20230104124010.6rambtw7mzg7sycv@houat/
16:59 tleydxdy: when a process is killed, how does the kernel find it's gpu contexts and free them? I'm specifically looking at amdgpu_ctx
17:00 HdkR: Probably the same way it finds FDs and frees them
17:00 HdkR: :)
17:03 tleydxdy: which is?
17:06 HdkR: Sadly that bit is beyond me since I'm not a kernel dev
17:10 tleydxdy: I tried to search everywhere that leads to kfree(ctx) and I can't find anything that does it
17:10 tleydxdy: only thing is the free ioctl
17:21 tleydxdy: ig somehow it's a side effect of closing the amdgpu_device?
17:39 mlankhorst: drm_file bookkeeping
18:37 sravn: macromorgan: Change the prototype to struct mipi_dsi_host * drm_of_get_dsi_bus(struct device *dev, struct mipi_dsi_device_info *info) and return an ERR_PTR in case of failure.
18:37 sravn: macromorgan: This is what I think mripard suggests, and it is more in line with what we do in other places so I like it.
18:48 jenatali: Looking at the Vulkan CTS cases for "no_position", what are you supposed to do when e.g. a VS doesn't write position but the next (non-fragment) stage reads it?
19:01 jenatali: Looks like the test isn't expecting valid positions to end up in the fragment input so I guess it can be anything...
19:25 robclark: venus-lavapipe looks unhappy, I kinda don't think this fail is related to the MR.. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34248664
19:30 DavidHeidelberg[m]: robclark: there is issue for it I think created by Emma
19:33 robclark: ahh, indeed there is
19:46 tdjb: Hi, I have this strange amdgpu crash which happens ins Warhammer 40000 Darktide if you disable the in-game FPS cap of 60 FPS (any other cap still leads to crashing), Windows users seem to have the same issue. How would I go about collecting useful information about the crash to create a meaningful report? Thanks.
21:38 alyssa: naive question ... if a shader samples the alpha component of an RGB texture, out of bounds with CLAMP_TO_BORDER wrap mode and a border colour with alpha not equal to 1,
21:38 alyssa: does that return 1.0 or the border alpha?
21:39 alyssa: seemingly panfrost differs from Apple's GL driver
21:39 alyssa: and IDK who's right
21:40 RSpliet: Naive request for additional precision :-P is this an XRGB/SRGB/RGBX/... texture, or an ARGB texture?
21:40 alyssa: RGBX
21:42 anholt: alyssa: piglit's texwrap test should tell you
21:42 alyssa: anholt: fair enough, will look there, thanks :)
21:42 alyssa: (IDK which of the two I want it to be. They are both bad.)
21:43 anholt: pretty sure it's going to be border color alpha, though
21:43 alyssa: same
21:43 alyssa: that
21:44 alyssa: 's what panfrost goes to great lengths to ensure
21:44 alyssa: and which I suspect is broken in Apple's GL driver
21:44 alyssa: not like they submitted conformance for the thing
21:44 jenatali: alyssa: D3D's spec says: "For example, suppose the resource format is DXGI_FORMAT_R8_SNORM, and BorderColor is needed during a sample operation. In this case only the RED component of BorderColor is used, along with the appropriate format-specific defaults for the other components."
21:45 jenatali: https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_3_FunctionalSpec.htm#7.18.9.1%20Border%20Color if you wanted to look
21:45 alyssa: jenatali: so D3D votes for 1.0 and GL votes for ???
21:45 jenatali: Yep
21:47 alyssa: GL *seems* to vote for border colour alpha
21:47 alyssa: if I'm understanding texwrap code right
21:48 jenatali: Does anyone know by any chance if typical desktop GPUs have switches for changing sample coordinate rounding behavior between D3D and VK/GL? I'm seeing D3D specs coordinates have to go to fixed 16.8 and then truncated, where VK specs coordinates are floored, and I'm actually seeing a VK test that seems to hit a difference in that exact behavior
21:51 alyssa: Who votes for "this is impossible to implement on AGX and the Apple driver is broken"?
21:52 RSpliet: GLES 3.2 says, on the topic of texture minification: "if the texture contains color components, the values of TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match the texture’s internal format in a manner consistent with table 8.8."
21:52 RSpliet: And that's as vague as it's going to get
21:53 alyssa: truly
21:56 alyssa: wait does texwrap even check this
21:58 alyssa: i do not see how texwrap possibly works
21:59 alyssa: right. init_float_texture applies the default swizzle implicitly
21:59 alyssa: so... texwrap votes for "border color alpha"
22:01 alyssa: which is weirdly inconsistent with D3D
22:01 jenatali: Agreed
22:01 alyssa: jenatali: well of course you agree :p
22:01 jenatali: I've been finding a bunch of those tiny little details that are weirdly inconsistent recently though
22:04 alyssa: similar questions arise around luminance and alpha of course
22:04 zmike: boo hiss
22:04 alyssa: e.g. if there are different values for each RGBA in the border colour
22:04 alyssa: but it's a greyscale (GL_LUMINANCE) format
22:05 alyssa: do we get colourful borders or not?
22:06 alyssa: d3d votes no, texwrap piglit seems to maybe vote yes
22:08 DemiMarie: alyssa: do you mean that Apple hardware is broken and cannot have OpenGL, Vulkan, or DirectX 12 implemented on it?
22:08 alyssa: DemiMarie: I mean, we already knew that much :-p
22:10 jenatali: alyssa: Well D3D doesn't have luminance or alpha formats anymore
22:11 jenatali: Ah that's not entirely true, A8 still exists
22:12 alyssa: "the border values defined by TEXTURE_BORDER_COLOR are used in place of the non-existent texel. If the texture contains color components, the values of TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match the tex- ture’s internal format in a manner consistent with table 8.18. The internal data type of the border values must be consistent with the type returned by the texture as described in
22:12 alyssa: chapter 8, or the result is undefined. If border values are out-of-range with respect to the texture’s internal format, the result is undefined. If the texture contains depth components, the first component of TEXTURE_BORDER_COLOR is interpreted as a depth value."
22:12 alyssa: that.. that really is not enlightening
22:13 alyssa: wtf does it mean to interpret consistent with table 8.18
22:17 alyssa: JoshuaAshton: ^^^ how does this work in VK
22:21 alyssa: "Table 24. Border Texel Components After Replacement
22:21 alyssa: " makes it pretty clear that Vulkan has D3D behaviour
22:21 alyssa: I think
22:21 alyssa: "This is substituted for the texel value by replacing the number of components in the image format"
22:22 alyssa: does this mean Zink fails texwrap?
22:22 alyssa: and/or that the VK CTS isn't testing this?
22:23 alyssa: zmike: you passing texwrap?
22:23 alyssa: seemingly nobody passes texwrap, but
22:24 DemiMarie: alyssa: what do you mean by “we already knew that much :-p”? The only limitation I knew of is the lack of double-precision floating point. Is it possible to implement robust buffer and texture access at least?
22:34 jenatali: alyssa: We pass most texwrap tests, we do fail for integer textures in some cases though
22:41 zmike: alyssa: you know you can check yourself https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/ci/zink-lvp-fails.txt
22:42 zmike: (the answer appears to be yes)
23:48 alyssa: jenatali: zmike: curious. i wonder how.
23:49 zmike: days and days of debugging
23:49 alyssa: well yeah I just
23:49 alyssa: if texwrap is asking for something completely different than vulkan
23:49 alyssa: and you can't layer it
23:49 alyssa: idk how you managed that
23:52 alyssa: then again if the VK CTS is missing tests for this edge case it's possible that vk drivers are implementing the gl thing and zink works by accident
23:52 alyssa: i mean
23:53 alyssa: if texwrap is authoritative for GL and my reading of the VK spec is right, then unless lavapipe is fixing up custom border colours, there is no way this works in both lvp and llvmpipe
23:53 alyssa: since gallium doesn't have a sampler state bit for this
23:53 zmike: gallium has a ton of stuff for border colors now
23:54 alyssa: lavapipe is indeed not fixing anything up
23:55 alyssa: idk if I have the will to read LLVM code to see what gallivm is doing
23:56 zmike: what are you even looking at
23:56 alyssa: lp_build_sample_texel_soa
23:57 alyssa: seemingly that implements the VK behaviour
23:57 zmike: I meant what behavior are you supposing can't be replicated
23:57 alyssa: zmike: R8_UNORM image, (0.5, 0.5, 0.5, 0.5) border colour, sample "green" in the shader, do you get 0 or 0.5
23:58 alyssa: or more problematically, sample "alpha", do you get 1 or 0.5
23:58 zmike: if it's just normal border color stuff I'm not sure why you're expecting that wouldn't work on zink
23:58 alyssa: this is seemingly different in VK and GL
23:59 alyssa: VK gives 0/1 for those
23:59 alyssa: GL we think maybes gives 0.5/0.5 for them
23:59 zmike: there's border color extensions and gallium swizzling
23:59 alyssa: I don't see how this works on llvmpipe