10:04tzimmermann: airlied, sima, could you please comment on the UMS removal patchset? https://patchwork.freedesktop.org/series/126754/
10:18airlied: tzimmermann: ack from me, getting rid of it ftw
10:21javierm: mairacanal: your convert a DRM driver to rust LPC talk was awesome :)
10:23soreau: tzimmermann: Does this mean anything for kernel options `nomodeset` and `driver.modeset=0`? Would the nomodeset cases try to use fbdev where it used to use UMS or what will happen?
10:25javierm: soreau: it will use any driver that relies on the system provided framebuffer (e.g: efifb, vesafb, simpledrm)
10:31tzimmermann: soreau, this change has no effect on nomodeset.
10:33tzimmermann: airlied, thanks
10:41sima: tzimmermann, also ack from me
10:42sima: tzimmermann, I guess just needs an ack from ppc maintainers for merging through drm-misc and I guess intel folks for the one i915 bit and then go land it all and celebrate :-)
10:42sima: airlied, agd5f given all the agp disabling, I also wonder whether we shouldn't just nuke all that too?
10:43sima: or do we need the drivers just to make sure agp mode is off?
10:44sima: but I guess nuking the uapi is really the thing that matters
11:28emersion: sima, just fyi, not sure this is the right way to multi-tree merge https://lore.kernel.org/dri-devel/bc60a7fd-8de7-4856-b5ed-e1172b9b79f7@amd.com/
11:28emersion: maybe it is, but if it isn't, please reply :P
11:28sima: uh no
11:29emersion: yeah, i think i remember something about… not doing this lol
11:32sima: git doesn't realize it's the same patch, which means the 3-way merge gets extremely confused by the changed context and makes an absolute mess of it at merge time
11:32sima: hwentlan__, agd5f ^^
11:32sima: I'll reply on-list too
11:33emersion: ty
11:34tzimmermann: sima, thanks
11:36sima: hwentlan__, we should have a patch to dim docs that any kind of cherry-picking is for maintainers only, somehow this came up a few times recently
11:38sima: hwentlan__, https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria <- probably should add it here to the list of non-linear actions
11:38sima: something like "Any non-linear actions (like cherry-picking, backmerges, merging topic branches and sending out pull requests) ..."
11:38sima: if you could do the patch&mr?
11:40javierm: sima: what about backports from let's say drm-misc-next to drm-misc-next-fixes ? Should we ask maintainers to do that if is needed?
11:41sima: javierm, yeah, there's dim cherry-pick for that which helps with making sure you have dependencies and stuff like that
11:41sima: and subsequent bugfixes, if there's any
11:42javierm: sima: yes, I know. But was a question do your comment "any kind of cherry-picking is for maintainers only"
11:42sima: javierm, yeah imo cherry-picking to multiple trees or from -fixes to -next is just wrong, and cherry-picking from -next to -fixes has enough warts that you should inform maintainers anyway, so might as well put it on their shoulders
11:43javierm: sima: makes sense
11:43sima: it's also why dim cherry-pick is documented under the "cmds for maintainer" section
11:43sima: just that we have a few gaps in the docs where it's not clear enough
11:43javierm: got it
11:44sima: javierm, there's also some details like you must sob that cherry-pick and you really should put a full reference to the commit in -next in so it's less confusing for -next and cc: stable people
11:44sima: *linux-next I mean
11:45javierm: sima: but dim cherry-pick already does that IIRC
11:46sima: yeah it takes care of all that
11:46sima: but you need to know it exists :-)
11:46javierm: but still makes sense for me that should be on maintainers' shoulders. They may decide that is OK to wait for the next release, or that should really be part of the -rc cycle, etc
11:46javierm: so definitely seems to be something that is for them to weight in and decide the course of action
11:47sima: it's more that cherry-picks tend to create really entertaining conflicts
11:47mairacanal: javierm: thanks! now, i'm starting to work on upstreaming the dependencies of DRM (like Xarray)
11:47sima: in practice at least
11:48javierm: sima: yeah, and that's why maintainers can decide whether to cherr-pick to -fixes (and possibly cause a conflict) or just wait for the next release (if the fix is not critical or for a patch in this merge window, etc)
11:49javierm: sima: anyway, just wondered if your comment also applied to cherry-picking fixes and why I asked. Thanks for the confirmation :)
11:49javierm: mairacanal: nice!
14:28agd5f: sima, AGP in amdgpu has nothing to do with traditional AGP. The driver uses uses the AGP aperture for direct access to system memory (without going through a GPU page table) as an optimization. That got broken with a recent rework, so we disabled it, but we did finally fix it.
14:29agd5f: The on GPU AGP aperture just forwards requests directly to the bus
14:31agd5f: that said, I don't object to getting rid of AGP in general
14:58kusma: Did someone force-push to main recently?
14:58kusma: (mesa main, I mean)
14:59jenatali: kusma: the Marge problem was being discussed in #freedesktop
14:59kusma: Something went very wrong here, and I see commits without Marge's part-of tags in the recent commit history, exactly where things started diverging: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26077
15:00kusma: jenatali: OK, thanks
15:01jenatali: "oh, I should've check sooner: the error marge is giving ("these changes already exist in branch main") is actually correct, so this MR should be closed"
15:01agd5f: airlied, sima any objections to me including Felix' revert in my -fixes PR today?
15:01jenatali: Specifically https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26372
15:02kusma: jenatali: Yup, that's the one.
15:14Lynne: new dedicated sparse queue patches break vulkan video decode
15:14Lynne: why was it that CTS was not enabled for decode on radv again?
15:25Lynne: triggers the only assert in radeon_check_space()
15:35Lynne: moving the order in pQueueFamilyProperties fixes it for some reason, that function is not very straightforwardly written
16:14pepp: I'd like to add a new trace_dma_fence_sync_to event to debug sync issues - would that be ok or should I make this an trace_amdgpu_... event?
16:14pepp: (see the 2 top patches from https://gitlab.freedesktop.org/pepp/linux/-/tree/add_trace_dma_fence_sync_to_event for the current implementation)
16:38sima: agd5f, I'm still a bit confused since everyone is talking about the follow up in -next but the revert in -fixes, which is why I suggested to backport when actually needed
16:38sima: but also meh, just send it :-)
16:38sima: when/if actually needed
16:39sima: (there's some pretty simple syntax that you can add to the cc: stable for the first patch that needs the revert so it's not really any more work than other cc: stable)
16:39sima: airlied, ^^
16:39sima: agd5f, oh I've just seen christian's reply
16:40sima: agd5f, a-b: me for the revert in your -fixes pull today, that's very much a reason I can get behind :-P
17:19idr: Ugh. So... my MR failed debian-testing-asan. As far as I can tell... it detects a leak in fclose called from a unit test. :facepalm:
17:24idr: cmarcelo: Actually... the open_memstream(&my_string, ...) parameter has to be freed after the stream is closed.
17:26idr: But asan blames fclose because... it had the last pointer to it? It seems like it should blame open_memstream. That would have made the real problem more obvious.
17:43bwidawsk: melissawen: Any chance to look into modifiers for vkms?
17:45melissawen: bwidawsk, yeah, forgot to get back with findings. So, VKMS already supports MOD_LINEAR since it's added by DRM by default.
17:45melissawen: I also checked the IGT tests that use this modifier, and it's working as expected
17:45bwidawsk: melissawen: hmm, I guess I need to dig more than as to why I get back INVALID
17:45bwidawsk: thanks for looking
17:46melissawen: the only thing I found is that VKMS is not rejecting the MOD_INVALID properly
17:46bwidawsk: well, it's some gbm/vkms combo here, and I just sort of guessed it was vkms' fault
17:47melissawen: do you think it would be the case for your gbm case? a bad handling of MOD_INVALID from vkms?
17:48melissawen: I'm not used to gbm, so I'd need much more time to debugging the stack.
17:49bwidawsk: no, iirc it uses the regular bo_alloc without modifiers because modifiers2 interface isn't supported
17:49melissawen: let me know if you have any news from your side. I'll try to find a time to investigate the bad management of MOD_INVALID anyway
17:50bwidawsk: so this falls back to MOD_INVALID
17:50bwidawsk: melissawen: okay, I'll let you know if I find anything new
17:50bwidawsk: Is there a way to limit drm.debug to only a specific card?
17:51emersion: melissawen: KMS drivers can't indicate that INVALID is not supported
17:51emersion: IOW, INVALID must always be supported
17:51emersion: in general, drivers assume LINEAR in trhat case
17:53daniels: idr: asan blames fclose because, unless you explicitly flush, the file only gets flushed on close
17:57bwidawsk: emersion: so I guess the ultimate question is should I able to allocate a LINEAR buffer from vkms
17:57bwidawsk: because it doesn't seem to work (for reasons I haven't debugged)
17:57zamundaaa[m]: bwidawsk: it's not vkms, llvmpipe is the issue
17:57zamundaaa[m]: See https://gitlab.freedesktop.org/mesa/mesa/-/issues/9373
17:57emersion: https://drmdb.emersion.fr/snapshots/9db7376259c4
17:58emersion: apparently vkms doesn't have DRM_CAP_ADDFB2_MODIFIERS?
17:58emersion: ie, it advertises lack of modifier support
17:58bwidawsk: emersion: yes, that's what I saw
17:58zamundaaa[m]: Heh, maybe there's multiple issues :D
17:59bwidawsk: zamundaaa[m]: in my case I am not using llvmpipe
17:59bwidawsk: this is with a pixman renderer
18:00zamundaaa[m]: Okay, that's unrelated then
18:02bwidawsk: it /seems/ like it should be an easy thing to fix
18:03bwidawsk: but I also vowed not to write any more kernel patches, so it's a stalemate
18:04melissawen: emersion, I can inspect better but I don't think the missing CAP is the case, since when running IGT kms_addfb_basic VKMS always pass the `igt_require_fb_modifiers` requirement
18:05melissawen: IIRC, this is the failing subtest: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/kms_addfb_basic.c?ref_type=heads#L710
18:06melissawen: vkms passes the requirement, but fails in rejecting the ioctl
18:06emersion: `bwwhy no more kernel patches?
18:06emersion: bwidawsk: ^
18:07bwidawsk: I lost the grit to write 37 versions of the same patch
18:07bwidawsk: though writing drivers in Rust is very appealing
18:08bwidawsk: and I did notice VGEM was being rewritten in Rust
18:08bwidawsk: though I can't seem to find a good use for vgem
18:20sewn: why was commit 0a564171f63eac6d81bbcb2aae72c788747c3c02 not included as part of the 23.3.0 release?
18:22sewn: if it was before commits that were included in the release
18:26kisak: sewn: https://gitlab.freedesktop.org/mesa/mesa/-/commit/0a564171f63eac6d81bbcb2aae72c788747c3c02 Branches containing commit -> main which tells us the merge request is after the branchpoint. https://gitlab.freedesktop.org/mesa/mesa/-/blob/23.3/.pick_status.json?ref_type=heads#L16385 nominated false means it wasn't marked for backport.
18:26sewn: oh i see
18:26sewn: thanks
18:28melissawen: emersion, the drmdb snapshot seems outdated, probably since https://patchwork.freedesktop.org/patch/471383/ (?)
18:28melissawen: than, maybe an old kernel is the issue of bwidawsk too (?)
18:29emersion: ah right
18:29melissawen: I'll send a new kernel to drmdb to populate it anyway
18:31melissawen: https://paste.debian.net/hidden/d2345c09/ <- using kernel 6.3
18:31bwidawsk: hmm, I don't think this is the case for me
18:31bwidawsk: I think the oldest I have anywhere is 6.3
18:32bwidawsk: I will try again, when I get out from under the pile
18:33bwidawsk: melissawen: ^^
18:33melissawen: if you can try current drm-misc-next is the best option
18:33bwidawsk: melissawen: thanks for digging into it
18:33bwidawsk: yeah, I can do that when I have something that builds again :D
18:34melissawen: I'm trying vkms on amd-staging-drm-next tree because it's my current working tree
18:35emersion: melissawen: nice!
18:37melissawen: bwidawsk, no problem. and sorry for delaying. I wanted to inspect more again before replying you and I ended up missing the timing :(
19:11idr: daniels: Ah. That makes sense. It's fixed now anyway. :)
21:44alyssa: any idea why KHR-GL33.packed_pixels.rectangle.* would fail while KHR-GLES3.packed_pixels.rectangle.* passes?
21:44alyssa: like.. those should be the same, no?
21:47idr: alyssa: There might be different formats available in GLES and desktop GL? Or at least different formats tested.
21:49alyssa: idr: yeah, seemingly
21:49alyssa: but..
21:50alyssa: Gradient comparison failed during ReadPixels for input = [GL_RGBA, GL_UNSIGNED_BYTE] output = [GL_BGRA, GL_UNSIGNED_INT_8_8_8_8
21:50alyssa: I find it... unlikely that BGRA8 readpixels is broken, that would be breaking a lot more than this CTS case
22:00alyssa: (and the trace looks fine..)
22:01idr: That is odd. :(
22:03alyssa: Ooooooh
22:03alyssa: setting pipe_cap_texture_transfer_modes = default, the test passes
22:04alyssa: with = blit, fails
22:05alyssa: granted iris has it =blit too, but
22:05alyssa: apparently my blits are broken /somehow/
22:08alyssa: but its.. just util blitter..
22:09alyssa: and it's.. specifically bgra8..
22:11alyssa: but ARGB8 and BGRA4 are seemingly fine?!
22:13airlied: do the test results file say what pixels are wrong?
22:13alyssa: <Text>Non-integer comparison: 1, 0, 18, 0.00787402: 0.141176 == 0.0705882: not equal.</Text>
22:14airlied: wierd it's like half the value
22:14alyssa: I assume it's BGR channel swapped
22:14airlied: maybe a missing swizzle somewhere
22:16alyssa: presumably, but the trace looks right and I'd expect more fireworks if that were wrong
22:38glehmann: does any of the non amd hw have an instruction for u2u32(pack64(a, b) >> (c & 0x1f))?
22:41alyssa: glehmann: agx does
22:42alyssa: well, almost
22:42alyssa: wrong
22:42alyssa: wrong mask on c because agx (-:
22:42alyssa: gotta love inexplicably non-sm5 shifts
22:43alyssa: the agx instruction also has an optional mask on it
22:43alyssa: extr (Extract From Register Pair)
22:43alyssa: https://dougallj.github.io/applegpu/docs.html
22:50HdkR: ooo, it supports extr with a register specifying the lsb? That's nice
22:56alyssa: HdkR: consolation prize for no 64-bit shifts
22:57alyssa: Ooooo. I think the problem is actually ARGB, not BGRA
22:57alyssa: yay endianness
22:57alyssa: :p
23:01alyssa: yep. siiigh
23:01alyssa: thanks for rubberducking :)
23:05alyssa: yep. just needed to invert swizzles when writing out
23:49illwieckz: Do someone knows a bit about glvnd? What problems is it trying to solve? Unless we do something wrong with the Dæmon game engine, accumulated experience over two years is that building an OpenGL application with GLVND ABI instead of LEGACY one 1. breaks compatibility with legacy Nvidia drivers, 2. breaks compatibility with AMD OGLP driver, 3. breaks compatibility with Wayland with Prime…
23:53illwieckz: Is glvnd expected to be backward compatible and all of these problems are bugs, or is it considered OK that maybe only current Nvidia drivers on Xorg is expected to work and we are just lucky if current Mesa drivers are compatible with it on Xorg too ?
23:54Kayden: so there are two aspects to glvnd
23:55Kayden: first is just the new vendor neutral dispatch library. glvnd provides libGL.so, and it loads the vendor drivers (libGLX_mesa.so, libEGL_mesa.so, libGLX_nvidia.so, etc)
23:55Kayden: that should be fully backwards compatible, and is meant as a way to let you parallel install mesa drivers, nvidia proprietary drivers, fglrx (not that that's a thing anymore) & whatever else
23:56Kayden: as long as you're linking against libGL.so it should not matter whether it's glvnd or mesa or nvidia directly
23:56illwieckz: I guess I never seen backward compatibility to be working, then
23:56Kayden: but it sounds like you may be running into the second aspect
23:56Kayden: which is...glvnd decided to define a new ABI for OpenGL, libOpenGL.so
23:56Kayden: which is not backwards compatible
23:56illwieckz: yes, that's my concern
23:57Kayden: IIRC it only has OpenGL core profile support. It also does not contain GLX
23:57Kayden: libGL has both OpenGL core, OpenGL compatibility (legacy), and GLX
23:57Kayden: which is awkward if you're trying to do, say, EGL only, on a non-X11 windowing environment
23:57illwieckz: so, does it mean that I can build an app with -DOpenGL_GL_PREFERENCE=LEGACY
23:58illwieckz: but use a glvnd libGL.so ?
23:58Kayden: I've not heard of that flag, but yes, it should be possible
23:58Kayden: you shouldn't have to target libOpenGL.so as an app / engine author unless you -want- to
23:58illwieckz: that's the cmake flag for selecting either LEGACY ABI or GLVND ABI
23:58illwieckz: ok, good to know
23:59illwieckz: because CMake defaults to -DOpenGL_GL_PREFERENCE=GLVND
23:59illwieckz: even if the developer has no idea this will break backward compatibility if I understand it right