ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
kzd_ has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
kzd_ has quit [Ping timeout: 480 seconds]
krushia has joined #dri-devel
kzd has joined #dri-devel
kzd_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
The_Company has quit []
<llyyr>
is there any movement towards solving #11383? mpv switched to using vulkan by default as of the last release, and we constantly get bug reports about mpv taking ages to start up now because on multigpu systems enumerating vulkan devices has to wait for slept devices to wake up
<llyyr>
note that the issue specifies nvk but it's a problem for every vulkan driver in mesa and outside mesa (nvidia)
sally has quit []
vimproved has quit [Remote host closed the connection]
vimproved has joined #dri-devel
sally has joined #dri-devel
rcf has quit [Remote host closed the connection]
feaneron has quit [Ping timeout: 480 seconds]
rcf has joined #dri-devel
<bluetail>
llyyr what can I do reproduce? I got https://0x0.st/8GZp.txt but got none of the issue you are mentioning
Swung0x48 has quit [Remote host closed the connection]
Swung0x48 has joined #dri-devel
Swung0x48 has quit [Remote host closed the connection]
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
<karolherbst>
mareko: is there anything I can do in rusticl to speed up data uploads to the GPU? Or things I need to consider like what flags are important to get optimal speed
<karolherbst>
I have a couple of tests which run for minutes and spend like 50% of the CPU time uploading/downloading VRAM, so would be nice to figure out how to speed things up if there are simple ways
warpme has quit []
kzd_ has quit [Ping timeout: 480 seconds]
<mareko>
karolherbst: AMD_DEBUG=info glxgears; print the theoretical PCIe bandwidth
<mareko>
karolherbst: AMD_TEST=dmaperf glxgears; tests the real bandwidth available to copies
<mareko>
don't access VRAM with the CPU, use staging allocations and do copies unless it's an APU
<mareko>
the roundtrip VRAM latency is insane from the CPU
Calandracas__ has joined #dri-devel
glennk has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
<mareko>
the GPU can hide the latency because it can request lots of data at once and then just waits for everything to arrive at maximum available throughput
<karolherbst>
okay, that might be helpful. The thing that I saw in perf profiles is mostly just the CPU spending time in memcpy
Calandracas_ has quit [Ping timeout: 480 seconds]
<karolherbst>
but yeah.. I was considering doing more staging copy things, but not sure yet how to go about it, not even sure it's the issue here
<karolherbst>
mareko: I was wondering if I could let the GPU write to a userptr allocation and if that would be any faster overall
<mareko>
PIPE_USAGE_STAGING if you're gonna read it by the CPU, PIPE_USAGE_STREAM if you're never gonna read it; allocate a temp buffer, do memcpy into it, then do resource_copy_region to upload it, then release the temp buffer; similar for downloads
<mareko>
PIPE_USAGE_STAGING enables CPU caching, the GPU has to go through the CPU cache for all access; PIPE_USAGE_STREAM is uncached for CPU reads, write-combined for CPU writes, the GPU skips the CPU cache and accesses RAM directly
<mareko>
STAGING is best for any random access and reads, STREAM might be better for sequential writes only
<karolherbst>
I use PIPE_USAGE_STAGING when the application requests fast CPU access atm
<karolherbst>
but it doesn't really matter here, because all the data is only used once anyway in thoes tests
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<karolherbst>
for writes I just use subdata and trust it to do the right thing
<mareko>
yes that should do the right thing
<karolherbst>
though as I mentioned above, I was considering to do a userptr (resource_from_user) allocation instead and let the GPU copy from userptr -> VRAM
<karolherbst>
"PIPE_USAGE_STREAM" is useful when the CPU only uploads once and never touches it ever again, right?
<mareko>
not necessarily, it just has to be sequential write-only access
<mareko>
you can try STAGING though
<karolherbst>
yeah.. doesn't make much of a difference
<karolherbst>
it's a test testing image copies for all sorts of formats, so it's uploading/download a lot of data
<karolherbst>
so not sure if caching matters that much there
<karolherbst>
there are a couple of "CL_MEM_HOST_*" flags I don't make use of yet.. so maybe I should look into this as well
<karolherbst>
anyway yeah.. will play around with doing the copies on the GPU side, because I wanted to do that to get rid of stalls that way anyway. Maybe this also speeds up transfers which would be great
YuGiOhJCJ has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has joined #dri-devel
apinheiro has joined #dri-devel
travltux[m] has joined #dri-devel
kts has joined #dri-devel
YuGiOhJCJ has quit []
kasper93 has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
coldfeet has joined #dri-devel
kasper93 has joined #dri-devel
dsimic is now known as Guest21461
dsimic has joined #dri-devel
Guest21461 has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
K900 has quit [Remote host closed the connection]
jsa1 has joined #dri-devel
Kwiboo- has quit []
K900 has joined #dri-devel
Kwiboo has joined #dri-devel
davispuh has joined #dri-devel
libv has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
kts has joined #dri-devel
vliaskov has joined #dri-devel
jsa1 has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
feaneron has joined #dri-devel
cadperle^ has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Sid127 has joined #dri-devel
caitcatdev has joined #dri-devel
epoch101 has joined #dri-devel
warpme has joined #dri-devel
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
fab has quit [Quit: fab]
warpme has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
warpme has joined #dri-devel
sarnex has quit []
warpme is now known as Guest21466
sarnex has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
Guest21466 has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
warpme is now known as Guest21468
Guest21468 has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
epoch101 has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
<karolherbst>
this might be a weird question, but how can I create a pipe_fence_handle without pipe_screen::flush
Sid127 has quit [Ping timeout: 480 seconds]
caitcatdev has quit [Ping timeout: 480 seconds]
<jenatali>
To do what with?
<karolherbst>
cl_khr_semaphore
<karolherbst>
basically want to create a fence that only gets signalled through fence_server_signal
<jenatali>
You want an external fence then
epoch101 has quit []
<jenatali>
create_fence_fd / create_fence_win32
<jenatali>
I don't know why the fd one is on a context and not the screen...
<karolherbst>
but I don't necessarily have an fd, nor do I really want to create one
<karolherbst>
I think I'll have to change gallium there anyway, because I also need to deal with payloads and be able to query those
epoch101 has joined #dri-devel
<karolherbst>
just trying to figure out what's there already and what's not