ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
dreda has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
linearcannon has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.3]
mattst88 has quit [Quit: leaving]
mattst88 has joined #dri-devel
<airlied> just fyi seeing ~25 minute download times on some CI joibs for the mesa.tar.gz
<airlied> anholt: ^?
<anholt> airlied: been going on with htz runners for a while, they've had no luck diagnosing
<anholt> I feel like we need to turn off htz for mesa at this point :/
<anholt> but I think sitewranglers were busy with bigger fail this week
<jekstrand> htz?
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<airlied> jekstrand: one of the runner locations I think
yoslin_ has joined #dri-devel
yoslin has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit []
camus has joined #dri-devel
<airlied> Lynne: branch is rebased now
nsneck has quit [Remote host closed the connection]
sdutt_ has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
hikiko_ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
boistordu_ex has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
<ishitatsuyuki> htz probably means hetzner if you are still wondering
<HdkR> Maybe someone here will knowledge about sharing FDs. I'm using sendmsg to send an ancillary buffer with SCM_RIGHTS. Randomly the ancillary buffer on the receiving end is nullptr, while the sending side successfully returns the number of bytes sent (only 1 byte in this case).
<HdkR> How the heck do you determine why spurious cmsg failure has occured? :|
<airlied> https://keithp.com/blogs/fd-passing/ maybe have some info that directio
<airlied> HdkR: aarch64 assembly relocations, something that would be down your alley?
dviola has quit [Quit: WeeChat 3.3]
lemonzest has joined #dri-devel
<HdkR> airlied: Probably. I don't usually mess with relocations directly though
<airlied> HdkR: nvidia recently added trampoline code to vulkan loader that creates a TEXTREL
<airlied> which our security people are very allgeric to
<airlied> https://github.com/KhronosGroup/Vulkan-Loader/issues/773 maybe you know, I'm trying to figure it out via stackoverflow :-P
<airlied> hmm the tests still pass with my attempt at fixing it, maybe it's even correct
<HdkR> Hm. I don't know exactly what things cause a TEXTREL to be emitted. Does ADR workaround it?
<airlied> is my attempt at a workaround
<airlied> which is adr so looks like it
<HdkR> `ldr x3, [x9, #:lo12:termin_error_string] ` I believe that is loading a 64-bit value at termin_error_string + #:lo12:termin_error_string
<HdkR> You'd probably want something like `add x3, x9, #:lo12:termin_error_string` ?
<airlied> but yeah you might be right there, since I think I do want the address
<HdkR> `And if you want the address of zbi_paddr in a register, you do`
<HdkR> If it is guaranteed to be within 1MB then you can use adr alone instead of adrp+add. I don't know if that is the case though.
<airlied> yeah I won't depend on that
dviola has joined #dri-devel
<HdkR> adrp+add can fail in the case that the distance is >4GB away. Which I guess no loader currently does?
* airlied crosses fingers on that one
<HdkR> I have no idea what asm gets emitted for `ldr x3, =termin_error_string`, since that's not a real instruction
<HdkR> I guess worst case would be movk*4 but I don't know where AArch64 relocation definitions officially live :D
<HdkR> Oh! MSG_CTRUNC is returned in the msg_flags if the data was dropped. I'll need to check on that
danvet has joined #dri-devel
Duke`` has joined #dri-devel
<airlied> ldr x3, 61a8 <vkdev_ext249+0x10>
<airlied> is what the =termin_error_string seems to generate
<HdkR> Ah. so the relocation just sets the address into a PC relative location so it can load in one instruction. Fair
<HdkR> Looks like I was leaking FDs and I was eventually bumping up to the FD limit of the process. It definitely set the MSG_CTRUNC flag and I didn't know that existed as a flag
itoral has joined #dri-devel
<pinchartl> robher: who would that overlay person be ? :-)
Duke`` has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
mszyprow has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mlankhorst has joined #dri-devel
hikiko has joined #dri-devel
jkrzyszt has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
kmn has joined #dri-devel
slattann has joined #dri-devel
tursulin has joined #dri-devel
<pq> HdkR, I think libwayland would be in big trouble if fd sending failed sporadically like that. Maybe you can compare what you do differently?
<pq> HdkR, some things coming to mind: You can't send ancillary data without real data. Be sure that your fds are not closed behind your back too early. (libwayland always dups)
<pq> HdkR, oh you found it already, nice.
<HdkR> Yea. unexpected problems :D
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<HdkR> I must have been sleepy when I made the assumption that one half a pipe closing wouldn't mean that the other half closed
<HdkR> would mean the other half was closed*
<HdkR> Easy enough fix, and then made it more robust so if my application gets close to the soft limit, it would use setrlimit to move it higher
<HdkR> Now if I manage to hit the 1048576 open fd hard limit...Then I have issues
JoseExposito has joined #dri-devel
<pq> HdkR, how will you know you get close to the soft limit?
<HdkR> query /self/proc/fd at the start to get the initial number of open fds. Then watch the number of socket connections and pipes that I have coming in to the application at that point. Once I get close to the threshold from getrlimit, bump it a bit early
rasterman has joined #dri-devel
<HdkR> Since this is a fairly self contained application, I only have a couple locations where FDs come in :)
<pq> how very optimistic of you to assume that libs don't open() or dup() behind your back :-)
<HdkR> Luckily this application doesn't open any libs :D
<pq> impressive
<HdkR> Fairly self contained. It's just doing some squashfs management
<HdkR> So execve and some PID watching :D
JoseExposito has quit [Quit: JoseExposito]
pcercuei has joined #dri-devel
elongbug has joined #dri-devel
pnowack has joined #dri-devel
slattann1 has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
dv_ has quit [Quit: WeeChat 2.8]
dv_ has joined #dri-devel
linearcannon has joined #dri-devel
FireBurnUK has quit [Quit: Konversation terminated!]
thellstrom has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
gpuman_ has quit []
<mlankhorst> airlied: ping?
Company has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
mlankhorst_ has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
lemonzest has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
mclasen has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
<Lynne> airlied: thanks!
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
arnd_ has quit []
arnd has joined #dri-devel
slattann1 has quit []
dreda has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
thellstrom has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
itoral has quit [Remote host closed the connection]
dreda has joined #dri-devel
vivijim has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
<jani> danvet: mlankhorst_: mripard: tzimmermann: ack for merging https://patchwork.freedesktop.org/patch/msgid/20211019161322.11037-1-jani.nikula@intel.com via drm-intel-next?
<danvet> jani, ack
<tzimmermann> jani, that would collider with my dp-module series
<danvet> hm mabye more kerneldoc for it?
<danvet> tzimmermann, like actual functional conflict?
<tzimmermann> the one you've been looking at
<danvet> or just addition in same place (which is generally nbd)?
<tzimmermann> no, just file naming i think
<danvet> tzimmermann, apply the rename patch to both trees and done or something?
<danvet> gets a bit messy maybe
<tzimmermann> danvet, maybe git even figures this out by itself
<danvet> not entirely sure, but since it's a very simple addition it really shouldn't be a big deal to resolve
<jani> tzimmermann: I was actually wondering what the rationale for the rename was to begin with
<danvet> plus since it trivially wont compile if airlied or me get it wrong I'm not worried about missing it
<danvet> so I think merge with ack probably still the simplest option
<tzimmermann> jani, drm_dp_helper.c generates drm_dp_helper.o, which conflicts with drm_dp_helper.ko
<tzimmermann> if i'm not mistaken
<jani> drm_kms_dp_helper?
<tzimmermann> jani, there's no 'kms' in 'dp' helpers any more
<jani> all of dp is kms? ;)
<tzimmermann> sort of, but kms helper contains all kinds of functions
<tzimmermann> all the other helper libraries are named drm_*_helper.ko . i didn't want to break that naming scheme
i-garrison has joined #dri-devel
<jani> all of this would be neater with subdirectories...
<tzimmermann> how does the naming work with subdirectories?
i-garrison has quit []
i-garrison has joined #dri-devel
mlankhorst_ is now known as mlankhorst
nabaiste^ has quit [Remote host closed the connection]
<jani> if it's one module per subdir, you just get a nicer "namespace"
<jani> otherwise I guess it's not all that much different
<jani> like, right now not all files that are part of drm_kms_helper.ko have "helper" in the name
<jani> the only way to know which files are part of which module is to look at the Makefile
<jani> oh, it really surprises me bridge/panel.o is also part of drm_kms_helper.ko
<tzimmermann> jani, the naming and the helper modules are fairly unorganized. i don't disagree with the subdirectory approach. i just think it should be a separate issue.
<tzimmermann> if dp helpers are in a subdirectory. drm_dp_helper.c can be split up further. the file has all kinds of functionality AFAICT
<tzimmermann> but befor ewe do that, we first have to get dp helpers out of the kms helper module
sdutt has joined #dri-devel
<alyssa> what's this blocked on?
<alyssa> ("intel: add an OpenCL C compiler")
<alyssa> ...and that looks like it messes up cross compiling? :|
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Ristovski> Is XA (X Acceleration) in mesa only used by EXA in Xorg and not the SNA accelmethod?
<MrCooper> it's only used by xf86-video-vmware
pendingchaos_ has joined #dri-devel
<Ristovski> MrCooper: And apparently freedreno and nouveau (at least according to the mesa ebuild on gentoo)
<Ristovski> but okay, that answers my question, thanks!
Haaninjo has joined #dri-devel
<MrCooper> that sounds like a mistake in that ebuild
<MrCooper> well, not sure about freedreno
<mlankhorst> danvet: reading your comment on atomic ops for patch 3, would this be allowed? https://paste.debian.net/1223243/
<mlankhorst> Noticed I left a small race when pages == vma->obj->mm.pages
pendingchaos has quit [Ping timeout: 480 seconds]
<mlankhorst> Or I could just kill the clearing of vma->pages entirely..
<mlankhorst> Perfection!
mattrope has joined #dri-devel
<Ristovski> mattst88: Btw, I guess libdrm gentoo package should now have video_cards_crocus? It currently uses video_cards_intel but that selects the "classic" driver in mesa unless you override it for that specific package only (while mesa package already has video_cards_crocus)
pendingchaos_ is now known as pendingchaos
<Ristovski> Especially since now building the classic drivers requires a separate branch of mesa
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
<pq> Oh, you can paste a commit sha into Gitlab search box and it finds the commit.
JohnnyonFlame has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
slattann has joined #dri-devel
slattann has quit []
<danvet> mlankhorst, uh this freaks me out
<danvet> mlankhorst, generally you need a barrier on both sides or nothing really happens at all
<danvet> hence the rule to have a comment in both places which a) explains what exactly you're trying to order and b) where the other side is
<danvet> now cmpxchg has a barrier on both sides, so maybe there's actually 3 things
<danvet> mlankhorst, ah just read on
<danvet> yeah if you can just ditch it all, much better
<danvet> the fewer atomics we have the less headaches
<danvet> and at least with the current state radically deleting them is defo the right direction
<danvet> there's still the pages_count atomic, but well can't fix it all
<danvet> one at a time
<Ristovski> Hmm, are there any docs on how to profile mesa stuff, or am I on my own using `perf` et al?
sneil has quit [Quit: Leaving]
<mlankhorst> danvet: correct, could probably be removed after conversion
<mlankhorst> But didn't test..
sneil has joined #dri-devel
jewins has joined #dri-devel
Duke`` has joined #dri-devel
mbrost has joined #dri-devel
milkylainen41 has joined #dri-devel
milkylainen41 has quit []
milkylainen6 has joined #dri-devel
milkylainen6 has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
jhli has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
optimumcond has joined #dri-devel
optimumcond has quit [Excess Flood]
optimumcond has joined #dri-devel
slattann has joined #dri-devel
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
OftenTimeConsuming has joined #dri-devel
<robclark> MrCooper, Ristovski: a long time ago, xf86-video-freedreno used XA.. but for a long time modesetting+glamor has been the recommendation.. I don't think xf86-video-freedreno even still builds (never updated it for ABI bumps)
optimumcond has quit [Killed (dwfreed (No reason))]
mszyprow_ has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
slattann has quit []
idr has joined #dri-devel
ybogdano has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
The_Company has joined #dri-devel
LexSfX has quit []
Company has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
rcf has quit [Quit: WeeChat 3.2.1]
rcf has joined #dri-devel
ybogdano has joined #dri-devel
rcf has quit [Quit: WeeChat 3.2.1]
sdutt_ has joined #dri-devel
dolphin has quit [Read error: Connection reset by peer]
dolphin has joined #dri-devel
rcf has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
<mattst88> Ristovski: no, for a couple of reasons: (1) crocus doesn't even need libdrm_intel, and (2) we're removing the individual VIDEO_CARDS options and condensing them into just VIDEO_CARDS=intel (see https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04c32f5c2e8ad380ee20055fb8cf5e31c94864c4)
<Ristovski> mattst88: oh, I see
lemonzest has quit [Quit: WeeChat 3.3]
ngcortes has joined #dri-devel
boistordu_ex has quit [Ping timeout: 480 seconds]
LexSfX has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
LexSfX has joined #dri-devel
LexSfX has quit []
rasterman has joined #dri-devel
boistordu has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: WeeChat 3.3]
Lyude has joined #dri-devel
Lyude has quit []
Lyude has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
<ngcortes> hey folks, gonna do another brief downtime of the results site to upload another patch
<ngcortes> *intel mesa ci results site
Haaninjo has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
LexSfX has joined #dri-devel
* airlied wonders about using openh264 to provide an lavapipe video path
illwieckz has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
alatiera has quit [Quit: The Lounge - https://thelounge.chat]
gouchi has quit [Remote host closed the connection]
alatiera has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
illwieckz has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
boistordu has quit [Remote host closed the connection]
boistordu has joined #dri-devel
illwieckz has joined #dri-devel
JohnnyonFlame has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
rasterman has quit [Quit: Gettin' stinky!]
ngcortes has joined #dri-devel
LexSfX has quit []
mbrost has quit [Read error: Connection reset by peer]
FireBurn has joined #dri-devel