ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
vliaskov has quit [Ping timeout: 480 seconds]
haaninjo has quit [Quit: Ex-Chat]
sukuna has joined #dri-devel
NiGaR has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> home]
NiGaR has joined #dri-devel
sukuna has quit [Remote host closed the connection]
sukuna has joined #dri-devel
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
LeviYun has joined #dri-devel
Fijxu has quit []
Fijxu has joined #dri-devel
Fijxu has quit []
Fijxu has joined #dri-devel
Fijxu has quit []
Fijxu has joined #dri-devel
Kayden has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
LeviYun has joined #dri-devel
iive has quit [Quit: They came for me...]
LeviYun has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<Lynne>
is a pipeline barrier with no image or buffer data guaranteed to be a noop?
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
Lynne: with no pMemoryBarriers as well (assuming PipelineBarrier2)?
<Lynne>
yes, vkCmdPipelineBarrier2, zero barrier structs in total
<Lynne>
(I forgot VkBufferMemoryBarrier2 was a thing, I only use VkMemoryBarrier2)
<ishitatsuyuki>
In terms of Vulkan execution model it should be a noop, but whether the call is actually noop depends on the driver
<ishitatsuyuki>
briefly looking at code it should be a noop on radv
oneforall2 has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
The_Company has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
libv_ has joined #dri-devel
alane has quit []
libv has quit [Ping timeout: 480 seconds]
alane has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Lynne>
cool
<Lynne>
do you know if radv happens to be more barrier-happy than hip?
<Lynne>
2 years ago I ported some simple opencl compute code to vulkan and copying everything opencl did, the result was that vulkan was massively slower due to each barrier between each shader dispatch
<Lynne>
I had to parallelize it at the cost of gigabytes of memory plus atomics when the original used tens of megabytes
<airlied>
probably a bit too vague a question to answer
chamlis has quit [Remote host closed the connection]
<airlied>
like what were you barriering and why? if something takes a lot longer it could be stalling somewhere unexpected
chamlis has joined #dri-devel
<Lynne>
just an nlmeans shader, what you do is you run the same shader about 800 times with different parameters, and each shader simply reads from an image, does some math, and adds the result to a buffer
<Lynne>
opencl did it the naive way, it bound one invocation, executed it, barrier, bind, execute, barrier and so on
<Lynne>
copying this in vulkan was massively slower
<airlied>
so you are barriering on the buffer?
<Lynne>
yes, just the buffer
<airlied>
so did you just write all the outputs to a buffer and sum at the end?
<airlied>
surprised CL was doing it faster, maybe it knew something so decided not to barrier
<Lynne>
it does not do any sync between each invocation... not sure I know enough about opencl to say whether that's legal or not
<Lynne>
each "pass" has 2 shaders - one to integrate the image with a given parameter, and one to compute the weights and then add the result to an image
<airlied>
so why did vulkan need a barrier?
<Lynne>
does it not?
<airlied>
seems like if you had a single ssbo and were just writing to it from subsequent shader invocations there is no need
<airlied>
esp if it's all on the compute queue
<airlied>
then barrier at the end to read back
<Lynne>
forget about what I wrote previously, focus on the 2-shader layout I mentioned
<Lynne>
so you call this sequence of shaders 800 times
<Lynne>
you need a buffer to carry the results between the 2 shaders, first one just writes to it, second one just reads (and writes the result atomically to another buffer, but that needs no barrier so its not a problem)
<Lynne>
do you need a barrier each time you reuse a temporary vkbuffer?
<airlied>
where is that temporary buffer in the cl code?
<Lynne>
integral_img
<airlied>
I'd guess your cl code is buggy and might just work by luck, but I'm not fully across opencl cmd submits
<airlied>
and you should use cl events between submissions
<Lynne>
okay, what about vulkan, when would vulkan need a barrier for such a code?
<Lynne>
between each dispatch, or between each reuse of the buffer?
<airlied>
yeah you probably do need a barrier between each dispatch if horiz and vert are reading/writing the same parts of integral_img
LeviYun has joined #dri-devel
<Lynne>
I've merged horiz/vert in my code
<Lynne>
would you need a barrier between horiz+vert and weights?
<airlied>
yes if weights is going to read back and you have to make sure the other shader has finished
kaiwenjon has quit [Quit: WeeChat 3.8]
kaiwenjon has joined #dri-devel
kaiwenjon has quit []
<airlied>
at a guess you'd be better of throwing them all into one shaders with a barrier in the shader :-), but I could be wrong
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Lynne>
the integration shader runs width-wise, so it does height number of workgroups
<Lynne>
the weights shader is per pixel
<Lynne>
I did try combining them, but it wasn't worth it
<Lynne>
if only you could dynamically stop or resume workgroups, I see no reason why it can't be done these days, as far as I understand the hardware schedules each warp/group independently
<airlied>
oh so like launch a max shader and drop some threads from executing for parts of it?
lemonesque has quit [Ping timeout: 480 seconds]
* airlied
is still too much of a cpu programmer :-P
<Lynne>
yeah, that would be cool, then you could call a function that increases the amount of workgroups
<Lynne>
the former one is already supported... in vertex shaders
<Lynne>
via the terminate_invocation call, I did ask why it isn't allowed here and no one could answer other than "because spirv does not allow it in compute shaders"
kaiwenjo1 has joined #dri-devel
<Lynne>
its obvious there's no reason why it shouldn't be supported, other than vulkan is restrictive by default to make sure everything breaks the same way on all platforms and also because no one cared enough during submission
kaiwenjo1 has quit []
<airlied>
I think you can just return in some threads
kaiwenjo1 has joined #dri-devel
<airlied>
but if you are using a full subgroup it won't do much
<airlied>
my guess is there is probably some amazing subgroup algorithm you could use, but I've no idea what it would be :-P
<Lynne>
there's quite a few parallel prefix sum algorithms out there
<Lynne>
...they were all slower than just doing it naively
<Lynne>
at least for sub 8k images
alanc has quit [Remote host closed the connection]
kaiwenjo1 has quit []
alanc has joined #dri-devel
<Lynne>
speaking of barriers, I wish the validation layers checked for those
<Lynne>
by the way, are there implicit barriers between each submission, or do you need a barrier at the start before reading from a barrier written to by a previous submission?
lemonesque has joined #dri-devel
epoch101 has joined #dri-devel
aravind has joined #dri-devel
LeviYun has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
Fijxu has quit [Quit: XD!!]
Fijxu has joined #dri-devel
zsoltiv_ has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Net147 has quit [Ping timeout: 480 seconds]
<soreau>
does i915 have anything like amdgpu_gpu_reset in /sys/?
<soreau>
I found i915_wedged but it puts a line in dmesg and not much else (the compositor seems unaffected)
JRepinc has quit [Remote host closed the connection]
JRepin has joined #dri-devel
vliaskov_ has quit [Read error: No route to host]
kaiwenjon has joined #dri-devel
<sima>
agd5f, I guess looks like greg will finally script cherry pick handling, might be good if you can adopt dim cherry-pick/cherry-pick-branch so we do this consistently?
<sima>
should be doable to have a flavor of this that doesn't need the entire dim setup
<sima>
demarchi might be able to help with that
DarkShadow44 has joined #dri-devel
jernej has joined #dri-devel
jernej has quit []
DarkShadow44 has quit [Read error: Connection reset by peer]
feaneron has joined #dri-devel
DarkShadow44 has joined #dri-devel
jernej has joined #dri-devel
kaiwenjo1 has joined #dri-devel
kaiwenjo1 has quit []
<Ermine>
what is DRM minor? is it render node?
<pq>
device numbers are (major, minor), DRM has a single major IIRC, and the minor is dynamically allocated to identify a device node that is either primary node, render node, or control node, per device driver instance.
<pq>
'ls -l' shows the major and minor numbers of a device node
<pq>
control nodes do not exist anymore
LeviYun has quit [Ping timeout: 480 seconds]
<Ermine>
ah, those minors
<Ermine>
thank you
<sima>
pq, with accel there's now a second major number range I thought, but yes
<pq>
ah
LeviYun has joined #dri-devel
nerdopolis has joined #dri-devel
rasterman has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
<agd5f>
sima, sounds good. stable kind of drives me crazy. Besides all of the cherry-pick stuff, the entire process is arbitrary. Half the time I have to argue with greg and sasha about getting a patch in and other times they pull stuff into kernels that I never asked them for and then when I causes regressions, I have to argue with them to revert it.
vsro has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Ping timeout: 480 seconds]
<sima>
agd5f, yeah it's pain
<sima>
but I think we have a good chance to stop at least some of the pain
* ukleinek
bets it's also a pain on their side
<sima>
just no more rebases of -next trees (but I think you've stopped doing that a while ago) so there's no sha1 references into the void
<sima>
and then very consistently cherry-pick stuff to -fixes with scripts
<sima>
maybe in another 8 years we get some of the other endless discussions sorted :-/
<ukleinek>
if I understood right that's only a part of their pain
<sima>
agd5f, I guess even if greg scripts it all now we'll probably have a bit more shouting on this until there's enough cherry-pick -x annotated history in upstream
<demarchi>
sima: but dim cherry-pick/cherry-pick-branch is only done by maintainers. Why would that need to be done without setup?
<sima>
so I'm bracing for that already
<sima>
demarchi, because agd5f doesn't use dim for amdgpu trees
<sima>
and might be worth to share the actual script for corner case bugfixes
<sima>
or maybe agd5f switches to dim entirely
<vsyrjala>
some time ago i proposed that we'd ask the stable folks to stop the auto backport nonsense completely for drm (or at least i915). but that request would need to come from maintainers i guess
<demarchi>
vsyrjala: but that thread was about a very wild backport, unrelated to Fixes: or Cc: stable
<demarchi>
having a commit with "drm/....: Fix ..." shouldn't really mean the commit needs to be backported
<demarchi>
vsyrjala: and if they stop doing, someone would need to handle the drm (or i915) side, which is not a small task
<vsyrjala>
i just want them to backport stuff actually marked with cc:stable. nothing else
<ukleinek>
vsyrjala: I would expect that is something they can handle.
<ukleinek>
I know a guy who requested that for patches with author=him, surely also works for patches touching drm
<emersion>
Ermine, pq: OpenBSD works differently in this regard IIRC
<emersion>
or FreeBSD?
<emersion>
one of these
<emersion>
so better not assume anything special about major/minor
<vsyrjala>
ukleinek: i also asked for that, but iirc greg said they only do exceptions based on code not people
<sima>
vsyrjala, I guess if intel/amd/msm all agree we can ask for that, maybe after the dust has settled with the cherry-pick tracing
<sima>
agd5f, robclark ^^ thoughts?
<vsyrjala>
ukleinek: no reply to that, so how do you know they agreed to it?
<sima>
I do agree that AUTOSEL is a nuisance at best
cyrinux has quit []
cyrinux has joined #dri-devel
<agd5f>
sima, probably, but there are cases where it's worked out in our favor and it's a happy surprise when I see a patch already in stable that I had planned to send out. OTOH, the opposite is also true. Not sure which where things shake out on the whole.
<ukleinek>
vsyrjala: Ard asked to expand from author=him, so I read that as the status quo?!
<sima>
agd5f, yeah I think we should perhaps wait a few releases until the cherry-pick dust has settled and then see
<vsyrjala>
it does feel like thye've toned down the AUTOSEL a bit at least. so perhaps it's not such a huge pain anymore
<sima>
since that cherry pick shouting has been such a huge distractions thus far
<sima>
yeah for a while it was picking up typo fixes just because of Fixes: tags iirc
<alyssa>
jenatali: to follow up on the ctor discussion - I *think* I'd like to proceed with what I have (bindgen C++ global ctor + the singleton you reviewed), since I have it working and all the alternatives have pitfalls
<agd5f>
I think it still does. Just this week I had to reject patches going back to stable which were picked up as dependencies sot that their subsequent reverts could be applied to the stable tree.
<alyssa>
I'm very open to a rework later if we can figure out an alternative that's actually better.. I don't think that needs to block merge now, since some of the alternatives would still use all the singleton infra anyway.
<jenatali>
Sounds reasonable to me
<alyssa>
(The possibility of statically baking all format strings across the tree... exists, I guess? but has a lot of open questions.)
<alyssa>
(and all the other options would still internally use the singleton, just not with dllmain)
<alyssa>
(and the singleton is the complicated part, the actual bindgen code here is really short)
<jenatali>
Right
<sima>
agd5f, ok that's a bit too hilarious, but also sounds like a bug in the cherry-pick logic?
<MrCooper>
IIRC there were earlier cases where Sasha drooped them in response
<MrCooper>
*dropped
kzd has joined #dri-devel
<alyssa>
> The conversion specifiers f, F, e, E, g, G, a, A convert a float argument to a double only if the double data type is supported
<alyssa>
thanks i hate it
<alyssa>
jenatali: (((:
<jenatali>
Yeah isn't that awful?
<alyssa>
for real
<alyssa>
i almost want to go out-of-spec here for driver CL because that's sufficiently dumb
<alyssa>
or call fp64 lowering in vtn_bindgen i guess
vsro has quit [Remote host closed the connection]
JRepin has quit []
JRepin has joined #dri-devel
karenw has joined #dri-devel
kzd has quit [Quit: kzd]
<robclark>
sima, I didn't manage to read entire scrollback, but is the proposal to request stable tree folks to only cherry-pick things that have Cc: stable? If so, I think we can do that.. (fyi lumag, abhinav__)
<sima>
robclark, it's more about whether we want to because autosel causes to much pain
<sima>
but maybe we can reduce the autosel pain first a bit, seems to have some obvious bugs
kzd has joined #dri-devel
<robclark>
I generally have an idea of what I want backported, and make sure they get Fixes tag.. but I can add Cc stable as well... I think I'd prefer not having random things cherrypicked
kaiwenjon has joined #dri-devel
<bl4ckb0ne>
is there a way to query the GL/GLES versions offered by EGL? Or at least the maximum version?
<alyssa>
(i'm not even touching most of the call sites -- the generated code literally matches the function signature we had before in 2/3 of the cases there =D)
<dcbaker>
alyssa: yes, the program is a dependency of the custom target
<alyssa>
awesome thx
<dcbaker>
I’m eating breakfast, but I’ll come have a better look in a couple at my computer. Phone is not a good review tool :D
JRepin has quit []
JRepin has joined #dri-devel
cgbowman has joined #dri-devel
<alyssa>
real
NiGaR has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
oneforall2 has joined #dri-devel
iive has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<dcbaker>
alyssa: you have my r-b for the "drop trivial depends"
<karolherbst>
that reminds me.. I need to look into this scratch issue...
karenw has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Read error: Connection reset by peer]
<dcbaker>
alyssa: I left your a few comments on the other one. Once the Meson 1.8 window opens I have some work to make copying custom_targets less awful that needs to get done...
coldfeet has joined #dri-devel
haaninjo has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
<alyssa>
dcbaker: thanks! squashed into !33099
<jenatali>
alyssa: Going to trigger MSVC builds on your MR just to confirm it plays nicely
<jenatali>
Overall looks pretty good. Didn't review the bindgen commit itself (yet) though
<alyssa>
thanks!
<alyssa>
bindgen commit should probably still be wip
<alyssa>
in particular it runs a complete random set of nir passes copypasted from the intel and asahi compilers
<alyssa>
need to figure out what we actually need
<alyssa>
next week problem
<jenatali>
This does raise the bar for building lavapipe on Windows since setting up mesa-clc is a pain right now, but that's probably fine
<dcbaker>
jenatali: is it just the well known set of of issues, or does Windows have issues that are separate from other OSes?
<jenatali>
"Installing" LLVM isn't really a thing on Windows
<jenatali>
It's either manually downloading it and configuring a bunch of paths, or else it's building it locally. Both of those are pretty miserable
LeviYun has quit [Ping timeout: 480 seconds]
<jenatali>
And I guess for mesa-clc it's actually linking against LLVM rather than calling out to Clang which rules out the downloading it aspect, it needs to be built, since it produces static libs and those aren't portable from one build environment to the next
<alyssa>
hopefully that one is solved this year
<jenatali>
That one?
<alyssa>
not using clang
<alyssa>
the binary one
<jenatali>
Ah right once the translator's obsolete we can just request a SPIR-V from binary clang, that'd be nice
<jenatali>
There's still the libclc aspect of it but that's more tractable I think
<alyssa>
meson 1.5 is in debian stable backports ..
<dcbaker>
I think 1.3 is required if you want any of the Rust drivers, so I think that would be fine? That's probably more of a distro maintainer question though
<dcbaker>
1.3 was November 2023
<alyssa>
i coulda sworn we just discussed this..
* dcbaker
realized today his first Meson commits went into Meson 0.40 way back in 2017...
* alyssa
just learned that jan 2024 was a year ago
<alyssa>
weird
<alyssa>
wonder when that happened
<dcbaker>
On April 1st
LeviYun has joined #dri-devel
<alyssa>
ah
fab_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
fab_ is now known as Guest6194
fab has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
haaninjo has joined #dri-devel
dviola has quit [Read error: Connection reset by peer]
diego has joined #dri-devel
NiGaR has quit [Ping timeout: 480 seconds]
JRepin has quit []
NiGaR has joined #dri-devel
JRepin has joined #dri-devel
LeviYun has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
NiGaR has quit [Remote host closed the connection]
NiGaR has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: alyssa]
Guest6194 has quit []
JRepin has quit []
JRepin has joined #dri-devel
pixelcluster has quit [Quit: Goodbye!]
pixelcluster has joined #dri-devel
oneforall2 has joined #dri-devel
LeviYun has joined #dri-devel
coldfeet has quit [Quit: Lost terminal]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
lemonesque has quit [Read error: Connection reset by peer]
yrlf has quit [Ping timeout: 480 seconds]
lemonesque has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
yrlf has joined #dri-devel
diego has quit []
dviola has joined #dri-devel
valpackett has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
LeviYun has joined #dri-devel
jkrzyszt has quit [Quit: Konversation terminated!]
edolnx_ has quit []
edolnx has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
nerdopolis has joined #dri-devel
kzd has quit [Quit: kzd]
sima has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
Hazematman has quit [Quit: WeeChat 4.5.1]
Hazematman has joined #dri-devel
Hazematman has quit []
mvlad has quit [Remote host closed the connection]
Hazematman has joined #dri-devel
<ccr>
cine
guludo has quit [Quit: WeeChat 4.5.1]
Hazematman has quit [Quit: WeeChat 4.5.1]
jhli has joined #dri-devel
KAL9000 has quit [Read error: Connection reset by peer]
KAL9000 has joined #dri-devel
smaeul has joined #dri-devel
smaeul_ has quit [Read error: Connection reset by peer]
LeviYun has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
feaneron has quit [Remote host closed the connection]