ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
iive has quit [Quit: They came for me...]
glennk has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
<DavidHeidelberg>
karolherbst: Adreno has only rotate-left (ROT inst., enough for CL).. would be ok just enable the flags?
<karolherbst>
DavidHeidelberg: in a separate commit as the one in my MR needs to be backported
<karolherbst>
or uhm.. applied to stable branches anwyay
<karolherbst>
DavidHeidelberg: btw, what bit sizes?
<karolherbst>
mhhh
<karolherbst>
actually
<karolherbst>
nir does optimize towards uror if enabled
<karolherbst>
though.. I assume it's still relatively cheap implementing uror on top of urol?
<DavidHeidelberg>
tbh, not much idea, just looked into your MR and found "unused" ROT inst. and while proprietary Adreno has CL support..
<karolherbst>
I wonder if you can do a negative roll to get the other direction...
<DavidHeidelberg>
I think it look like 16+32 support
<karolherbst>
but if it needs to be split (uror/urol support), I'd rather do it in a new MR anyway
columbarius has joined #dri-devel
<karolherbst>
would be good to first figure out what the hw can actually do
co1umbarius has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
<DavidHeidelberg>
karolherbst: sure the MR look good as is :)
<alyssa>
alu is cheap o:)
<karolherbst>
DavidHeidelberg: does adreno have a funnel shift?
<DavidHeidelberg>
I don't think so, at least from docs/code
<karolherbst>
mhhh
<karolherbst>
it's kinda weird to add a rotate-left but not a rotate-right...
<DavidHeidelberg>
maybe no-one needed it yet (no OpenCL until lumag started writing it), so it's undocumented..
<karolherbst>
I actually wonder...
<alyssa>
alu is cheap o:)
<karolherbst>
if you left rotate by -1, you right rotate by 1, no?
<alyssa>
with sm5 semantics (and 2's complement), yes i think so
<karolherbst>
I wonder if that's true for any rotation
<karolherbst>
worst case the backend puts a neg into the mix, if we are nice, we do that in opt algebraic...
<karolherbst>
but it's kinda pain
<karolherbst>
aren't we at the point where we need a better solution instead of doing `struct nir_shader_compiler_options`? :D
anujp has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
<alyssa>
iirc, the original plan was that drivers would bring their own nir algebraic pases
<alyssa>
maybe have common rules to choose from to paste together as desired?
<alyssa>
obviously that's not the path we took though
* alyssa
shrug
<alyssa>
there are worse things
<karolherbst>
I mean.. that's what we kinda have right now, no? :D
<karolherbst>
just different
<karolherbst>
with nir_shader_compiler_options you select the rules you want to have (opt_algebraic)
<karolherbst>
I just wonder if drivers filling a table with supported bit sizes of nir_op's would be the more sane way of dealing with all of this here...
<karolherbst>
oh well...
<karolherbst>
not that it matters much
Company has joined #dri-devel
<DavidHeidelberg>
hmm, only SHFL, not SHFR. So something like negative value is probably the way to go
<DavidHeidelberg>
and it should support 16 and 32 bit
<DavidHeidelberg>
hmm, hold a sec, it's not like on nvidia it can be adjusted by subop.. so not sure how it's called in adreno driver :(
camus has joined #dri-devel
ghfj has quit [Remote host closed the connection]
heat_ has quit [Ping timeout: 480 seconds]
danylo has quit [Ping timeout: 480 seconds]
remication has joined #dri-devel
mbrost has joined #dri-devel
remication has quit [Remote host closed the connection]
kzd has joined #dri-devel
Calandracas_ has quit []
jbarnoin has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
bmodem has joined #dri-devel
kzd has quit [Quit: kzd]
cheako has quit [Quit: Connection closed for inactivity]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
kts has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
aravind has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
itoral has joined #dri-devel
kts has joined #dri-devel
sima has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
rgallaispou has joined #dri-devel
simondnnsn has joined #dri-devel
samuelig has quit [Quit: Bye!]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
hansg has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
frankbinns1 has joined #dri-devel
OftenTimeConsuming has quit []
xroumegue has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit []
OftenTimeConsuming has joined #dri-devel
xroumegue has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
OftenTimeConsuming has quit [Quit: OftenTimeConsuming]
OftenTimeConsuming has joined #dri-devel
mripard has joined #dri-devel
yuq825 has joined #dri-devel
samuelig has joined #dri-devel
simondnnsn has joined #dri-devel
OftenTimeConsuming has quit [Quit: OftenTimeConsuming]
lynxeye has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
frankbinns1 is now known as frankbinns
tursulin has joined #dri-devel
frieder has joined #dri-devel
<vsyrjala>
demarchi: "dim: line 187: [: -eq: unary operator expected"
OftenTimeConsuming has quit [Quit: OftenTimeConsuming]
OftenTimeConsuming has joined #dri-devel
jfalempe has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<jani>
meh, I've missed the pull request with that change :(
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
danylo has joined #dri-devel
glennk has joined #dri-devel
yyds has joined #dri-devel
yyds_ has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<karolherbst>
I'd rather have some explicit review on that part before forcing `-fPIC` generally
kts has joined #dri-devel
<karolherbst>
jenatali: one thing I was thinking about is to add a `clc_init()` with potentially returning a `struct clc_context` object to cache some calculation made clc_compile_to_llvm_module, but also elsewhere. I don't think it's really worth it from a compilation overhead perspective, though we do a couple of syscalls in there so it might actually matter for smaller kernels... ever played around with that?
rasterman has joined #dri-devel
vliaskov_ has joined #dri-devel
<rgallaispou>
Hi
<rgallaispou>
I've a dependency in my serie [1] which is merged in linux-next. I am based on drm-misc-next which does not include it yet, and cherry-pick the dependency manually. When generating the patches I cannot specify the base commit for the dependency (git format-patch --base='...') because it is on another tree. So I get striked by the kernel test robot.
<rgallaispou>
Should I base it and test directly on linux-next to get the dependency right, or was it correct the way I did previously ?
yyds_ has quit [Remote host closed the connection]
yyds has joined #dri-devel
simondnnsn has joined #dri-devel
Leopold__ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
Leopold__ has quit [Remote host closed the connection]
Leopold__ has joined #dri-devel
pcercuei has joined #dri-devel
mvlad has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
jsa has joined #dri-devel
jsa has left #dri-devel [#dri-devel]
jsa has joined #dri-devel
simondnnsn has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
yyds has quit [Remote host closed the connection]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.3]
dviola has joined #dri-devel
glennk has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
a-865 has quit [Ping timeout: 480 seconds]
mvchtz has quit [Quit: WeeChat 3.5]
bmodem has quit [Ping timeout: 480 seconds]
phire has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
mvchtz has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
cedar^ has joined #dri-devel
<jenatali>
karolherbst: nah, I haven't seen that overhead be a problem I think
simondnnsn has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. on windows it's fine, but now that I want to use `dladdr` and `realpath` on Linux it might be significant enough to shave off a few seconds of CL CTS runtime...
simondnnsn has joined #dri-devel
<karolherbst>
but haven't checked yet
<karolherbst>
realpath is quite expensive as it resolves all symlinks in the path, so it has to do quite a few syscalls like `stats` on each part of the path and the likes... but compared to the full compilation I'm sure it's still entirely irrelevant
<karolherbst>
but who knows
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
glennk has joined #dri-devel
itoral has quit [Remote host closed the connection]
yuq825 has quit []
aljazmc has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<daniels>
it's present in debian oldstable and the old ubuntu LTS so should be fine, but last time I tried to increase a dependency version the policy seemed to be that it was completely unacceptable to require anything released in the last 5 years, other than libdrm
<karolherbst>
daniels: I think for piglit that's fine...
<karolherbst>
I think if your use case is to run piglit main on 5 year old software, you might want to either pin your piglit version or reconsider your life choices
<karolherbst>
however
<daniels>
shrug, that's the policy for mesa
<karolherbst>
you don't need custom cmake modules for finding pkg-config based deps
<daniels>
kinda-sorta
<daniels>
Wayland relies on wayland-scanner to parse XML for extension definitions and generate C, so for cross-compiling you want to discover wayland-scanner and wayland-protocols from the host
<karolherbst>
ohh, you want to use helper stuff for wayland codegen things...
<karolherbst>
mhh
<karolherbst>
maybe we should pull those into wayland git repos...
<karolherbst>
and not make everybody write their own wrappers
<emersion>
meh
<emersion>
i'd rather not add helpers for each and every build system
<daniels>
for Meson it's pretty trivial, for autoconf we do install wrappers into aclocal to use, but the state of the art for cmake seems to be to find a module somewhere and vendor it into your tree
<daniels>
I also, specifically, don't want to spend any more time on CMake than is strictly necessary
<karolherbst>
yeah...
<emersion>
^
mvchtz has quit [Quit: WeeChat 3.5]
<daniels>
doing the libclc spirv stuff was at least 20x my lifetime quota
<karolherbst>
:D
<karolherbst>
fair enough
mvchtz has joined #dri-devel
<bl4ckb0ne>
are dmabufs available in android? I'm looking at a way to import a buffer into vk without using AHardwareBuffer
frieder has quit [Remote host closed the connection]
<karolherbst>
so that's going to be fun if anybody comes around and claims "but 5 years"
hansg has quit [Quit: Leaving]
jernej_ is now known as jernej
mbrost has joined #dri-devel
anujp has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
kts has quit [Quit: Leaving]
<mupuf>
daniels: my policy is that if it is in Debian stable, the thing is already too old
dviola has quit [Quit: WeeChat 4.2.0]
dviola has joined #dri-devel
<mupuf>
End users shouldn't use them, and especially not devs
<daniels>
mupuf: this is not a universally-shared opinion
<mupuf>
Haha, indeed!
<karolherbst>
well.. luckily it's about piglit, not mesa here
mbrost has quit [Ping timeout: 480 seconds]
<mupuf>
But people in the know know that stable distros sell false promises unless they pay for it
<karolherbst>
I wished more would know that
<mupuf>
And even for paid ones, what you pay for is developer time to provide guidance and emergency fuxes
<karolherbst>
well.. and you pay for testing of updates
<mupuf>
But that only covers known issues
fab has joined #dri-devel
<karolherbst>
and regressions
<karolherbst>
but yeah
<mupuf>
Yep
<karolherbst>
better than what LTS distros do :P
<mupuf>
+9000
<mupuf>
Worse, Debian doesn't even update packages to their current LTS before releasing a new stable
<karolherbst>
I think the issue is that they don't care about upstream LTS anyway
<karolherbst>
I wished they would, but...
<mupuf>
It's all a show ;)
<karolherbst>
anyway, nothing wrong with debian for fire&forget use cases
<karolherbst>
or if you don't necessarily care about either
<mupuf>
Look, we have 70k packages!! Oh, they aren't outdated, they are just "stable"
<karolherbst>
or if stuff not moving is your use case
<mupuf>
And even unstable has years old packages :D
<mupuf>
Yeah, Debian should focus on server use cases
AnuthaDev has joined #dri-devel
<karolherbst>
I think it's fine, we just all have a different opinion on what "unstable" means
<mupuf>
Drop the rest
<karolherbst>
or uhm..
<karolherbst>
"stable"
<mupuf>
</rant>
<mupuf>
I wouldn't get so upset if users did not come expect developers to support their insanity
<karolherbst>
well.. most users seem to be fairly understanding
<karolherbst>
I think last year I only had one "but what I'm supposed to do" case
<mupuf>
But hey, it is 2024, if your distros doesn't provide packages: fire up podman
<mupuf>
Or distrobox and develop there
<karolherbst>
I mean.. that's kinda an option that docker/podman/flatpak make distributions pointless overhead (like having 1000, not just let's say 10), because of their inability to change
<daniels>
mupuf: it's not about users - iirc it was mareko and mattst88 saying that we couldn't require newer wayland-protocols until it was in LTS
<emersion>
well, depends which distro
<karolherbst>
yeah... but that's why I said "10", not "1" :P
rgallaispou has left #dri-devel [#dri-devel]
<emersion>
i'm working on a libva patch which fixes an issue, which will take a while to ship in a release, and i think a very long while to ship in flatpak
<emersion>
if at all
<karolherbst>
but yeah....
Aura has quit [Ping timeout: 480 seconds]
<mupuf>
Ubuntu LTS or Debian stable?
crabbedhaloablut has quit [Read error: Connection reset by peer]
<emersion>
like, all flatpak packages will need to bump their SDK
<AnuthaDev>
I couldn't find much discussion about Xorg EVoC online so asking here. I am interested in some ideas listed in the DRM TODO
<karolherbst>
AnuthaDev: we can't take any students atm
<karolherbst>
(should probably update the wiki)
<AnuthaDev>
Ah, I see
<AnuthaDev>
tbh I was suspecting it given the lack of online activity about it
<AnuthaDev>
unfortunate nonetheless
<karolherbst>
yeah... maybe it will be all sorted out this year
<AnuthaDev>
Hope so :)
<mattst88>
karolherbst: remind me why we can't take students now?
<karolherbst>
SFC stuff
<mattst88>
ahh, right. switching from SPI to SFC
<karolherbst>
yes
<karolherbst>
kinda have to make real and proper contracts with students about work like that
<karolherbst>
so yeah...
<mattst88>
AnuthaDev: FWIW, I haven't seen many students do EVoC -- I think it's mostly been useful for cases where a student is already involved in the project
<karolherbst>
I had an EVoC student being new working on rusticl tho
<AnuthaDev>
Well I would've participated via GSoC but have already exhausted my limit of 2
<karolherbst>
and they were more or less new to the project, well.. kinda
<karolherbst>
mhh yeah...
<karolherbst>
maybe sima is able to give an ETA on when we'll be able to take EVoC students again?
<AnuthaDev>
I actually tried emailing evoc@foundation.x.org like 4 weeks ago, but never received a response...
<karolherbst>
huh
<karolherbst>
you got two replies, no?
<karolherbst>
wait..
<karolherbst>
alyssa messed up replying and sima didn't fix it :D
<AnuthaDev>
Yeah, I just checked, no replies
<sima>
ugh
<karolherbst>
I'll forward :D
<karolherbst>
done
<sima>
ugh we haven't updated the evoc page yet I think :-/
<karolherbst>
sima: anyway, we can still do EVoC via SPI now?
<sima>
karolherbst, yeah I think we should be set up now
<sima>
just need to make it clear that spi requires a signed contract, and the thing internship cannot start before that's sorted out
<karolherbst>
okay, and here I thought we have to wait until the SFC stuff is done :D
<AnuthaDev>
Oh damn I got a reply from alyssa? They're my inspiration 🙏
<AnuthaDev>
Also, if I didn't mess up the email address I emailed sima too 😅️
<sima>
my email situation is a disaster unfortunately
<karolherbst>
stop doing email then, it solves all problems :P
<sima>
but yeah I got it I think, somewhere, but I failed to realize that the reply I typed on the other thread went nowhere :-/
<sima>
karolherbst, currently at the "stop doing" part :-P
<AnuthaDev>
Because of the timing being during holidays I didn't send followup messages....
<sima>
AnuthaDev, so you got what alyssa & me wrote through karolherbst now?
<AnuthaDev>
Yep
<sima>
also sorry for this mess :-(
<karolherbst>
email is hard
<AnuthaDev>
Ah its alright :)
co1umbarius has joined #dri-devel
<sima>
ok need to prep dinner now, kinda wanted to get that started an hour ago ...
<karolherbst>
mood
<karolherbst>
just with everything today
columbarius has quit [Ping timeout: 480 seconds]
<sima>
I did manage to pull out the salad bowl but then got distracted ...
<karolherbst>
I decided I'm not able to cook today
<karolherbst>
welll
<karolherbst>
s/decided/accepted/
<sima>
yeah there's days where accepting stuff aint happening is too much ...
<karolherbst>
oof
<karolherbst>
I got pretty good at it
<emersion>
mattst88: hm, still not sure whether that's what we should go for
<mattst88>
emersion: I don't see a ton of value in the even-odd stable-unstable split for pixman anymore; but also switching away from it seems like more work
<alyssa>
AnuthaDev: :-)
<AnuthaDev>
🙏🙏
lynxeye has quit [Quit: Leaving.]
* alyssa
isn't good at email
<AnuthaDev>
How to send these sort of "narrator" messages? I am very new to IRC
<karolherbst>
/me
* karolherbst
wonders if AnuthaDev meant that
* AnuthaDev
check test
<AnuthaDev>
Oh it works, cool!
* AnuthaDev
feels blessed he gets to eat mom's cooking
* alyssa
recommends against saying everything in 3rd person, though
* AnuthaDev
thinks its common in anime probably
<AnuthaDev>
ok i'll stop lol
<AnuthaDev>
OK, so from what I understand I can apply for EVoC , but I'll need a project plan and a mentor. Correct?
<AnuthaDev>
And the contract will need to be sorted beforehand...
<karolherbst>
yeah
<karolherbst>
well
<karolherbst>
the contract needs to be sorted before you start the work
<karolherbst>
it's basically to protect you from doing unpaid work
<karolherbst>
but you can work on small tasks to get familiar with the projects/code base you want to do the EVoC with
<karolherbst>
and mentors are generally more open for the program if they see the student being capable beforehand
<AnuthaDev>
Yep, I'll need to do a lot of "unpaid work" to even get started 😄️
<karolherbst>
well...
<karolherbst>
"a lot" :P
djbw has joined #dri-devel
<AnuthaDev>
No experience below userspace 😅️
<karolherbst>
well.. you don't have to work on the kernel
<karolherbst>
it can also be mesa
<karolherbst>
or anything in xorg/freedesktop
<AnuthaDev>
But you see, I want to work on the kernel :)
<karolherbst>
fair :)
<karolherbst>
do you have a second machine?
<AnuthaDev>
Not at the moment, had an old laptop which is currently broken
<karolherbst>
mhhh
<AnuthaDev>
Am thinking of getting a pi 5
<karolherbst>
ohh, that might be good
<karolherbst>
if you want to get one anyway
<karolherbst>
kernel development without a serial console can be pain
<AnuthaDev>
From what I see on mesamatrix.net I can even work on the pi's GPU drivers?
<karolherbst>
sure
<karolherbst>
might want to speak with the devs there and figure out what would be a goo beginners task
<AnuthaDev>
I should've messaged the IRC earlier. So many cool people around.
<karolherbst>
apinheiro: ^^ tldr: EvoC student might be interested working on the v3d driver, though not sure if you are the best person to ping for the kernel side of things
<AnuthaDev>
As opposed to email... I spent my New Years wondering whether I had spelled sima's email correctly :P
<sima>
AnuthaDev, for kernel rpi gpu driver ping melissawen and mairacanal
<AnuthaDev>
Understood.
<AnuthaDev>
Oh I had a question btw, how do you develop for devices that you don't have physcially for testing?
<AnuthaDev>
> Maintainer of the driver you plan to convert
<AnuthaDev>
Do i just send patches hoping that they are correct and the maintainer would test them?
<alyssa>
Ideally you'd get the hardware
<alyssa>
AnuthaDev: ^
<AnuthaDev>
Hmm, that sounds expensive
<alyssa>
yeah..
<alyssa>
in mesa we have drm-shim to mock devices which helps here
<alyssa>
don't think kernel has an equivalent /
<alyssa>
:/
vliaskov_ has joined #dri-devel
<AnuthaDev>
I should probably stick to focusing on one driver then
<AnuthaDev>
Either the one in my laptop or a pi 5
<AnuthaDev>
"AMD RX Vega 7"
<Company>
I vote pi 5
<Company>
my pi 4 that I use for testing needs lots of love
vliaskov__ has joined #dri-devel
AnuthaDev has quit [Quit: AnuthaDev]
Aura has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
APic has quit [Ping timeout: 480 seconds]
zf has joined #dri-devel
Company has quit [Quit: Leaving]
ngcortes has joined #dri-devel
APic has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
krushia has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
krumelmonster has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
krumelmonster has joined #dri-devel
simondnnsn has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mbrost has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
<apinheiro>
karolherbst, sorry, has just seen your ping now (just when I'm about to disconnect)
<apinheiro>
for the kernel side of things, perhaps maira (or even melissa) are more suited
<apinheiro>
not sure if she will have time for an Evoc though
<apinheiro>
karolherbst, maira is mairacanal at #videocore
<apinheiro>
oh, she is here too
<apinheiro>
mairacanal, ^
<apinheiro>
just in case you were not connected then:
<apinheiro>
"<karolherbst> apinheiro: ^^ tldr: EvoC student might be interested working on the v3d driver, though not sure if you are the best person to ping for the kernel side of things"
<JoshuaAshton>
sima: Bump on bubbling fence errors to userspace :)
<gfxstrand>
Ooh, spicy!
<JoshuaAshton>
gfxstrand: You want in? :p This could also allow us to do away with check_status in Mesa VK Common Code (which also isn't used by RADV anyway as it doesn't function with soft recovery)
<gfxstrand>
I'd love it if we can somehow verify that the only errors returned are ones generated by our context somehow.
<gfxstrand>
But I've not looked at any of the proposals.
<gfxstrand>
The problem with general error propagataion is that dma_fences get passed around so if you're not careful you can end up with errors from other contexts in your context.
<gfxstrand>
We had bugs for a while where a GPU hang on Intel in an app would kill Xorg.
<JoshuaAshton>
Yeah, eg if you imported a drm syncobj and it resulted in Mesa saying VK_ERROR_DEVICE_LOST and marking the decide as lost because it had an error
<JoshuaAshton>
That would be a problem
<gfxstrand>
Oh, it's worse than just imports
<JoshuaAshton>
VK_SUCCESS works but doesn't give enough info for eg. a compositor to discard a frame because it's fence actually had an error and was garbage. (Unless there was some way to query it explicitly)
<gfxstrand>
You could have some shared buffer somewhere that causes implicit fence imports due to memory management stuff.
<JoshuaAshton>
gfxstrand: Oh?
<JoshuaAshton>
Yeah...
<gfxstrand>
Even if you're using explicit sync
<gfxstrand>
:D
<gfxstrand>
You have to assume any dma_fence from any context can arbitrarly land in any other context even if the two don't know about each other according to userspace.
<JoshuaAshton>
Perhaps we don't actually surface it through any client API eg GL/VK, and instead return VK_SUCCESS (like AMD does now for signalled fences with errors), and allow the application to check its imported fences/syncobj explicitly?
<JoshuaAshton>
I'd propose VK_TIMEOUT but that's forbidden if timeout is UINT64_MAX :(
jsa has quit []
<gfxstrand>
Taking a step back... I think the idea of being able to VK_ERROR_DEVICE_LOST on vkWaitEvents or vkWaitSemaphore is a good one.
<gfxstrand>
The question is how we go about making it safe inside the kernel.
ngcortes has joined #dri-devel
<gfxstrand>
We need some way of specifying that you only care about errors from your own VkDevice, whatever that is.
<JoshuaAshton>
I think that should only be done if the error was signalled by the current context
<JoshuaAshton>
yeah
<gfxstrand>
Which, annoyingly, may not be just the DRM fd. At least not on RADV.
<JoshuaAshton>
Indeed, that's on physical device level
<JoshuaAshton>
(As much as I disagree with that...)
<gfxstrand>
Restricting to your DRM FD wouldn't be too hard, I don't think. We'd need some extra tracking but it's probably tractable.
<gfxstrand>
Doing it per-context would probably mean driver-specific syncobj wait ioctls which would suck.
<gfxstrand>
That or some sort of per-engine cookie that gets passed around that lets us identify which queue generated an error.
<gfxstrand>
That sounds problematic for security, though.
<gfxstrand>
Passing global things to clients seems bad
<gfxstrand>
I guess we could have a drm-fd-local thing that gets passed around
<gfxstrand>
Feels annoyingly complicated but probably doable.
applecuckoo has joined #dri-devel
<JoshuaAshton>
Yeah, makes sense
<daniels>
basically just dmabuf/fence again, but this time for identifying contexts
pcercuei has quit [Quit: dodo]
mvlad has quit [Remote host closed the connection]