00:46redeeman: hello, what assumptions does userspace make about /dev/dri/renderD* devices? if there are no permissions to renderD128, will is renderD129 supposed to be attempted? a quick test shows that "vulkaninfo" does indeed do that, but mesa prints an error with permission denied. glxinfo does not print an error, but continues to work. I ask because I run a multiseat setup, and i notice both have 0666 permissions, and im thinking that I would
00:46redeeman: quite prefer one seat not to touch the others graphics card for any reason at all
02:34dcbaker: karolherbst: 1.2.0-rc1 will branch soon, and those rust fixes will be in. The -I stuff didn’t land, so we may need to do something different there in the short term
07:29hakzsam: olv: do you plan to update https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23117 ?
07:33olv: yeah, I should be able to get to tomorrow or the day afer
07:34olv: sorry for the delay
07:45karolherbst: dcbaker: okay. the flag stuff is easy to workaround though, or rather the current workaround doesn't look too ugly, so that's fine
07:45karolherbst: ohh wait.. on debian it's broken.. nvm
08:17pq: redeeman, I think that depends on how each application picks the GPU it wants to work with. Window system may give hints that apps might follow, but if something tell the app to really this particular "wrong" GPU, then naturally it won't work.
08:17pq: redeeman, so it depends on what API the app is using in the first place, and does it give the API implementation an opportunity to pick an arbitrary GPU.
08:18pq: redeeman, if there is exactly one GPU for a seat, I guess you could try setting DRI_PRIME to a devpath in the environment.
08:19pq: redeeman, https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME
08:21pq: it won
08:21pq: it won't work for everything, I think Mesa EGL Surfaceless platform does not use DRI_PRIME for picking the EGL_DEFAULT_DISPLAY.
09:06karolherbst: anholt_: yeah soo.. I think the current blockers on v3d are better handling of load/stores and kinda deal with 8/16 bit types. My load/store global impl is best effort but I think I missed a few things: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/476162c8136ebd19865f84073fcb00a8f06ddd96
09:51kchibisov: Is mesa not supporting EGL_KHR_display_reference?
10:52redeeman: pq: there is one gpu for each seat, would you also agree that it is probably most correct to not let seats cross contaminate? my attention was drawn to this when amdgpu_top was able to access both gpu's, but even more to my horror, chrome seems to allocate vram on both gpu's
10:55pq: redeeman, yes, I agree. If you want separation, you should be able to have separation.
10:56pq: especially when you already have completely separate GPUs to begin with
11:00redeeman: i'll give it a go and just change the permissions out to match the seat permissions that are already enforced on the card devices and see, I just wanted to know if there was some assumptions from userspace that was known to break in 100 ways
11:01pq: nothing that I know of, but I also don't know how things handle not having access to a render node
11:02pq: render nodes are supposed to be safe in that they already isolate user contexts from each other
11:02pq: but of course, isolating contexts does not stop someone from hogging all VRAM or GPU time
11:02pq: hence dedicating a GPU per user makes sense to me
11:03pq: well, per seat
11:34alyssa: zmike: do interpolation qualifiers (flat/noperspective) need to match between the VS/FS when GPL/ESO are used?
11:34alyssa: as far as I can tell:
11:35alyssa: - OpenGL always gives enough information to match them without variants. ARB_separate_shader_objects requires the qualifiers to match. And linked shaders, you can just specialize at link time without variants.
11:36alyssa: - Vulkan monolithic pipelines, same as the GL linked shader case
11:38alyssa: - Vulkan 1.3 explicitly does not require the qualifiers to match (15.1.3 "Interface matching")
11:39alyssa: - Vulkan EXT_shader_object spec says nothing about interpolation qualifiers. So seemingly this allows them to NOT match. This may or may not have been intended.
11:40alyssa: - Vulkan GPL has a feature bit for this purpose: graphicsPipelineLibraryIndependentInterpolationDecoration
11:40alyssa: Although...
11:40alyssa: GPL proposal 5.6 comments
11:40alyssa: "Some implementations require the interpolation decorations in the last geometry shader stage if pipeline libraries are used, and this is advertised by the graphicsPipelineLibraryIndependentInterpolationDecoration property. It is expected that these implementations are serving markets where OpenGL ES is dominant, where this requirement was never dropped for separate shader objects, unlike OpenGL"
11:41alyssa: So apparently the GL requirement dropped at some point...
11:49alyssa: According to Khronos wiki, GL 4.3 but I can't find a better source https://www.khronos.org/opengl/wiki/Type_Qualifier_(GLSL)#Interpolation_qualifiers
11:54alyssa: DXVK hard requires graphicsPipelineLibraryIndependentInterpolationDecoration for GPL support https://github.com/doitsujin/dxvk/blob/0f4458e173749187c3900533196bf0327bc9fe80/src/dxvk/dxvk_device.cpp#L50C1-L57
12:11alyssa: Bottom line is that we'll need to handle it for DXVK. Oh well.
12:11alyssa: It's not the end fo the world. Annoying that this information is so spread out across Khronos specs.
12:19pq: someone is still using skynet.ie address for airlied on mailing lists and I get tons of failed to deliver from gmail when replying.
12:20pq: "Gmail will retry for 140 more hours. You'll be notified " again and again
12:22lordheavy: Hi everybody, i'm just here to get some help; rusticl doesn't work here - clinfo doesn't detect any device and i don't know how i can't fix this problem. I use llvm/libclc/mesa from git under archlinux
12:23lordheavy: Here are some usefull (i hope) information how i build the packages: https://paste.xinu.at/EWg6r6/
12:24lordheavy: Output from clinfo without/with RUSTICL_ENABLE=radeonsi: https://paste.xinu.at/1JfORu/ https://paste.xinu.at/0cl/
12:25lordheavy: Output from glxinfo: https://paste.xinu.at/43T/
12:25lordheavy: Thanks for your help :)
12:40karolherbst: still trying to wrap my head around all that DRM stuff, but inside drm_crtc_helper_funcs::mode_valid, can I know what connector the mode is requested on? It's really a pita that I can reject userspace modes inside drm_connector_helper_funcs::mode_valid.. and I kinda need something which comes closest to that.
12:42karolherbst: or is it "good enough" for atomic and non atmic uapi users to do that validation inside drm_connector_helper_funcs::atomic_check?
13:01pq: Is https://docs.mesa3d.org/gallium/distro.html the page that is supposed to tell me what are "iris" or "crocus" or "i915" when used to refer to "gallium drivers"? Or maybe the "Drivers" section on the navigation bar on the left?
13:03pq: https://docs.mesa3d.org/amber.html is almost telling me what I wanted to know, but I also am specifically not wanting amber, so I wouldn't have known to look there.
13:07FLHerne: pq: iris and crocus definitely belong in that Gallium list
13:09FLHerne: probably in the 'Drivers' section too although that seems a fairly random assortment
13:09FLHerne: could do with some more links from https://docs.mesa3d.org/systems.html
13:09FLHerne: I note 'Drivers' lacks an index, and some pages explain what they are whereas some assume you know and go straight into details
13:12pq: What is "Gallium Off-screen rendering" and why does it default to "NO" in the Meson summary?
13:29MrCooper: pq: I believe that's the Gallium version of OSMesa, a special API for offscreen software rendering
13:30pq: oh, osmesa, ok
13:32MrCooper: lordheavy: RUSTICL_ENABLE=radeonsi is required, it can't find spirv(64)-mesa3d-.spv
14:15Lynne: I haven't been able to get rusticl to run either, despire running fine on iris
14:26karolherbst: is there actually a reason why we don't validate userspace modes? Seems like even if atomic_check fails, X is silly enough to set the mode regardless and stays on it?
14:26karolherbst: or rather... do we have a 100% reliable way to fail a requested modeset from non atomic userspace so it uses a different mode or something?
14:27pq: karolherbst, what do you mean set the mode regardless? Isn't atomic_check called as part of atomic_commit so it fail the whole commit?
14:27karolherbst: yeah, but X doesn't seem to care
14:29pq: The mode doesn't get set, Xorg cannot force its way through that. It can just sit there broken, but it cannot force the mode if the driver fails it.
14:29karolherbst: okay, let me rephrase: X sits there broken
14:29pq: ah
14:29karolherbst: and gives me a black screen
14:29karolherbst: but actually.. I just want to reject broken userspace modes
14:29karolherbst: like.. entirely
14:30karolherbst: I also don't know why we don't run mode_valid on userspace modes on connectors...
14:30pq: if you already make the drmModeSetCrtc() ioctl fail, you've done it already. If X doesn't handle that failing, it's X's fault.
14:31karolherbst: I don't actually know what userspace does and what ioctl fails.. maybe I should check that...
14:31pq: Xorg only uses legacy non-atomic UAPI, which the kernel translates to internal atomic API.
14:31karolherbst: right
14:32pq: So if you fail the internal atomic commit, you're done.
14:32daniels: *atomic check
14:32karolherbst: yeah.. but that leaves users with broken systems, because Xorg adds broken modes
14:33karolherbst: people don't want xorg to not do that, so that leaves me with dealing with that mess
14:33karolherbst: but we also don't reject broken modes, so... kinda sounds like our fault
14:33pq: daniels, isn't atomic check is called from inside atomic commit? I presume one cannot commit without also going through check.
14:33daniels: so there's not really an 'add mode' step; drmModeSetCrtc takes a completely random DRM mode struct which userspace can fill with anything it wants, even if it hasn't passed it to the kernel first
14:34karolherbst: okay.. fair
14:34daniels: pq: DRM_IOCTL_MODE_ATOMIC will call atomic_check() followed by (if you haven't passed TEST_ONLY) atomic_commit(); DRM_IOCTL_MODE_SETCRTC will call both
14:34pq: daniels, exactly.
14:35karolherbst: okay soo, here is the deal.. X doesn't fall back when starting with a broken mode
14:35pq: what would it even fall back to?
14:35karolherbst: a mode it didn't add?
14:35karolherbst: I mean.. if xorg tries to set to a state with its own mode and it fails, it's kinda its own fault for trying so, no?
14:36pq: Xorg uses exactly the mode that the config or X11 clients tell it to.
14:36karolherbst: I've been there already
14:36karolherbst: it does try something on its own
14:36karolherbst: gnome doesn't add those modes
14:36karolherbst: and apparently xorg shouldn't as well? what is it now
14:36karolherbst: I've seeing custom modes that _I_ didn't configure
14:37MrCooper: karolherbst: just stop caring about Xorg :)
14:37karolherbst: yeah.. I mean.. fine by me, but then users still have to be able to migrate or something
14:37karolherbst: but yeah, can also just close all bugs with xorg as "invalid"
14:37MrCooper: the vast majority of them are able to migrate
14:37jannau: karolherbst: gnome is adding modes (under speficic conditions)
14:38karolherbst: it's not about being able to
14:38karolherbst: it's about forcing them to
14:38karolherbst: jannau: yeah.. but in this case it's X
14:38karolherbst: because I see those modes without gnome running
14:38MrCooper: think of it as encouragement
14:38karolherbst: uhhh.. I wish _I_ could move to wayland for testing, but apparently today we can't even select the main GPU in a multi GPU setup
14:39karolherbst: which I really need
14:39pq: DRI_PRIME?
14:39karolherbst: not for rendering
14:39karolherbst: for compositing
14:39pq: yes, for compositing
14:40karolherbst: if that works... but anyway, I kinda wished X just wouldn't do this...
14:40pq: set that for the compositor, does it not work? Though I guess it defaults to the same GPU that drives the outputs in most compositors.
14:42pq: On Wayland compositors the choice of a GPU and display DRM devices is up to each compositor, and not Wayland, so it can vary.
14:42karolherbst: right
14:43karolherbst: but anyway
14:43karolherbst: I really just need a way to deal with that mess without breaking users machines
14:44lordheavy: MrCooper Lynne: Either with RUSTICL_ENABLE=radeonsi - it doesn't work - except "Libclc failed to load. Please make sure it is installed and provides spirv-mesa3d-.spv and/or spirv64-mesa3d-.spv" message - but libclc is installed with both spirv-mesa3d-.spv and spirv64-mesa3d-.spv
14:45karolherbst: maybe it doesn't really find the correct path? where are those files installed?
14:45lordheavy: Rusticl isn't very verbose about the problem. Is there any way to have more verbosity ?
14:48karolherbst: lordheavy: the path kinda has to match libexecdir, but you can probably also check with strace where it tries to search for it
14:48lordheavy: karolherbst: clc is installed in /usr/lib/clc
14:49karolherbst: does the path of libclcs pkgconfig file point to the same location?
14:49karolherbst: but anyway.. strace should also tell you where it tries to load it from.. gimme s ec
14:50karolherbst: RUSTICL_ENABLE=lp strace -s 512 clinfo 2>&1 | grep -i spv
14:50karolherbst: openat(AT_FDCWD, "/usr/lib64/clc/spirv64-mesa3d-.spv", O_RDONLY) = 3
14:50lordheavy: karolherbst: good catch! path is libexecdir=/usr//usr/lib/clc
14:50karolherbst: uhhh
14:50karolherbst: what a weird path :)
14:51lordheavy: lol yes i know now how to fix that :)
14:52karolherbst: I don't know if meson picks up a change in the pkgconfig file itself, but probably
14:55zmike: alyssa: good talk
14:55alyssa:gives zmike a thumbs-up
14:56alyssa: zmike: possibly Zink should refuse to GPL if the vulkan driver doesn't advertise graphicsPipelineLibraryIndependentInterpolationDecoration though
14:57alyssa: purely theoretical issue since {nvidia, all current mesa drivers} advertise that
14:57alyssa:doesn't really care
15:05lordheavy: karolherbst MrCooper: fixed, thanks - now it works
15:06karolherbst: also... would _anybody_ scream if we pipe modes through connects mode_valid callback?
15:07karolherbst: I really need a way to reject modes through mode_valid based on the connector used... e.g. for rejecting modes used on HDMI displays based on the clock
15:07karolherbst: and the other places don't cut it
15:07karolherbst: encoder doesn't, because at this point I only know it's TMDS and that _might_ be duallink
15:08karolherbst: and doing it on the crtc is kinda... "weird", or maybe it's the proper place?
15:08_jannau__: karolherbst: I think nouveau might miss drm_mode_config_funcs::mode_valid
15:08karolherbst: yeah, it does
15:09karolherbst: and I already implemented that.. kinda
15:09karolherbst: or wait...
15:09karolherbst: is that another one?
15:09_jannau__: that gets the connector as argument and I think it will be called from setcrtc
15:09karolherbst: ehh no, that's not useful
15:09karolherbst: it only gives me the dev and the mode
15:09karolherbst: but the mode might be fine on other connectors
15:10karolherbst: like... 240MHz rate might be fine on duallink DVI, but not on HDMI
15:10karolherbst: I really really _really_ have to know what connector it's used on
15:11karolherbst: drm_connector_helper_funcs::mode_valid would be the _perfect_ place for it, but it's not called on userspace provided modes
15:11_jannau__: oh, sorry. I missed that we currently just map that onto the connector in apple drm since there is just one connector
15:11karolherbst: yeah... kinda figured that :D
15:12karolherbst: I currently reject the mode in the encoder callback
15:12karolherbst: but that only works because the mode I see is really crazy
15:12karolherbst: so on some GPUs we can only do 165MHz HDMI (or lower), doubled with DVI duallink, but the mode in question (356MHz) is over that in either case
15:13karolherbst: but a 200MHz HDMI mode would be accepted there :/
15:13karolherbst: because the encoder is "TMDS" which can be either
15:22_jannau__: drm_atomic_helper_check_modeset docs suggests that the mode is checked in drm_connector_helper_funcs.atomic_check
15:22karolherbst: yeah, but not userspace ones
15:24karolherbst: so.. what it's used on is to filter modes the kernel tells userspace exist
15:24karolherbst: but it's not used on modes userspace then tries to set
15:24karolherbst: I suspect just checking when doing atomic_check is the only _currently_ working way of doing this then
16:44karolherbst: okay.. I think I'm done implementing the mode check
16:44karolherbst: do you think this looks sane? https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/8ad0190520652e199c6f9706d9401e3314b4c3db
16:45karolherbst: seems to work good enough with non atomic C
16:45karolherbst: *X
16:46karolherbst: and it looks like gdm can recover from the default mode being broken? mhh
17:00karolherbst: heh.... with the nouveau DDX I don't get random modes.. guess it's modesettings doing then
17:20idr: Could someone who knows more about the clc paths weigh in on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23903#note_1979316?
17:20idr: It sounds like there's a pre-existing bug that we've just been lucky to not hit.
17:22karolherbst: we resolve those functions really really early
17:41jenatali: For now, anyway. The more cleanup we do could enable things to be unresolved until later
17:56JoshuaAshton: alyssa, zmike: Yeah, we hard require graphicsPipelineLibraryIndependentInterpolationDecoration in DXVK also
17:58idr: karolherbst: So... do you think that particular hunk is okay?
17:58karolherbst: I'm sure if it isn't CI will scream at you
17:58idr: If things change in the future... it will show up as graceful test failures (due to failing linking) or ... ?
17:58karolherbst: (or whoever assigns to marge)
17:59karolherbst: yeah soo.. piglit kinda relies on this... think...
17:59karolherbst: yeah.. I'm sure we have builtin tests
17:59karolherbst: mhh though those might be different.. let me check something
17:59idr: Okay. I just wanted to be sure that this change wasn't going to make things worse... now or in the future.
17:59jenatali: I think it can only improve things
18:01karolherbst: yeah.. so piglit tests that calling external functions works