oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
glennk has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
tyalie has quit [Ping timeout: 480 seconds]
tyalie has joined #dri-devel
Duke`` has joined #dri-devel
dolphin has joined #dri-devel
jsa1 has joined #dri-devel
kode54 has quit [Read error: Connection reset by peer]
kode54 has joined #dri-devel
tzimmermann has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
fantom has joined #dri-devel
dantob has joined #dri-devel
<dj-death>
jnoorman: landing !34344 today? :)
kts has joined #dri-devel
asrivats_ has joined #dri-devel
Thymo has joined #dri-devel
kts has quit [Quit: Leaving]
asrivats_ has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
sima has joined #dri-devel
warpme has joined #dri-devel
<jnoorman>
dj-death: sorry about the delay. There are still some questions around how we want to handle SSBO offsets in ir3. So what I'll do is pull-out the reviewed NIR commits from !34344 and merge them separately to unblock you :)
<dj-death>
jnoorman: thanks!
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jfalempe has quit [Ping timeout: 480 seconds]
<karolherbst>
mareko: I noticed that radeonsi advertises support for sRGB image stores. Sadly I don't really know what's the expected behavior in OpenGL, but it doesn't match what OpenCL expects, and that is treating the values within the shader as RGB and doing implicit conversion into sRGB space on stores and the opposite for loads. Atm it seems like that
<karolherbst>
radeonsi advertises image support for everything it can texture from, so I wonder if that needs to change or not.
phasta has joined #dri-devel
cascardo_ has joined #dri-devel
bbrezillon has quit [Quit: WeeChat 4.6.3]
cascardo has quit [Ping timeout: 480 seconds]
pjakobsson has joined #dri-devel
<jnoorman>
dj-death: !35542
<dj-death>
jnoorman: thanks a bunch
<dj-death>
jnoorman: I'll probably have to add another callback for accept offsets, I guess drivers will choose what's more conveninent for them
kts has joined #dri-devel
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
rgallaispou has joined #dri-devel
bbrezillon has joined #dri-devel
lynxeye has joined #dri-devel
simon-perretta-img has joined #dri-devel
tyalie has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
tyalie has joined #dri-devel
tyalie has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
tyalie has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
JRepinc has quit []
JRepinc has joined #dri-devel
kode54 has quit [Read error: Connection reset by peer]
kode54 has joined #dri-devel
haaninjo has joined #dri-devel
dolphin is now known as Guest18232
dolphin has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
Guest18232 has quit [Ping timeout: 480 seconds]
<ccr>
tomba, you were spotted at Vanha ;)
<tomba>
ccr: Oh? Fellow batmudder? =)
tyalie has quit [Ping timeout: 480 seconds]
<ccr>
tomba, wizard for last 13+ years. I saw you chatting with Zin at the terrace :)
tyalie has joined #dri-devel
<tomba>
ccr: small world =)
<ccr>
sometimes it is
iokill has joined #dri-devel
iokill has quit []
iokill has joined #dri-devel
The_Company has quit []
Company has joined #dri-devel
tyalie has quit []
tyalie has joined #dri-devel
feaneron has joined #dri-devel
dantob has quit []
dantob has joined #dri-devel
dantob has quit []
rasterman has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
calico has joined #dri-devel
calico is now known as Guest18235
Guest18155 has quit [Ping timeout: 480 seconds]
cascardo_ is now known as cascardo
dantob has joined #dri-devel
nerdopolis has joined #dri-devel
guludo has joined #dri-devel
parthiban has joined #dri-devel
dantob has quit []
paulk-bis has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
normalpan has joined #dri-devel
warpme has quit []
JLP_ has joined #dri-devel
JLP has quit [Ping timeout: 480 seconds]
<jannau>
should there be a DEFINE_LOADER_DRM_ENTRYPOINT for each kmsro display driver? "apple" and "vkms" are missing compared to dril_drivers in src/gallium/targets/dril/meson.build
warpme has joined #dri-devel
<jannau>
not even sure if this related to the issue the alpine edge user sees with mesa 25.3.1. I looked into this since the users gets "apple supports no extensions (Symbol not found: __driDriverExtensions)"
JRepinc has quit []
JRepinc has joined #dri-devel
SanchayanMaity__ has quit []
OftenTimeConsuming is now known as Guest18243
OftenTimeConsuming has joined #dri-devel
Guest18243 has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Read error: Connection reset by peer]
<hch12907>
probably a silly question, but is the minimum required python version for building Mesa still 3.7?
vliaskov_ has quit [Ping timeout: 480 seconds]
asrivats_ has quit [Ping timeout: 480 seconds]
<hch12907>
would be nice to bump it to 3.9, so that functions like str.removeprefix and str.removesuffix can be used
Duke`` has joined #dri-devel
jkrzyszt_ has joined #dri-devel
phasta has quit [Quit: WeeChat 4.6.2]
dsimic is now known as Guest18251
dsimic has joined #dri-devel
Guest18251 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
kts has joined #dri-devel
vliaskov has joined #dri-devel
jkrzyszt_ has quit []
Jeremy_Rand_Talos has joined #dri-devel
bolson has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
rgallaispou has left #dri-devel [#dri-devel]
jkrzyszt_ has joined #dri-devel
epoch101_ has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
epoch101 has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<mareko>
karolherbst: I don't think our image stores support sRGB, and I don't think GL expects it to be supported
<mareko>
same for Vulkan
<karolherbst>
radv doesn't have that problem
<mareko>
what problem?
<karolherbst>
advertising support for sRGB storage images
<karolherbst>
radeonsi always sets "PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_SHADER_IMAGE" together
jsa1 has joined #dri-devel
<karolherbst>
or rather, both depend on the result of si_is_sampler_format_supported
<karolherbst>
so if I call into "is_format_supported" with sRGB and PIPE_BIND_SHADER_IMAGE it gets marked as supported
<karolherbst>
dunno if that's also an issue with OpenGL tbh, not entirely sure how it's checked there
<karolherbst>
anyway, the end result is, that radeonsi claims to support it for PIPE_BIND_SHADER_IMAGE
<mareko>
if there is a way to set the format to srgb in the image store instruction, radeonsi could insert the conversion code there
<mareko>
GL rejects SRGB as a shader image format
idr has joined #dri-devel
<alyssa>
mareko: we don't generally know the image format when storing though and it'd be a silly thing to emulate unconditionally
<mareko>
that's true, but I don't know about OpenCL
<mareko>
karolherbst: you can return false from si_is_format_supported if the format is sRGB and bind is a shader image
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
vliaskov has joined #dri-devel
paulk-bis has quit []
paulk has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<karolherbst>
mareko: in OpenCL you only know the data type, but not the format
<karolherbst>
and yeah.. returning false is what I had in mind
<karolherbst>
no idea what needs srgb write support, but it took me like 10 minutes to write the code and it works on the arm based drivers. Not sure about the reason they've added it, but...
jsa1 has joined #dri-devel
<alyssa>
karolherbst: because it's more work to disable it than not and if there are no CTS fails nobody notices
<karolherbst>
yeah.. the CTS not testing this was my assumption, didn't know it was invalid from a GL perspective
<zmike>
GL has a very specific list of formats allowed for storage images
<alyssa>
the mobile hw im familiar with can do sRGB image stores, I just don't know why you would
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
kts_ has quit []
<karolherbst>
apparently it was important enough that it was made mandatory for OpenCL 2.0 support :')
<karolherbst>
so if I ever want to default to OpenCL C 2.0 or 3.0 instead of 1.2, I have to support it 🙃 which isn't a great reason
<karolherbst>
but that also means there are probably applications out there not checking for the ext string, but just for the format and that's a pain to find
<DemiMarie>
I think figured out a way to make cross-VM syncobj work.
<DemiMarie>
robclark: in the guest you import something that references the host fences and insert them into the guest syncobj
vliaskov has quit [Ping timeout: 480 seconds]
<DemiMarie>
when submitting to the host, the guest extracts all of the fences from it
<DemiMarie>
then the host userspace searches for a host fence that corresponds to each of the guest fences it received
<DemiMarie>
if the guest userspace is well behaved, this will always exist. If not then the guest gets VK_ERROR_DEVICE_LOST.
<DemiMarie>
an alternative is to use "fake" (PV) syncobs
<DemiMarie>
guest userspace thinks it has a real syncobj backed by guest fences, but it really has a fake syncobj backed by host fences
<DemiMarie>
if you try to use the syncobj for anything that needs real (guest) fences, you get an error back
<DemiMarie>
but if you don't, and if you conform to the OpenGL/Vulkan specs you won't, you never know that the syncobj you got is not a real one
<DemiMarie>
the guest trusts that a host syncobj will signal promptly because it trusts the host, so it's okay for the guest to import a host syncobj
<DemiMarie>
s/syncobj/dma-fence/g obviously
<DemiMarie>
do you want to have a voice call about this at some point? maybe with alyssa?
<robclark>
I'm not entirely sure what you are trying to do.. but when a syncobj is submitted to the guest kernel, the guest fence should already exist (even if it's corresponding host fence doesn't).. that guest fence can be pushed to the host, by the time the host sees it the corresponding host fence already exists. That can be turned into a host syncobj if desired.
<DemiMarie>
you can submit a syncobj with no fences
<robclark>
drm does not allow that
<DemiMarie>
I meant submit via Wayland, not to the GPU
<DemiMarie>
this is for cross-VM Wayland
<robclark>
sure, but that should use a virtgpu cross_domain context, and all the same rules apply
<DemiMarie>
you can send a syncobj via SCM_RIGHTS without having any sync files in it
<jenatali>
karolherbst: There are so many things that are mandatory for 2.0 that were not good ideas
<DemiMarie>
virtgpu is just a transport here
<karolherbst>
jenatali: I know.. that's why I'm curious if anything even uses that one... but it's also trivial to support...
<DemiMarie>
robclark: a cross_domain context isn't a real GPU
<robclark>
re: SCM_RIGHTS, sure.. but that is only within the guest, and not where it gets passed to host
<DemiMarie>
you need something in the cross-domain API that isn't a dma_fence
<DemiMarie>
and has no analog in normal DRM uAPIs
<robclark>
what should happen is the wl proxy in guest calls virtgpu EXECBUF ioctl with the syncobj as arg
<DemiMarie>
and then the host needs to send a syncobj to the compositor
<robclark>
hmm, although I suppose the issue is you want to pass to host before the dma_fence exists.. I think what I'd suggest is the proxy should do drm ioctl to wait until syncobj is backed by dma_fence, similar to what vk drivers do
<DemiMarie>
robclark: that's a Wayland protocol violation I think
<DemiMarie>
the protocol explicitly makes that the responsibility of the host compositor
<DemiMarie>
what you could do is have something in virtgpu that is _not_ a dma_fence, but rather a collection of them
<DemiMarie>
and that collection is allowed to be empty
<DemiMarie>
yeah, what you are proposing is a protocol violation
<DemiMarie>
I believe guest userspace is allowed to send a syncobj that will never have a fence added to it, and Wayland requires that requests are processed in-order
<DemiMarie>
So what you are proposing would deadlock
<robclark>
I mean you might be able to do something with a fake timeline on the host side, but I don't think you know the ordering of the fence that will eventually correspond to the syncobj.. so I think my idea is still better. Either that or teach wl to use dma-fence again
<robclark>
DemiMarie: maybe another way to look at it would be to consider the guest wl proxy _as_ the wl compositor.. where the wait happens.. but it is just a kind of nested compositor that, after the wait, fwd's things to the host compositor
<DemiMarie>
you would find out the ordering by hooking ioctls on the syncobj
<DemiMarie>
robclark: my experience with Qubes is that you don't want to do that kind of stuff
<robclark>
but you need the fence to know the fence ctx
<DemiMarie>
fence ctx?
<DemiMarie>
can't you get that from the fence ioctls in the guest?
<DemiMarie>
or what about the fake syncobj idea?
<robclark>
the fence timeline/ordering
<DemiMarie>
the guest kernel knows every ioctl that happened to that syncobj
<DemiMarie>
and can forward it to the host
<robclark>
not without changes in drm core and to drm_syncobj.. currently fence is a driver thing, but syncobj is not
<robclark>
and guest kernel can't really wait for a host syncobj to be populated with a fence
<DemiMarie>
can that population happen for any reason other than the guest doing something?
<DemiMarie>
I guess what I am saying is that changes to core and drm_syncobj are needed
<DemiMarie>
alternatively, guest userspace can use a different driver for its syncobjs
<DemiMarie>
a PV implementation
<DemiMarie>
that accepts the same ioctls but forwards them to the host
<DemiMarie>
teaching Wayland to use fences won't happen
<robclark>
I'd try my idea first.. wl protocol didn't _need_ to be using syncobj instead of fences (and I still think it was a mistake).. we had an experimental proto w/ wl using fences (and android uses fences) with no problems
<DemiMarie>
you don't need to support nvidia proprietary
<DemiMarie>
that's the thing that led to syncobj
<DemiMarie>
desktop does need to support that driver, as much as it would be nice not to
<DemiMarie>
and nvidia proprietary requires syncobj
<DemiMarie>
the reason for that requirement is that without it you have no CUDA and CUDA has no good open-source alternatives in many ecosystems
alanc has quit [Remote host closed the connection]
<robclark>
how are you going to use cuda in a guest?
alanc has joined #dri-devel
<DemiMarie>
the broader Wayland ecosystem needs to support nvidia proprietary
<DemiMarie>
and in the non-virtualized case, syncobj is strictly better
<DemiMarie>
so you would need to convince compositors to support a protocol that is only needed for virt
<DemiMarie>
also, there is an nvidia ioctl proxy that might be used for cuda
<airlied>
karolherbst: didn't CL3.0 back it out of being mandatory, nobody should be advertising CL 2.0
<DemiMarie>
telling people to go from syncobj to sync file means telling them to drop support for Nvidia proprietary and that won't fly
<robclark>
strictly better has been asserted many times, but in handwavey ways.. anyways, do the wait in the guest wl proxy to get something working. That way if we actually do need something else there is some evidence to back up the claim and reason to spread this mess into guest drm_syncobj
<robclark>
protocol could support either
<DemiMarie>
I think nvidia proprietary never creates an unsignaled fence
YuGiOhJCJ has joined #dri-devel
<robclark>
anyways, if you do the wait for the guest syncobj to be populated in the guest wl proxy, then the fence can be turned back into a syncobj on the host and no wl compositors are hurt in the process
<DemiMarie>
the problem is that you are reordering Wayland requests or potentially deadlocking
sima has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
<robclark>
thread per client to do the waits wouldn't deadlock.. and would be equiv to doing the wait on the app side
* robclark
bbiab
OftenTimeConsuming has joined #dri-devel
sima has joined #dri-devel
epoch101_ has quit []
parthiban has quit [Remote host closed the connection]
parthiban has joined #dri-devel
fab has joined #dri-devel
iive has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Calandracas has joined #dri-devel
yogesh_m1 has quit [Ping timeout: 480 seconds]
yogesh_m1 has joined #dri-devel
<DemiMarie>
robclark:
<DemiMarie>
it isn't that the wait deadlocks
<DemiMarie>
the client is allowed to send another request, wait for the reply, and only then add a fence
<DemiMarie>
so if you don't send the subsequent request until the fence had a syncobj, the client is blocked forever
<DemiMarie>
the only way to avoid deadlocks would be to reorder requests, but Wayland doesn't allow that at all
sima has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<robclark>
but the wl proxy in the guest is the compositor.. it's just a rootless nested compositor
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]