<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]
<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) ;-)
<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
<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
<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 :)
<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...