06:23 urja: Okay so, this is a quick "if someone has an idea" kind of question... basically, i've built my own linux system (armv7h / for the ASUS C201)
06:24 urja: and i built mesa with panfrost,kmsro,swrast (no llvm so softpipe)... the thing is, in weston i get panfrost just fine, but if i'm running sway i get softpipe
06:24 urja: (and an error message about mesa looking for zink dri)
06:25 urja: mesa 24.0.5, weston 13.0.0, sway 1.9 (if any of those mattered)
06:51 kode54: that's got EGL, right?
06:51 kode54: (probably a dumb question)
06:53 urja: I assume so :P, i can run eglgears_wayland in both situations
06:53 urja: just in sway its 18 fps softpipe vs in weston i get smooth (vsync-locked i assume) panfrost
06:54 urja: okay actually idk about the fps because eglgears does not print it, but i can see it (and glxgears in the same situation is 18 fps)
06:59 kode54: emersion: should urja drop into #sway on libera.chat with this too?
06:59 emersion:reads
07:00 emersion: aha, i thought it was a weston question, but that was just a disguise!
07:01 kode54: yeah, weston was thrown in as an example of something that is apparently behaving
07:01 urja: yeah weston is the reference system that's working as it should (so i dont know why sway isnt) :P
07:01 emersion: can you obtain debug logs of sway? (sway -d >sway.log 2>&1)
07:02 emersion: and yeah, #sway is probably a better place
07:04 urja:is reading over the debug log now....
07:04 urja: again a thing i didnt realize to do (because i'm not familiar with sway so i didnt realize that was an option, somehow)
07:05 emersion: what is your display driver btw?
07:07 urja: rockchip (as in, RK3288 running the integrated panel over eDP, so rockchip drm in the kernel for the display... panfrost for the rendering)
07:08 tzimmermann: airlied, i'm going to send the drm-misc-fixes PR in a minute. sorry for being late this week
07:11 urja: i took a log where i ran eglgears_wayland for a couple of seconds and then closed sway again
07:12 urja: http://urja.dev/sway.log.txt
07:17 emersion: hm that's weird
07:17 emersion: it doesn't even attempt GL
07:19 emersion: can you confirm that wlroots has been built with GLES2 support?
07:19 emersion: /usr/include/wlr/config.h should tell
07:19 emersion: (WLR_HAS_GLES2_RENDERER)
07:20 emersion: can you try forcing WLR_RENDERER=gles2 in the env, just to see the error?
07:24 urja: oo, wlroots... yeah it might not be
07:25 urja: context: i tried building the system without GLES2 until i realized weston can't do desktop GL, then enabled GLES2... but i think i didnt rebuild wlroots (only sway itself, umm)
07:25 emersion: makes sense
07:26 urja: "I'm building a desktop setup, what do i need GLES2 for" *disables GLES2 for faster build* then *hours later* "oh, everyone is using GLES2 now, right, didnt know"
07:27 emersion: yeah, GLES is basically a trimmed-out version of desktop GL
07:27 emersion: so using GLES gives wider hw support than desktop GL
07:27 emersion: trimmed-down*
07:29 urja: yes "Cannot create GLES renderer: disabled at compile-time"
07:30 emersion: aha!
07:30 emersion: we could probably better log this situation
07:30 emersion: in the case where the renderer is auto-selected'
07:40 javierm: tzimmermann: hi, I was about to ask if you noticed the simpledrm thread but I see you answered already and also pq
07:40 urja: yes, this is the package for which i had to give an empty list of renderers to build (i didnt have vulkan nor gles2), and wondered that "that's weird" and then forgot about when i was enabling gles2
07:41 urja: Thank you a bunch, it works now (glxgears running in vsync under sway)
07:41 tzimmermann: javierm, sure. i did
07:44 javierm: tzimmermann: yeah me too. But didn't notice pq and your answer before sending mine
07:44 tzimmermann: we all typed in parallel (or concurrently?)
07:45 pq: haha
07:45 pq: did we agree?
07:46 tzimmermann: afaiu we all said that userspace needs better hotplugging support
07:46 pq: seems so
07:46 javierm: yeah
07:47 pq: does simpledrm actually do what's doc'd for hot-unplug?
07:47 tzimmermann: pq it does
07:47 pq: cool
07:47 tzimmermann: it's trivial. the only operation to handle is a pageflip
07:48 javierm: pq: the tricky part is for real drivers to decide when to kick out the video devices that conflict with their aperture
07:49 javierm: if they do it too early, then cold be that their probe fails and the machine doesn't have a video output anymore
07:49 javierm: but if they do it too late, it may be that simpledrm stops working anyways because the driver messes with the system framebuffer setup
07:50 javierm: simpledrm is realy just a best effort...
07:52 tzimmermann: what javierm says ^, and i don't think we can give any guarantees for anything here. and simpledrm is still a best-case scenario. in a worst case, the user could hotunplug device 1, and only then physically plug-in device 2. userspace should still be able to survice that.
07:52 javierm: what I'm trying to say is that the gap between /dev/dri/card0 goes away and a /dev/dri/card1 is registered may vary per DRM driver, but still doesn't change the fact that user-space needs to cope with hotplugging
07:55 javierm: tzimmermann: indeed. It could be doing a rmmod or the bind/unbind sysfs entries
08:00 tzimmermann: javierm, BTW, could you take a look at https://patchwork.freedesktop.org/series/133285/ and https://patchwork.freedesktop.org/series/133283/ ?
08:03 pq: sounds like we all agree
08:05 emersion: i agree as well
08:05 emersion: but it's a bit tricky to handle in user-space
08:07 emersion: in particular, the DRM device is used to decide what kind of renderer is created on startup (GL on same GPU, software rendering, etc)
08:07 derr: everyone have a drm device... ? -ubernoob
08:07 derr: i cant choose between software and opengl in my cs anymore.
08:10 derr: 'responsible for interfacing with gpu' i dont even have a real gpu i think so, guess not.
08:10 tzimmermann: emersion, how does userspace handle multi-gpu output? for example, a gpu on pci plus a usb-attached display?
08:11 tzimmermann: how does it pick a renderer?
08:12 emersion: most user-space has a concept of "primary GPU"
08:12 emersion: primary GPU goes away, compositor goes down
08:14 tzimmermann: i see
08:17 derr: i was here a while ago having my mesa drivers fixed, in the process , there are some minor font issues, i try to export LC_ALL="en_US.UTF-8" but not working. for steam\counter-strike.. anyone have experience ?
08:18 jadahl: what is the simpledrm thread that is to some degree about hotplugs?
08:18 tzimmermann: emersion, in EGL, there used to be a EGL_CONTEXT_LOST event that signealled that the rendering context became invalid. i assume that the compositors would have to reintialize their graphics output on hotplugs of the primary device and send out such an event to all applications (?) and then it becomes the applications problem (?)
08:18 jadahl: is it the same thing as before about compositors launching with simpledrm before the real driver becomes ready?
08:19 tzimmermann: jadahl, yes
08:19 tzimmermann: https://lore.kernel.org/dri-devel/87seyqce3q.fsf@minerva.mail-host-address-is-not-set/T/#mfb583addbc8f38c8d2ae56faba09b47f65ab5c07
08:20 emersion: tzimmermann: yes, some compositors do that already, and that is easy to do because you're more or less guaranteed that you'll end up with a new GPU context that looks the same as the old one
08:20 jadahl: in the past discussions about it, I tried to make it clear that it is not ok to launch the compositor during the pre-real-driver phase, because it screws up how the initial animations behave
08:21 emersion: tzimmermann: it becomes trickier when you have intermediate state with no GPU at all, or when the pixel formats change, etc
08:21 emersion: *supported pixel formats
08:22 jadahl: (ignoring the part about primary-gpu-unplug not working anywhere, which arguably is a different but related bug)
08:22 tzimmermann: emersion, i suggested to keep the primary device's devfile open until a new primary device shows up. there's no need to signal context-lost before that
08:23 emersion: do we even have a GPU context with simpledrm?
08:23 tzimmermann: jadahl, there's no way of knowing that a real driver will be comming. sometimes simpledrm is all you get
08:23 tzimmermann: emersion, only for software rendering
08:23 emersion: wouldn't the compositor start with software rendering with simpledrm, and then need to switch to GL when the real driver takes over?
08:24 tzimmermann: but simpledrm is a special case of a larger problem
08:24 emersion: switching from a software renderer to a GPU one wouldn't really be possible
08:24 jadahl: tzimmermann: I know that, but there are ways "around" it (in theory), e.g. dumb timeout, drivers notifying that they are starting to load, and then after initial probe say the didn't find anything, and so on
08:24 tzimmermann: emersion, IDK what userspace uses for softwar rendering
08:25 emersion: dumb buffers, pixman
08:25 emersion: (or llvmpipe maybe)
08:25 jadahl: tzimmermann: what is not acceptable is starting e.g. gdm with simpledrm, then switching to a real GPU a second later
08:25 jadahl: as it creates a terrible user experience
08:25 tzimmermann: jadahl, it's a distributed system. none of these solutions will solve the problem. you don't know whether a native driver is comming
08:26 emersion: yea
08:26 jadahl: tzimmermann: even if its not solvable in 100% of the cases, I can't imagine it's not solvable for the majority
08:26 jadahl: not to mention that from userspace's perspective, it's a regression
08:27 jadahl: (majority of users, e.g. normal system with a amdgpu attached etc)
08:28 jadahl: I agree that hot-unplug is something that should be supported by userspace, but for e.g. a regular computer with a amdgpu to no longer being able to get a decent looking login experience is a regression no matter how you see it
08:30 emersion: also hot-unplug support is not something you can quickly implement, in general it requires very intrusive major changes to userspace
08:30 tzimmermann: jadahl, even with the old fbdev drivers, it's always been like that. back then we had bugs where we had to disable the output to fix the boot
08:30 jadahl: I imagine if it'd happen, the screen in some cases would go from bland to bright, or bad gradients to good gradients, etc, if the real gpu driver has graphics capabilities the simpledrm one hasn't
08:31 jadahl: tzimmermann: something made it "work", because I have no memories of bug reports about it until simpledrm->real-drm-driver transitions started to happen
08:33 jadahl: either way, why can't drivers coordinate with the kernel about "probing started, probing ended, found N relevant devices" ?
08:33 tzimmermann: just shouting "regression" is not helpful IMHO. the first priority should be to work around these crashes. and my comments on the start-up timeouts was a reminder that the problem is not just in simpledrm. it's any hotplugging
08:33 karolherbst: it feels this entire problem space would go away if compositors would move away form "single rendering context" model
08:33 karolherbst: which they should do anyway
08:33 jadahl: karolherbst: no, it wouldn't
08:34 emersion: karolherbst: yes, but loooots of work
08:34 karolherbst: why not? If your driver changes, then it's just like moving to a different display (e.g. for muxed internal ones)
08:34 emersion: we don't disagree here, but the current model still needs to keep working
08:34 karolherbst: yeah, fair
08:34 jadahl: karolherbst: the problem is that when we boot, and and end up at the gdm screen, we'll "soft animate" the login gui elements. with simpledrm, we always disable animations, so they'd just plop up
08:34 tzimmermann: jadahl, because driver modules come and go, and hardware devices come and go. there is no start-probing/end-probing
08:35 emersion: jadahl: why do you disable animations?
08:35 karolherbst: jadahl: yeah, but a compositor being able to handle "the gpu for this display changed" would also be handle "the driver changed" situations
08:35 karolherbst: *be able to
08:35 jadahl: emersion: because animations + software rendering isn't a good combination
08:35 emersion: i got confused by the "soft animate"
08:35 karolherbst: probably at least
08:36 jadahl: emersion: soft as in "smoothed in"
08:36 jadahl: I should just have said "animate"
08:36 jadahl: :P
08:36 emersion: yeah, i parsed it as "software rendered animation" :P
08:36 jadahl: karolherbst: I don't think there is any disagreement about compositors being able to handle unplugs etc, it's primarily about the boot experience no longer working properly
08:36 emersion: right, so you want to animate, because there's a real GPU, but can't know the GPU will be coming soon
08:37 karolherbst: yeah, fair
08:37 daniels: (also you're going to need to keep copies of everything you uploaded to GL and recreate that)
08:37 tzimmermann: jadahl, emersion, flickering animations could maybe be fixed by drivers by cleverly transfering DRM atomic state from the old device to the new device. but that's likely different problem
08:37 emersion: daniels: GPU resets!
08:38 daniels: \o/
08:38 jadahl: emersion: and/or show anything, because HDR/DeepColor needing real gpu drivers and what not
08:38 jadahl: tzimmermann: that's not enough. we never want to animate with simpledrm, so there would be no animation
08:39 emersion: DeepColor™, is that an AI-powered thing? x)
08:39 karolherbst: ....
08:39 jadahl: :D
08:44 jadahl: anyhow, the only place I can imagine being able to make a somewhat educated guess whether the kernel have done any initial probing and whether any drivers are probing anything, is the kernel. the only work arounds I can think of that userspace can do is while (!is_hw_accel() || !arbitrary_timeout_reached()) wait_on_udev()
08:45 emersion: yeah
09:08 derr: karolherbst: u wanted to try compile some version 23 of mesa or such on my system for, some reason ? i remember saying yes to something i had no clue what was =)
09:08 derr: you may, (instruct me) if you want and need. think i already have mesa 23 tried and installed with steam tough
09:11 karolherbst: derr: mostly just trying out this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28641
09:12 karolherbst: but like... I'm off today, so I don't really want to spend too much time on IRC :D
09:12 derr: ill read trough see if i can make head or tails of it
09:27 javierm: tzimmermann: sorry, was in a meeting. Sure, I'll take a look to your series
09:27 tzimmermann: thank you
09:50 eric_engestrom: gfxstrand: "how long until 24.1 final?" -> next week unless something comes up
09:50 eric_engestrom: gfxstrand: as for the modifiers in nvk, I'm replying on the MR where you tagged me, but basically "yes" :)
09:51 eric_engestrom: DavidHeidelberg: I don't have any other cts backport in my queue right now, so feel free to make an MR with just that 👍
10:05 tjaalton: teflon inflated the mesa tarball from 19->28MB...
17:24 jenatali: eric_engestrom: Thanks for trying :) I've gotta run to a pediatrician appt but I can fix the breaks when I'm back
17:25 jenatali: Oh looks like you're already on it, cool. Once you get a working pipeline you have my a-b to go ahead and land it
17:28 mattst88: what is the difference between spir-unknown-unknown and spir64-unknown-unknown?
17:28 mattst88: SPIR-V targeting something (a GPU?) with 32-bit pointers vs 64-bit pointers?
17:31 jenatali: Yes
17:37 mattst88: okay, thanks
17:38 DemiMarie: also worth noting that even if a GPU is present, the initramfs might not have the firmware for it
17:38 mattst88: trying to figure out whether it's worth adding test expectations for 32-bit x86 in https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2555
17:39 mattst88: seems like the original author copied these tests from llvm-project.git and modified them slightly for targeting SPIR-V
17:39 mattst88: so I'm unsure whether there's actually really any value in them at all
17:42 mattst88: i.e. why is it valuable to check for x86-64 specifics in the output resulting from compiling some llvm .ll files through SPIR-V to x86-64
18:21 gfxstrand: How do I disable threaded context?
18:21 zmike: GALLIUM_THREAD=0
22:28 kode54: congrats to gfxstrand on the command queue merging finally reaching merge ready status
22:41 zmike: yes, gfxstrand has been hard at work on it for months
22:54 Ermine: Is ANV a Vulkan driver for Intel GPUs ?
22:56 Sachiel: yes
23:21 jenatali: Any spec lawyers around?
23:22 jenatali: The GL spec section 9.3 says "Specifically, the values of rendered fragments are undefined if any shader stage fetches texels and the same texels are written via fragment shader outputs"
23:23 jenatali: Does a clear count as a fragment shader output?
23:26 zmike: no
23:26 jenatali: So binding a framebuffer for both input and output, and then clear, draw doesn't constitute a feedback loop and so no TextureBarrier is needed?
23:27 zmike: you mean doing fbfetch?
23:27 jenatali: No, not fbfetch
23:27 zmike: not sure what you mean by input and output then
23:28 jenatali: Binding a framebuffer for output, and also binding one of its attachments as the texture to one of the sampler units
23:28 jenatali: (Hopefully I get my GL terminology right)
23:29 zmike: ah
23:29 jenatali: The spec says it's legal to do texel fetch, not framebuffer fetch, for the current pixel in the fragment shader, as long as you have a TextureBarrier since the previous write - but it only qualifies that as needed in the case of fragment shader outputs
23:30 zmike: that's what https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_attachment_feedback_loop_layout.html is for
23:30 jenatali: Yep
23:31 zmike: and in this scenario your fb attachment which is also a sampler is not being written?
23:31 zmike: by the fragment shader, that is
23:31 jenatali: There's a single draw which is a feedback loop. It reads and writes the same texture
23:32 zmike: is this a piglit or a cts case
23:32 jenatali: The prior write is from a clear though, not a fragment output
23:32 jenatali: No, real-world app
23:32 zmike: huh
23:32 jenatali: And so I'm trying to decide between declaring app bug, they need a texture barrier, or if I need to do unnatural things in my driver to make it work
23:33 zmike: that's basically an input attachment (fbfetch), where you're supposed to barrier
23:33 zmike: I've seen the case where a fb attachment is used as a sampler without writing to it
23:33 zmike: not sure I've seen your case though
23:33 zmike: I'd have to check the spec, which I can't easily do from my couch
23:34 jenatali: Yeah, it's basically an input attachment. But it's at the start of a subpass where the attachment load op is clear
23:34 jenatali: In VK it's more naturally expressed
23:34 zmike: right, but in that case you'd need a barrier too
23:34 jenatali: Oh you do?
23:34 zmike: yes
23:34 jenatali: Cool then I'm going to claim app bug
23:35 zmike: there's cts coverage for clear -> fbfetch which works like this
23:35 zmike: though technically it's advanced blend which is lowered to fbfetch
23:35 zmike: implementation detail
23:35 jenatali: But it's not strictly fbfetch, this is a feedback loop, i.e. input attachment that's also an output attachment
23:36 jenatali: Which can be used to implement advanced blend
23:36 zmike: yeah, like I said I'd have to check the spec to be lsure
23:36 zmike: I'm just comparing to existing mechanics
23:36 jenatali: Alright fair enough, I'm going to pose it to Adobe to see if they'll fix it
23:37 zmike: it sounds like an app bug fwiw, but this is not an official 🪑 statement
23:37 jenatali: Yeah, sounds like an app bug to me too but I like to have some evidence before claiming that :)
23:46 ramamonacius: Think of your new life as a worm after we kill you all off! Tbh. I am long time supporting chinese and russians based of their sanity and bravery and no solidarity and cheater politics, you are so nasty people in the western world, why would others have to suffer due to your actions? And why the fuck does it take so long to get rid of you? I thought the fuckers get handled by vaccines, but still the joss discrimination mob
23:46 ramamonacius: tells lies and abuses me. You are so big garbage in our planet.