06:38 airlied: win 14
06:38 airlied: oops
07:39 aperezdc: Company: you can eglGetConfigAttrib(..., EGL_NATIVE_VISUAL_ID, &gbm_format) when using drm/kms/gbm
07:50 distrotouch: it's a Frankenstein gate, intrinsic assumes you are going to subtract where add is internal in the tandem, theoretically you could also do add where you compensate for common bits, but I have not delt with this path it's because internal add ripple plus at add batched exec is not needed. so it ends up as removing twice the distance fields and focal index from doubly compacted alu bank
07:50 distrotouch: that yields value at focal position and value+index at other positions within a bank, reverse removing the inverted result yields index+distance in the focal position and distance+distance in non interested positions after inverting that and removing one distance and then index and then all distances and then non focal constants you get the transition values from polderan. it can do
07:50 distrotouch: billions of alus in around 20 instructions. but you could slim it at values+index+2*distance and value+2*distance, remove non focal amount of constants yields value+1*distance + distances of all non focal values, so minus distances yields focal searched value. but ir results need less logic to ask the values at certain PC per filtering. so you need value +distance*2+pc, but as we do not
07:50 distrotouch: implement add it's sane to eliminate the rest of the non focals, and sequence the value at 2*distance, so... that's just very short version that we really use. so the engine is the slimmest possible, once you had did add offsets at compile time with bitwise operation so that we do no longer have to serialize the carry on add. As I develop this code only after I invented it my own too, I
07:50 distrotouch: will not fail cause due to I designed it, I know best what it does, I am ready with modern engine by the end on the year, I only need to build dictionaries for alus.
07:51 distrotouch: in other words your envy and no callabiration with me works out for me too anyways, cause the design of the higher performance code is again anyways done by me.
08:01 austriancoder: If anyone has some spare time for a quick review: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29042
08:22 Company: aperezdc: I'm on Wayland, I just wanted to dump the format in use as debug info
08:25 Company: actually, I'm on Wayland, X11 or ANGLE
08:25 Company: but I care about Wayland
08:36 aperezdc: no idea what the native visual id happens to be in wayland... might be a drm format
08:44 kode54: whee
08:45 kode54: I found another possible reason for inclusion of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680 in stable
08:45 kode54: memory corruption bugs that just mysteriously went away after libgalliumvl was no longer directly linked
08:48 pq: aperezdc, Company, I don't think EGL Wayland platform has a native visual id. It could, and probably should - it would be logical, but I don't think it's implemented, or even defined what the number should represent on the EGL Wayland platform.
08:49 pq: EGL_KHR_platform_wayland does not define it.
09:34 topnotchenergy: <distrotouch> because you fucked a crook or some bitch did fuck a terrorist penniless bum loser and your state of being abortion leftovers who has no money having cracked a sports star up in hospitals and streets, you tend to think wrong you can say things to me in abusive style at my own premises mostly ontop, but those are the exact real reasons you can not or you regret it like most
09:34 topnotchenergy: the Estonian and Finnish crooks at the path did. and PC is determined by biggest values highest bit in the set, cause it cares not about duplicates, cause answer sets are uniquely contiguous, I know the implementation has to work cause it's common sense.
09:35 topnotchenergy: you just ask the PC offset from data bank where it's written.
09:38 pixelcluster: dwfreed: ^^
09:58 topnotchenergy: I tested a bunch too, and know my own style, the PC bank is multibank access, it's for any intermediate or debug needing value so you feed pcs UpTo point of where you need the result, skip all future PC's and access any of the earlier, but I said it's my last year with this or educating a you by provided material.
10:15 topnotchenergy: I start my career of work with being a real personality in the world, unlike an abuse terror fucker. and I do not have anything to discuss with morons whose cowork got me injured for sports and delayed with programming, I am technically fine but I do not spend time with nonsense courtesan terrorists.
10:24 hansg: Hi All, I just pushed a small fix to drm-misc-fixes and when generating drm-tip there is a small pre-existing merge conflict when merging drm-xe-next. I assume that whomever caused that is going to fix it.
10:55 topnotchenergy: the current os and more complex bits are fine, there's nothing much that Linux kernel is needing on rewrites, this job is easy, just because Micheal said that kernels are worse than we might think is not a reason why I see things alike. Linux is good windows is good, osx good, compilers are good, one needs tiny extensions per Isa to do the needed, I would say filesystems could be
10:55 topnotchenergy: plumbed to Linux in better ways, but it does not bother me to expose newer full filesystems or just compressing or compacting extensions, the last bits I was happy about was mesa gud. everything other I had, and I do not offer vulkan state as per advice, I advise ogl es, vulkan is though also offered, but is not recommended by note.
11:04 stsquad: dear god the spambots are being fed by LLMs now :-/
11:05 airlied: no, no they aren't
11:08 ccr: hand-crafted psychosis
11:09 stsquad: markov chain with delusions of grandeur?
11:38 trytogodog: <topnotchenergy> volkovs brainpain they put your markov chain jabber to your spots graveplate in cemetery, something to remember you about, that who were such delusional trolls of terror. that however means nothing to me, I already knew that, samewise your crooks articles how to score mindill bitches, are empty nonsense to ignore only by me, I do not fight for bitch courtesans and you
11:38 trytogodog: messed up, it <topnotchenergy> wasn't me who swallowed your cum at all monkeys, since I do not swallow things from you as I have said that was a pair of Finnish porn scum their doodles or freaks have never been associated with me, if you insist not understanding this for whatever fraud reason, you eventually get thrown out or shot everywhere you go. Your pregnant married freaks can talk to
11:38 trytogodog: your hand alike I am not after such I do not talk to such they are not allowed to stalk me.
11:39 dliviu: mripard: that was some impressive response time to a patch, 2 minutes to be merged. Anything burning that I need to be aware of?
12:07 mripard: dliviu: I guess it's by accident: I was going through my backlog and merging the patches that still needed to. I guess it got there right before I was done. Is there an issue with that patch?
12:09 dliviu: mripard: no, I just thought you've stepped in to sort it out because there was an underlying urgency. I'm fine with you merging it and also telling me I'm too slow :)
12:09 mripard: that's definitely not the message :)
13:02 jfalempe: sima: when you have time, can you please take a look at https://patchwork.freedesktop.org/series/132720/ ?
13:08 sima: jfalempe, I see the problem, but 99% sure this isn't the solution
13:08 sima: like the entire point of better panic handling is to avoid the console lock
13:09 sima: plus it's a trylock, so down to luck
13:09 sima: also in a real panic, at least with the current code, I think there's excellent chances someone is holding the console lock already, but not sure on that
13:10 javierm: jfalempe: I agree with sima, I understand that's appealing to have drm panic enabled with fbcon but I would keep it as a mutually exclusive config option
13:11 sima: javierm, oh I think we can make this work properly, it's just a lot more work
13:11 javierm: sima: we could *try* to make it work properly :)
13:12 jfalempe: sima: I tested it on an arm board, and that was preventing to have fbcon panic on top of drm panic. But yes, I agree it's not the perfect solution.
13:12 javierm: but jokes apart, yeah that's that I tried to say. We might but it could be lot more work and unsure if is worth it, since the long term plan is to disable fbcon anyways
13:14 jfalempe: This is mostly to help transition, since disabling fbcon/VT is a bit hard for distribution. In fact I always test drm_panic with fbcon enabled.
13:18 sima: oh dear lovely, vgacon just sets conswitchp directly without calling do_take_over_console
13:25 sima: jfalempe, javierm one interim option would be to limit the exclusion to just !VT_CONSOLE
13:25 sima: because there's 2 kinds of consoles in the kernel
13:25 sima: vt-consoles (like fbcon or vgacon), those are fine
13:25 sima: kernel consoles, which print stuff in panic, which is the issue
13:26 sima: so we could have CONFIG_VT with fbcon, just not a kernel console on top of that
13:26 sima: if that's not enough I guess we'd need a flag on the kernel struct console in vt.c that tells the printk/kernel-console stuff to not use this in panic mode
13:27 javierm: sima: keeping the fbcon but tell the kernel to not use in panic mode makes more sense and wouldn't have to take any locks on the drm panic path
13:27 javierm: that's a good idea
13:27 jfalempe: sima: I didn't find the distinction between both kind in the code.
13:27 sima: but really that solution is a lot more elaborate because a) long term we want this console to only print through the thread infrastructure and b) it'd be separate from the drm panic stuff so locking (which would need to be common, otherwise the thread will keep printing while we panic and create a mess
13:28 sima: ) will be ... fun
13:28 sima: jfalempe, one is a struct consw, like in fbcon.c
13:28 sima: those are console drivers for the vt subsystem
13:28 sima: then there's struct console, like the one in vt.c, those are console the kernel uses for dmesg output and panic printing
13:29 sima: static struct console vt_console_driver = { in vt.c
13:29 sima: static const struct consw fb_con = { in fbcon.c
13:29 jfalempe: ok thanks, because I looked for that too, to find a way to disable fbcon panic output.
13:29 sima: javierm, so CONFIG_VT_CONSOLE=n disables the console in all context, i.e. no more dmesg output on your fbcon even during normal operation
13:30 sima: but you already have that with quiet
13:30 sima: so it's a slightly larger hammer, but a clean one
13:30 sima: the right-sized hammer is messy to implement and will get even more messy once vt.c uses threads
13:31 sima: (which it really should, for anyone who wants to keep it)
13:32 javierm: sima: yeah, but config VT console = n is also something that distros won't really disable
13:32 javierm: which seems to be jfalempe's goal
13:32 sima: javierm, to get 99% there, a simple background job that dumps dmesg output into the foreground console (in userspace) might be all you need with CONFIG_VT_CONSOLE=n
13:32 sima: that way you still get dmesg spam during normal operations, but not during panic
13:33 sima: javierm, CONFIG_VT isn't CONFIG_VT_CONSOLE
13:33 sima: CONFIG_VT is what gives you the virtual consoles/terminals, aka vt/vc
13:33 sima: CONFIG_VT_CONSOLE is what gives you the kernel console on top of vt, aka dmesg spam in fbcon
13:34 sima: so this would give you CONFIG_FRAMEBUFFER_CONSOLE=y, CONFIG_VT=y, CONFIG_VT_CONSOLE=n
13:34 sima: jfalempe, would that be enough?
13:35 javierm: sima: ahhhh
13:36 jfalempe: sima: I probably need to run some tests with that to check what breaks, but that sounds good.
13:36 sima: like I said, there's 2 types of consoles here, and the naming is a mess :-/
13:36 sima: jfalempe, only thing that breaks is dmesg output onto vt/fbcon
13:36 sima: everything else should work, userspace should not see a difference
13:36 sima: and since most distros boot with quiet, usually you get no dmesg output at all anyway
13:38 jfalempe: ok, I will send a patch to change from !FRAMEBUFFER_CONSOLE to !VT_CONSOLE.
13:39 jfalempe: for me, long term, we want to remove fbcon and VT, but the problem is that it's hard to do all at once, so proceed with small step is more acceptable.
13:40 sima: jfalempe, javierm also if the lack of dmesg on vt is an issue, essentially all you need is "dmesg -w > /dev/vcs" running in userspace somewhere to fill that gap
13:41 jfalempe: and at least plymouth should be able to display the boot logs https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224
13:41 sima: ah yes CONFIG_VT=y should be enough for that
13:45 sima: oh I got mixed up ...
13:45 sima: jfalempe, yeah if your plymouth has this, then at least during boot you should be covered already
13:45 sima: and after that people care a lot less about dmesg on their vt
13:46 sima: jfalempe, but you might hit an edge case, where plymouth sees that vt are enabled and uses that, but without CONFIG_VT_CONSOLE there won't be much interesting stuff there
13:47 jfalempe: sima: Yes I will check how it checks for VT in plymouth, and it shouldn't be hard to handle the case where CONFIG_VT=y and CONFIG_VT_CONSOLE is not set.
13:48 jfalempe: that looks like a good path forward.
13:52 sima: jfalempe, it's a bit ugly, but I think the only option would be to check whether /sys/class/console/active matches tty*
13:54 sima: hm not sure that's even the right match
13:54 jfalempe: sima: hum, I don't have a /sys/class/console at least on fedora 40
13:55 jfalempe: ah it's /sys/class/vtconsole
13:55 sima: nah that's vt consoles
13:55 sima: we want kernel consoles
13:55 sima: /sys/class/tty/console/active
13:56 sima: which hilariously are called tty in sysfs because reasons (and well historical overlap with serial lines and consoles on those I guess)
13:56 sima: it's all a mess
13:57 sima: ok pretty sure this is it I think
13:57 jfalempe: ok, I get this one, active says ttyS0 on my VM, and tty0 on my laptop.
13:57 sima: since the vt console driver has the name "tty"
13:57 sima: yeah ttyS* is a serial line, usually the kernel console on vms
14:02 sima: jfalempe, oh /proc/consoles is better
14:02 sima: that's the real list of kernel consoles
14:03 jfalempe: sima: hum yes it gives the same info. I'm rebuilding a kernel without VT_CONSOLE (but with VT and FRAMEBUFFER_CONSOLE) to see what it gives.
14:10 sima: jfalempe, trying to figure out whether it's better to match against "tty0" or tty[0-9]*"
14:10 sima: probably tty0 only, since that's the default vt console setup
14:10 sima: definitely can't match just for tty prefix since all the serial consoles have tty[A-Z]* names
14:11 sima: also reading all this kernel code just gives me headaches
14:12 jfalempe: sima: I need to test on real hw, because on my VM, I get the same ttyS0 with or without VT_CONSOLE. but that's normal.
14:13 sima: jfalempe, try booting with console=tty0 on the vm
14:13 sima: assuming you have tty0 listed in /proc/consoles
14:13 jfalempe: no I only have ttyS0
14:14 sima: hm maybe that only lists the active ones
14:14 sima: old subsystems without sysfs introspection ftl :-(
14:14 sima: jfalempe, it should show up, assuming you have it in /sys/class/tty
14:16 jfalempe: yes there is a tty0 in /sys/class/tty
14:16 jfalempe: cat /proc/consoles
14:16 jfalempe: ttyS0 -W- (EC p a) 4:64
14:17 sima: jfalempe, yeah so booting with console=tty0 should switch that
14:18 sima: probably set as default in the vm config to something like console=ttyS0
14:18 sima: then you should be able to test with a vm and don't need real hw
14:20 jfalempe: yes, so now /proc/consoles is empty, but that's expected since I built with vt_console=n
14:22 jfalempe: so plymouth can even check for something in /proc/consoles. if nothing found (and no quiet) then display the kmsg.
14:38 sima: jfalempe, it should have "tty0" when you build with VT_CONSOLE=y
14:39 jfalempe: Yes, that's what I get on my laptop
14:39 sima: jfalempe, also not sure whether you should check for nothing or "not tty0" ...
14:40 sima: since the kernel might fall back to other consoles if VT_CONSOLE=n and then for backwards compat we probably still want to print to the screen plymouth draws into
14:40 jfalempe: my reasoning is that if there are other consoles to get the logs, they are probably better than spamming the screen.
14:40 sima: it's not perfect, but more robust
14:40 sima: jfalempe, the fallback might be some bios console or something that the user isn't even aware of
14:40 sima: and so the upgrade to VT_CONSOLE=n causes a regression
14:41 sima: the perfect test would be "old kernel has tty0, new one doesn't", but you can't boot into the old kernel to check :-)
14:41 sima: ok gtg run some errands quickly, I'll be back in a bit
14:41 jfalempe: hum yes, I will discuss that with plymouth maintainer.
14:41 jfalempe: and I will need to leave for today soon too.
17:28 alyssa: lavapipe-venus has been slow (twice now in a few days I've seen it as the long pole) - not sure if anything changed per se but we should probably bump the fraction for it?
17:31 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29655 hopefully this is not controversail
17:49 zmike: huh I was going to hypothesize that it was caused by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29408 but then I noticed it still hasn't merged
18:41 lileo: Does anyone recall a patchset for kms atomic feedback, that allowed drivers to respond with more specific failure reasons?
18:42 emersion: i can't think of anything
18:44 lileo: hmm... i may be hallucinating
18:44 lileo: I thought i saw something like that fly by my inbox a while ago
20:35 sima: airlied, https://lore.kernel.org/dri-devel/CAPM=9tyots9C8wEU0TgGnFmLOkfqn62ngaYYjV2yuTf7jwDGFw@mail.gmail.com/ multiple LRU isn't really a fundamental issue, we already have those for system memory aplenty
20:35 sima: you just try to shrink them in parallel and with equal pressure
20:36 sima: which is what the core mm shrinker does by looping over shrinkers (for objects, including drm bo in system memory) and page lru
20:36 sima: afaiui in practice the bigger issue is trying to assign roughly comparable eviction/refault costs between different stuff
20:37 sima: like despite that it's all pages, filecache isn't the same as anon memory at all
20:54 gfxstrand: airlied: How close do you think we are to being able to forget that big endian exists in Mesa?
21:02 zmike: gfxstrand: it sounds like you're asking about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29649 with the intent to review!
21:11 airlied: s390 will live a long time
21:13 gfxstrand: Can we amber BE support?
21:14 airlied: not really, we build mesa releases for s390
21:16 gfxstrand: But what is someone doing on s390 where they benefit from modern Mesa?
21:16 airlied: running RHEL
21:19 airlied: the workload we care about is gnome-shell on llvmpipe really, and forking an ancient mesa and having to maintain it outside of normal updates isn't really useful
21:21 airlied: fedora also builds for s390, again don't want to maintain some ancient forks for currently existing CPUs
21:21 airlied: and we have to maintain an old LLVM if we maintain an old mesa
21:54 mattst88: heh, I just recently fixed a big endian bug in mesa (commit 5997cf7587ce56aedac9114c0db9b250f1b54461)
23:34 alanc: we still ship Mesa with llvmpipe on SPARC as well, also mainly for running gnome-shell
23:35 gfxstrand: :cry:
23:36 alanc: of course, in our case (Solaris), that will die once gnome-shell can no longer run on X11 (either Xorg or Xvnc)
23:37 Sachiel: wayland was a plan to get rid of big endian all along