00:50karolherbst: mhh now I remember why I haven't implemented it with persistent mappings.. I need to get my head around how to fit this into rusts ownership model.. but I have an idea actually..
04:44karolherbst: robclark: pushed a new tree to "rusticl/profiling/good" which uses a persistent + coherent mapping. But on iris I sometimes get 0s as results and no idea why 🙃 wondering if things are better on freedreno. At least it does work with zink here...
14:23robclark: karolherbst: hmm, the first version had some problems with cts test_profiling when I left a cts run going overnight... should probably figure out what is going on there before worrying about making it faster
14:33mareko: rusticl could also target vulkan
14:37robclark: but then rusticl would have to live with the limits of vulkan..
14:37mareko: or limits of gallium
14:37robclark: limits of gallium are things we can change if they matter enough
14:38mareko: cl_khr_command_buffer is where VK would be needed
15:26karolherbst: yeah, I was considering targeting vulkan directly from time to time, shouldn't be too hard to do, because the most difficult bits are handling shaders. Not sure how feasible it would be to make nir to spirv a bit more generaal
15:33karolherbst: robclark: did you had a fail in execute_multipass?
15:36robclark: karolherbst: yes, ERROR: clGetEventProfilingInfo failed! (CL_PROFILING_INFO_NOT_AVAILABLE from /home/robclark/src/opencl/cts/OpenCL-CTS/test_conformance/profiling/execute_multipass.cpp:183)
15:36karolherbst: yeah.. that probably means it read "0" as the result
15:36karolherbst: I suspect something about synchronization or cache flushing is going on
15:36robclark: unless you have reason to believe your new branch fixed things, I'll look closer
15:37karolherbst: if anything, I suspect my branch to make that issue more visible
15:37robclark: need to double check, but the mapping will either be wirtecombine or cached-coherent.. but doesn't rule out flushing on gpu side
15:38robclark: haven't looked closer yet, still going thru other things and absorbing caffeine this morning ;-)
16:15pac85: https://media.discordapp.net/attachments/1139200387501531178/1472264823109718108/cornellgears.png?ex=6991f0f7&is=69909f77&hm=44a40886ddb1fdea07add1988567986aabaa2f3a76207389d12a51a6cb1423bc&=&format=webp&quality=lossless&width=805&height=805
17:28cheako: sghuge, all: Does anyone have tips for dx12 games? I just learned about vkd3d. ^^^ In reference to ivalice chronicles.
18:15cheako: How come I have so many versions of d3d12? https://pastebin.com/C0Eb8ryw
18:18zf: all dlls in steam get installed (well, symlinked actually) twice per prefix
18:18zf: once for each of 32-bit and 64-bit
18:24zf: twice per game, I mean
18:27robclark: karolherbst: yeah, looks like profiling fails are because res=0.. idk where waiting for result to be ready is, but that appears to be missing
18:27karolherbst: robclark: I'm kinda inclined to think this is more of a cross context problem, but not quite sure yet
18:28robclark: I wouldn't rule out some issue on driver side.. but curious if you can repro fails
18:28karolherbst: I see similar behavior on iris
18:28karolherbst: but zink seems fine
18:29karolherbst: but zink also reads on the CPU, soo...
18:29karolherbst: lp is fine, which isn't surprising either
18:30robclark: I *guess* there is a missing fence wait that waits on CPU (in either old or new path) was papering over
18:30karolherbst: compared to main my branch has like ~8% lower overhead in clpeak
18:30karolherbst: on lp that is
18:30robclark: not super concerned about overhead, as much as just letting the gpu and cpu work in parallel in the first place ;-)
18:31robclark: at least at this point
18:31karolherbst: yeah sure
18:31karolherbst: mhhh
18:31karolherbst: the thing is..
18:31karolherbst: there is a thread that waits on fences that are created after the event was processed. And only if that fence wait is completed, the event will put into CL_COMPLETE state
18:32karolherbst: and only then will the call succeed in reading a timestamp..
18:32karolherbst: but maybe the issue is somewhere else..
18:32robclark: hmm, status does seem to be CL_COMPLETE..
18:33karolherbst: yeah... it's a bit weird
18:33karolherbst: maybe the coherent mapping is not as coherent as I think it is
18:33karolherbst: but you mentioned you see the same issue with my previous version, that wasn't doing coherent mappings yet
18:33karolherbst: and was only mapping when reading it out
18:34robclark: right.. haven't tried new branch yet
18:34robclark: kinda juggling two different debugs on two branches atm
18:34karolherbst: but I was mapping on a different context than the get_query_result_resource was executed on
18:35karolherbst: so that doesn't change and is probably the reason of the issue
18:35karolherbst: do I need to barrier? but a coherent mapping _should_ fix that
18:35karolherbst: maybe
18:35karolherbst: but the barrier also wouldn't be needed with the old version
18:36karolherbst: let me write a gallium test app for this...
18:36robclark: Hmm, in my case I think mapping on a different ctx should be fine.. it's all just memory.. not like this is an image that needs untiling or anything
18:37karolherbst: yeah.. it's weird
18:37karolherbst: like on iris it's not a reliable fail, it just sometimes fails
18:37robclark: I wouldn't rule out the CPU seeing the fence write before the query hits memory.. but I _think_ that should be ok
18:37robclark: yeah, well, timing ;-)
18:37robclark: not 100% fail here either
18:39karolherbst: well execute_multipass seems pretty reliable tho
18:39karolherbst: at least with newest version
18:40karolherbst: anyway. let me write asimple demo app against gallium, should be way simpler to reason about it there
18:40robclark: sg
19:12karolherbst: robclark: uhm.. would it be a problem if I don't set PIPE_BIND_QUERY_BUFFER ...
19:13karolherbst: not sure if drivers care all that much about that one..
19:13karolherbst: just one thing that I've noticed
19:13karolherbst: ohh nvm, I actually set that one..
19:20robclark: there is a special hack for older gens (like a2xx/a3xx IIRC) that needs PIPE_BIND_QUERY_BUFFER.. but those can't do the _result variant of queries.. or rusticl in general
19:21robclark: err, _resource()
19:33karolherbst: robclark: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/c48b81584291ebeb0d05ac176a48be25c8e4e082
19:33karolherbst: sooo
19:33karolherbst: that doens't work on iris...
19:33karolherbst: and I'm not really seeing why not :)
19:33karolherbst: get_query_result_resource is 0 and get_query_result has a proper value
19:34karolherbst: it only makes sense if the fence doesn't impact queries
19:34karolherbst: aand if queries need a different sync promitive
19:36karolherbst: works fine on lp tho
19:37karolherbst: do I have to use PIPE_QUERY_WAIT with pipe_query_result_resource? mhh
19:39robclark: I think w/ qbo barriers are needed.. but in theory you shouldn't need anything if you are reading on the cpu after the fence is signaled (at least on freedreno).. hmm, but I guess I should double check that qbo tests are still passing on 8xx
19:41karolherbst: but also.. it's a timestamp, what's there to wait on on the GPU side...
19:41karolherbst: but using PIPE_QUERY_WAIT does make it work with iris...
19:41karolherbst: and afaik with get_query_result_resource it's not about a CPU side wiat
19:45robclark: right, usually qbo reads are from gpu but possibly a different stage
19:48cheako: sghuge: I found a version of vkd3d that fixed fft.
20:01robclark: karolherbst: hmm, PIPE_QUERY_WAIT forces cmdstream flush (submit ioctl).. which probably isn't what we want (but probably papers over issues)
20:01karolherbst: mhhh
20:01karolherbst: but I do flush in that test anyway...
20:05karolherbst: anyway, we should probably decide if the code there should give me a query result or not as it is right now
20:10robclark: I think I see a possible issue on my side.. we are probably copying from internal buffer to result rsc before the write lands to the internal buffer (at least for the end query)
20:12robclark: (oh, and get_query_result_resource() not implemented for a5xx... which I suppose could plausibly sorta do rusticl.. I guess if someone cared enough they could copy some code from a6xx, since it should work the same way)
20:14robclark: yeah, ok.. that was the issue
20:16robclark: yeah, fixes all the fails on a6xx and a8xx
20:17robclark: karolherbst: btw we should probably actually introduce PIPE_QUERY_TIMESTAMP_RAW documented to require pscreen->convert_timestamp()
20:17karolherbst: yeah...
20:18karolherbst: I was thinking the same, because intel already does some conversion, which isn't accurate tho
20:23karolherbst: anyway, it doesn't explain why it's broken with iris, tho could also be a driver bug
20:24karolherbst: mhhhh
20:26karolherbst: iris predicates the result?
20:27karolherbst: mhhh
20:29karolherbst: robclark: I have a theory: with GL you never see a timestamp query with get_query_result_resource and so it's likely broken everywhere?
20:31robclark: I think gl cts doesn't have very good coverage of it.. and in real life it is probably used mostly just for occlusion query
20:31robclark: there might be some piglit tests I fail since not converting from ticks to ns
20:32robclark: (some day I might get a pm4 pkt to do the conversion.. but that doesn't exist today)
20:32karolherbst: yeah.. or that
20:33karolherbst: robclark: I'm not a _bug_ fan of adding another query type given how drivers have their code paths for all the queries, maybe we should just add `PIPE_QUERY_RAW_VALUE` to pipe_query_flags
20:34karolherbst: tho also that can have messy semantics with other queries...
20:35robclark: I was kinda thinking rusticl tries PIPE_QUERY_TIMESTAMP_RAW and then falls back to PIPE_QUERY_TIMESTAMP so we don't have to implement the new query everywhere
20:36robclark: then we just add the new query for the drivers that benefit
20:36karolherbst: mhh that might work...
20:37robclark: it would make sense to be part of the patch that introduces convert_timestamp().. I'll type that up later
20:37karolherbst: okay, cool
21:34karolherbst: yeah.. looks like with iris 25% of the CPU time spent is on creating the resource for the events mhh..
21:35karolherbst: 90% of the ndrangekernel call... oops
21:36karolherbst: util_vma_heap_alloc apparently is quite expensive
21:36karolherbst: I have an idea...
21:38karolherbst: I could just create 0x1000 sized buffers and run through them from start to end and then just throw them away and allocate new ones. No need for anything more comple
21:38karolherbst: per queue
21:46karolherbst: or I use the stream uploader...
21:47karolherbst: ehh probs not
21:51robclark: yeah, suballoc from a page size buffer if you can
21:52robclark: that will lower cpu overhead for driver