ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nopjmp_ has quit []
nopjmp has joined #dri-devel
ity has joined #dri-devel
mbrost has joined #dri-devel
iive has quit [Quit: They came for me...]
nerdopolis has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
luc has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
LeviYun has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
alane has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mwk has quit [Remote host closed the connection]
mwk has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
krushia has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
luc has quit []
nopjmp has quit []
nopjmp has joined #dri-devel
LeviYun has joined #dri-devel
Stary has joined #dri-devel
<Lynne>
any way of updating descriptors for buffers via an vkdeviceaddress instead of vkbuffer+offset when using peasant-tier descriptor pools?
LeviYun has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
The_Company has quit []
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
Duke`` has joined #dri-devel
coldfeet has joined #dri-devel
luc has joined #dri-devel
karenw has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
LeviYun has joined #dri-devel
paulk has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<glehmann>
Lynne: no, that only works with descriptor buffers. You can always use BDA instead of buffer descriptors in your shaders though, if you don't need robustness (bounds checking)
<Lynne>
you don't get robustness or any sort of validation with descriptor buffer storage buffers
LeviYun has joined #dri-devel
yogesh_mohan has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
triplea has joined #dri-devel
warpme has joined #dri-devel
_xav_ has joined #dri-devel
LeviYun has joined #dri-devel
vliaskov_ has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
tobiasjakobi has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
triplea has quit [Remote host closed the connection]
triplea has joined #dri-devel
LeviYun has joined #dri-devel
fab has joined #dri-devel
kts has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
chripyVagrancy has joined #dri-devel
LeviYun has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
triplea has quit [Remote host closed the connection]
triplea has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
guru_ has joined #dri-devel
triplea has quit [Remote host closed the connection]
triplea has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
flom84 has joined #dri-devel
LeviYun has joined #dri-devel
flom84 has quit []
Haaninjo has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
LeviYun has joined #dri-devel
triplea has quit [Remote host closed the connection]
triplea has quit [Remote host closed the connection]
triplea has joined #dri-devel
LeviYun has joined #dri-devel
triplea_ has joined #dri-devel
triplea has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
BesterGester8 has joined #dri-devel
LeviYun has joined #dri-devel
nerdopolis has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
LeviYun has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
triplea__ has joined #dri-devel
LeviYun has joined #dri-devel
triplea_ has quit [Ping timeout: 480 seconds]
DottorLeo has joined #dri-devel
wens has quit [Read error: Connection reset by peer]
LeviYun has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
<DottorLeo>
hi karolherbst, i've seen your MR about enabling by default some drivers for rusticl. I'm curious about what drivers could be enabled by defaults, are there any candidates for 24.1 :) ?
<karolherbst>
it's mostly for future versions and it's mostly up to the driver maintainers
<DottorLeo>
thanks. I was curious because i have an RDNA2 card and i'd like to toy a bit with rusticl on some opencl applications
<karolherbst>
you can already do that
<DottorLeo>
i also see that you have a radeon card for testing, mind if i ask what gpu do you have?
<karolherbst>
this MR is not about enabling rusticl for certain drivers, just for what devices it's enabled by default at runtime
krushia has joined #dri-devel
<karolherbst>
so with RUSTICL_ENABLE=radeonsi you can already test it on yours
<karolherbst>
and my AMD GPU is RDNA2 as well
<DottorLeo>
nice :D
<karolherbst>
though you won't have a lot of fun with 24.1 I think
<karolherbst>
not sure the critical fixes arrived in time for that release
<DottorLeo>
could you be interested in bug report about rusticl on GFX9 and maybe older?
wens has joined #dri-devel
<DottorLeo>
i'll try to use that variable, thanks!
<karolherbst>
sure, just make sure you check with a more recent mesa release
<karolherbst>
24.1 is already eol
<DottorLeo>
sorry 25.1 ^^"
<DottorLeo>
i mean future mesa release :D
<karolherbst>
24.2 would be good enough already
<K900>
There should be a 24.3 before 25.1
<DottorLeo>
yeah, waiting for Fedora to update to that
<K900>
It's not out yet
warpme has quit []
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
plutone has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
Company has quit [Remote host closed the connection]
tobiasjakobi has quit []
Company has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
<alyssa>
anyone seen dEQP-VK.spirv_assembly.instruction.graphics.float_controls.fp32.generated_args.denorm_nmax_nan_flush_to_zero_vert fail on x86_64?
<alyssa>
looks like the constant folding doesn't agree with CTS
<alyssa>
but radv&nvk advertise float controls..
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
DottorLeo has quit [Quit: Konversation terminated!]
<alyssa>
well, here's a nir bug. no clue how this worked before
<alyssa>
unless this is a FEX bug :clown:
imre has joined #dri-devel
<chripyVagrancy>
I don't know if that works for what you do, but you could test with box64 instead of FEX and see if that yields the same result.
davispuh has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<alyssa>
I have an x86 build box :)
triplea has joined #dri-devel
triplea__ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
sravn has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
<robclark>
lina: tu passes all BOs for residency (we don't yet have vm_bind), not for sync.. implicit and explicit sync works btwn processes and across vm boundary with fences.. it's all dma_fence under the hood for any kind of sync
<robclark>
even syncobj is dma_fence
<alyssa>
FEX bug!
* alyssa
writes patch
<HdkR>
\o/
<chripyVagrancy>
cool stuff
<chripyVagrancy>
(was talking about https://box86.org/ in case that wasn't clear)
LeviYun has joined #dri-devel
luc has joined #dri-devel
<HdkR>
I would love to see CTS runs on FEX versus Box64, but that's also a lot of effort :P
dsimic is now known as Guest4220
dsimic has joined #dri-devel
Guest4220 has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
warpme has quit []
imre has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
tobiasjakobi has joined #dri-devel
<lina>
robclark: If MSM_SUBMIT_BO_NO_IMPLICIT is not set on a BO, the kernel driver will handle implicit sync at the kernel level as long as the global MSM_SUBMIT_NO_IMPLICIT is not set (see msm_gem_submit.c). tu never sets the former and only sets the latter if all BOs are internal, which means that the kernel driver is handling implicit sync for tu, at
<lina>
least for in syncs.
tobiasjakobi has quit []
<lina>
Ah, and submit_attach_object_fences handles out sync unconditionally.
riteo_ has joined #dri-devel
<robclark>
lina: tu could probably be more clever and figure out which BOs need implicit sync.. or if it wanted to require a newer kernel could attach dma fence fd to shared dmabufs.. but it needs to do _some_ sync related to residency (so we don't unpin in-use BOs)
<robclark>
if you want to do implicit sync in userspace use the dmabuf ioctl to attach fence fd
<lina>
Which doesn't work across the VM barrier.
<lina>
Which is exactly my problem.
<robclark>
ofc it does
<lina>
How would it? the dmabuf ioctls only apply in the guest, they don't touch fences in the host
<robclark>
if it is a host fence, it is pushed back down to the host (if the ctx-type supports it)
<lina>
How?
heat has quit [Remote host closed the connection]
<lina>
Am I missing some mechanism here for dma-buf fence sync across virtgpu?
LeviYun has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<robclark>
virtgpu should fish out the fence from the dma_resv (at least assuming someone implemented implicit sync support in virtgpu)
epoch101 has joined #dri-devel
<robclark>
it's all just dma_fence in the end
<robclark>
and if it is a host fence the wait can be pushed down to the host instead of waiting in the guest
<lina>
How would that even work? The dma-buf ioctl code is generic and knows nothing about virtgpu. If you put a fence in a buffer in the guest then there is no codepath to somehow sync that back to the host.
epoch101 has quit []
<robclark>
the fence is tracked in the dma_resv
<lina>
Yes, in the guest... not the host
<robclark>
right, but to pass it to the host goes thru virtgpu
<lina>
There is no codepath to do that as far as I can tell.
sassefa has quit [Ping timeout: 480 seconds]
<robclark>
for shared buffers it should be attached to the virtgpu EXECBUF ioctl
<robclark>
(for implicit)
<robclark>
or you can use the dmabuf ioctl to pull the dma_fence fd back out
sassefa has joined #dri-devel
sassefa has quit []
<lina>
Where?
<lina>
The virtgpu code on the guest kernel side adds the guest-side virtgpu fence into objects passed into the exbuf, nothing more (which is useless for me since that's the thing mesa already does manually for implicit sync on the guest side)
warpme has joined #dri-devel
triplea has quit [Read error: Connection reset by peer]
<robclark>
virtgpu guest kmd extracts all the fences, if they are guest fences it does guest side wait, if they are host fences they are passed back to the host
<DemiMarie>
robclark: host fences are waited on the CPU which is too slow
<lina>
*All* fences are waited on the CPU except those from the same queue.
<lina>
And again this does nothing to pass fences down to BOs on the host side
<robclark>
host fences are passed back to host
<robclark>
it turns into explicit sync on the host side
<lina>
I spent the past two days reading this code and have not found any code that does that...
<DemiMarie>
Could syncobjs be made first class citizens in the protocol, just like BOs are?
<robclark>
no
<DemiMarie>
Why?
<robclark>
syncobjs are only UMD syntax sugar
<robclark>
it is all dma_fence under the hood
<robclark>
lina, I'll walk you thru it next week
<DemiMarie>
I meant host syncobjs in the form of file descriptors.
<lina>
There are zero hits for DMA_BUF_IOCTL_IMPORT_SYNC_FILE in virglrenderer, how could it possibly be doing implicit sync properly...
<robclark>
DemiMarie: fd's don't exist across vm boundary.. and drm_syncobj isn't something that a driver can have a custom impl of.. but it is unneeded, it's _all just dma_fence_
<robclark>
lina: it isn't needed
<robclark>
lina: I'll walk you thru it next week
<DemiMarie>
robclark: doesn't the guest need to be able to perform operations on host syncobjs to make the Wayland syncobj protocol work?
<robclark>
don't use wl syncobj proto
<lina>
I'm literally looking at virtgpu_fence.c and virtgpu_submit.c and the only code here is to handle virtgpu guest fences (which are always signaled by the host), nothing at all about host fences and nothing to somehow pass fences down to the host in any way.
<DemiMarie>
There is literally no other non-deprecated option for Wayland explicit sync
plutone has quit [Remote host closed the connection]
<robclark>
well, turn it back into syncobj on the host side
<kisak>
colinmarc: the last scheduled point release for 24.1 has passed.
plutones has joined #dri-devel
<robclark>
wl syncobj was probably a mistake but it should be possible to work around
<lina>
robclark: If you don't use the syncobj proto (so you use implicit sync) then you *need* to insert fences into buffers for it to work (implicit sync) and for that on the guest side you need those dmabuf ioctls and they literally are never mentioned in the virglrenderer code. This simply cannot work without host-side implicit sync, which is the case
<lina>
for tu/msm right now as I just confirmed.
<DemiMarie>
robclark: how is one supposed to do that?
coldfeet has quit [Quit: leaving]
<robclark>
lina: probably ryan would be better positioned to explain the wl part since he was working on wl cross-domain
<DemiMarie>
Asahi does not support implicit sync at the kernel level at all.
<robclark>
then asahi is holding it wrong
<robclark>
it is literally impossible to support implicit sync across drivers entirely in userspace
<lina>
???
<DemiMarie>
For Vulkan one should not be using kernel implicit sync even if the driver supports it.
<lina>
Of course it is, you just take the syncobjs and import/export them from buffers, it's what our gallium driver does to emulate implicit sync and it's what the vulkan common WSI code does.
<lina>
DMA_BUF_IOCTL_IMPORT_SYNC_FILE as I mentioned
<lina>
If you read the MRs I linked, my stopgap fix for now was to literally do the same thing in virglrenderer to add implicit sync support to the virtio interface (only, not the native one)
<lina>
But that only works well for GL
<DemiMarie>
This is a problem with the virtio-GPU protocol. It needs to support cross-VM explicit sync with syncobjs.
<lina>
(Unless you do what tu/msm does which is apparently to implicit sync every single buffer... which can't possibly be fast)
<robclark>
DemiMarie: it is not about the UMD api
<DemiMarie>
robclark: Asahi simply does not need implicit sync across drivers.
<lina>
Implicit sync *works* across drivers and we *do* need it
<lina>
It works perfectly fine between our GPU driver and our display controller driver
<DemiMarie>
robclark: disregard what I said
<robclark>
DemiMarie: no, hw only supports fences, not syncobjs.. (in this case virtual hw).. syncobj is just fancy syntax on top of fences
<lina>
The syncobj is just a transport vehicle for a fence
<robclark>
right
<lina>
The explicit sync UAPI puts the fence in your syncobj, then you use the dma-buf API to transfer the fence to the relevant BOs, and the end result is the same as if the kernel had done it all in one go (implicit sync UAPI)
<robclark>
right
<lina>
And that works in the host, and it works in the guest within the guest, but it does not synchronize at all between host/guest.
<colinmarc>
kisak: thanks for the answer. how does that work with stable distros like ubuntu, will noble upgrade to 24.2?
<lina>
You put the fence in the BO in the guest and the host knows nothing about that fence.
<colinmarc>
my manjaro box doesn't have 24.2 either, but I guess it will soon
<robclark>
at one point in time virtgpu did not support implicit sync.. I believe someone was working on that.. defn you'd need virtgpu support for implicit sync, but that doesn't require anything new in terms of protocol or on the host side
<robclark>
guest side implicit sync becomes explicit sync on the host side
<lina>
Sigh... that simply does not work...
<lina>
If an implicit sync protocol puts a fence in a BO in the guest then you can't magically force the receiver side in the host to use explicit sync instead
<lina>
The host needs the fence in the BO too
<robclark>
I'll walk you thru it next week, we aren't getting anywhere here
<DemiMarie>
What is happening next week?
<lina>
I'll look forward to finding out about all this code that I can't find and which does not work with drm/asahi and which is clearly not needed for drm/msm since as I just confirmed it does implicit sync all in the kmd in the host...
<DemiMarie>
I think this needs to be handled in a conference call
<robclark>
I'll be back from vacation next week and in the office
<kisak>
Routine updates are at the discretion of the package maintainers for individual distros. Specific to Ubuntu, I don't agree with their policies and maintain a PPA to treat mesa devs as first class citizens, but that's a whole can of drama I don't feel like opening today.
<kisak>
colinmarc: ^
<DemiMarie>
robclark: next week as in September 23 or September 30?
<colinmarc>
kisak: apologies, I didn't know I was asking about drama :) just asking practically, it's unlikely for ubuntu noble to get 24.2, then?
<robclark>
well, this week if the week starts on Sun
<lina>
OK ^^
LeviYun has joined #dri-devel
sassefa has joined #dri-devel
<colinmarc>
kisak: only asking because I need to provide advice for users of my app on ubuntu and I'm a bit confused about how mesa bugfixes filter down
<colinmarc>
if that advice is "install mesa from a PPA", that's fine
<DemiMarie>
colinmarc: Can you ship your app as a Flatpak or Snap with bundled Mesa?
<colinmarc>
I don't currently, but maybe
<DemiMarie>
robclark: thank you.
<DemiMarie>
lina: did you see my response on GitLab?
<kisak>
For Ubuntu LTS, the non-LTS stack eventually gets backported from non-LTS, and separately there's an end-of-series bump for the previously mentioned backport. That makes 2 updates every 6 months.
<colinmarc>
Demi: can you relink the thread? I'm curious about this topic but it got buried above
<DemiMarie>
Colin Marc: Which topic?
<DemiMarie>
Mesa?
<colinmarc>
implicit/explicit sync over the virtio-gpu boundary
<DemiMarie>
It is all the recent conversation not part of your discussion.
<colinmarc>
Yeah, I know it's unrelated, I was just curious if there was a gitlab issue where I could read some background
<DemiMarie>
I don't want to use quote replies or Matrix threads because those do not translate to the IRC side well at all.
<DemiMarie>
Colin Marc: Can you work around the Mesa issue in your app?
<colinmarc>
Yeah, I'm going to do some gross runtime stuff and disable hierarchical coding based on the mesa version
<colinmarc>
It'll be fine :)
epoch101 has joined #dri-devel
<colinmarc>
I think I can even fetch the driver version via vulkan itself with some extension or another
<colinmarc>
The particularly mean bug that I would really like to backport limits GOP size to 32, though. Which is really rough for bitrate
<DemiMarie>
Can you backport the fix to Ubuntu’s version and send a patch there?
<colinmarc>
I don't think ubuntu maintains a separate version, they just... don't update
<DemiMarie>
I meant as a patch to be applied during Ubuntu package build.
<colinmarc>
I have a hard time imagining they'd accept that, given it's not a security issue or a crash and no one really cares about vulkan video yet :)
LeviYun has joined #dri-devel
coldfeet has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
kts has joined #dri-devel
mbrost has joined #dri-devel
nerdopolis has joined #dri-devel
chripyVagrancy has left #dri-devel [#dri-devel]
LeviYun has quit [Ping timeout: 480 seconds]
<lina>
DemiMarie: Replied ^^
<DemiMarie>
lina: thanks!
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
warpme has joined #dri-devel
warpme has quit []
luc has quit []
LeviYun has joined #dri-devel
Peuc has quit [Quit: Peuc]
LeviYun has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
sassefa has quit []
sassefa has joined #dri-devel
LeviYun has joined #dri-devel
sassefa has quit []
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
testaccount has joined #dri-devel
testaccount has quit []
mbrost has joined #dri-devel
testaccount has joined #dri-devel
kts has quit [Quit: Leaving]
testaccount has quit []
testaccount has joined #dri-devel
testaccount has quit []
LeviYun has joined #dri-devel
glennk has quit [Remote host closed the connection]
LeviYun has quit [Remote host closed the connection]