<kode54>
vkoverhead still locks up my GPU if I use the Xe KMD
<kode54>
right when it gets to the descriptor portion of the test
aravind has joined #dri-devel
robobub_ has joined #dri-devel
robobub_ has quit []
<karolherbst>
Kayden: sooner or later I'll probably need an API to force a certain SIMD mode, because Intel has some subgroup extensions for that kinda stuff
ngcortes has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
kzd has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
elongbug has quit [Quit: Leaving]
kzd has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
<karolherbst>
OpTypeInt 24 0 🙃 I know what you are all thinking, and I agree: this is invalid SPIR-V
rasterman has joined #dri-devel
Company has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
lemonzest has joined #dri-devel
sima has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
aravind has quit []
JohnnyonFlame has joined #dri-devel
pekkari has joined #dri-devel
Cyrinux9 has quit []
Cyrinux9 has joined #dri-devel
pekkari has quit []
pekkari has joined #dri-devel
pekkari has quit []
pekkari has joined #dri-devel
pekkari has quit [Read error: Connection reset by peer]
pekkari has joined #dri-devel
pekkari has quit [Read error: Connection reset by peer]
deathmist1 has quit [Remote host closed the connection]
deathmist1 has joined #dri-devel
mmx_in_orbit__ has quit []
Danct12 has joined #dri-devel
ccr has quit [Quit: Lost terminal]
sravn has quit [Quit: WeeChat 3.5]
ccr has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
djbw_ has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
ds` has quit [Quit: ...]
ds` has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
kts has joined #dri-devel
gouchi has quit [Remote host closed the connection]
i-garrison has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
Duke`` has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
smiles_1111 has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
Danct12 has joined #dri-devel
dfip^ has quit [Ping timeout: 480 seconds]
Kayden has quit [Read error: Connection reset by peer]
sravn has joined #dri-devel
<doras>
I'm trying to figure out why calls to glGetQueryObjecti64v with GL_QUERY_RESULT take ~9 milliseconds to return. They are called using objects created with glQueryCounter and GL_TIMESTAMP.
<doras>
I couldn't quite figure out where this is implemented in Mesa. I found the Gallium interface, but it wasn't clear how I can get to the actual implementation from there.
bmodem has joined #dri-devel
<zmike>
it goes through the query interface as PIPE_QUERY_TIMESTAMP
<Andrew-R>
karolherbst, oh, cool, llvmpipe/rusticl now report more realistic numbers in clpeak! :)
fab has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<karolherbst>
Andrew-R: huh... I didn't fix anything there :D
<doras>
Thanks zmike. Tracing this issue with eBFP suggests that the entire time is spent inside an ioctl. Now I need to figure out which and what it does...
<doras>
This is with radeonsi, by the way.
kts has joined #dri-devel
Haaninjo has joined #dri-devel
<doras>
Seems to be amdgpu_cs_wait_ioctl. Hmmm...
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
fab has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
<doras>
For context, this is called from Mutter's page flip event callback in a direct scanout scenario (client buffer was imported). The object for which the timestamp is queried is the client's EGLImage which was just flipped successfully. Any waiting for fences on this buffer was supposed to be done before flipping as far as I know. I'd expect the buffer to be idle at this point, so there shouldn't be any waiting required.
bmodem1 has joined #dri-devel
bmodem1 has quit []
bmodem has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #dri-devel
Leopold has quit [synthon.oftc.net graviton.oftc.net]
Leopold has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
pcercuei has joined #dri-devel
Kayden has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
CATS has joined #dri-devel
AndroUser2 has quit [Ping timeout: 480 seconds]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #dri-devel
djbw_ has joined #dri-devel
<doras>
I guess glGetQueryObjecti64v records all calls to GL functions, not just those done in the context of the EGLImage. Though Mutter is not supposed to call any GL functions after the atomic commit when the query object is created and until getting a page flip event. The client likely does draw on a different buffer, so maybe we somehow end up waiting on its own work? It still sounds like an issue in amdgpu to me.
JohnnyonF has joined #dri-devel
fxkamd has quit []
fxkamd has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
junaid has quit [Quit: leaving]
junaid has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<doras>
Well, it doesn't look like Mutter and the client are accessing the same fences (at least directly), and it does look like radeonsi is doing a command submission on behalf of Mutter inside glGetQueryObjecti64 which creates a fence and immediately waits on it before returning.
<Andrew-R>
...reading karol's mastadon leaves me with feeling world might be much better place if developers stopped to chase tails of proprietary software and hardware. Like, just quit en masse and enjoy things you really enjoy ... I can live with xvesa.
melonai0 has joined #dri-devel
melonai has quit [Ping timeout: 480 seconds]
<karolherbst>
Kayden: seems like linux 6.3 has a _major_ i915 perf regression. Or it's the fedora38 builds.. or something.. in any case, my CPUs spend 80% of their time inside i915_active_acquire_preallocate_barrier
<karolherbst>
on 6.3
<karolherbst>
and I see the GPU being starved
<karolherbst>
still checking things out, so not 100% sure about this, but it's kinda looking like this
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
<karolherbst>
maybe I also messed something up.. dunno.. it's kinda weird