<aperezdc>
Company: you can eglGetConfigAttrib(..., EGL_NATIVE_VISUAL_ID, &gbm_format) when using drm/kms/gbm
LeviYun has quit [Ping timeout: 480 seconds]
warpme has quit []
<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
<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
<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
<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
<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.
samuelig has quit [Quit: Bye!]
<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.
<kode54>
memory corruption bugs that just mysteriously went away after libgalliumvl was no longer directly linked
azerov has joined #dri-devel
<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.
<pq>
EGL_KHR_platform_wayland does not define it.
rasterman has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
feaneron has joined #dri-devel
distrotouch has quit [Read error: Connection reset by peer]
topnotchenergy has joined #dri-devel
<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
<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.
<topnotchenergy>
you just ask the PC offset from data bank where it's written.
hansg has joined #dri-devel
<pixelcluster>
dwfreed: ^^
topnotchenergy has left #dri-devel [#dri-devel]
topnotchenergy has joined #dri-devel
warpme has joined #dri-devel
LeviYun has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
topnotchenergy has left #dri-devel [#dri-devel]
pcercuei has joined #dri-devel
samuelig has quit [Quit: Bye!]
rsalvaterra has joined #dri-devel
samuelig has joined #dri-devel
topnotchenergy has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<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.
LeviYun has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aissen_ has quit [Ping timeout: 480 seconds]
<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.
aissen has joined #dri-devel
topnotchenergy has left #dri-devel [#dri-devel]
<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.
kts has joined #dri-devel
warpme has quit []
samuelig has quit []
samuelig has joined #dri-devel
topnotchenergy has joined #dri-devel
<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
<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.
nerdopolis has joined #dri-devel
<stsquad>
dear god the spambots are being fed by LLMs now :-/
<airlied>
no, no they aren't
<ccr>
hand-crafted psychosis
<stsquad>
markov chain with delusions of grandeur?
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
hansg has quit [Quit: Leaving]
warpme has joined #dri-devel
topnotchenergy has quit [Remote host closed the connection]
guludo has joined #dri-devel
topnotchenergy has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
trytogodog has joined #dri-devel
<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
<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
<trytogodog>
your hand alike I am not after such I do not talk to such they are not allowed to stalk me.
nashpa is now known as dliviu
trytogodog has left #dri-devel [#dri-devel]
trytogodog has joined #dri-devel
trytogodog has left #dri-devel [#dri-devel]
<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?
topnotchenergy has quit [Ping timeout: 480 seconds]
samuelig has quit [Quit: Bye!]
samuelig has joined #dri-devel
LeviYun has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
<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?
<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 :)
<mripard>
that's definitely not the message :)
hansg has joined #dri-devel
warpme has quit []
hansg has quit [Quit: Leaving]
LeviYun has joined #dri-devel
epoch101 has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
simon-perretta-img has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
bolson has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
mbrost has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
LeviYun has joined #dri-devel
frieder has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
simon-perretta-img has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
kts has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
<sima>
jfalempe, I see the problem, but 99% sure this isn't the solution
<sima>
like the entire point of better panic handling is to avoid the console lock
<sima>
plus it's a trylock, so down to luck
<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
<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
yyds has joined #dri-devel
<sima>
javierm, oh I think we can make this work properly, it's just a lot more work
<javierm>
sima: we could *try* to make it work properly :)
<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.
<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
<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.
<sima>
oh dear lovely, vgacon just sets conswitchp directly without calling do_take_over_console
samuelig has quit []
samuelig has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<sima>
jfalempe, javierm one interim option would be to limit the exclusion to just !VT_CONSOLE
<sima>
because there's 2 kinds of consoles in the kernel
<sima>
vt-consoles (like fbcon or vgacon), those are fine
<sima>
kernel consoles, which print stuff in panic, which is the issue
<sima>
so we could have CONFIG_VT with fbcon, just not a kernel console on top of that
<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
<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
<javierm>
that's a good idea
<jfalempe>
sima: I didn't find the distinction between both kind in the code.
<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
<sima>
) will be ... fun
<sima>
jfalempe, one is a struct consw, like in fbcon.c
<sima>
those are console drivers for the vt subsystem
<sima>
then there's struct console, like the one in vt.c, those are console the kernel uses for dmesg output and panic printing
<sima>
static struct console vt_console_driver = { in vt.c
<sima>
static const struct consw fb_con = { in fbcon.c
<jfalempe>
ok thanks, because I looked for that too, to find a way to disable fbcon panic output.
<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
<sima>
but you already have that with quiet
<sima>
so it's a slightly larger hammer, but a clean one
<sima>
the right-sized hammer is messy to implement and will get even more messy once vt.c uses threads
<sima>
(which it really should, for anyone who wants to keep it)
<javierm>
sima: yeah, but config VT console = n is also something that distros won't really disable
<javierm>
which seems to be jfalempe's goal
<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
<sima>
that way you still get dmesg spam during normal operations, but not during panic
<sima>
javierm, CONFIG_VT isn't CONFIG_VT_CONSOLE
<sima>
CONFIG_VT is what gives you the virtual consoles/terminals, aka vt/vc
<sima>
CONFIG_VT_CONSOLE is what gives you the kernel console on top of vt, aka dmesg spam in fbcon
<sima>
so this would give you CONFIG_FRAMEBUFFER_CONSOLE=y, CONFIG_VT=y, CONFIG_VT_CONSOLE=n
<sima>
jfalempe, would that be enough?
<javierm>
sima: ahhhh
<jfalempe>
sima: I probably need to run some tests with that to check what breaks, but that sounds good.
warpme has quit []
<sima>
like I said, there's 2 types of consoles here, and the naming is a mess :-/
<sima>
jfalempe, only thing that breaks is dmesg output onto vt/fbcon
<sima>
everything else should work, userspace should not see a difference
<sima>
and since most distros boot with quiet, usually you get no dmesg output at all anyway
<jfalempe>
ok, I will send a patch to change from !FRAMEBUFFER_CONSOLE to !VT_CONSOLE.
<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.
<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
<sima>
ah yes CONFIG_VT=y should be enough for that
bmodem has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<sima>
oh I got mixed up ...
<sima>
jfalempe, yeah if your plymouth has this, then at least during boot you should be covered already
<sima>
and after that people care a lot less about dmesg on their vt
<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
<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.
<jfalempe>
that looks like a good path forward.
fab has quit [Quit: fab]
<sima>
jfalempe, it's a bit ugly, but I think the only option would be to check whether /sys/class/console/active matches tty*
<sima>
hm not sure that's even the right match
<jfalempe>
sima: hum, I don't have a /sys/class/console at least on fedora 40
<jfalempe>
ah it's /sys/class/vtconsole
<sima>
nah that's vt consoles
<sima>
we want kernel consoles
<sima>
/sys/class/tty/console/active
<sima>
which hilariously are called tty in sysfs because reasons (and well historical overlap with serial lines and consoles on those I guess)
<sima>
it's all a mess
<sima>
ok pretty sure this is it I think
<jfalempe>
ok, I get this one, active says ttyS0 on my VM, and tty0 on my laptop.
<sima>
since the vt console driver has the name "tty"
<sima>
yeah ttyS* is a serial line, usually the kernel console on vms
<sima>
jfalempe, oh /proc/consoles is better
<sima>
that's the real list of kernel consoles
bmodem has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<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.
warpme has joined #dri-devel
<sima>
jfalempe, trying to figure out whether it's better to match against "tty0" or tty[0-9]*"
<sima>
probably tty0 only, since that's the default vt console setup
<sima>
definitely can't match just for tty prefix since all the serial consoles have tty[A-Z]* names
<sima>
also reading all this kernel code just gives me headaches
<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.
<sima>
jfalempe, try booting with console=tty0 on the vm
<sima>
assuming you have tty0 listed in /proc/consoles
LeviYun has joined #dri-devel
<jfalempe>
no I only have ttyS0
<sima>
hm maybe that only lists the active ones
yyds has quit [Remote host closed the connection]
<sima>
old subsystems without sysfs introspection ftl :-(
<sima>
jfalempe, it should show up, assuming you have it in /sys/class/tty
Haaninjo has joined #dri-devel
<jfalempe>
yes there is a tty0 in /sys/class/tty
<jfalempe>
cat /proc/consoles
<jfalempe>
ttyS0 -W- (EC p a) 4:64
oneforall2 has joined #dri-devel
<sima>
jfalempe, yeah so booting with console=tty0 should switch that
<sima>
probably set as default in the vm config to something like console=ttyS0
<sima>
then you should be able to test with a vm and don't need real hw
fab has joined #dri-devel
<jfalempe>
yes, so now /proc/consoles is empty, but that's expected since I built with vt_console=n
LeviYun has quit [Ping timeout: 480 seconds]
<jfalempe>
so plymouth can even check for something in /proc/consoles. if nothing found (and no quiet) then display the kmsg.
kzd has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
kts has joined #dri-devel
frankbinns2 is now known as frankbinns
<sima>
jfalempe, it should have "tty0" when you build with VT_CONSOLE=y
<jfalempe>
Yes, that's what I get on my laptop
<sima>
jfalempe, also not sure whether you should check for nothing or "not tty0" ...
<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
<jfalempe>
my reasoning is that if there are other consoles to get the logs, they are probably better than spamming the screen.
<sima>
it's not perfect, but more robust
<sima>
jfalempe, the fallback might be some bios console or something that the user isn't even aware of
<sima>
and so the upgrade to VT_CONSOLE=n causes a regression
<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 :-)
<sima>
ok gtg run some errands quickly, I'll be back in a bit
<jfalempe>
hum yes, I will discuss that with plymouth maintainer.
<jfalempe>
and I will need to leave for today soon too.
oneforall2 has quit [Remote host closed the connection]
samuelig has quit [Quit: Bye!]
samuelig has joined #dri-devel
oneforall2 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
oneforall2 has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
oneforall2 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
warpme has quit []
warpme has joined #dri-devel
oneforall2 has joined #dri-devel
jsa1 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
jsa has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
rz has quit [Remote host closed the connection]
rz has joined #dri-devel
epoch101 has quit []
warpme has quit []
epoch101 has joined #dri-devel
LeviYun has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
jessica_24 has joined #dri-devel
LeviYun has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
nerdopolis has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
coldfeet has joined #dri-devel
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
LeviYun has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
epoch101 has quit []
alyssa has joined #dri-devel
<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?
<airlied>
not really, we build mesa releases for s390
Duke`` has quit [Ping timeout: 480 seconds]
<gfxstrand>
But what is someone doing on s390 where they benefit from modern Mesa?
<airlied>
running RHEL
<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
davispuh has quit [Ping timeout: 480 seconds]
<airlied>
fedora also builds for s390, again don't want to maintain some ancient forks for currently existing CPUs
<airlied>
and we have to maintain an old LLVM if we maintain an old mesa