<pepp>
zmike: r-b (I took a look earlier but forgot to add a comment)
<zmike>
pepp: great, thanks!
MajorBiscuit has joined #dri-devel
<bnieuwenhuizen>
anholt: the common WSI code now has stuff to do things on newer kernels (see wsi_dma_buf_export_sync_file / wsi_dma_buf_import_sync_file in wsi_common_drm.c)
<bnieuwenhuizen>
if you use that + DMA_RESV_USAGE_BOOKKEEP in the kernel for submissions you should be good I think
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
bgs has quit [Remote host closed the connection]
srslypascal is now known as Guest2959
srslypascal has joined #dri-devel
Guest2959 has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #dri-devel
agners has joined #dri-devel
Guest2847 is now known as frytaped
fahien has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
khfeng has quit [Quit: Konversation terminated!]
khfeng has joined #dri-devel
rasterman has joined #dri-devel
<turol>
it would be nice if radv KHR_pipeline_executable_properties told me which of VGPR/SGPR/LDS was capping my max waves
fab has quit [Quit: fab]
kts has quit [Quit: Leaving]
Haaninjo has joined #dri-devel
sdutt has joined #dri-devel
macromorgan has joined #dri-devel
fahien has joined #dri-devel
kts has joined #dri-devel
fab has joined #dri-devel
fxkamd has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
anshuma1 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
linkmauve has left #dri-devel [#dri-devel]
Duke`` has joined #dri-devel
anshuma1 has quit []
anshuma1 has joined #dri-devel
djbw has joined #dri-devel
LexSfX has quit []
illwieckz has quit [Read error: Connection reset by peer]
sdutt has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
chipxxx has quit [Read error: Connection reset by peer]
anshuma1 has quit []
illwieckz has joined #dri-devel
linkmauve has joined #dri-devel
LexSfX has joined #dri-devel
ybogdano has joined #dri-devel
Danct12 has joined #dri-devel
mbrost has joined #dri-devel
frieder has quit [Remote host closed the connection]
rkanwal has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
jhli has quit [Remote host closed the connection]
Major_Biscuit has quit [Ping timeout: 480 seconds]
<anholt>
bnieuwenhuizen: so, we have a flag to (sort of) disable the implicit sync before the job gets submitted, on all BOs. With the current common code, is there anything that helps me set that flag?
<bnieuwenhuizen>
anholt: wdym? submit ioctl is entirely in your court still, no?
<anholt>
bnieuwenhuizen: so, I think you were saying that common code can use new kernel bits to set up an incoming sync that waits appopriately. however, I didn't see how it's flagged to my driver's submit that that's been done so I could turn off the implicit sync.
<bnieuwenhuizen>
ah right
<bnieuwenhuizen>
I actually dunno if there is. The WSI code just tries it and uses it if the ioctls exist
<bnieuwenhuizen>
jekstrand: ^
<anholt>
yeah. so I was trying to piece together why that wsi code exists, if the drivers can't use that code's conditional execution to conditionally disable their implicit sync.
<anholt>
but then, there's also this anv/dzn sync-from-a-bo path too.
<bnieuwenhuizen>
on AMD we were kinda planning to rely on some later bits landing in the kernel being sufficient
<anholt>
so I watched your talk, and read jekstrand's blog, and tried to read the code, and I'm just utterly lost.
<bnieuwenhuizen>
ok, so if you can put your implicit sync code in create_sync_for_memory (for wait) and struct wsi_memory_signal_submit_info (for signal) then you're good, the WSI will automatically skip that
<bnieuwenhuizen>
otherwise we're missing a bit that tells you if it is enabled ... Could probably just check for the existence of the ioctl
<jenatali>
anholt: The dzn code was copy/pasted and doesn't work, WDDM doesn't work like that. I need to rework it at some point
<anholt>
bnieuwenhuizen: sorry, that doesn't make sense to me. all I have is a flag on my submit ioctl to skip implicit sync. are you saying I would also need to come up with a create_sync_for_memory like anv? I thought the new ioctls should mean you don't need to make a sync from a bo.
<bnieuwenhuizen>
anholt: for legacy kernels
<anholt>
ah, ok. I don't think it's worth the complexity for those for tu.
<bnieuwenhuizen>
for non legacy kernels, you can basically go "does the DMA_BUF_IOCTL_EXPORT_SYNC_FILE_WSI ioctl exist for a random dmabuf, if yes disable implicit sync"
<bnieuwenhuizen>
getting a dmabuf is kinda annoying which is why the WSI doesn't tell you up front but just tries it where we have one
<bnieuwenhuizen>
probably should create a helper for that let me see
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
<bnieuwenhuizen>
anholt: I think this would be the check you're looking for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19062 If this returns true you can disable implicit sync on submissions. So call this on device creation, store the flag in your device and do the implicit sync disable if flag is set to true
ybogdano has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest2984
srslypascal has joined #dri-devel
Guest2984 has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
sarnex has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<jekstrand>
anholt: Yeah, the enabling is far from perfect. In ANV, it just silently disables the BO sync path.
<jekstrand>
anholt: I'd be happy for someone to give some serious thought to cleaning up some of those interfaces.
mbrost has quit [Ping timeout: 480 seconds]
chipxxx has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
mbrost has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
kts has quit [Quit: Leaving]
Lucretia has quit [Remote host closed the connection]
vliaskov has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
<marex>
ok, etnaviv doesn't support GL_RGBA32F , that's why the gles3 engine of STK won't work with hw skinning enabled
<airlied>
does it not support it at all or just not support it for linear filtering?
<marex>
airlied: for one thing, one has to explicitly enable gles3 support in etnaviv by exporting env variable
<marex>
its still work in progress
<marex>
and then, the GL_RGBA32F is only supported for vertex textures from what I can tell
alyssa has left #dri-devel [#dri-devel]
<airlied>
that suggest somes mipmapping wierdness
<marex>
airlied: well, lemme just add that to todo and for now stick to the GLES2 engine
<airlied>
marex: older x86 GPUs didn't have full GL_RGBA32F, I think classic drivers did RGBA16 fallbacks, now they just advertise support but like about linear filtering
<marex>
airlied: like they sampled the texture as R32G32F twice, and got R32G32B32A32 FLOAT out ?
<airlied>
nope the hw has RGBA32F but only in nearest filtering
<airlied>
falling back to RGBA16F is also acceptable though