On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand <jason@xxxxxxxxxxxxxx> wrote: > > On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay <programmerjake@xxxxxxxxx> wrote: > > > > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach <dev@xxxxxxxxxx> wrote: > > > > > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay: > > > > I think I found a userspace-accessible way to create sync_files and > > > > dma_fences that would fulfill the requirements: > > > > https://github.com/torvalds/linux/blob/master/drivers/dma-buf/sw_sync.c > > > > > > > > I'm just not sure if that's a good interface to use, since it appears > > > > to be designed only for debugging. Will have to check for additional > > > > requirements of signalling an error when the process that created the > > > > fence is killed. > > It is expressly only for debugging and testing. Exposing such an API > to userspace would break the finite time guarantees that are relied > upon to keep sync_file a secure API. Ok, I was figuring that was probably the case. > > > Something like that can certainly be lifted for general use if it makes > > > sense. But then with a software renderer I don't really see how fences > > > help you at all. With a software renderer you know exactly when the > > > frame is finished and you can just defer pushing it over to the next > > > pipeline element until that time. You won't gain any parallelism by > > > using fences as the CPU is busy doing the rendering and will not run > > > other stuff concurrently, right? > > > > There definitely may be other hardware and/or processes that can > > process some stuff concurrently with the main application, such as the > > compositor and or video encoding processes (for video capture). > > Additionally, from what I understand, sync_file is the standard way to > > export and import explicit synchronization between processes and > > between drivers on Linux, so it seems like a good idea to support it > > from an interoperability standpoint even if it turns out that there > > aren't any scheduling/timing benefits. > > There are different ways that one can handle interoperability, > however. One way is to try and make the software rasterizer look as > much like a GPU as possible: lots of threads to make things as > asynchronous as possible, "real" implementations of semaphores and > fences, etc. This is basically the route I've picked, though rather than making lots of native threads, I'm planning on having just one thread per core and have a work-stealing scheduler (inspired by Rust's rayon crate) schedule all the individual render/compute jobs, because that allows making a lot more jobs to allow finer load balancing. > Another is to let a SW rasterizer be a SW rasterizer: do > everything immediately, thread only so you can exercise all the CPU > cores, and minimally implement semaphores and fences well enough to > maintain compatibility. If you take the first approach, then we have > to solve all these problems with letting userspace create unsignaled > sync_files which it will signal later and figure out how to make it > safe. If you take the second approach, you'll only ever have to > return already signaled sync_files and there's no problem with the > sync_file finite time guarantees. The main issue with doing everything immediately is that a lot of the function calls that games expect to take a very short time (e.g. vkQueueSubmit) would instead take a much longer time, potentially causing problems. One idea for a safe userspace-backed sync_file is to have a step counter that counts down until the sync_file is ready, where if userspace doesn't tell it to count any steps in a certain amount of time, then the sync_file switches to the error state. This way, it will error shortly after a process deadlocks for some reason, while still having the finite-time guarantee. When the sync_file is created, the step counter would be set to the number of jobs that the fence is waiting on. It can also be set to pause the timeout to wait until another sync_file signals, to handle cases where a sync_file is waiting on a userspace process that is waiting on another sync_file. The main issue is that the kernel would have to make sure that the sync_file graph doesn't have loops, maybe by erroring all sync_files that it finds in the loop. Does that sound like a good idea? Jacob
