ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
KarenTheDorf is now known as karenthedorf
bolson has joined #dri-devel
Vanfanel has quit []
AndreyKonovalov[m] has quit []
devarsht[m] has quit []
KunalAgarwal[m][m] has quit []
Andy[m] has quit []
doras has quit []
doraskayo has quit []
gnustomp[m] has quit []
K0bin[m] has quit []
Guest9951 has quit []
xerpi[m] has quit []
yyds has joined #dri-devel
krushia has joined #dri-devel
Kayden has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
sergi has quit [Quit: Client limit exceeded: 20000]
heat has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
sukuna has joined #dri-devel
alane has quit []
alane has joined #dri-devel
Quinten[m] has quit []
samueldr has quit []
Company has quit [Quit: Leaving]
vdavid003[m] has quit []
fililip[m] has quit []
masush5[m] has quit []
Vin[m] has quit []
meltq has joined #dri-devel
meltq has quit [Ping timeout: 480 seconds]
rossy has quit [Remote host closed the connection]
rossy has joined #dri-devel
bmodem has joined #dri-devel
colemickens has quit [Quit: Connection closed for inactivity]
epoch101 has quit []
sukuna has quit [Remote host closed the connection]
sukuna has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
flynnjiang1 has joined #dri-devel
flynnjiang has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
glennk has joined #dri-devel
sima has joined #dri-devel
tak2hu[m] has quit []
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
fab has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
fab has joined #dri-devel
Haaninjo has joined #dri-devel
tzimmermann has joined #dri-devel
sukuna has quit [Remote host closed the connection]
kts has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
cheako has joined #dri-devel
kts has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
frankbinns has joined #dri-devel
Coelacanthus[m]1 has quit []
QiuWenbo[m] has quit []
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
<MrCooper>
DemiMarie: AFAIK pinning VRAM for P2PDMA should work
<DemiMarie>
MrCooper: even though it is a FOLL_LONGTERM pin?
azerov has quit []
<MrCooper>
don't know anything about that, just from a dma-buf & DRM PoV it should work, AMD have P2PDMA working (between GPUs)
frankbinns1 has joined #dri-devel
frankbinns has quit [Read error: Connection reset by peer]
azerov has joined #dri-devel
frankbinns2 has joined #dri-devel
<DemiMarie>
with upstream drivers?
<MrCooper>
yep
<DemiMarie>
nice
<DemiMarie>
The reason I am so surprised is that if it worked with RDMA, I would expect that it would be much easier to support Xen than it actually has been.
frankbinns1 has quit [Ping timeout: 480 seconds]
<MrCooper>
I don't know if it works with RDMA specifically
bmodem has quit [Ping timeout: 480 seconds]
samuelig has quit [Quit: Bye!]
samuelig has joined #dri-devel
lynxeye has joined #dri-devel
ids1024[m] has quit []
<DemiMarie>
Ack
<DemiMarie>
Xen has the annoying problem that it currently has no MMU notifier integration
apinheiro has joined #dri-devel
enunes[m] has quit []
gegoxaren[m] has quit []
bmodem has joined #dri-devel
<pepp>
DemiMarie: Xen's main problem is the lack of MMU notifier indeed
rasterman has joined #dri-devel
<DemiMarie>
pepp: at Xen Project Summit 2024, one of the Xen maintainers gave an ACK to implementing that, so patches that add MMU notifier support should be upstreamable
<DemiMarie>
Hypervisor changes are required but should also be upstreamable.
<pepp>
DemiMarie: yep
<DemiMarie>
pepp: anywhere I can follow work being done?
<MrCooper>
pepp: out of curiosity, do you have P2PDMA working with RDMA?
<pepp>
DemiMarie: for Xen? I don't think patches were sent upstream yet, but I'm not working on this
<DemiMarie>
pepp: I'll take WIP patches right now. Turns out that Wayland passthrough needs this, even with software rendering.
<pepp>
MrCooper: sorry, I'm not familiar with RDMA
davispuh has joined #dri-devel
<pepp>
DemiMarie: as I said, I'm not working on Xen patches... plus I'm not sure what you mean by "Wayland passthrough needs this"?
<DemiMarie>
pepp: crosvm supports guests connecting to a Wayland compositor on the host. This requires blob resources to be able to render anything.
<DemiMarie>
pepp: I see. I was not sure what you meant by “this”.
<pepp>
unrelated topic: would non-amdgpu drivers be interested in adding a new drm_ioctl_flags indicating "this ioctl doesn't use the GPU"?
<pepp>
the purpose is: if the GPU is not used, then no need to resume it if it's suspended.
<tzimmermann>
unfortunately, i took the code at face value and didn't add proper ref counting either
<javierm>
tzimmermann: oh, I see
<tzimmermann>
should we add this?
<javierm>
tzimmermann: and when the put_device() would happen?
<tzimmermann>
the screen_info code tracks the device. the sysfb code later calls screen_info_apply_fixups() to update the global screen_info from the tracked data. thats where the put_device() would happen
<javierm>
tzimmermann: right. Yes, that makes sense to me
<tzimmermann>
and the whole tracking code is only required by sysfb.c. so the tracking code would be moved to sysfb. so when there's a get_device() there's also a put_device()
<tzimmermann>
and if sysfb has been disabled, no tracking is required anyway (hence no get/put pair)
<sima>
I think the brain is back to at least semi-working :-P
<javierm>
:)
<javierm>
sima: am I correct on what I said there ?
<javierm>
mixing regmap, DRM and panic handling locking made my head explode but I know that you will have the correct answer
<jhugo>
sima: Thanks. I think that will help focus the current thread to an immediate resolution
<javierm>
sima: hmm, although I'm probably missing drm_dev_{enter,exit}() in the flush panic handlers
<sima>
javierm, raw spinlock isn't good enough for panic
<sima>
unless you trylock
<sima>
hm
<sima>
yeah, only trylock of raw spinlock, everything else is not allowed
<javierm>
sima: Ok. And for normal operation, do I need to keep the regmap lock?
<javierm>
I don't think so since the DRM core will already handle the sync for the KMS objects right ?
<javierm>
sima: because if that's the case, then I could just disable it and on DRM panic there won't be any lock tried to be held
shalem has joined #dri-devel
<sima>
javierm, maybe
<sima>
like I don't know what you're all protecting with that regmap lock
<baltmansuite>
in reality only mutual exclusion or mutual inclusion ways are done with the access indirection, that requires the least of states, so addition becomes every power where the bits are both in is squared, so 73 in on both addition operands means it's answer is 74, and the non common value gets just added to it, but with subtract common part is zero and non-common parts smaller value gets.
<baltmansuite>
subtracted from bigger, i remember it was taught in secondary school logics subjects. Hence there is different polderan access indirection table for subtract, 128-129=-1 128-64=64 129-129=0 and 129-64=65, only 64's need to get eliminated. That works easy. Now there is 65 accesses done instead of 64. so there is 64 128 192...64*64 in first bank all of those values yielding zero, and 65 66
<baltmansuite>
67 68...., so access is asymmetric we recap how polderan worked now, it puts index+value+2*distancefrom_const to subtrahand and , the access number times constant to the minuend, ah fuckers would not understand anyhow i code it myself, you are just trashcoders, it's immense trash what you do, such pigs should be cooked into meat and fed to dogs for example DemiMarie's pork has excess
<baltmansuite>
fat and poison in it. It munches big Macs behind qubeos computer, and releases excrements to the channel, absolute cryptic nonsense.
<javierm>
sima: the regmap core protects the register map basically, but I believe that is mostly useful if the regmap is shared across drivers
<javierm>
sima: let's say a MFD driver (for a PMIC or whatever) that defines the regmap and passes it to both a regulator and RTC drivers
<javierm>
this is pretty common when one have a multi-function IP block where the same register map needs to be shared by different drivers
<javierm>
sima: thanks, I'll ask broonie. Too many subsystems and locks involved for my Friday evening :)
shalem has quit []
shalem has joined #dri-devel
hansg has quit [Ping timeout: 480 seconds]
bolson_ has quit [Ping timeout: 480 seconds]
hansg_ has joined #dri-devel
shalem has quit [Read error: Connection reset by peer]
<sima>
javierm, I guess it also depends upon how you get at your registers
<sima>
like mmio really shouldn't need any locking
<sima>
but if you have anything where you need more, it gets funny
<sima>
like if your regmap is behind an i2c, you pretty much can't do panic handling
<sima>
at least until i2c has learned about panic locking with a raw spinlock
<sima>
javierm, some git grep says these are either behind i2c or spi
<sima>
so ... not yet ready for panic at a rather fundamental level I think
shalem has joined #dri-devel
<sima>
iirc those buses also have uapi interfaces, so really can't just chug the locking and yolo
baltmansuite was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<javierm>
sima: but even the regmap lock won't protect the device register from concurrent accesses if someone has both a kernel and user-space driver for the same I2C device
hansg_ has quit [Ping timeout: 480 seconds]
<sima>
javierm, yeah but there's also i2c locking
<javierm>
sima: that serialization should be handled by the I2C core
<sima>
so if you nuke the regmap one, you'll still splat :-)
<javierm>
sima: oh, yes. I was just talking about the regmap lock
<sima>
because i2c has that locking
<javierm>
sima: need to then look at the other layers of the onion :)
<sima>
what you need is a raw spinlock in the lowest i2c level to protect against the panic case
<sima>
which is uber fun if you're i2c buses are nesting
<sima>
also, you can only have 1 raw spinlocks in our entire regmap chain
<sima>
and then you need special panic code which a) takes that raw spinlock b) does no other locking at all
<sima>
your looking at a cross-subsystem deep locking drilling exercise here, I'm afraid
<sima>
panic handling is really, really hard
<javierm>
sima: leaving the DRM panic patch/discussion aside, I believe that I could just disable the regmap locking safely since is not really needed
<sima>
yeah that might be
<javierm>
sima: in other words, there can't be concurrect calls to the struct drm_plane_funcs .update_plane handlers for the same plane right ?
<sima>
nope
<javierm>
sima: awesome. I'll disable that then
<javierm>
sima: but I'll just park the DRM panic patch then, until I understand how the locking for I2C and SPI core works for the IRQ context case (and if is even possible)
<sima>
javierm, you need nmi context for panic
<sima>
irq isn't enough
<javierm>
sima: right
<javierm>
now I'm surprised that the DRM panic patch even works on this driver :)
<sima>
lumag, sorry for the late replies on the panel shutdown discussion, maybe we should have the next round here on irc since I'm not sure where communication (or my understanding) fails ...
<lumag>
sima, I think it was mostly dianders .
<lumag>
sima, When you pointed out to the devlinks, I thought that we might be able to use the same approach to solve our bridge runtime stuff, but it seems we can not.
<sima>
lumag, should be the same issue, but bridges are a lot more messy since a bunch of drivers still use component.c for bridges
<sima>
and some drivers use device links already (just in their driver code, manually) for bridges iirc
<lumag>
sima, msm uses components for "root" bridges.
<lumag>
maybe we should stop doing that.
<sima>
uh yeah iirc those cases are the reason why adding device links to bridges has become really messy
<sima>
and people gave up on all the past attempts :-/
<sima>
forgot what the issue was
kts has quit [Quit: Konversation terminated!]
<sima>
lumag, also I more meant the discussion around how to fix the bogus panel shutdown warnings
frankbinns has joined #dri-devel
<lumag>
sima, yes, I think that was also dianders's topic
<sima>
lumag, oh right I mixed up the names with the writeback discussion
<lumag>
sima, n/p
<sima>
dianders, ping me here so we stop confusing us :-)
* sima
bad at this sometimes ...
<lumag>
sima, for writeback, as you have mentioned it, do you have any comments / suggestions / ideas on the 'queue +1 job' uAPI?
<lumag>
sima, using a single CRTC to drive both screen output and a writeback is a saviour, especially on resource-constrained devices.
<sima>
oops wanted to, but forgot
<sima>
typing now
<lumag>
thanks!
lynxeye has quit [Quit: Leaving.]
<sima>
lumag, sent
<lumag>
sima, thanks!
<lumag>
That's really an interesting approach
<sima>
well it's how this entire thing was designed almost a decade ago, just like ... didn't yet get there
<lumag>
:-D
<sima>
but I think if we limit to a) only commits where needs_modeset(crtc) == false and where that also holds for the previous commit
bolson has joined #dri-devel
<sima>
and we audit drivers to not look at obj->state pointer for those paths, we should be fairly close now
<sima>
maybe an explicit opt-int flag on the atomic ioctl, so that we can keep the EBUSY checking as-is
<sima>
and then maybe a max queue parameter, since some hw can in some cases enqueue into hw directly
<sima>
but maybe in practice we don't want more than 2, because with more you get into the headache of having to cancel them if something has changed
<sima>
and my gut feeling says it's not really more work, because it's fundamentally all the same races you need to fix
<sima>
difference just whether you fix them fundamentally at the state struct level, or add-hoc just for the writeback commit
<lumag>
two should be more than enough, as a starter point.
<lumag>
and definitely an opt-in IMHO
<sima>
oh yeah, we can't fix all drivers
<sima>
it's more how much of an opt-in it should be
<sima>
oh atomic's 10th birthday (per upstream merge date) is next month already
<sima>
ah now, that was a random patch date, it's in November this year
<dianders>
sima / lumag: Sorry, I was AFK for a bit but I'm here now. There's honestly nothing really urgent about the drm shutdown stuff and I almost feel like in-person would be better. Any chance you guys will be in Vienna in Sept? I plan to be at ELC and LPC.
<lumag>
dianders, I have a talk at OSS/EU and even if my proposal for LPC isn't accepted I plan to stay.
<sima>
dianders, I should submit my lpc talk this evening ...
<sima>
so kinda plan to, but not yet definite (don't have a ticket, so if the talk doesn't make it it's maybe a sponsor ticket or maybe I'll skip)
<sima>
hm no sponsor ticket, intel's not on the list
<dianders>
lumag / sima: Sounds good. I'm happy to table the discussion until then, or just drop it. Honestly the only reason I submitted the patch is that I got talked into playing janitor and trying to help clean up some of the mess around enable/prepare. I'm already many layers deep into yak shaving and I'm happy to leave the rest of the yaks alone...
<sima>
dianders, well I think fixing the bogus warning should be doable, but we seem to confuse each another a bit
Danct12 has joined #dri-devel
<sima>
doable without the explicit list I mean
asriel has joined #dri-devel
<dianders>
sima: hmmm, so you're saying that:
<dianders>
1. Say that DRM modeset drivers are responsible for adding a devicelink such that they get a shutdown() call before the panel's shutdown() call.
<dianders>
2. In the panel driver shutdown, add a warning if the panel hasn't already been turned off.
<dianders>
...but you still can't necessarily detect broken drm modeset drivers, right? If you have a DRM modeset driver that doesn't have the device links and _also_ doesn't call drm_atomic_helper_shutdown() then the panel warning won't fire at all, right?
<lumag>
dianders: check for the .shutdown callback just by reviewing existing drivers?
<lumag>
and documenting that it is mandatory
<sima>
no to 2, I think that's impossible to add unless we add the device link to the panel code and hence guarantee it's there for everyone
<sima>
let me type up the diff
<lumag>
dianders, also, there might be a lengthy bridge chain between the drm device / driver and the panel.
<lumag>
So all bridges should get devlinks
<lumag>
Maybe this can be handled in the automated way in drm_bridge_attach ?
<sima>
yeah we need devlinks all the way
<sima>
at which point you run into the complication of bridges that are handled with component
<sima>
and into all the various duct-tapes that drivers added meanwhile, like their own devlinks
<sima>
and much worse
<dianders>
Sure, if we can do it in drm_bridge_attach() that'd be nice. I'm still worried that it's going to cause consternation somewhere along the way due to someone thinking that the order is wrong, but I'd be more than happy if someone wanted to figure out how to get that working...
<dianders>
sima: LOL, sure. I guess then we'd just leave that code there basically "forever", or you have some way to know when we could finally delete it?
<sima>
dianders, whenever someone fixed up all the driver (hopefully with device_link)
<sima>
drm is full of this kind of "oops we made a mistake, but need to keep existing crap working" stuff
<dianders>
sima: sure, but if we knew people had fixed up all drivers (by calling drm_atomic_helper_shutdown() properly) we could also delete it.
<dianders>
Will it be easier to know that all drivers have device_link than that all drivers call drm_atomic_helper_shutdown() properly?
<sima>
dianders, yeah but reality in a subsystem with a 100+ drivers is sometimes just a bit disappointing
<sima>
dianders, if we add it to bridge/panel code, yes
<dianders>
sima: OK, fair enough.
<sima>
well probably more step 0: endless screaming to figure out all the trapdoors 1: merge device_link automagic code to bridge (maybe can rely on panel-bridge for panels?)
<dianders>
sima: I'd be OK with a patch like the one you propose and then when someone solves the device link problem then we can delete it...
<sima>
2: wait a few releases because inevitable we've missed a few corners and broke a few things
<sima>
3: delete crufty compat hacks
<sima>
we have cases in drm where this is taking longer than 10 years
<lumag>
sima: that sounds like a plan for DRM_BRIDGE_ATTACH_NO_CONNECTOR, but we are still not there
<sima>
dianders, yup, that's pretty much what I suggested we go for
<sima>
lumag, yeah
<dianders>
sima: sure. you want to post an official patch, or you want me to?
<sima>
dianders, maybe check that all the docs are updated and todo.rst has a good entry for this mess, as a bonus patch
<sima>
dianders, would be happy to ack yours, you put in plenty more time into this than me already
<sima>
plus this was just my "this should work" idea, I didn't think it through :-P
<sima>
nor test it
<dianders>
sima: I don't really care about my name on it, but sure. Let me try to write something up. I don't think it'll take too long for that. There's already a big TODO so it's mostly just updating it.
<sima>
aye thanks
<lumag>
sima, speaking about msm :-D What's the problem with components? I can probably look into dropping their usage for our on-chip bridges, but I'd like to understand the actual problem.
<sima>
lumag, iirc components.c only solves the load-order issue
<sima>
doesn't add any devlinks
<lumag>
it doesn't
<sima>
and iirc at least some versions of devlinks where then fighting with component.c over the load ordering fun
<lumag>
But the devlinks should be there already because of the graph links
<sima>
yeah, but for pm stuff you need to upgrade them
<lumag>
But they are circular devlinks, which are immediately broken
<lumag>
I see.
<sima>
plus way back when this happened I'm not sure the devlinks for load ordering from the dt links was merged into upstream already
<sima>
iirc that bikeshed finally got resolved later
<sima>
and yeah I think the fun was that we ended up with circular dependencies or something and the driver couldn't load anymore
<sima>
there was I think also issues about when to add the devlink and when to remove the pm part of it
<sima>
but all very vague
<lumag>
I see, thanks
<sima>
in a way you want the load order devlink when you first try to find the bridge/panel through of
<sima>
but the pm links should only exist between attach and detach of the bridge
<sima>
also I think the pm core code didn't have yet enough flags for the exact devlink we needed, and some gaps
<sima>
like maybe only used for rpm not for system pm actions like suspend/resume
<sima>
it was all a mess tbh, but I thought we've gotten like 90% and then everyone gave up and declared the problem Too Hard
<sima>
but was probably the usual "last 10% is 90% of the effort" case ...
<sima>
lumag, tldr; I guess if you can make automatic pm devlinks in drm_bridge work for msm somehow we should have a real chance to merge this
<sima>
since I think msm covers a lot of the pitfalls already
<sima>
worst case we need a DRM_BRIDGE_ATTACH_NO_DEVLINK flag I guess
<lumag>
rofl
<lumag>
At least it's better than NO_CONNECTOR flag.
<lumag>
NO_DEVLINK shows what needs to be fixed.
<sima>
yeah
<sima>
but we might be even worse of and need the explicit opt-in
<sima>
but if we can get away with the explicit opt-out for bridge pm devlinks then I think it's a roaring success and we should just party for a year or something
<lumag>
sima, I'd hate the opt-in here.
Haaninjo has joined #dri-devel
<lumag>
We have it with DRM_BRIDGE_ATTACH_NO_CONNECTOR and it's really not so easy to review all the leftovers
<sima>
lumag, yeah, but NO_CONNECTOR needs both updated consumers and bridge drivers, so it's nxm hard
<sima>
devlinks hopefully only need consumer-side audit
<sima>
unless stuff like the simple-panel shutdown hacks have spread to many places ...
<lumag>
sima, my point is that if we have a migration plan, it must be fairly easy to find all the outstanding drivers.
<sima>
lumag, yeah, ideally
<sima>
reality is sometimes disappointing non-ideal though
<lumag>
:D
<lumag>
sima, hopefully last question for today:
<lumag>
sima, jhugo regarding fastrpc. Does drivers/accel/ require drm_accel.h API?
<lumag>
(to end up the fastrpc story and let me forget about it for quite a while)
<sima>
imo yes
<sima>
like habanalabs is the exception that proves the rule, because that was all a very messy 3 years and a lot of looking away and compromising was needed to get somewhere less awkward
<jhugo>
For something new, yes. Habana did come over and convert. I'm not sure that is really a "model" for others to follow
<sima>
plus habanalabs then switched over anyway since they control the userspace of their customers enough
<sima>
yeah all very special exception case
<lumag>
sima, jhugo so it should be come-over-and-convert or stay-away-and-hide?
<jhugo>
I suspect "accel fastrpc" is going to be vastly different than the "misc fastrpc". Both will need to exist, sadly
<sima>
like if it's an entire driver rewrite in misc/fastrpc for new hw it should probably just be a new accel driver for that hw
<sima>
like we continue to have large amounts of overlap between fbdev and drm display drivers in terms of supported hw
<sima>
and distros just don't care, because they don't compile any of the old code
<lumag>
no, it's an evolution. The same driver works for all the hardware since 2016
<jhugo>
Yeah, Qcom could even pick a generation of hardware to break the interface. Its happened before (smd -> glink)
<sima>
yeah that too
<lumag>
jhugo, rofl.
<sima>
I meant more from an upstream pov, if the driver becomes unreconizeable it starts to smell a bit much like "we're just avoiding drivers/accel and its rules"
<sima>
and that point I guess I'll start asking the really annoying questions :-)
<lumag>
well, it already does a bit.
<sima>
lumag, yeah so if the rename is to prep the codebase for massive expansion, then ... maybe time for the annoying questions already?
<lumag>
That's why at some point calebccff pointed out strange patch series
<lumag>
I don't have resources for that :-(
hansg_ has joined #dri-devel
<lumag>
So far we started being annoying by doing reviews.
samuelig has quit []
<lumag>
But anyway, I think I got your idea.
<lumag>
or your point
samuelig has joined #dri-devel
<sima>
uh that other patch series is fun ...
<sima>
lumag, patches 2&3 sound a bit like the current driver is essentially dysfunctional
<sima>
so if current upstream was never useful, we can just git rm the entire pile and start fresh
<lumag>
sima, it is working
<sima>
yeah but that entire "get capabilities from dsp" seems to be extremely broken as-is
<sima>
read 4x too little from hw, then only copied tiny part to userspace
<sima>
doesn't sound like "it works" to me
shalem has quit [Ping timeout: 480 seconds]
<lumag>
sima, it was passing 4 extra bytes, not 4x
<lumag>
And it's might be that the call is not used in simple loads.
<lumag>
Because at least I've been building and testing the apps on several platforms.
<lumag>
But the real issue is not on the kernel side.
<sima>
yeah the userspace is probably blobby to no end :-)
Kayden has quit [Quit: -> hillsdale]
<lumag>
The whole story requires a daemon, toolchain and some libs / glue code and the shell binary blob to be executed on the DSP. The daemon has been ported from Android, you can guess about its style and simplicity to read it. The official toolchain isn't open-source, but there exists an open-source toolchain by Qualcomm. The rest is closed-source.
<lumag>
So it's not all-blobs
<sima>
yeah ...
<sima>
the other question is also how much you really run random workloads on that thing
<sima>
which is kinda the accel/drm use-case, and where the runtime+compiler requirement comes from
<sima>
if it's just an essentially fixed-function dsp, then the blobs are a lot more just like firmware
<lumag>
sima, fixed-function is a non-fastrpc case. fastrpc is used to offload user-written code
<lumag>
There are additional restrictions (some DSPs can accept only the 'signed' code, while other allow actually user-written code)
nerdopolis has quit [Ping timeout: 480 seconds]
<sima>
hm yeah that's a more clearly accel
<lumag>
Yep
<lumag>
The 'fixed-function' code lives in drivers/rpmsg, drivers/soc/qcom sound/soc/qcom/
<lumag>
That's why I proposed moving to drivers/accel/
hansg_ has quit [Remote host closed the connection]
<airlied>
sima: oh wow too use to ignoring them, the missing Sob should probably get elevated above the missing links
<airlied>
I might reset drm-next since it's the last pull
mattst88 has quit [Quit: Lost terminal]
<sima>
airlied, dim shouldn't complain about missing Link: tags for stuff in merges ...
<sima>
but maybe it broke somewhere
<sima>
airlied, the missing review it'll complain about, maybe that's the one you're seeing?
<sima>
we could filter that out too
<sima>
airlied, just did a test-run, it doesn't complain about missing Link: here, only about a pile of missing sob and one missing review
<sima>
airlied, https://paste.debian.net/hidden/38361c67/ this should shut up missing review on pulls, but not sure that's a good idea since for e.g. -misc topic branch prs we want that check
<sima>
airlied, anyway for this much missing sob I think a hard-reset is in order
coldfeet has quit [Remote host closed the connection]
<airlied>
sima: yes just hard reset it now
f_ is now known as F_
F_ is now known as f_
<airlied>
sima: ah maybe it's missing review on non-misc trees I see a lot off and my brain auto parses out
<DemiMarie>
Does userspace that doesn't use all of the hardware features meet the open userspace requirement?
<airlied>
probably need to make missing sob ultra fatal
<DemiMarie>
Fail the push?
<airlied>
if we could enforce everyone to use our tooling :-P
<DemiMarie>
Packaging it for all the distros would help
<DemiMarie>
I meant server-side, though.
sima has quit [Ping timeout: 480 seconds]
mvlad has quit [Quit: Leaving]
<airlied>
mlankhorst: were you meant to dequeue misc-fixes?
<airlied>
granted there's only one in there, but it's marked for stable etc
mattst88 has joined #dri-devel
hansg has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
hansg has quit [Quit: Leaving]
jfalempe has quit [Quit: jfalempe]
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
guludo has quit [Remote host closed the connection]
guludo has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Quit: Leaving.]
feaneron has quit [Quit: feaneron]
nerdopolis has joined #dri-devel
pcercuei has quit [Quit: dodo]
nerdopolis has quit [Ping timeout: 480 seconds]
jhli has quit [Remote host closed the connection]
<DavidHeidelberg>
I don't use zink, but getting: "MESA: error: ZINK: failed to load libvulkan.so.1" + "libEGL warning: egl: failed to create dri2 screen" :(