ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<soreau>
mareko: AMD_DEBUG=nodcc makes the bug worse, (many more frames are transparent textures) while AMD_DEBUG=notiling makes the bug not happen at all
<soreau>
almost have enough to file a bug report but the way to reproduce it is kinda going out on a limb
<soreau>
but no2d makes it worse too, huh
<soreau>
AMD_DEBUG=w32ps makes it not happen as well
mediaim has quit [Read error: Connection reset by peer]
illwieckz has quit [Remote host closed the connection]
columbarius has quit [Ping timeout: 480 seconds]
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
illwieckz has joined #dri-devel
cphealy has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
camus has joined #dri-devel
illwieckz has quit [Quit: I'll be back!]
illwieckz has joined #dri-devel
yuq825 has joined #dri-devel
diego has joined #dri-devel
diego has left #dri-devel [WeeChat 4.0.4]
dviola has joined #dri-devel
crabbedhaloablut has joined #dri-devel
loki_val has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
aravind has joined #dri-devel
illwieckz has quit [Read error: Connection reset by peer]
illwieckz has joined #dri-devel
<lina>
DemiMarie: The AGX hardware is pretty "normal" as far as security goes. It doesn't do the nvidia thing of exposing MMIO directly to userspace, so you have to go through the kernel/firmware, but it still has context separation and all that, and it can actually run multiple jobs from different contexts at once securely. Most of the dumb things I run into are bad design decisions in Apple's drivers and
<lina>
firmware... like, I think the cross-context DoS aspect is mostly just the firmware not being designed correctly, not that the hardware is broken like that.
<DemiMarie>
lina: Makes sense. I was quite surprised that this was only DoS; “buffer control” sounds rather important!
<lina>
Oh that one is at least somewhat worse than DoS at least to some extent, but my driver isn't vulnerable to that.
<DemiMarie>
nice :)
<DemiMarie>
might be able to get another bounty from Apple if you could exploit ti
<DemiMarie>
it
<lina>
That one I found gets accessed through privileged context #0 always, so now I just double-map it in context #0 low memory and firmware memory, with the right permissions.
<DemiMarie>
nice
<lina>
I actually told them about that one, they implemented a (worse than mine) workaround in 13.0, then reverted it for some reason...
<lina>
I think they just don't care of "mostly DoS level" problems right now
<DemiMarie>
reverted it? that sounds fishy!
<lina>
Their workaround was mapping it in context #0 user area and actually making the firmware use that, which involved the firmware TTBR-switching into #0 to mess with it, which I guess has a performance penalty since it's a uPPL call. Or maybe it interacted badly with the other stuff they use user contexts for.
<lina>
I suspect they just didn't think of the double-mapping solution.
<lina>
I also told them to just outright unmap the whole firmware are from user contexts, and I used to do that, but sadly with G14X the GPU started requiring *read* access to command buffers since I suspect they're now using hardware register sequencing.
<lina>
So now I map those read-only there, which is a bit sad but not a major infoleak (it's mostly just dumb render settings in there, the most useful info you can get out of it is framebuffer dimensions)
<lina>
I still need to investigate whether safer workaround for that one are possible, they might well be
<DemiMarie>
Wow!
<lina>
A lot of this is "how much can I diverge from what macOS does and still make it work"
<DemiMarie>
You are definitely better at writing drivers than they are.
<lina>
The main DoS thing I can't fix is that if jobs are running in parallel, a fault/timeout in one often kills the others. But that's a common problem in GPU land, sadly...
<DemiMarie>
Unfortunately so…
<lina>
However, I can still investigate stuff there. Like, for example, there may be a way to retry jobs that are idempotent, and a lot of "simple" render jobs are idempotent (anything that starts with a framebuffer clear), so that could harden things like common compositor jobs from misbehaving apps.
<DemiMarie>
There’s other ways not to be idempotent, like image load/store.
<lina>
yes
<DemiMarie>
Userspace could do that automatically, though.
<lina>
There is actually one kind of unknown job flag where the logic we have/reverse engineered is suspiciously like "is idempotent", and I wonder if it affects firmware job recovery...
lemonzest has quit [Quit: WeeChat 4.0.4]
<lina>
Job retries? No, that has to happen in firmware/kernel, because by the time userspace submits a job and gets out fences those signal successful completion of the job to the next part, there's no going back unless you break the signaling look in userspace which sucks for performance.
<DemiMarie>
I would not be surprised at all.
<lina>
Job faults are a stop-the-world situation, so the kernel is in a perfect spot to mess with things as long as the firmware likes what it ends up with. I just need to understand what we can do.
lemonzest has joined #dri-devel
<lina>
Right now we just clear the faulted job IDs and the firmware action seems to be to shunt them to complete (we mark them as failed).
<lina>
But maybe there are ways to ask for a retry, or to mess with in-memory state to do something else.
<airlied>
I think there a lot of reasons mentioned why kernel retries are bad plan
lemonzest has quit []
<DemiMarie>
How bad is serializing all jobs such that only one executes at a time?
<lina>
airlied: I think the issue was retries for a culprit job are bad; retries for a victim job that is idempotent aren't.
<airlied>
that seems like it would be bad just from a throughput pov
lemonzest has joined #dri-devel
<lina>
Why would it affect throughput? In the normal case the codepath never gets called.
<airlied>
lina: but you can't really tell idempotent with a shader analysis can you?
<lina>
This only happens on faults.
<airlied>
if you serialised all jobs
<airlied>
always
<airlied>
without a shader analysis
<lina>
Oh sorry, misread
<lina>
Yes
<lina>
airlied: We own the shader compiler, we know what the shaders do... If there are any stores it's not idempotent.
<airlied>
if a job has landed on the hw at all, and you it dies, resubmitting it is generally considered a bad strategy
<airlied>
what about hw counters etc?
<airlied>
depth buffer interactions
<lina>
This is a job-based architecture, everything is a big load/store around jobs
<lina>
There is no state
Duke`` has joined #dri-devel
<DemiMarie>
I wonder why faults wind up killing other jobs.
<lina>
The only issue is how many tiles were partially read/written from the framebuffers, but that's why this only works if we either have separate load/store pointers (which is totally possible and would make sense for a robust mode), or if everything starts with a clear.
<lina>
DemiMarie: I think the firmware is just dumb and does a full reset when it faults.
<DemiMarie>
lina: ouch
<airlied>
lina: does it include vertex and compute shaders?
<lina>
Yes, though compute will of course do arbitrary load/store so unless you have higher level knowledge that's harder.
<lina>
Vertex and fragment have a very well defined pipeline in simple cases.
<lina>
In the end this would be (already is if my guess is correct) a UAPI flag, so the driver has to know.
<airlied>
occlusion queries just seem like they could get miscounted, but maybe that won't matter
<airlied>
or at least pipeline stats might get screwed up
<lina>
I forget if those are cleared before everything, they probably are though?
<lina>
I mean you're rerunning the whole job
<DemiMarie>
does anyone care about pipeline stats except for debugging?
<DemiMarie>
also something with stores can be idempotent if none of the stores alias any of the loads
<lina>
Stats/perfctrs of course would change, but we don't even support those right now and... really, who cares, when the alternative is outright killing the job?
<lina>
I mean nobody thinks killing the compositor when your app faults is a good idea, so our options right now are either just do nothing and deal with the resulting screen corruption/glitching from an aborted compositor job, or try to make it less bad...
<airlied>
does OSX kill the compositor?
<lina>
No, OSX glitches.
<lina>
We've seen a bunch of that experimenting...
<airlied>
so someone thinks it is a good idea :-)
<airlied>
granted we'd have to make out compostiors deal with device loss
<lina>
Actually I don't remember if I've seen the compositor glitch, but I've definitely seen other apps glitch.
<DemiMarie>
How bad would it be to have the compositor jobs never run in parallel with other jobs?
<lina>
It's actually possible the existing idempotent-suspect flag already works like this
<lina>
I haven't tested it
<lina>
If macOS always runs jobs like that with their compositor it'd be immune.
mediaim has joined #dri-devel
<lina>
DemiMarie: I'm not sure we can sanely mutex those like this. It's a firmware scheduler, if we try to micromanage it it might as well not be there and we lose performance...
<lina>
Of course there's still tons of unknowns and features that it might have that we might not know about.
<lina>
So really the answer to a lot of these things is just to dfo more experiments and reverse engineer more of the firmware directly ^^
<lina>
There's only so much I can do by observing the way macOS does things
<DemiMarie>
True
<DemiMarie>
Hopefully you don’t wind up having to ship firmware ROP chains in production!
<lina>
I can check whether that flag is an "idempotent" flag by forcing a job kill in my python testbed and then seeing if the firmware reruns on recovery (I can observe job states over time with some polling stuff)
<lina>
Stuff like that
<lina>
Those experiments are really hard to run in Linux but thankfully we have m1n1 ^^
<lina>
DemiMarie: Yeah, though I'm eyeing at least the SGX write microops... I already tried and succeeded in using them to increase the bindless sampler count from 1024 to 2048 (really dumb firmware limitation, I think Apple actually fixed it in 14.0 but we might as well support it everywhere)
<lina>
Those are handy to get the hardware to do things the firmware doesn't support ^^
<DemiMarie>
lina: I wonder why the firmware crashes when there are too many faults.
<DemiMarie>
I hope it isn’t overflowing a fixed size log buffer or something bad like that…
<lina>
Yeah... that one, I don't know if that's my fault or a race in the firmware or what. It's really tricky to debug. I don't think I've ever seen it in macOS but macOS also has very different allocation patterns to my driver, so it doesn't mean it's my bug... but it might well be.
<lina>
Last I tried to dive into it, at least some cases looked like a command type confusion. But that could well be a caching issue that's my fault.
<lina>
Caching has been consistently a major pain...
<lina>
It's not a buffer overflow or anything like that.
<DemiMarie>
That’s good
<lina>
The crashes are often asserts where stamps are noncontiguous and things like that.
<lina>
It's a state problem.
fab has joined #dri-devel
<lina>
Others I've seen were definitely type confusion leading to a bad access, like it was trying to parse a command as a different type and dereferencing pointers.
<lina>
Which suggests somewhere along the way command indexes or types got confused somewhere in some array.
<lina>
The good thing is that faults are stop-the-world and do a full cache flush and the kernel *can* just directly write firmware .data, so if it comes to that we could just "fix" whatever is wrong in firmware memory, though it would be ugly...
<lina>
But maybe this is all something I missed, or maybe we can fix it by only messing with shared data structures which is much cleaner.
<lina>
Come to think of it, since faults are stop-the-world, I could try to snapshot RAM after every fault and get it to crash and then try to replay that state in my fancy javascript emulator...
<lina>
That might get me somewhere, if the snapshotting overhead doesn't mask the heisenbug...
<DemiMarie>
I wonder if the firmware is forgetting to disable interrupts during some non-atomic operation.
itoral has joined #dri-devel
<lina>
Yes, it could well be a race like that
<lina>
Something like the fault handler/timeout IRQ gets invoked during a bad point
<DemiMarie>
Anyway it’s bedtime here
<lina>
Good night! ^^
<DemiMarie>
Goodbye, and nice talking to you!
<mediaim>
That's a weird content this cow reports DemiMarie, I know how aggressive thinkers some are though, like airlied, I doubt they have anything against to modernize and simplify the stack a bit, mmiotrace as a tool is also quite easy to rewrite to performing version.
<HdkR>
If +M is missing we need more moderators in more timezones.
<HdkR>
I volunteer for tribute since my polyphasic sleep cycle means I'm usually available.
<psykose>
i usually don't care much for trolling because it's at least a little funny but this spam is just brain death after months of it
<psykose>
this person is such a loser
Duke`` has quit [Ping timeout: 480 seconds]
<Sachiel>
+M doesn't help in this case either
<HdkR>
+M just adds a layer of annoyance which slows things down
<HdkR>
Which can be helpful to reduce the number of interactions at least
mediaim was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<HdkR>
Does akick work for non-registered users even?
<Sachiel>
he is registered
<Sachiel>
he always is, that's why I say +M doesn't help
<ccr>
registering is "too easy", he always creates new users
<HdkR>
Guess they started doing that once everyone slapped +M on the channels
<ccr>
not a problem that could be trivially solved, unfortunately.
<Sachiel>
nah, he always has
<Sachiel>
he's been doing it for years
<ccr>
closer to ten years, I'd say .. at least about as long as I've been idling on x/freedesktop related channels
<ccr>
hmm .. that might've sounded a bit suspicious :D
<psykose>
one of those rare situations one really wishes for that extrajudicial hit squad
<ccr>
:/
<psykose>
ah well
<psykose>
it is what it is :)
tzimmermann has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
Danct12 has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
<HdkR>
No need to take the discussion that low. Going down to that level makes a fool out of everyone.
<dottedmag>
psykose: Please feel sorry for them, they definitely have lost some gears, not their fault (most likely). I've seen people gradually descending into this kind of hell, and it's not fun.
<tzimmermann>
javierm, i'd say that arnd 's patch is different
<tzimmermann>
the sh4 driver needs FB=y
<arnd>
is there anything I need to change in my patch to get that applied? I have not seen the other patch and don't know if there are still any open issues with mine
<arnd>
it should get the defaults back to exactly what they were in 6.5
Danct12 has joined #dri-devel
Danct12 has quit []
<arnd>
ah, you mean rdd's reply, yes his patch is fine. I think what happened there is that it was broken already but the bot saw a slightly different error message after the recent changes
junaid has joined #dri-devel
<arnd>
before tzimmermann's patch, it had a link failure against a number of symbols, now it also needs fb_io_read/fb_io_write on top of those
<tzimmermann>
arnd, feel free to ignore my comment on your patchset. it was more like a 'what if'.
apinheiro has joined #dri-devel
junaid has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
pcercuei has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
<javierm>
tzimmermann: sha4 driver requires FB=y ? But even before the FB_CORE split FB was a tristate symbol
<arnd>
javierm: sh has endless randconfig build failures, the bot just has a database so it can ignore the known ones, but that only works as long as the error message has the same output
<javierm>
arnd: ah, I see. Now understand your previous message about slightly different error message
<jannau>
tzimmermann: PPC dts doesn't seem to use "power-domains" properties, at least not in tree. so ofdrm is good as it is
kxkamil has quit []
frieder has joined #dri-devel
<tzimmermann>
jannau, thanks. i'll merge your patch then
<tzimmermann>
picngme if I forget about is
<tzimmermann>
it
<tzimmermann>
'ping'
<jannau>
sure. thanks
<javierm>
tzimmermann: right, typo but still my point stands. FB used to be tristate anyways so if FB_SH7760 needs FB to be built-in, then should depend on FB=y
<javierm>
not depend on FB
<tzimmermann>
javierm, i think this is fallout from my patch 5f86367006c6 ("fbdev/sh7760fb: Use fbdev I/O helpers")
<tzimmermann>
fb_io_read() used to be part of fb_read(). but now it is set by FB_IOMEM_HELPERS
kxkamil has joined #dri-devel
<tzimmermann>
i cannot really tell why this makes a difference, but apparently it does
lynxeye has joined #dri-devel
<tzimmermann>
hmm, but that doesn't explain the other missing symbols, such as fb_alloc_cmap()
<tzimmermann>
no idea than
<tzimmermann>
then
pekkari has joined #dri-devel
novaisc has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
tonyk has joined #dri-devel
jfalempe has joined #dri-devel
<javierm>
tzimmermann: let me fetch that config and see if I can reproduce it
pekkari has joined #dri-devel
Haaninjo has joined #dri-devel
<arnd>
javier tzimmermann:I'm very sure it was always broken, just send a fix and don't spend too much time researching it
<tzimmermann>
ok
donaldrobson has joined #dri-devel
<arnd>
tzimmermann: I saw your latest cleanups for drivers/video split out the logo stuff. I was going to propose the same thing but your patch is nicer than the one I made anyway, so I'm really happy with that
<arnd>
I also tried to untangle modedb.c as I noticed that almost all of it is only needed with CONFIG_FB=y but not with pure DRM/FB_CORE
<arnd>
I spent way too much time on that but just couldn't figure it out so far
<tzimmermann>
thanks
<arnd>
I have a simple patch that adds an #ifdef CONFIG_FB around everything but the middle block (fb_var_to_videomode, fb_videomode_to_var, fb_mode_is_equal, fb_find_best_mode, fb_find_nearest_mode, fb_match_mode, fb_add_videomode, fb_delete_videomode and fb_destroy_modelist)
<tzimmermann>
i'll look at modedb if i find time
<arnd>
ok, great
<javierm>
tzimmermann: do you want to post a fix making it depends on FB=y ?
<tzimmermann>
javierm, i'm on it
<arnd>
I'm fairly sure the remaining modedb functions I left there are not actually needed since there is no point maintaining the linked list when there is only ever one entry in it and you can't change modes from it, but it is all tangled up in fb_set_var()
<javierm>
tzimmermann: I tried to reproduce locally but I need a superh cross-compiler since the driver depends on platform data in <asm/sh7760fb.h>
<tzimmermann>
i've been interested in merging drm's and fbdev's modetables and cmdline code in a single place within video/.
<tzimmermann>
i just haven't figured out how to sell that to either drm nor fbdev devs :P
<javierm>
tzimmermann, arnd: didn't find a sh cross-compiler already packaged in fedora so gave up :)
<arnd>
tzimmermann: my feeling was that the fbdev mode lists are a lost cause and ti would be better to just keep them away from the drm/fb_core side
<tzimmermann>
javierm, yeah, some of these drivers are almost impossible to build
<tzimmermann>
arnd, i'll keep that in mind
<arnd>
tzimmermann: in particular, the mode setting through the sysfs code looks actively evil and should probably just be removed. I think there are no users because adding a modelist that way seems to add userspace pointers into kernel structures, and that crashes when you try to read it out again, at least from another process
<tzimmermann>
javierm, for of them (ep93xx IRCC) i made it config_cross_compile and copied some headers into x86 arch. then i could partially build it for one of my patches
<javierm>
tzimmermann: urgh
<tzimmermann>
it was good enough to build-test that patch's change
<javierm>
tzimmermann: yeah, I'm just thinking if pulling <asm/sh7760fb.h> would need to get more headers due transitive dependency
<javierm>
anyways, you are on it so I leave that in your capable hands :D
<tzimmermann>
arnd, i'm thinking of tables of displaymodes. they seem to be duplicated. but maybe it's not worth the effort anyway
<arnd>
tzimmermann: my feeling is that the "fb_videomode modedb[]" array is too tangled up with the legacy drivers that have their own tables in platform data, so you can't easily change the code using it, and making drm use the fb table would be a step backwards for drm
qyliss has quit [Quit: bye]
<sima>
yeah I don't think there's a benefit in trying to merge fbdev and drm mode handling, just a lot of pains
<sima>
what might make sense is just radically cutting it if there's only drm fbdev enabled
<arnd>
tzimmermann: something that would probably help is to try moving fb_set_var() into a separate file that is only used by fb_device or the legacy drivers, the tricky bit here is changing the callers in fbcon (fbcon_set_disp, fbcon_resize, fbcon_switch, fbcon_blank) to do a lower level operation on the fb device, at least for the drm case
qyliss has joined #dri-devel
<tzimmermann>
the cost-benefit ratio might not be worth it
<sima>
for fairly radical nuking making fb_info->modelist optional and then dumping all related code, with fbcon just copying over the current fbdev mode, might work
<javierm>
hopefully we should be able to get rid of fbcon at some point
<sima>
but only for the case where only drm is enabled as sole driver
<sima>
yeah ideally all we keep support is the fbdev uapi on top of drm
<sima>
because the entire fbcon locking is fairly fundamentally busted
<tzimmermann>
but i didn't fully check if both are fully compatible.
<tzimmermann>
sima, the reason for me to consider it, would be that it would result in a single parser for that complicated option
<arnd>
what would be the replacement for fbcon? my feeling was that /dev/fb is the one we should get rid of, not the console
<tzimmermann>
but i never spent any time on it
<sima>
tzimmermann, well if you make fbinfo->modelist optional with a Kconfig and then go around adding #ifdef until it compiles
<sima>
you should get there too
<sima>
without any risk of breaking legacy fbdev drivers
<tzimmermann>
arnd, /dev/fb is already optional
<sima>
arnd, /dev/fb has some apps that use it, and it's uapi
<arnd>
tzimmermann: I know, they are both optional, the question is just which one you consider more important
<sima>
plus it alone is fairly reasonable wrt locking/lifetime fun
<sima>
arnd, fbcon otoh is terminally screwed up and would need a full rewrite if you want to get rid of the cve potential
<sima>
and if you rewrite the thing, might as well implement it mostly in userspace
<tzimmermann>
fbcon would be replaced by a simple display output for system panics and a console in userspace
<tzimmermann>
arnd, search dri-devel for 'drm_panic'
<arnd>
sima: my impression from /sys/class/graphics/fb0/modes is that this is also an instance cvs
<arnd>
cvs
<arnd>
cve
<tzimmermann>
there's been an RFC patchset on it
<sima>
arnd, yeah, that's why I suggested the fbinfo->modelist Kconfig
<sima>
I think if you do that, you'd nuke the modes sysfs, the duplicated parser, and a lot of other fun stuff
<sima>
but only works if the sole fbdev driver is drm, since that has a fixed mode :-)
<sima>
maybe with some functions shuffled and some wrappers added it wouldn't even be that many #ifdef all over the code
<arnd>
the problem I ran into there is setting the mode through the tty path, which then tries to look up the current mode in the list. there is probably a way to replace that, but that is the part I meant above with reworking fb_set_var()
<tzimmermann>
from my distro POV, i'd rather just disable fbdev entirely than make it more fine-grainedly configurable
<sima>
arnd, for drm you can just keep the current one from info->var and be done
<arnd>
having an option to set FB_DEVICE=m might also be interesting, that way a distro can still build the module but not load it by default
<sima>
instead of trying to match some mode
<sima>
arnd, also if drm ever gets multiple true fbdev mode support, the proper approach would be to just wire the fbdev mode stuff through to drm
<sima>
instead of trying to maintain 2 mode lists
<arnd>
sima: right, that is what I had hoped, I just couldn't prove that this is the case. my initiali reading was that there is a case where you set the mode through /dev/dri/*, which then calls into the fbcon code and from there into fbmem.c, and that would fail
<sima>
arnd, last lines in do_register_framebuffer() for what happens if you only have one mode, we essentially just put the mode from info->var into the modelist
pekkari has quit [Ping timeout: 480 seconds]
<sima>
arnd, nah nothing flows from dri back to fbdev, at all
<sima>
the one fbdev mode is picked up when we register the fbdev, and fairly fake (at least for multi screen with different outputs)
<arnd>
what happens if you set the mode on the console through dri?
<sima>
you cant
<arnd>
ok
<arnd>
what about setting it through console ioctl?
<sima>
or well you can, but the moment the console gets back into control it'll restore the drm-fbdev-emulation mode
<sima>
it'll change the sw size, but physically nothing changes
<sima>
fbcon just renders into a smaller part of the real framebuffer
pekkari has joined #dri-devel
<sima>
arnd, drm fbdev emulation is a subordinate drm display owner (called drm master because)
<arnd>
in that case, we can probably just blank out all the fbcon functions that call fb_set_var() and return an error from them when CONFIG_FB is disabled, and at that point eliminate all of modedb.c and fb_set_var()
<sima>
so the moment you have a real drm master, drm-fbdev and so fbcon is not in control at all
<sima>
arnd, ah no, because we do support change some things, just not the actual physical mode
<arnd>
signing off for today, have to catch a flight
<sima>
but we should be able to nuke the modelist related stuff, from a quick look nuking everything you hit when you make fbinfo->modelist optional and replacing the fbcon mode picker with the logic in register_framebuffer that just picks info->var should work
<sima>
arnd, ttyl, and good travelling!
<sima>
arnd, also if anyone notices the sysfs regression, implementing something non-broken for the single-mode-only case shouldn't be much code
<sima>
and if do add drm support for picking actual physical modes then we could add fbops->fb_match_mode and ->fb_list_modes or something like that
<sima>
that would be a bit more work, but the #ifdef will at least find everything that needs to be touched
<jfalempe>
tzimmermann, I'm looking into reusing some fbdev drawing functions for drm_panic.
<jfalempe>
but that's really hard to make it independent from fbdev structs and api.
<tzimmermann>
i'd start by trying to get rid of the fb_info. that's an fbdev framebuffer
<javierm>
jfalempe: I wonder though if wouldn't be better to merge a minimal drm panic handler, even if only supports XRGB8888 and then as follow-up try to do that?
<javierm>
otherwise I fear that it will take much more time to land something if untagling that is a requirement
<javierm>
tzimmermann: ^
<jfalempe>
Yes, that's also another approach, I think fbdev code is not ready to be used by others.
<tzimmermann>
javierm, it would be nice to have at least an idea where to go with drm_panic before merging it
<tzimmermann>
maybe have a todo item with some sort of roadmap
<jfalempe>
one other thing would be to merge the cfb_xxx.c with sys_xxx.c using the iosysmap api.
sgruszka has joined #dri-devel
<tzimmermann>
jafalempe, i'd not want to do that
<tzimmermann>
jfalempe ^
loki_val has quit []
<jfalempe>
drm_panic uses iosysmap, so it would be better to have the lower level handle that too.
<tzimmermann>
jfalempe, the inner loops would have plenty 'if (is_iomem) else'.
<tzimmermann>
not nice
<tzimmermann>
and it requires a large refactoring of these fbdev routines
<javierm>
tzimmermann: fair. A TODO makes sense, even mentioning that is experimental and depends on EXPERT
<javierm>
I just think that is easier if is in the tree instead of having a patch-set inflight that takes a lot of time to land and needs constant rebasing
<jfalempe>
Yes, that would also be easier for early adopter of drm_panic, to showcase the feature.
<javierm>
or even depends on !VT
crabbedhaloablut has joined #dri-devel
<jfalempe>
drm_panic currently depends on !FRAMEBUFFER_CONSOLE, because they kind of conflicts. not sure about !VT.
<tzimmermann>
jfalempe, javierm, give me a bit to look through the cfb_ and sys_ functions. i would assume that fucntions like fast_imageblit and slow_imageblit could be stripped from their fb_info dependencies
<jfalempe>
tzimmermann, one other issue, is they don't handle drm format, they only use bit per pixels, so they can't handle XRGB8888 and XBGR8888
qyliss has quit [Quit: bye]
<sima>
jfalempe, imo copypasting drawing code is entirely fine ...
<sima>
also if you want to share code to make things work beyond xrgb8888 maybe the drm format conversion stuff might be useable?
<sima>
my experience with fbdev code is that if you touch it, it tends to go boom in really entertaining ways
<jfalempe>
Yes, I can probably reuse some of that too.
<sima>
so unless we have a really solid reason to refactor it big time, just leave it as-is
qyliss has joined #dri-devel
<jfalempe>
sima, I'm not really eager to touch fbdev code ;), but still wanted to take a look, as it was suggested in reviews.
<sima>
jfalempe, I think if you do want common code, then blt functions on top of iosys_map probably makes the most sense
<sima>
but that's not how fbdev code works at all
<sima>
so personally I wouldn't bother
pekkari has quit [Quit: Konversation terminated!]
<jfalempe>
sima, ok, I think I will just move that code to its own file (ie drm_panic.c for the panic handler and something like drm_draw.c for the drawing part).
Danct12 has quit [Quit: WeeChat 4.0.4]
Danct12 has joined #dri-devel
consolers has joined #dri-devel
<consolers>
how to fix compilation of freeglut with demos=on and egl=on ?
<consolers>
make the demos depend on epoxy?
itoral_ has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, jfalempe, on the format issues: we could draw in XRGB8888 unconditionally and convert via DRM's format helpers to the surface's output format
<tzimmermann>
it's probably the easiest way forward
<tzimmermann>
we'd need to preallocate (mode width × 4 × font height) bytes to draw glyphs in a line. then convert into the surface region
<tzimmermann>
then do the next line of output
<jfalempe>
tzimmermann, ok thanks, yes that's also a possibility. I'm also thinking on how to avoid having to allocate a whole framebuffer.
<tzimmermann>
you only need a line line of text. fullhd with fontheight of 16 is (mode width × 4 × font height) = 1920×4×16 = 122880
<tzimmermann>
30 pages
<tzimmermann>
and we already have a good number of conversion helpers available
<tzimmermann>
to preallocate memory, there's drm_mode_config.max_width as a limit
<jfalempe>
tzimmermann, thanks I'm now looking into this, it sounds much easier and feasible than fbdev.
<jfalempe>
maybe a special case for monochrome, as the fonts are already in monochrome, no need to convert it twice.
yyds has quit [Remote host closed the connection]
<javierm>
tzimmermann, jfalempe: that's a simpler approach indeed
<tzimmermann>
there's one thing: these helpers use kmalloc. is that still available in the case of a kernel panic?
vliaskov has joined #dri-devel
<pq>
You might not even need a full mode width for a tmp buffer, it could be some number of glyphs and do a screen line in a few pieces. Might fit better in CPU caches too?
<pq>
if you use the conversion helpers made for VKMS, you might want to render glyphs into the internal format directly
<pq>
IIRC that's 16 bpc
<jfalempe>
tzimmermann, you can still use kmalloc, but it's risky.
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
gcarlos has joined #dri-devel
Danct12 has quit [Quit: WeeChat 4.0.4]
fab has quit [Quit: fab]
fab has joined #dri-devel
pekkari has joined #dri-devel
azerov has quit [Quit: Gateway shutdown]
hansg has joined #dri-devel
consolers has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
itoral_ has quit [Remote host closed the connection]
sgruszka has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
<llyyr>
!24677 "radeonsi/vcn: Fix leaking fences in decode" causes issues when seeking in mpv with "--vo=gpu-next --hwdec=vaapi --video-sync=display-resample --gpu-api=vulkan". For h264 videos, incorrect frames are displayed and for h265 videos multiple frames are blended together
<llyyr>
is this likely to be an issue with that specific mesa commit or mpv?
<llyyr>
In particular, removing "if (fence != dec->prev_fence) return true;" from the commit fixes the issue
<gpiccoli>
that's great to hear! and this seems to be a panic handler, but nothing related with the FB saving data right?
<gpiccoli>
I can read the logs here as well, I'm using a bouncer and can check the logs - thanks for the link!
<jfalempe>
gpiccoli, yes this is only to display something useful for end user when a panic occurs.
<tzimmermann>
gpiccoli, yes. the idea is that DRM install a panic handler. the handler fill ask the DRM driver to return whatever the hardware's latest scanout buffer is.
<gpiccoli>
jfalempe, tnx a bunch for the effort! This is quite a welcome change IMO
<tzimmermann>
s/fill/will
<gpiccoli>
dpanic_line logo[] <- awesome!
<jfalempe>
gpiccoli, it works only with simpledrm, but I hope to have other drivers working too.
<gpiccoli>
so, you're using panic notfiers uh? "struct notifier_block drm_panic_notifier"
<gpiccoli>
nice use, and I guess I'll mention that next week in my presentation if you're OK with that
pekkari has quit [Quit: Konversation terminated!]
<gpiccoli>
I'll be talking exactly about these notifiers in Recipes, and the refactor we're trying to propose (and some other complexities on panic, like .. graphics!)
rgallaispou has left #dri-devel [#dri-devel]
<jfalempe>
yes, that's a really easy interface, you register a callback, and it's called when a panic occurs.
<gpiccoli>
This last past ofc I don't understand much, that's the reason I asked here to see if there was some change since I (unfortunately) don't follow much the gfx lists...
<gpiccoli>
exactly jfalempe , super easy...but I'd say... way too easy haha
<gpiccoli>
there is no track of who registers what, the risks of the callbacks, etc. Also, there's a inherent problem in ordering the callbacks and their order vs kdump
<jfalempe>
gpiccoli, feel free to mention it in your presentation, it's all public anyway.
<gpiccoli>
"it works only with simpledrm" <- so if I'm using amdgpu, for example, even with oyour patches I'll see nothing in a panic?
<gpiccoli>
simpledrm is a big step already, and tnx for that. Just curious to understand the current impl heh
Company has joined #dri-devel
<jfalempe>
gpiccoli, yes, you should blacklist amdgpu, so it will use simpledrm instead.
<jfalempe>
also during early boot, the kernel uses simpledrm before loading amdgpu, so if your kernel panic at this moment, you will see it.
<gpiccoli>
ok, cool - will read the patches more carefully, but thanks a bunch for this work, panic graphics seems an area that deserves more love
<gpiccoli>
oh yeah, or efifb right? Or not anymore?
<jfalempe>
it depends on distribution, but the future is simpledrm.
<javierm>
gpiccoli: for efifb you will need to make fbdev drivers to implement a .get_scanout_buffer callback
<javierm>
but those are just platform drivers... so adding that to dev->driver would be more tricky
<zmike>
MrCooper: feels like this might be a question for you: is there a way to block scanning a certain pci device in xorg init? or do I have to explicitly select the devices to use
<gpiccoli>
oh sure! but I said is like..during early boot, some cases I saw efifb handling the display
yuq825 has left #dri-devel [#dri-devel]
<zmike>
I have some garbage onboard vga that gets detected and disables modifier support in my xserver
<gpiccoli>
but it's nice to see that simpledrm is the future
<javierm>
gpiccoli: yeah, as jfalempe said depends on the distribution. OpenSUSE and Fedora moved to simpledrm already, others distros are still using {efi,vesa,simple}fb
<gpiccoli>
interesting! tnx for the clarification folks, very useful for me!
<javierm>
gpiccoli: for context, simpledrm just reuses whatever framebuffer is passed by the firmware/bootloader to the kernel
<javierm>
gpiccoli: which means that supports the same than efifb, vesafb, simplefb, etc
<javierm>
one generic system framebuffer driver to rule them all :)
<gpiccoli>
that's really great! Lemme take the opportunity to pick y'all brain since we're talking a about that. How difficult seems to be to..kinda of having simpledrm "hijack" the display back in panic, even if the drm driver in-use was like amdgpu or i915?
<MrCooper>
zmike: good luck, I stopped caring about Xorg a while ago
<zmike>
😬
<jfalempe>
gpiccoli, I think it would be easier for i915 or amdgpu to implement the get_scanout_buffer() function.
<gpiccoli>
so, imagine all distros move to simpledrm , so early boot is always handled by it. Then amdgpu takes over...but in panic time, having amdgou working is a pain, really a pain! So, getting back to simpledrm "saved state" would be a perfect solution
<gpiccoli>
jfalempe, the thing is: these devices require really a lot to work, lots of interrupts handling, and panic..disables CPUs, preempt, interrupt
<javierm>
gpiccoli: simpledrm taking back could be tricky, what I wonder though is if you can add that support to kdump
<gpiccoli>
we'd need something really simple to avoid creating a big risk in this already delicate moment that panic is
<javierm>
that is, kexec a new kernel and pass the existing framebuffer to the new kernel
<gpiccoli>
javierm, I agree, exactly!
<javierm>
then from the new kernel simpledrm, there's a system framebuffer that's provided by the "firmware" but that's the previous kernel that panics
<gpiccoli>
than, on kdump, simpledrm is there up and running, light than any other big GPU driver as Intel's/AMD's
<jfalempe>
yes, but you need to access the hardware to setup the framebuffer mapping. so only the amdgpu driver can do that
<jfalempe>
on boot it's the uefi/bios firmware that prepare that.
<javierm>
jfalempe: yeah, agreed. The native driver would have to do that preparation
<gpiccoli>
yeah..seems tough
<jfalempe>
after you load amdgpu. simpledrm cannot work anymore.
<gpiccoli>
in that same thread I mentioned, it was discussed with AlexD about that, for amdgpu seems complicated to reprogram the device...
<jfalempe>
I'm curious to see how they do that on other OS, so there is probably a way.
<javierm>
gpiccoli: as a first test what you could do is to boot using simpledrm but no native driver (e.g: nomodeset in the cmdline), set kdump and panic
<javierm>
gpiccoli: if you make struct screen_info to survice the kexec or the old kernel to pass that info to the new kernel somehow, then it may work with only simpledrm in 1st kernel and simple in 2nd
<gpiccoli>
yeah, this work! I already done some tests like this
<gpiccoli>
but IIRC, with efifb..I can have graphics in kdump
<gpiccoli>
the thing is: I don't feel real-world users (desktop / gamers) would use simpledrm in the first kernel...maybe servers (which is already something quite nice). Hence my question..
<gpiccoli>
if we could have a way to "forget" that users were running complex drivers and restore everything simply (using simpledrm!) in kdump, that would be wonderful
<javierm>
gpiccoli: right, EFI would work because the EFI-GOP information is maintained in an EFI table during kexec
<gpiccoli>
but as I say that, I can even realize how wishful thinking this seems to be heheh
<tzimmermann>
gpiccoli, for simpledrm to work, you need hardware with a programmed display mode
<tzimmermann>
amdgpu would provide that
<gpiccoli>
oh javierm , good point! So simpledrm test worth a try
<javierm>
gpiccoli: yeah because in EFI is using the same info
<tzimmermann>
but simpledrm is a real driver. you'd have to go through the whole driver probing. that's not feasible during a panic, i guess
<javierm>
I guess that DT platforms would also work since I assume that kdump pass the existing DTB to the new kernel?
<javierm>
tzimmermann: yeah, I don't think is feasible to do it without kdump/kexec
<gpiccoli>
tzimmermann, amdgpu would provide means...already provides or would *need* to provide? hehe
<gpiccoli>
yeah javierm , agreed about DT - it makes sense
<tzimmermann>
amdgpu already programs the mode
<gpiccoli>
recently there's been lots of talks to preserve memory across kexec/kdump...
<javierm>
tzimmermann: it programs yeah, but it would need to re-program to the system provided framebuffer format in order to work, right ?
<tzimmermann>
gpicolli, with the get_scanout_buffer callback, you can get the current settings
<gpiccoli>
oh cool tzimmermann - I tought amdgpu leaves the device in a over-complex "state" for simple scanout to work
<tzimmermann>
and then operate on those
<tzimmermann>
gpiccoli, there's no guarentee tha tit always works
<tzimmermann>
but get_scanout_buffer will be implemented by amdgpu. so you could attempt to make it work in as many cases as possible
<gpiccoli>
yeah, I understand! and not to mention..amdgpu is responsible for handling huge amount of devices, so ...maybe work in APUs and not dGPUS or vice-versa
<gpiccoli>
great to know tzimmermann !
<tzimmermann>
for example, on panic, amdgpu could try to program something simple to the hardware
<gpiccoli>
this get_scanout_buffer is some new API or just regular/old one (and I'm not aware 'cause I'm far from gfx world?)
<tzimmermann>
it's easier said than done, but still...
<javierm>
gpiccoli: new API
<gpiccoli>
oh yeah, panic time I guess is a no-go
<gpiccoli>
cool! so is there a definitive patchset that I should read to understand that?
<javierm>
tzimmermann: I guess that there are two options 1) re-program the display using the same info that was provided by the firmware (so that re-using the EFI-GOP would just work)
<tzimmermann>
it's a single new callback that the DRM driver provides
<javierm>
2) Make kdump to query the info from get_scanout_buffer() and pass that to the new kernel for simpledrm to pick that up
<javierm>
it could even be a video= cmdline param like bootloaders pass to the x86 vesa arch code
<tzimmermann>
javierm, i'd try to return whatever is currently programmed. if that's not possible, i'd try to program something simple
<javierm>
tzimmermann: yeah, makes sense. The question is a) how to pass to the new kernel and b) how to tell the sysfb platform code that needs to query in a different place
<tzimmermann>
javier, gpicolli, i had some ideas specifically for kexec/kdump. get_scanout_buffer would return the current display config, which kexec would store away for the kexec kernel. the architecture's bootcode in the kexec kernel detects this and sets screen_info accordingly
<tzimmermann>
and within the kexec kernel, simpledrm would use whatever it find in screen_info
<tzimmermann>
my question has always been were to store the framebuffer config during for the kexec kernel
<javierm>
tzimmermann: yup, that's what I had in mind too. Hence my comment about struct screen_info surviving a kexec
<javierm>
but I'm not that familiar with kexec to know if that would be robust or fragile
<javierm>
it's more safe to attempt to re-program a HW during panic or to attempt to store something in memory for the new kernel to use? That's the question I guess
<tzimmermann>
i'm not familiar enough with kexec to answer that question (yet)
An0num0us has quit [Ping timeout: 480 seconds]
donaldrobson_ has joined #dri-devel
<javierm>
tzimmermann: hehe, loved the yet :D
<tzimmermann>
i'd say it's better to store whatever is already there
<tzimmermann>
reprograming during panic seems very fragile to me
donaldrobson has quit [Ping timeout: 480 seconds]
<tzimmermann>
within get_scanout_buffer, the DRM driver knows if the current display mode is legitimate. but if it isn't, get_scanout_buffer fails and the kexec display remains of
<tzimmermann>
'off'
<tzimmermann>
that's at least a save state
<tzimmermann>
later within the kexec kernel, the native DRM driver would re-inint the hardware and the display comes back
<javierm>
tzimmermann, gpiccoli: I think we need this regardless since I've seen in the past issues with kdump where display only worked when booting with nomodeset
<tzimmermann>
javierm, TBH, when I proposed get_scanout_buffer for drm_panic, i was already eyeing towards kexec/kdump usecases
<javierm>
tzimmermann: cool
frieder has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
frieder has joined #dri-devel
junaid has joined #dri-devel
<gpiccoli>
sorry, was out for some mins
<pq>
zmike, foremost I'd look in BIOS settings to disable that on-board VGA. Next I'd probably try to assign it to a non-default seat with udev rules.
<gpiccoli>
"it's more safe to attempt to re-program a HW during panic or to attempt to store something in memory for the new kernel to use?" <- javierm , I'd say easily the latter, way safer! Since you preload the crash kernel , it's not in a bad moment as panic
<gpiccoli>
"I think we need this regardless" <- also agree! That'd be awesome
<gpiccoli>
I'll study a bit the get_scanout stuff, all new to me
<gpiccoli>
Also, I'm always to discuss kdump/kexec/panic, though as I said, unfortunately I'm not gfx expert! I'll be watching this work and if you could CC me it's even better hehe
<gpiccoli>
Quite interested on that, I can test as well...I have amdgpu APU (Steam Deck) and a dGPU, and of course, qemu heh
<zmike>
pq: sadly the onboard can't be disabled in bios
<zmike>
udev rules could be interesting though, I'll see what that yields
<gpiccoli>
zmike, is it the same driver as the other gpu ?
<zmike>
no
<gpiccoli>
I mean, the onboard one?
<zmike>
all my other vga devices are amd and this is aspeed
<gpiccoli>
using this, you could "force" this device to bind to pci-stub
<gpiccoli>
which...does nothing and leaves the device there, not messing with the others hehe
<zmike>
hm
<gpiccoli>
I'd try the module_blacklist cmdline first as it seems cheaper/quick to test
<pq>
ID_SEAT=idontwanna with whatever the right syntax is in udev rules.conf.
<zmike>
gpiccoli: that worked
<zmike>
amazing
<gpiccoli>
great zmike ! You mean, the module_blist or driverctl ?
<zmike>
driverctl
<gpiccoli>
I found this tool fantastic when was working with VMs
<zmike>
it's very easy to use
<gpiccoli>
Because you can pre-bind all devices you want to PCI-PT to vfio/pci-stub, not risking a bind to the real driver, that might init the device to a state that is hard to "un-init" heh
<gpiccoli>
indeed! quite user friendly
hansg has quit [Remote host closed the connection]
fab has joined #dri-devel
heat_ has joined #dri-devel
Duke`` has joined #dri-devel
frieder has quit [Remote host closed the connection]
<soreau>
zmike: is it supposed to work or has it ever worked? this is the first I've tried zink with this app
tzimmermann has quit [Quit: Leaving]
<zmike>
it used to work
<zmike>
and there's open MRs that make it work again
pochu_ has joined #dri-devel
<soreau>
gitlab search doesn't seem to work very well
pochu has quit [Ping timeout: 480 seconds]
<soreau>
google is much better.. *tries MR 24700*
An0num0us has joined #dri-devel
pochu has joined #dri-devel
benjaminl has joined #dri-devel
pochu_ has quit [Ping timeout: 480 seconds]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
<soreau>
zmike: I rebaed your egl branch on main, built it and weston-simple-egl runs but if you try to resize it, segfaults with this trace: http://pastie.org/p/6JbddPJMNtDvJWssjJfBmF/raw (same on the egl branch without rebasing)
<soreau>
oh hm
<zmike>
works fine here
<soreau>
it's picking the wrong libvulkan_radeon.so
<sima>
jfalempe, preallocating a line and then using format helpers also has my vote as probably the most reasonable approach
<sima>
jfalempe, you would need to make sure the line buffer is allocated at driver register time thought and probably quite a bit more than just for full hd
<sima>
since you cannot allocate anything in panic context
<sima>
jfalempe, since fbcon must pin an entire framebuffer just in case it should still be a win in memory consumption if you disable fbdev entirely
<sima>
so I wouldn't worry about allocating a pretty wide line buffer
junaid has quit [Remote host closed the connection]
sauce has quit [Ping timeout: 480 seconds]
<jfalempe>
sima, ok, I'm already rewriting the draw primitive to draw line by line.
donaldrobson_ has quit [Ping timeout: 480 seconds]
sauce has joined #dri-devel
apinheiro has quit [Quit: Leaving]
Ahuj has quit [Read error: Connection reset by peer]
junaid has joined #dri-devel
ngcortes has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<dcbaker>
karolherbst: I reviewed your rust-meson patch.
<karolherbst>
cool, thanks
pochu has quit [Quit: leaving]
<Lynne>
apparently nvidia no longer ship an ada-only gsp firmware
<Lynne>
they seem to be loading in the ampere firmware instead (which did work before, with some complaints)
<karolherbst>
it should still work
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
mairacanal has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
heat_ has quit [Remote host closed the connection]
<soreau>
when I run e.g. weston-simple-egl with zink, it's like vblank_mode=0 at ~3500fps, while radeonsi runs it at the screen refresh rate
An0num0us has quit [Ping timeout: 480 seconds]
<soreau>
with glxgears on zink, it's also the same as screen refresh
<soreau>
I guess it's time for a 'zink is too fast' issue report
kzd has joined #dri-devel
Kayden has quit [Quit: -> JF]
<soreau>
zmike: FWIW, this fixes the resize crash with weston-simple-egl for me http://ix.io/4GKs
<soreau>
I noticed that when it crashed, wsi_wl_surface_create_swapchain() was being called before wsi_wl_swapchain_queue_present() around the time is created a new swapchain, and it was using the old swapchain somehow
<soreau>
after setting old_chain->wsi_wl_surface = NULL
crabbedhaloablut has quit []
An0num0us has joined #dri-devel
RPAnimation has joined #dri-devel
kts has quit [Quit: Leaving]
sima has quit [Ping timeout: 480 seconds]
RPAnimation has quit [Remote host closed the connection]
Kayden has joined #dri-devel
RPAnimation has joined #dri-devel
RPAnimation has quit [Remote host closed the connection]
<karolherbst>
dcbaker: how can I run a single test?
<dcbaker>
in meosn? ./run_single_test --use-tmpdir --quick test\ cases/rust/1\ basic
RPAnimation has joined #dri-devel
<dcbaker>
(or whatever the path to your test is)
<dcbaker>
karolherbst: ^
<karolherbst>
thanks
RPAnimation has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
RPAnimation has joined #dri-devel
RPAnimation has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
grillo_0 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
<koike>
sima robclark daniels airlied o/ I wanted to check with you about drm ci workflow, iiuc patches should land on drm-misc/drm-misc-next and maintainers of trees like msm should cherry-pick them? Or merge drm-misc-next into their tree?
<robclark>
koike: I think it would be ok for you to ack-by drm/ci patches to land thru driver tree in cases where they are only about one driver and not going to conflict with other drm/ci patches that are in flight. For changes that impact multiple drivers, like uprev'ing igt, that should probably go via some more central tree
<robclark>
patches landing via driver tree should have a-b from you and if you are watching other drm/ci patches you should have an idea if there is potential for merge conflicts, etc
<robclark>
that's my $0.02 anyways ;-)
shashanks_ has quit [Remote host closed the connection]
shashanks_ has joined #dri-devel
<koike>
robclark: if the patch enables a new device I wonder if it wouldn't be nice to get it in a central place, so other patches doing core changes could validate on that device too
<robclark>
hmm, I guess that depends on how often you expect drivers to break themselves vs core change to break them.. IME it is more often the former..
<robclark>
but in this case, the new job is manual for now
<robclark>
until we get some confidence in the stability of the new board farm
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
<koike>
robclark: right, so I guess we can try this way
<airlied>
koike: yeah I think new ci files and core stuff via the misc tree, and backmerge to driver tree if necessary
<airlied>
and updates for fixes on single family should be in the driver tree
benjamin1 has quit []
<koike>
ok, thanks for clarifying :)
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
dcbaker: I just ran into a bug writing a test: apparently you can't use the same header file for multiple rust.bindgen targets
<dcbaker>
uhhhh, yeah. You say that and I immediately see why that would be
<karolherbst>
anyway. pushed some changes + the test
<karolherbst>
yeah.. you probably want to use the output file(s) as source for that target name or something
ngcortes has quit [Ping timeout: 480 seconds]
<dcbaker>
karolherbst: ugggh, that mypy thing is real... I swear I've fixed that before