ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
camus has joined #dri-devel
K`den has joined #dri-devel
Kayden is now known as Guest1084
K`den is now known as Kayden
Guest1084 has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
Bennett has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
iive has quit []
<bnieuwenhuizen> jekstrand: are the msft texture classes the same as vulkan format reinterpret compat classes?
<jekstrand> bnieuwenhuizen: No
<jekstrand> bnieuwenhuizen: MSFT classes are the same channel layout. Vulkan are just the same bpp.
<bnieuwenhuizen> hmm, so msft classes is also roughly what AMD compression does ...
<bnieuwenhuizen> all very annoying for vulkan
<jekstrand> Yup
<jekstrand> Why do you think I wrote that extension?
<bnieuwenhuizen> the format list one?
<jekstrand> Yup
<bnieuwenhuizen> because RADV needed it of course /s
<bnieuwenhuizen> honestly that design has served us very well
<bnieuwenhuizen> both for the SRGB mess and for the D3D compat class mess
<jekstrand> :D
<jenatali> It's very odd to me that GL and Vulkan were both so aggressive at requiring casting that the hardware was really bad at
<jenatali> Or, alternatively, that the hardware built compression that didn't work in those GL/Vulkan scenarios
<jekstrand> You overestimate how much hardware people care about GL.
<bnieuwenhuizen> more surprised about the former, but that was before my time
<jenatali> Apparently so
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand> GL_ARB_texture_view was written by NVIDIA and their hardware doesn't care.
<jekstrand> And it's implementable everywhere
danvet has quit [Ping timeout: 480 seconds]
<jekstrand> And, at least in GL, you had to go out of your way a bit more to use it
<bnieuwenhuizen> yeah, more susprised at the not adjusting in Vulkan part
alatiera has quit [Quit: Ping timeout (120 seconds)]
<jenatali> Yep, makes sense. And yeah, agreed about that
<bnieuwenhuizen> since the initial intro in GL time I don't think AMD had hardware compression yet
alatiera has joined #dri-devel
<jenatali> At least they added an "I want to cast" flag, but I'm surprised people didn't propose something more scoped
<bnieuwenhuizen> well, with the format list extension we have something that allows for very accurate scoping now
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
nchery has quit [Ping timeout: 480 seconds]
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
cworth has quit [Ping timeout: 480 seconds]
<airlied> anholt: I think you mentioned intel perf taking a long time to build, got it down on my ryzen from 1m to 30s
cworth has joined #dri-devel
<jekstrand> jenatali, bnieuwenhuizen: Yeah, Intel didn't have compression when ARB_texture_view came out.
Mooncairn has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
fxkamd has quit []
Mooncairn has quit [Quit: Quitting]
mripard has quit [Read error: Connection reset by peer]
bbrezillon has quit [Read error: Connection reset by peer]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
mripard has joined #dri-devel
bbrezillon has joined #dri-devel
glennk has joined #dri-devel
Mooncairn has joined #dri-devel
<airlied> anholt: I wonder about splitting the perf metrics gen into one C file perf per gen, to allow some parallel compiles
<airlied> though that might be more meson/python than I want right now
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
Mooncairn has quit [Quit: Quitting]
jewins has quit [Ping timeout: 480 seconds]
<airlied> dj-death: ^ also
ngcortes has quit [Remote host closed the connection]
alatiera has quit [Read error: Connection reset by peer]
alatiera has joined #dri-devel
heat has quit [Quit: Leaving]
boistordu_old has joined #dri-devel
OftenTimeConsuming has quit []
OftenTimeConsuming has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
alatiera has quit [Read error: Connection reset by peer]
alatiera has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #dri-devel
macromorgan has quit [Quit: Leaving]
sarnex has quit [Ping timeout: 480 seconds]
enilflah has joined #dri-devel
idr_ has joined #dri-devel
idr has quit [Remote host closed the connection]
enilflah_ has quit []
sarnex_ has joined #dri-devel
sumits has quit [Quit: ZNC -]
holmanb_ has quit [Remote host closed the connection]
holmanb has joined #dri-devel
sumits has joined #dri-devel
<anholt> airlied: there's an MR to do that, but that would get in the way of fixing up the codegen to just be less massively duplicated.
<anholt> mattst88 was working on fixing up the codegen I heard
<mattst88> yeah. I've struggled to get big improvements. transitioned things to static structs, which massively reduced .text size but increased .rodata size by equivalent amounts
<mattst88> I'm working on deduplicating things across gens now
<mattst88> strings are deduplicated by the compiler already, so no size savings there
<airlied> mattst88: maybe you can just ack my simple MR that reduces the compile time by half then :-)
<mattst88> but I suspect stuffing all of them into a string pool and initializing the struct fields with a pointer into that pool would reduce relocs
<airlied> doesn't help the code bloat but definitely helps the compiler
<mattst88> airlied: lol, yes. can do
<mattst88> hah, wow. I didn't realize that the order things appeared in meson actually influenced the build order other than incidentally
<airlied> mattst88: it seems to kick the earlier ones off earlier
<airlied> so at least for that file it gives a better chance of it being finished or other work being available to fill other cores
oneforall2 has quit [Quit: Leaving]
<mattst88> makes sense. I just thought meson was smarter than previous build systems in this regard :)
<airlied> well it can't know how long it's going to take
oneforall2 has joined #dri-devel
<airlied> that would require psychic powers or records of how long things took in the past :-P
<mattst88> true. I just thought it would have enough parallelism to fill things -- oh, but I see intel was second to last in the file
<airlied> yeah it generally has enough parallelism, but that file seems to drain it
<mattst88> right
idr_ has quit []
lemonzest has joined #dri-devel
sdutt_ has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
Duke`` has quit []
tzimmermann has joined #dri-devel
sadlerap has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
Duke`` has joined #dri-devel
kmn has joined #dri-devel
mattrope has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
sadlerap has joined #dri-devel
mszyprow has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
itoral has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
pnowack has joined #dri-devel
danvet has joined #dri-devel
mvlad has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit []
rgallaispou has joined #dri-devel
tursulin has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
<ccr> zmike, I posted a kind of a stop-gap solution for that as comment on #4609, but I think I'll finally try to implement a custom differ for traces instead of this current way of dumping and then just regular per-line diffing. no promises tho, and will probably take some time to get it done.
pcercuei has joined #dri-devel
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
mi6x3m has joined #dri-devel
<mi6x3m> ajax, karolherbst it works with glxgears :)) but i think i'm gonna take an older wine because i don't really need that much features
<mi6x3m> weird to see a 100MB glxgears
<mi6x3m> stripped 21MB though
<karolherbst> mi6x3m: I guess with -Os it can be reduced a bit further
<mi6x3m> probably but 20MB is already quite impressive, i find it hard to believe it's a self-contained GL
rgallaispou has quit [Read error: Connection reset by peer]
<dj-death> airlied: thanks, nice reduction, I think splitting will reduce even further
<dj-death> airlied: just need to be smarter about strings
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
MajorBiscuit has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
shsharma has joined #dri-devel
rasterman has joined #dri-devel
<javierm> tzimmermann: your latest RFC makes a lot of sense to me and that feels the correct way to handle this issue
<javierm> tzimmermann: there's no point to leave the platform device if another driver is kicking the conflicting fb
agx has quit [Remote host closed the connection]
agx has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
kts has joined #dri-devel
kts has quit []
rgallaispou has quit []
rgallaispou has joined #dri-devel
kts has joined #dri-devel
ella-0 has joined #dri-devel
kts has quit []
ella-0 has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
mi6x3m has quit [Quit: Leaving]
<tzimmermann> javierm, yes. i'd still want to merge all the other changes; if only for correctness
<tzimmermann> i'm slightly nervous about fbdev userspace that mmaped the video memory. but it should all be gone when we unplug the device
<tzimmermann> so userspace won't get SIGBUS
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
aravind has joined #dri-devel
<javierm> tzimmermann: yeah, agreed
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
Peste_Bubonica has joined #dri-devel
<danvet> tzimmermann, javierm jani pq emersion thoughts?
<danvet> before I send it out with everyone + dog on cc :-)
<emersion> looks good!
* tzimmermann is taking cover before the shitstorm begins
<javierm> danvet: looks good to me as well!
rgallaispou has quit []
<pq> danvet, fine by me, and while I have followed the emails with some nice popcorn, not sure how much I'd matter on this topic.
<jani> where's my popcorn
mclasen has quit []
<danvet> pq, it will probably boil down to who can pile up more acks for their MAINTAINERS patch or some silly game like that
mclasen has joined #dri-devel
pjakobsson_ has quit []
<pq> I can do *that* silly game, sure.
<pq> I'm also 5k emails behind, so better poke me in IRC if I don't notice.
pjakobsson has joined #dri-devel
<javierm> danvet: I believe this situation has shown the need of a written process to become a subsystem maintainer
<javierm> I don't think is documented anywhere what are the requirements and steps to become one
<javierm> well, other than post a patch to MAINTAINERS and that ending in linus' tree
<ccr> danvet, "firmEware"?
<ccr> ye olde firmeware english!
<danvet> ccr, fixed
<jani> javierm: I think the unwritten rule is you should at least contribute some code first before assuming maintainership
<jani> MAINTAINERS says, "Orphan: No current maintainer [but maybe you could take the role as you write your new code]."
<ccr> danvet, heh. was just humorously nitpicking :)
<jani> it doesn't say "up for grabs to anyone"
Peste_Bubonica has quit [Quit: Leaving]
<javierm> jani: yeah, I know but that's still succint and vague. At the end of the day is an honour system and that can be exploited
alatiera has quit [Ping timeout: 480 seconds]
Lucretia has quit [Read error: Connection reset by peer]
alatiera has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
Lucretia has joined #dri-devel
mstoeckl_ has left #dri-devel [#dri-devel]
mstoeckl has joined #dri-devel
Daanct12 has joined #dri-devel
<jani> javierm: I don't disagree
ella-0 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
ella-0 has quit [Read error: Connection reset by peer]
devilhorns has joined #dri-devel
jfalempe has quit [Quit: Leaving]
Daaanct12 is now known as Danct12
jfalempe has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
ella-0_ has quit [Remote host closed the connection]
boistordu_old has quit []
Company has joined #dri-devel
itoral has quit [Remote host closed the connection]
kts has joined #dri-devel
ella-0 has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
aravind has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
nchery has joined #dri-devel
<MrCooper> danvet: I'm afraid your denial that some setups work better with fbdev acceleration hooks than is possible even in theory with software rendering & shadow buffer isn't helping
<danvet> MrCooper, not sure where that denial is, if you throw enough people at the problem there's ofc lots you can do
<danvet> and also for the "do nothing at all approach" then yes ditching the bltcpy accel will crawl
<danvet> in reality all the people who can type fast fbcon code have long moved on
<danvet> and for the dmesg case that's being brought up the fastest thing really is to only render the last few lines and not the 5k lines before that
<danvet> and at that point it doesn't matter how you render them, as long as you don't read uc/wc memory
zackr has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
ella-0 has joined #dri-devel
sdutt has joined #dri-devel
<danvet> MrCooper, the thing that really annoys me is the insistence about all the things drm cannot possible do, and how easy it is in fbdev
<danvet> which is largely bs
<GyrosGeier> drm cannot render a picture in fewer than ten lines of code :P
boistordu has joined #dri-devel
<GyrosGeier> I think that's the main avenue of criticism: it's complex
<danvet> yeah people don't understand it, so assume it can't do it
<danvet> GyrosGeier, also if you're really 1:1 compatible with opening /dev/fb/0
<imirkin> danvet: i just know that on my fairly plain box, nouveau's fbdev accel was helpful for fbcon.
<danvet> then I think drm is the same lines of code
aravind has joined #dri-devel
<danvet> imirkin, oh yeah the current stuff we have in nouveawu/i915/amd crawls
<danvet> because it "accelerates" fbcon with sw memmove
<danvet> which read from wc
<imirkin> that sounds ... not accelerating
<danvet> which is roughly the slowest way to do anything
<danvet> plus it renders every line of output, even if you put thousands of lines into your console
<imirkin> so yeah, that's my main (only?) comparison point
<danvet> imirkin, yeah, but that's how fbcon works
<danvet> fbcon is architected that without hw accel it will crawl
<danvet> in the dumbest possible way
<imirkin> and it's not like i use the console for a _ton_, the main use-case there is running dmesg
<imirkin> which is obviously a ton of lines and involves a ton of scrolling
<danvet> yeah, just dmesg | tail -n100
<danvet> or dmesg |less
<danvet> also this is why every distro boots with quiet
<GyrosGeier> in the good old days, we could just call dmesg and use scrollback
<danvet> makes booting faster
<imirkin> my standard has been to just run it and then shift-pageup/down
<danvet> GyrosGeier, the good old days were vgacon largely
<danvet> where this works because it's characters, not a rendered pixmap
<imirkin> but.... my utf8?!
<pq> good old days of hardcopy console... I didn't yet live those days
<danvet> so yeah kernel console is one of these topics were lots of people like to complain
<imirkin> danvet: it has a lot of users :)
<pq> fbcon printing every single line matches what a hardcopy console would do, right?
<danvet> but for roughly 20 years no one is bothered enough to write even the simplest patches
<danvet> imirkin, not really
<imirkin> every kernel developer
<danvet> it's enabled in a lot of distros
<danvet> I don't use it
<imirkin> every kernel developer - 1
<imirkin> :p
<danvet> ssh
<danvet> like I don't want all those machines here :-)
<pq> unfortunately fbcon doesn't emulate the sound of a dot matrix printer
<imirkin> pq: i'm sure there's a patch for that
<danvet> imirkin, the other thing is also that people have funny ideas about how easy it is to fix fbcon
<imirkin> perhaps someone can add that to kmscon
<danvet> like -rt folks are screaming at console_lock for a good 5 years by now
<imirkin> danvet: this is why i didn't make a huge stink about it when you(? someone...) dropped all that stuff
<imirkin> i know fbcon is a huge pain :)
<danvet> imirkin, the thing is, it really doesn't need to be
shsharma has quit [Ping timeout: 480 seconds]
<danvet> 5 years ago we had this glorious plan of kmscon for login sessions
<imirkin> but legacy/etc make it harder?
<danvet> and a drmcon emergency console
<danvet> and an 80% demo of each was typed up
<danvet> but never enough people who cared to push it through
<imirkin> yeah, i remember that effort
<imirkin> seemed like a nice idea
<emersion> danvet, i never really understood how kmscon could work
<emersion> like, how would it replace fbcon?
<MrCooper> danvet: Geert gave an example where there simply isn't enough bandwidth for updating the display at full refresh rate from a shadow buffer; since you keep saying the latter is the solution, he must feel you're not taking him seriously in the best case
<danvet> emersion, it's just wayland without wayland but directly embedding the entire
<emersion> sure, but how to tell the kernel to spawn kmscon instead of fbcon?
<danvet> MrCooper, hm the one example I've seen was "4k uses a lot of bw, my parisc can't do that" which looked like a strawman
<danvet> MrCooper, the other is some really slow panels behind i2c and stuff like that
<MrCooper> nah, I mean the embedded display connected via I2C
<emersion> is there some kind of "exec this when the user switches to a new tty" thing?
<danvet> where gert says uploading xrgb8888 is too much
<javierm> emersion: I think fbcon is used for two things currently 1) early kernel boot log and 2) a VT. kmscon could replace (2) and drmlog replace (1)
<javierm> emersion: kmscon could be in the initramfs
<danvet> MrCooper, and that thing has a blt engine on the panel?
<danvet> (which like actually beats uploads at the right bitdepth)
<MrCooper> danvet: also consider that the same deferred drawing optimizations done with a shadow buffer could be applied to HW acceleration as well
<danvet> I know there's been some really funny soc architectures in the past
<MrCooper> danvet: I don't know, but I assumed Geert was implying so, otherwise not sure what his point was :)
<daniels> emersion: I guess it would be a userspace change where you would invoke kmscon+getty rather than just pure getty on each VT?
<daniels> (other getty implementations are available)
<emersion> hm i have absolutely no idea how getty works tbh
<danvet> MrCooper, the patches I've seen didn't look like anything like that, just (better) damage tracking in the upload
<GyrosGeier> there's also the school of thought that believes that skipping updates is fine as long as you can get back into the same state
<danvet> like I know there's funky hw, but geert's stuff didn't look like that funky
<danvet> and came with the insistence that drm cannot do damage tracking and therefor must suck
<danvet> or that drm must do xrgb8888
<emersion> apparently it's spawned by systemd?
<danvet> because a bunch of the drivers do that as sw fallback because of some userspace
<danvet> so ofc you cannot use anything else
<danvet> definitely not in the fbdev emulation
<danvet> MrCooper, so yeah I know that there's systems where you have to shovel an mpeg stream over the bus becuase nothing else is small enough
<danvet> and fun things like that
<danvet> but fbdev/fbcon as-is sucks for these too, plus in none of these threads has this actually come up
nchery has quit [Ping timeout: 480 seconds]
<MrCooper> danvet: damage tracking doesn't help in the scrolling case, always full damage
<danvet> yeah the damage tracking is paramount to get anything out of an i2c panel at all
<danvet> for the fbcon scrolling you need to decouple, and atm that means shadow fb
nchery has joined #dri-devel
<danvet> until someone types that up for fbcon itself
<danvet> that = update ratelimiting
<GyrosGeier> replicate vgacon's model of a long buffer, and the current on-screen portion being at an offset?
<danvet> doing that properly is really tricky because people get pissed when their oops doesn't get printed
<danvet> which is what the -rt folks are trying to fix with the console rewrite
<danvet> so that you can do some consoles async, except when it really matters, and without hacks like we currently do
<danvet> GyrosGeier, yeah pretty much
<danvet> well, console has that for you already
<GyrosGeier> that only maps vertical scrolling, but that's all that people are asking for anyway?
<danvet> you just need to pull the rendering out of the synchronous printk context
<danvet> "just"
<GyrosGeier> this could be combined with damage tracking
<danvet> yup, and at that point you have a competent kernel console
<danvet> with no hw accel needs
<danvet> and non-shitty locking
<danvet> if it ties correctly into the fixed console stuff
<danvet> like this entire thing has been discussed for years at plumbers in various forms
<danvet> except somehow the people who still care about actual fbdev drivers are never involved in that
<daniels> emersion: yeah, getty is spawned by systemd (previously inittab); somehow (??) pid 1 gets notified of VT switches, and it autospawns a getty on every new VT, which is the thing providing the login/pass prompt under KD_TEXT
<danvet> best part is that if it's all done right you actually end up with better chances that the oops shows up on screen
<daniels> emersion: so you'd instead want to spawn kmscon and then have that run getty
<emersion> makes sense
<danvet> daniels, also I think you need to emulate CONFIG_VT in userspace
<danvet> or maybe that part wasn't typed up yet
<danvet> but cuse ftw
<emersion> hm right not sure how the hand from kmscon to another DRM master would happen
<emersion> handoff*
<daniels> make seatd do it? :P
<danvet> I thought it's just a bunch of ioctl over vts
<danvet> which I thought you can fully emulate with cuse
<emersion> hm, yeah, logind/seatd could do it maybe
<emersion> ah, interesting
<GyrosGeier> wat
<GyrosGeier> why did they bother to start gettys on demand?
<GyrosGeier> the code to do that is likely larger than the nonshareable pages of ten gettys
<GyrosGeier> I'd still be happy if logind/seatd wasn't required for any functionality
<danvet> GyrosGeier, I think keeping the kernel's CONFIG_VT and running kmscon as KD_GRAPHICS and just spawning them all at boot-up should be enough
<danvet> and no logind/seatd required
<danvet> the userspace logind is only needed when you also run vt-switching entirely in userspace, but I don't think david way back then ever got that far
<GyrosGeier> as long as Xorg can save/restore state on switch, I'm good
<GyrosGeier> and possibly Qt's "qws" backend
dnkl has joined #dri-devel
<emersion> "save/restore state on switch"
<emersion> that's an over-statement
<pq> Secondary physical seats do not have any VTs, but you can still switch between sessions on one, implemented by logind.
<GyrosGeier> I build embedded devices, and systemd has way too much embedded policy to be useful for us
<pq> The first physical seat is the special-case that has VTs to deal with.
<GyrosGeier> like, no one ever logs in
<emersion> the state-of-the-art of VT switching is just "leave things dirty when switching away, when switching back set the props i need and hope for the best"
<ajax> i thought systemd learned how to cope with CONFIG_VT=n at one point
<ajax> if no one ever logs in it's _somewhat_ difficult to justify having any tty drivers...
fxkamd has joined #dri-devel
<GyrosGeier> we have a fbcon that shows error messages on boot if there are any, otherwise we use kms to set a graphics mode and render to the framebuffer from a program that is started from the inittab
<pq> The kernel also has no idea about physical seats at all, so CONFIG_VT=n and getting rid of all input device consuming (e.g. fbcon) in the kernel would be nice.
<pq> ...if the go to the opposite end from embedded
<pq> *if we
<GyrosGeier> mmh
<GyrosGeier> but what if error messages?
<GyrosGeier> I mean, even Windows has a framebuffer text console that gets activated when you have a scheduled file system check
mlankhorst has quit [Ping timeout: 480 seconds]
<pq> someone mentioned drmcon or something?
<ajax> if i was a kernel i would simply not cause any errors
<pq> it doesn't need any input, it's only for output, right?
<daniels> ajax: ah, Rust
<GyrosGeier> lol I had to fix a device this morning where the SD card was loose, causing read errors :P
ella-0 has quit [Read error: Connection reset by peer]
<ajax> (i am not being entirely serious, hopefully that's clear)
<imirkin> ajax: that you're not a kernel?
<daniels> imirkin: if he were, he'd cause errors for fun
<imirkin> and profit!
Company has quit [Read error: No route to host]
Company has joined #dri-devel
iive has joined #dri-devel
ella-0 has joined #dri-devel
Haaninjo has joined #dri-devel
mattrope has joined #dri-devel
<ajax> instead i just cause errors because i'm incompetent
<danvet> pq, yeah drmcon would be a kernel console only
<danvet> i.e. only output
<danvet> from printk and what you put into /dev/kmsg (or whatever the name was again, I forgot
<pq> only kernel output? even better
<danvet> well userspace can print into too with /dev/kmsg
<danvet> we do that in igt as breadcrumbs
<ajax> unrelated: anyone know how well 8k displays are expected to work?
<pq> yeah, but that's kinda almost kernel output, but I mean that no normal userspace app would be able to use it as a console
<emersion> ah that's smart
<pq> it's just a one-way character stream, like a line printer
<pq> or... a logger
<danvet> pq, yup
<emersion> it's a bit tempting to add a --print-to-kmsg compositor debug option, to print a serial number right before/after atomic commits
<danvet> pq, that's the other issue, how the kernel logging console and the vt console subsystem are all mixed up and messy
<pq> and it won't hook up to any input devices normal consoles do
<danvet> which is why the entirety of vt runs under console_lock
<danvet> which really doesn't help anything at all
<pq> just gimme kmscon and I'll happy CONFIG_VT=n (I wish) ;-)
<pq> which reminds me...
<emersion> danvet, how far off was kmscon?
<danvet> emersion, I thought it was at the "polish it to integrate into distros" stage
<danvet> s/to/and/ really
<danvet> iirc at least that was david's next steps, but then he disappeared into cloudy systemd stuff
<danvet> maybe tzimmermann/javierm tackle this after simpledrm is rolled out
<danvet> so that fbcon could be disabled
<danvet> well that needs drmcon done first I guess for emergency logging
<danvet> but then I guess fbcon can go and kmscon comes in, and also config_vt can probably go since it sounds like logind/seatd take care of it all already
<danvet> and then an enormous amount of syzbot reports just stop mattering in reality :-)
<danvet> also if you disable fbcon, all the fbdev locking problems disappear
<danvet> so keeping /dev/fb/0 around is totally ok
<danvet> also that code is pretty decent and easy to read, so no problem keeping it going for decades
<tzimmermann> danvet, pq, emersion, javerm and me discussed kmscon + drmlog as possible next steps
<danvet> it'd be really awesome I think
<pq> Why do people want kernel error logs *on screen* in the first place? Why not... files in persistent storage?
<danvet> pq, it's really for oopses
<danvet> where anything helps
<danvet> except with anything that's not just a dumb scanout buffer in wc memory, that's an extremely risky endeavour
<pq> exactly, how is showing stuff on screen any more easier or reliable than writing to disk or pstore?
<danvet> which is why I really want all that console improvements from the rt folks
<danvet> pq, so my idea is two fold
<danvet> for normal output it will be all done async, in a separate kthread
<danvet> and not possibly block/impact anything except the display
<danvet> we need the console_lock untangling for that
<danvet> also as soon as fbdev or drm userspace kicks in, this will not do anything
<danvet> or maybe it's going to be tied to KD_TEXT/GRAPHICS still, dunno
<danvet> the other thing is the emergency oops printer, for which I think we'd need driver support
<MrCooper> ajax: AFAIK 8K is supposed to work with amdgpu, but can't confirm first or even second hand
<danvet> since the only safe thing there is to look up an existing kernel mapping of the currently displaying buffer
<tzimmermann> GyrosGeier, danvet, for a fast console use fb emulation's overallocation + shadow fb + damage handling. then over-allocate video ram for the actual output. this way, only the next to be displayed needs to be memcpyd to the video ram. the memory offset can be shifted back and forth for scrolling. we have all components to make this happen AFAICT. just no driver bothered yet.
<danvet> and just write into that
<danvet> in an oops userspace is dead and the kernel doing it's last sigh
<danvet> so you can do that
<danvet> but also critically, you cannot do anything else
<danvet> i.e. "can't take locks" -> skip "display not on" -> skip "no kernel mapping exists" -> skip
<danvet> since if any of these fail you just oops even harder somewhere in drm
<danvet> or kill the machine outright while fiddling with clock generators
<danvet> tzimmermann, yeah I think that'd be the fastest fbcon really
<danvet> pq, also drmlog emergency would be the very last thing
<danvet> best part is that right now we've pretty much nerved fbcon emergency logging completely, so for parity I don't think we really need that
<danvet> and the best effort async printing from a kthread is good enough
<danvet> tzimmermann, btw for drmlog it's probably really good to sync with that console_lock effort
* danvet trying to load context and names on that
<tzimmermann> danvet, i didn't even look closely at drmlog
<danvet> ah right john ogness is the name
<danvet> tzimmermann, I honestly wonder whether we should bother with the emergency console part, at least at first
<danvet> iirc noralf did a prototype a while back
<danvet> but it really only works with driver support to fish out the vmap
<danvet> maybe if we wire that up for shmem and perhaps ttm helpers generically it's worth the bother, but otherwise probably not
<ajax> ugh, glapi
<HdkR> ajax: My 8k display worked okayish with amdgpu. Sometimes the tiles misaligned though.
<ajax> HdkR: which card, if you remember?
<HdkR> Which the Nvidia blob also misaligns the tiles sometimes. So whatever there.
<HdkR> This would be RX 5700
<ajax> rx480 here, might be one gen too old to really do it
aravind has quit [Ping timeout: 480 seconds]
<HdkR> It needs Displayport 1.4 on each of the ports. Not sure if the RX480 has that or 1.2
mbrost has joined #dri-devel
<HdkR> Internet claims the RX480 supports 1.4
<HdkR> One quirk was that auto tiling setup wasn't working. Had to manually xrandr the connections to the correct resolution modes
<ajax> urf
<ajax> not super interested in trying to make this work with xfree86 tbh, but also not super thrilled about teaching mutter about it...
<HdkR> Is it just tiling being the issue? Because there was some 5k Displayport 1.2 tiled monitor was well
<HdkR> s/was well/as well/
<ajax> not sure tbh. single cable stuff seems to work fine but 8k@30Hz is not super fun
<ajax> anything at 30Hz, honestly, is too laggy to use a mouse
<HdkR> Yea, destroy the 8k30 mode :P
devilhorns has quit []
devilhorns has joined #dri-devel
Duke`` has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
<javierm> for reference, this was the drmlog posted by david bach then:
<danvet> javierm, yeah the one from noralf should be good starting point
<danvet> maybe we can ditch some of the work stuff with the console kthread
<danvet> but I'm not sure how far that's pushed really
cwfitzgerald[m] is now known as cwfitzgerald
<danvet> I routinely get lost in there since there's a few things that are similar but not the same
Hi-Angel has quit [Remote host closed the connection]
<danvet> maybe good to combine the two since the drmlog from david has a pile more rendering code
<danvet> otoh that one is b&w only
<danvet> hm no
<danvet> javierm, it evolved a bunch
<javierm> danvet: thanks for the ref. I missed this before
<danvet> I thought there was an update from last year on direction
<danvet> but can't find it right now
<danvet> maybe some lwn merge window coverage
<danvet> iirc some of the defaults and stuff changed
<danvet> like the separate kthread is now opt-in or something
<danvet> Linus has some opinions
devilhorns has quit []
<Ristovski> ccr: Can you elaborate a bit on the issue you reported yesterday to do with Darkplaces and it being slightly choppy? Is it constant or does it happen only rarely? I have at times experienced a similar issue with other apps, but not with zink (?so maybe unrelated?)
devilhorns has joined #dri-devel
* Ristovski has reached the point where he can detect perf issues via muscle memory in Xonotic
<danvet> javierm, last discussion I had with John ogness
join_subline has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<javierm> danvet: perfect, thanks
kts has quit [Quit: Konversation terminated!]
ybogdano has joined #dri-devel
kts has joined #dri-devel
<ccr> Ristovski, it's a bit like .. maybe frames being shown in wrong order, and game frame time going fast and slow. a bit difficult to explain, I could take a video of it I suppose.
join_subline has joined #dri-devel
<ccr> Ristovski, Darkplaces works just fine with native i965/crocus GL for me, this occurs only under Zink (and apparently vsync has something to do with it too)
<Ristovski> ccr: Interesting. So it's not the same issue I am experiencing, but similar symptoms
MajorBiscuit has quit [Ping timeout: 480 seconds]
<Ristovski> There is also that cursed issue where sometimes there is additional input lag that goes away when I switch to a tty and back (very hard to notice, but you will notice it if you have 10+ years of Quake movement muscle memory :P)
<ccr> :)
<ccr> DP is also the only software I've seen exhibit this issue with Zink .. but I haven't really ran that many programs under Zink anyway, so shrug
LexSfX has quit []
tzimmermann has quit [Quit: Leaving]
MajorBiscuit has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<hakzsam> who is the libdrm release manager these days? it would be cool if we can have a release for the new AMDGPU ioctl
<bnieuwenhuizen> there is none. We can make a release if we want
<MrCooper> hakzsam: it's whoever needs a release to happen, sounds like it's you for the next one :)
<hakzsam> ok, will do thanks :)
MajorBiscuit has quit [Ping timeout: 480 seconds]
<HdkR> New amdgpu ioctl?
<HdkR> Is this upstream?
<HdkR> ah, new CTX ioctl subop rather than an entirely new ioctl
sarnex_ has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
<HdkR> Looks like I don't need to change any definitions in my ioctl fork for that to just work. Thanks :)
<ccr> Ristovski, in case you wish to see.
LexSfX has joined #dri-devel
ybogdano has joined #dri-devel
<hakzsam> do I need a gpg key?
Mis012[m] has joined #dri-devel
<Ristovski> ccr: Aaah I see! That is indeed quite bad, the random jitter I very rarely get is nothing compared to this.
<ccr> yep. with vsync on, it's almost as good as native GL, but still has slight weird feeling to it ..
<ccr> interestingly the in-game fps meter stays around the same in both vsync on and off cases
<emersion> hakzsam: to sign the release tarball yes
<emersion> you also need an SSH account on fdo
<hakzsam> I have an assh account, but no gpg key (or I don't remember)
<airlied> ajax: 8k may involve DSC working
<HdkR> Luckily there aren't any 8k+DP+DSC monitors on the market. Only the 8K Dell and televisions which use HDMI :)
demarchi has quit [Ping timeout: 480 seconds]
<airlied> ah cool
<imirkin> hakzsam: you had to get a gpg key to make the ssh account iirc
<airlied> dj-death: 4s? is that -O0 or ccache?
<imirkin> hakzsam: either way, the gpg key you sign with can be whatever
demarchi has joined #dri-devel
alyssa has joined #dri-devel
<alyssa> "
<alyssa> nir: add no_varying & no_sysval_output IO semantic flags, transform feedback info in IO intrinsics; fixes
<alyssa> "
<alyssa> it's not entirely clear to me how the new information is menat to be used by drivers that arne't radeonsi
<alyssa> it seems like it's probably useful for AGX and maybe Mali, but I don't have a good feel for how this is supposed to fit together
tobiasjakobi has joined #dri-devel
<alyssa> cd ~:wq
<dj-death> airlied: debugoptimized build no ccache
tobiasjakobi has quit [Remote host closed the connection]
<airlied> dj-death: wierd that it's so much slower here
<airlied> I'm running the cc command that ninja outputs manually to time it
mlankhorst has joined #dri-devel
anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
ahajda has quit []
<dj-death> airlied: no idea :(
<dj-death> airlied: anyway splitting things almost halves the time here, so should be helpful for you too
mszyprow has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<zmike> alyssa: maybe you should do a full asm-level review of vbuf for performance reasons
gouchi has joined #dri-devel
devilhorns has quit []
<alyssa> zmike: *closes Ghidra tab of u_vbuf.c.o and sweats nervously*
<zmike> alyssa: given the gains I'm getting out of it with just this small series it's not hard to imagine there's others that could be just as big
<alyssa> i am currently debugging the kernel
<alyssa> can't help much rn sorry
<zmike> boooooooooooooooring
* ccr calls phoronix hint line
<alyssa> maybe jekstrand[m] can help, not like he's doing anything else at his job at Agriculture and Agri-Food Canada
<zmike> no, he has more important matters to worry about at Braun working on their new line of smart coffee makers
<Sachiel> wait... he has a [m] now? New Matrix movie confirmed
kts has quit [Quit: Konversation terminated!]
ahajda has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<jekstrand> The matrix is also a diversion...
<ccr> there is no spoon!
<Sachiel> sporks only
ybogdano has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
rasterman has quit [Read error: No route to host]
sdutt has joined #dri-devel
gawin has joined #dri-devel
frieder has joined #dri-devel
frieder has quit [Remote host closed the connection]
camus1 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
cworth has quit [Quit: Leaving]
<alyssa> has anyone seen an irq_work_run_list BUG_ON fail from drm_sched_entity_fini?
<alyssa> in over my head
gouchi has quit [Remote host closed the connection]
<alyssa> Although, umm
<alyssa> irq_work_queue is defined in irq_work.c which says it's for a hardirq context
<alyssa> I don't see drm_sched_entity_fini as needing a hardirq context?
<alyssa> oh, for queueing work to be run in a hardirq context, never mind
<alyssa> maybe I should try with kasan in case htings are even more broken than I think
mszyprow has joined #dri-devel
<alyssa> [ 0.000000] BUG: KASAN: invalid-access in setup_arch+0x658/0x7e8
<alyssa> ummmmm
<airlied> seems suboptimal :-P
camus1 has joined #dri-devel
<alyssa> airlied: guessing that the arm64 specific kasan stuff is broken. Trying the generic implementation instead...
<alyssa> also enabling kernel UBSAN
mvlad has quit [Quit: Leaving]
camus has quit [Ping timeout: 480 seconds]
thellstrom has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
<alyssa> at least on the surface it looks like IRQs being enabled somehwere they shouldn't
ahajda has quit []
fxkamd has quit []
<airlied> the active bit being stuck at the top looks bad
* jekstrand will pretend hes' never written kernel code and let airlied do the helping. :)
<alyssa> airlied: that's only tangentially related, that happens with large numbers of faults. it should not take down the machine
alatiera5 has joined #dri-devel
<airlied> I don't think I'm allowed write kernel code anymore
<alyssa> to be clear, reproducing this panic requires storming the GPU with 1000s of faults in a short priod of time
<alyssa> so if the bug only occurs with gpu faults/hangs and is a race that we win 99.9% of the time...
<alyssa> ...then deqp-runner using all cores with my broken as F mesa is better than igt ;-)
<alyssa> Okay, I think I see what's happening
<alyssa> Zooming in, now
<alyssa> see kernel/irq_work.c
<alyssa> specifically the implementations of irq_work_run and irq_work_run_list
<alyssa> the BUG_ON we fail in irq_work_run_list comes when we try to run for the lazy_list, it passes for the raised_list
Haaninjo has quit [Quit: Ex-Chat]
<alyssa> meaning, IRQs are getting enabled later in irq_work_run_list
alatiera has quit [Ping timeout: 480 seconds]
<alyssa> => some broken worker in panfrost or DRM core is enabling IRQs
* alyssa printks harder
<airlied> alyssa: drm/sched: Avoid lockdep spalt on killing a processes
<airlied> seems possibly relevant not sure
alatiera5 is now known as alatiera
<airlied> but might be the cause of it :-P
<alyssa> running deqp again with some printks to name and shame the guilty
<alyssa> so we'll know in a fe wminutes
<alyssa> (dmesg is spamming faults but not hard enough, apparently :-p)
<alyssa> naming and shaming 000000002d2a73cf
<alyssa> um
<alyssa> does %pF not work that way
<alyssa> airlied: Unfortunately I have that patch in my tree already
<airlied> alyssa: yeah I was going to say revert it :-P
<alyssa> oh
mlankhorst has quit [Ping timeout: 480 seconds]
<alyssa> will do next trial
<alyssa> ugh why does it takes well over 2 minutes of spamming faults before it kerplutzs
<alyssa> coming up on 3 minutes and still going, mumble
<mareko> somebody mentioned my name here but it's farther than I can scroll
<alyssa> airlied: 63.913050] panfr[ 267.080613] naming and shaming drm_sched_entity_kill_jobs_irq
<alyssa> _work+0x0/0x60
<alyssa> that was introduced by the lockdep spalt patch indeed
<gawin> mareko: "23:56 airlied: mareko: since I know you don't always see MRs, might benefit from your input "
<airlied> mareko: it's merged now so all good :-)
<alyssa> airlied: calling spin_lock/unlock in an irq context is a no no isn't it..
<airlied> totally a no no
<alyssa> the fallout from "Avoid lockdep spalt" might be far worse than anticipated then
<alyssa> or panfrost was broken before.
nchery has quit [Quit: Leaving]
<alyssa> guess I need to audit /everything/ called by panfrost's free_job..
<alyssa> dma_fence_put is safe?
<airlied> I think so, but I'm not the expert on scheduler
<alyssa> ummmm
LexSfX has quit []
<alyssa> drm_sched_entity_kill_jobs_cb -> panfrost_free_job -> panfrost_job_put -> panfrost_job_cleanup -> panfrost_gem_mapping_put -> panfrost_gem_mapping_release -> ...
<alyssa> panfrost_gem_teardown_mapping -> panfrost_mmu_unmap -> { iopgtbl_ops->{iova_to_phys, unmap}, panfrost_mmu_flush_range -> pm_runime_get_noresume, pm_runtime_active, mmu_hw_do_operation, pm_runtime_put_sync_autospend -> ...
<alyssa> also from gem_teardown_mapping -> spin_lock, spin_unlock, drm_mm_remove_node -> ...
<alyssa> panfrost_mmu_ctx_put -> panfrost_mmu_release_ctx -> spin_lock, spin_unlock, pm_runtime_*, panfrost_mmu_disable -> mmu_hw_do_operation_locked
LexSfX has joined #dri-devel
<alyssa> I see multiple bad spinlocks if this is meant to run in an IRQ context
<alyssa> but it would seem, um
<alyssa> panfrost_free_job was written under the assumption of being called from a process context.
<alyssa> none of this is time critical so maybe doing the free job on a workqueue is easier than fixing this mess
<alyssa> bbrezillon: robher: ^
<alyssa> airlied: If I'm not mistaken, that patch makes free_job called in an IRQ context when it used to be called in a process context. So that's a regression and I assume panfrost isn't the only affected driver...
gawin has quit [Ping timeout: 480 seconds]