anarsoul has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
yyds has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<rgallaispou>
pq: Wait until you see our internal CI tests... I've struggled to instaure IGT, which is currently being integrated
<pq>
sorry?
cmichael has joined #dri-devel
<pq>
emersion, did you just send an email encrypted to me to dri-devel@?
<emersion>
maybe
<rgallaispou>
I meant that part of the internal CI tests in my company were based on modetest. I've talked internally about how IGT is the way to test, and struggled to make it into the CI
<emersion>
ProtonMail doing ProtonMail things probably
<emersion>
encrypted to you because it noticed you have a usable PGP key, and unencrypted to dri-devel
<pq>
aaah
<pq>
I thought everyone else would have had a hard time reading it.
bmodem has joined #dri-devel
<emersion>
i've disabled encryption for you
<pq>
no worries, I just thought no-one received it plain text
<pq>
thanks
<emersion>
right, it fetched the PGP key from keys.openpgp.org automatically
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<pq>
emersion, have you changed your pgp key for email?
<emersion>
hrm, right, i use a different key for email and for the rest…
<emersion>
i should try to improve my setup…
<pq>
gpg: key 16E23940A7E8E335: new key but contains no user ID - skipped
kts has joined #dri-devel
<mripard>
pq: I understand your PoV, but composite output is in a super bad place, because no relevant upstream cares about it. So, yes, of course, it should be the compositors job or whatever to do that, but none will and we have to resort to workarounds.
<pq>
mripard, the commit message could have explained so.
<pq>
I just saw new UAPI being added in relative silence, since nothing said "UAPI" and no-one had commented on the patch.
<pq>
meaning someone will probably just merge that patch after a while of no-one saying anything
<sima>
pq, rpi has a pretty good track record of creative solutions :-/
<pq>
I was just about to say "probably like the Broadcast RGB affecting YCbCr in vc"...
<pq>
(I'd love to get paid to make interlaced and composite work well in Weston.)
<pq>
with an actual CRT too, taking into account the non-rectangular shape without black margins
<daniels>
mripard: yeah, it’s a shame that no-one has really tried to figure out properly what ‘composite’ means in terms of uAPI - I’ve seen every different combination so far I think :\
<daniels>
pq: I’ve been trying to find someone with upstream-useful hardware to do that …
<mripard>
pq: sure, that's totally reasonable for you to ask for a better commit log
<pq>
daniels, oooh! I lack the CRT. I have an original RPi.
<mripard>
I was just saying that the modetest solution wasn't totally a bad one :)
<pq>
no, it is a totally bad one
<mripard>
or rather, all of the solutions we have are bad ones
<sima>
well xrandr at least went through the compositor, so it was aware and could restore
<sima>
modetest is a bit much hopes&prayers
<sima>
like the moment compositors restore everything on vt-switch it'll break
<daniels>
pq: does this mean that you’re nearly finished CM so will have time on your hands? :P
<pq>
daniels, not at all, unfortunately.
<sima>
and yeah for a few properties the userspace was indeed "user screams at xrandr"
<sima>
but "user screams at modetest" feels a bit much a stretch, since with xrandr you _could_ put the right values into Xorg.conf and it would work automatically
<sima>
I'll reply and then start cooking lunch, somehow that's very late
<sima>
mripard, so moving drm.git also on hold until dim is sorted?
<mripard>
sima: I have done some code to update automatically the remote url in dim
<mripard>
I'm writing the commit log at the moment
<mripard>
so I don't think we need to roll anything back at the moment
<sima>
mripard, hm I can still push to legacy drm.git, so I guess that wasn't changed yet?
<sima>
or I'm unclear what you don't want to roll back ...
<sima>
jani, uh I got a conflict between drm-intel-fixes and drm-intel-next and I'm pretty sure it's not me?
<sima>
and I'm rusty on the "just pick -next" git merge incantation ...
<jani>
sima: this is probably on dolphin having picked up a few fixes
<mripard>
sima: we pushed the nightly.conf change this morning
<dolphin>
yeah, I picked fixes, but did not get conflict
<dolphin>
well, now there is a conflict
<mripard>
sima: once we agree on the dim MR, I think we can make the cgit repo ro
<dolphin>
maybe the conflict was hidden because the remote was missing
<dolphin>
resolving it now, anyway
<sima>
dolphin, thx
warpme has quit []
warpme has joined #dri-devel
<dolphin>
sima: It is fixed now
<sima>
mripard, oh that might explain some conflicts, because the gitlab drm is slightly outdated ...
<mripard>
drm-next is up-to-date afaik
<sima>
daniels, mripard can you pls make the drm.git on legacy ssh ro asap so there's no mess with diverging trees
<sima>
airlied_, ^^ fyi
<mripard>
it looks like you just pushed -rc6 to fixes?
<sima>
yeah
<mripard>
I'll make sure drm-fixes is in sync too then
davispuh has joined #dri-devel
<sima>
can you push to gitlab?
<mripard>
yep
<mripard>
daniels granted me temp rights to do the transition
glennk has joined #dri-devel
<sima>
aye
<mripard>
done
<sima>
mripard, oh you pushed the MAINTAINERS directly? figured should have at least some ack from airlied or me :-)
<sima>
oh it has lol
<mripard>
I had your ack yesterday, and I understood you instructed me to do so?
<mripard>
if I misunderstood, sorry :/
<sima>
oh I meant I push it, I didn't realize you have full repo access
<mripard>
I'm sorry
<sima>
airlied_, need to update the drm repo url with git remote set-url or something like that
<sima>
mripard, eh no worries
guludo has joined #dri-devel
<sima>
mripard, hm so reconsidering, ok if I snatch up git committer and add my sob? shouldn't cause issue, and airlied&me are supposed to be the only ones who can push to that one directly
<sima>
just so we don't look too much like access rights yolo to linus by accident
<mripard>
makes sense to me
itoral__ has quit [Remote host closed the connection]
<sima>
mripard, the ssh url you've used in nightly.conf doesn't match what the gitlab web ui gives you, resulting in some very good entertainment
<sima>
I fixed ngihtly.conf so that both ssh url formats are now there
<sima>
but probably good to do the same for the other transitions too
<mripard>
sima: yeah, it's basically due to whether you're using it with or without the protocol
<mripard>
gitlab gives it without the protocol, which works
<mripard>
you can use an ssh URL which also works
<sima>
hm xe should probably have both too to avoid confusion
<sima>
demarchi, ^^
<mripard>
but they have different syntaxes
<sima>
mripard, yeah but it meant that I had two remotes pointing at the same thing, and for silly reasons git didn't auto-grok the right username for the one with the ssh:// proto prefix
<sima>
and so I went on a detour screaming at my ssh_config :-)
<sima>
until I realized there's two remotes
<sima>
and only one works
<sima>
the one I set up and tested yesterday, so was a bit puzzled
<sima>
airlied_, maybe want to cherry-pick the MAINTAINERS patch from drm-next to drm-fixes too when you do that, so there's no confusion for linus for the pr this week
<mripard>
demarchi: I've updated the MR according to your feedback
<daniels>
I’ll sort the mirror later this afternoon
Daanct12 has quit [Quit: WeeChat 4.2.1]
Calandracas has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
<sima>
mripard, personally I would have tried the "keep the old urls and mirror there" approach first
<sima>
and then maybe add a dedicated check to dim push-branch
<sima>
maybe even suggest to run the correct git remote set-url with the first url or so
<mripard>
So you would only do so when someone push? I guess I can do that
<sima>
mripard, yeah if the more general solutions are tricky, that's what I'd try
<sima>
and then maybe we can figure out a better way if we try to sunset the mirrors
diego has left #dri-devel [#dri-devel]
<mripard>
I think the current solution demarchi suggested work fine, but we have to keep the mirrors for a while
<mripard>
which seems to be aligned with what you want
dviola has joined #dri-devel
<sima>
mripard, I'm also agree with jani, this should be part of the "the remote isn't there, do you want me to create it" logic
kts has joined #dri-devel
<jani>
sima: just mentioned on the MR, this also shouldn't be specific to any repo
<sima>
mripard, so somewhere in url_to_remote
<sima>
jani, yeah
<sima>
mripard, so the issue is that if you don't run the separate setup step (like I never run update-branch, I just git pull the branch I use since I have them all)
<sima>
then url_to_remote will create a _new_ remote
<sima>
which absolutely wreaks it all
<sima>
this was my confusion today
<sima>
so I think that's the part we need to fix
<sima>
probably need to keep a list of old urls in nightly.conf to be able to do that
<mripard>
so something like, if the remote isn't there, we add it, otherwise we change its URL?
<sima>
mripard, well need to first look whether it's there with the old urls, and if yes, then offer to update the url of that existing remote
<sima>
if there's no old url, then the current code that offers to create it
<sima>
mripard, which probably means we should asap add all the old drm.git urls so that people don't hit that surprise of "hey here's a new remote you didn't ask for" gotcha?
<mripard>
so, that would be pretty much the current logic but it url_to_remote and taking the first repo in nightly.conf instead of hardcoding it?
<mripard>
sima: I think we still need to add the old URLs to nightly.conf, because that prevents people from pulling the latest rerere cache and maintainer-tools
<mripard>
once we have that and the old repo setup as mirrors, then I think we're no longer in a rush
<mripard>
things might break when pushing to the old repo that would be read-only, but at least we can distribute nightly.conf and maintainer-tools updates
<mripard>
... but then your solution probably deals with that nicely too
<mripard>
sorry
<mripard>
I'll give it a try
fab has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
qyliss has quit [Quit: bye]
Calandracas has joined #dri-devel
qyliss has joined #dri-devel
qyliss has quit [Quit: bye]
qyliss has joined #dri-devel
qyliss has quit []
qyliss has joined #dri-devel
JohnnyonFlame has joined #dri-devel
kts has joined #dri-devel
<demarchi>
sima: yeah... let's merge mr 38
<mripard>
sima: pushed a new version with drm_old_repos
<mripard>
it was mostly working :)
<sima>
it pains me to admit that I know how to script bash
<mripard>
I added you SoB and co-developed-by, I assume that's ok?
<sima>
mripard, ack
<sima>
mripard, so for migration, we need to make sure everyone updates dim, then we need to update nightly.conf (both old and new place at least) and then everyone needs to try twice and it should work?
<sima>
since first try needs the new nightly.conf and then 2nd will fix up remote urls?
DodoGTA is now known as Guest1189
<sima>
demarchi, I guess you'll rebase !38 one and push?
DodoGTA has joined #dri-devel
<sima>
mripard, why the for remote loop?
<mripard>
sima: yeah, if we push the new nightly.conf with drm_old_repos and the new dim changes, we need people to still being able to fetch that, so the first run should succeed
<mripard>
which it will if they *don't* update the URL like we told them to
<mripard>
and the second run will update and work just fine
<mripard>
so maybe we should just tell them to run dim ub twice without doing anything
<sima>
remote=$(url_to_repo "$url") <- this line a bit later will get you the right nightly.conf repo name
<sima>
I forgot to move that when I moved the for loop a bit higher above the error message, sry about that
<mripard>
sima: there was an syntax error for an out of bounds access if I didn't
<mripard>
and definitely don't know how to script bash :-D
<sima>
oh if there's no repo name for that I guess?
<mripard>
I *think* it's because it's a 2d array: first index in the remote name, second is the URL index
<sima>
yeah but which one does it pick if it's multiple local tags
<demarchi>
unless I'm missing something
<sima>
since we need to push that specific tag with the tag message and signature and all that for non-dry run
<demarchi>
ok... just remove the comment or reword to something else?
<sima>
just remove
<sima>
put that in a gitlab comment too
<sima>
and I thought git rev-parse is the one that does symbolic lookup, not the one that spits out a sha1
<demarchi>
after doing my first pull request, what I don't really like in that function is the strict use of branch@{upstream}... would it be acceptable to allow it to be overriden?
<demarchi>
I don't feel like creating a pull request containing a commit pushed 1min ago by someone else and would rather create the pull request with something that already soaked some testing after being merged
<sima>
demarchi, I think for that it would be better to have a pull-request-for-tag function
<sima>
so just bottom part
<sima>
since the "make a tag part" is already split out into dim tag-branch
<sima>
then you can tag something, let it soak for a day, then make the pr
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<sima>
that would also be useful for when the mail setup is wrong and the tail of the dim pull-request function dies
<sima>
or maybe make dim pull-request smarter so you can pass it a tag instead of a branch
<sima>
and then it skips the tag creation
<demarchi>
yeah... I will take a look at it later this week before my next pull
<demarchi>
sima: about rev-parse.... it will spit the sha1
<demarchi>
there's a --symbolic and --symbolic-full-name to change the behavior, but by default it's sha1
<sima>
ah yes
kzd has joined #dri-devel
gouchi has joined #dri-devel
<DemiMarie>
robclark: is this something that a malicious guest would not be able to bypass, unlike kernel-mode validation of queue contents?
<robclark>
yeah, it could just not pass it on to the kernel.. OTOH there might be valid cases to restrict in kernel (ie. to tie it in to cgroups or something like that)
gouchi has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Duke`` has joined #dri-devel
warpme has quit []
<DemiMarie>
robclark: how concerned are you about someone using a firmware vulnerability for RCE over the air?
<sima>
mripard, well for now only the one for drm.git?
<bl4ckb0ne>
not sure yet
<sima>
or do you want to push them all early, so that people are prepared?
<robclark>
DemiMarie: I'm not too much involved in video side of things but AFAIU there is a separate sandbox process in chrome for doing video decode.. it defn would make sense to want to limit what processes can do video dec
cmichael has quit [Quit: Leaving]
<sima>
that way they'd have the upgrade proof nightly.conf already ...
<sima>
mripard, but maybe wait for a tested-by from demarchi or someone, before we make things worse by accident
<DemiMarie>
robclark: I agree. I’d also want to make sure that the VCN/HuC firmware isn’t trusted by the kernel or the rest of the GPU.
joantolo[m] has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Haaninjo has joined #dri-devel
<mripard>
sima: I meant only the drm one indeed :)
<mripard>
demarchi, jani: did you update your drm repos in dim already?
<demarchi>
mripard: I did, but I can undo it and test
<demarchi>
give me a few minutes... just need to finish pushing something
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<demarchi>
dim: No git remote for any of the URLs git@gitlab.freedesktop.org:drm/kernel.git https://gitlab.freedesktop.org/drm/kernel.git ssh://git@gitlab.freedesktop.org/drm/kernel.git found in /home/ldmartin/p/linux-dim/src
<demarchi>
Enter a name to auto-add this remote, leave blank to abort: drm
<demarchi>
error: remote drm already exists.
<demarchi>
then it continues and no url changes
<mripard>
but if you were to have a dim tree that hasn't been updated today, you would have an older rerere tree too
macromorgan has joined #dri-devel
<mripard>
at 044940a15536
<mripard>
(anyway, I really have to go now, I'll look later)
heat is now known as Guest1198
heat has joined #dri-devel
Guest1198 has quit [Read error: No route to host]
macromorgan_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<demarchi>
mripard: oh... I forgot to apply the changes to drm-rerere
JohnnyonF has quit [Ping timeout: 480 seconds]
<demarchi>
ok, retrying with the additional rerere changes and it worked
<demarchi>
( good thing that today I found a neat script tmpoverlay.sh to overlay a tmpfs on top of a dir, so I can rewind to what I had before and try multiple times :) )
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
fab has joined #dri-devel
bolson has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<mripard>
demarchi: \o/
fab has quit [Ping timeout: 480 seconds]
<mripard>
thanks for testing
<mripard>
so, should we merge this?
<abhinav__>
mripard Hi, as requested y'day, for msm for one of the features for 6.9, we had some changes merged on drm-misc on 02-24 , after the last cutoff tag on 02-22, by any chance is another tag creation possible for 6.9
<mripard>
abhinav__: we normally don't: Linus wants everything in -next by -rc6. What is that feature about?
junaid has joined #dri-devel
<bl4ckb0ne>
seems like my issue was a leftover data from glGetError, so the issue was sitting between the chair and the keyboard
junaid has quit [Remote host closed the connection]
diego has left #dri-devel [#dri-devel]
dviola has joined #dri-devel
agd5f has quit [Read error: No route to host]
agd5f has joined #dri-devel
mvlad has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
<Lynne>
"We're a real Vulkan driver now" <- not until descriptor buffers :)
<dj-death>
don't say that
<dj-death>
otherwise gfxstrand will block my runtime patch until she gets it working on nvk...
<Lynne>
surely that patch is mature enough to drink now
<dj-death>
just got a facelift
<dj-death>
might get ID-ed
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Marcand has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<DemiMarie>
robclark: would it be possible to promote virtio-GPU native contexts to a generic part of Mesa supported by all drivers?
apinheiro has quit [Quit: Leaving]
<DemiMarie>
robclark: also I noticed that Cloudflare is using Dawn in a multi-tenant context (Workers), so hopefully they will put effort into DoS prevention. For them, crashing the GPU _is_ a security vulnerability!
<robclark>
DemiMarie: I don't think you could (or even should) make it fully transparent... one early idea I investigated was so called "rendernode forwarding" (basically a proxy rendernode device in the guest).. but the latency was too high, compared to linux syscalls which are pretty fast.. my conclusion is that it is better to lean into async, ie. come up with ways to avoid synchronous calls to the host.. whether that be userspace
<jenatali>
Our WDDM forwarding mixes a bunch of synchronous calls with async, but yes we're also heading in the direction of direct usermode -> GPU interactions to avoid the remoting overhead
<mattst88>
gfxstrand: heh, yep. even a 1-bit int has to be 4-byte aligned /o\
<DemiMarie>
robclark: was a synchronous hypercall API considered? “Synchronous” meaning “force a VMExit and immediately switch to the userspace VMM”.
<mattst88>
pretty silly
<DemiMarie>
jenatali: what about allocation? Moving allocation into firmware seems like a very bad idea.
<jenatali>
No that's still a synchronous call
<robclark>
vmexit would be faster, but plumbing that thru kvm (at least on arm64) looked unfun
<DemiMarie>
robclark: Unfun?
<jenatali>
Allocation is low-frequency though
<vsyrjala>
i wonder if modern compilers still emit terrible code for c bitfields
<robclark>
for us, allocation is async but if you need to mmap (or dmabuf export or some other cases) that is a barrier
<jenatali>
At least... it should be
<robclark>
DemiMarie: I didn't see a way to implement it that would be acceptable upstream
<DemiMarie>
robclark: why?
<DemiMarie>
Why would upstream say no.
<DemiMarie>
Low latency hypercalls are needed for other cases too.
<robclark>
but not things that exit back to vmm, iirc
<robclark>
anyways, vmexit is still expensive.. and if you can keep things async then you don't need vmexit
<gfxstrand>
mattst88: Oh, it's not that that's bugging me. It's that MSVC actually does re-start the alignment when you switch types so if you have `unsigned i : 4; bool i : 1`, that's 8 bytes.
<DemiMarie>
robclark: they are likely needed for some future stuff in Wine I think.
<gfxstrand>
mattst88: GCC/clang don't. so that's 4 bytes.
<jenatali>
gfxstrand: Yeah MSVC bitfield packing is very strict. It only packs actual identical types
<DemiMarie>
jenatali: I would be tempted to use a static assertion that the layout is right and tell Windows users to use clang.
<jenatali>
Static assertions are great. But for this particular issue, accommodating MSVC isn't really difficult...
<DemiMarie>
robclark: how common is allocation failure?
<robclark>
rare.. and generally unrecoverable anyways
<gfxstrand>
Yeah, for this fix, I just made my booleans unsigned. I don't really like that because it means you loose automatic `x != 0` semantics on assignment but it's safe enough in this case.
<DemiMarie>
robclark: my PoV is that one should try to recover, but only if one will be testing that code, and that is often not the case.
<robclark>
there are still cases (for gl) where driver will be reallocating behind the scenes where there isn't really a way to return an error
Duke`` has quit [Ping timeout: 480 seconds]
<DemiMarie>
Ah, what about Vulkan?
<DemiMarie>
Also, I thought there were very latency-critical paths in compute somewhere.
<robclark>
it might be more reasonable to make allocation synchronous for vk, assuming a well behaved vk app (but I've seen enough app/engines do vk badly, so idk)
<robclark>
compute you can have ping/pong between gpu/cpu if app doesn't try to pipeline things... but that is pretty much going to suck regardless
<DemiMarie>
Generally context switches seem to be getting more and more expensive compared to straight line throughput.
<robclark>
eventually people doing wizz-bang things with compute will learn how to use a gpu
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<DemiMarie>
I think there might be cases where parts of an algorithm do well on a CPU and parts do well on a GPU and these parts are tightly interleaved. I haven’t seen any examples in practice, though.
<DemiMarie>
Anyway, high performance APIs like io_uring are async nowadays.
<DemiMarie>
And IIUC virtio-user often busy spins for performance, though it is not required to.
<robclark>
yeah.. a uring type uabi for drm would be interesting for other reasons.. but a virtqueue is basically like a uring
<robclark>
yeah, venus does busy loops a fair bit.. for nctx I tried to avoid needing to do busy loops
sima is now known as Guest1235
sima has joined #dri-devel
TMM has quit [Ping timeout: 480 seconds]
TMM has joined #dri-devel
Guest1235 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold__ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Calandracas has quit [Remote host closed the connection]
guludo has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
sarthakbhatt has quit [Remote host closed the connection]
sukuna has joined #dri-devel
odrling has joined #dri-devel
JohnnyonFlame has joined #dri-devel
cambrian_invader has joined #dri-devel
<cambrian_invader>
are there any userspace helpers for /dev/drm_dp_aux or has everyone been getting by with dd?
Marcand has quit [Ping timeout: 480 seconds]
<vsyrjala>
i think there's something in igt. no idea what it does. i just use dd+xxd/hexdump
<vsyrjala>
quick glance at the igt tool suggest it doesn't work with offline dpcd dumps. so not useful for me in its current form
<vsyrjala>
it also doesn't decode anything, so not really any better than hexdump
<vsyrjala>
a tool that would fully decode the dpcd would be nice
<cambrian_invader>
yeah, that's the kind of thing I was looking for
<cambrian_invader>
I guess I will just memorize everything :)
<vsyrjala>
also some monitors are borked an return errors for certain dpcd ranges, which is illegal according to the spec
<vsyrjala>
so may have to rescue-dd/etc.
<cambrian_invader>
my monitor/displayport does not work at all (or rather more than 10% of the time), so I am already sorted in that department
<vsyrjala>
nice
<vsyrjala>
somehow i still haven't managed to memorize much of dpcd. i guess my brain has too many i915 register decoders so no more room for anything else
kzd has quit [Quit: kzd]
vliaskov has quit []
jsa has quit [Read error: Connection reset by peer]